Website performance monitoring Website performance monitoring should track real user tasks, key page types and clear change over time.
A 200-millisecond homepage tells you very little about whether anyone can actually book. It can also look fast on an office laptop and feel unresponsive on the phones visitors actually use. Performance monitoring needs both technical timing and evidence that priority journeys complete.
Begin by naming those journeys: finding a service, submitting an enquiry, buying a product, signing in or downloading a document. The dashboard should help an owner answer whether people can complete them now and what changed when they cannot.
Separate availability from correctness
An uptime check confirms that a URL returns an expected response. It does not prove search works, prices are current or an email arrived. Monitor the public page, then add synthetic tests for the few transactions that matter most.
Use safe test accounts and non-chargeable payment methods where needed. A test should verify the result, such as a lead record or confirmation state, rather than stopping after a button click.
Measure real user experience
Core Web Vitals describe three aspects of page experience. Largest Contentful Paint measures loading, Interaction to Next Paint measures responsiveness and Cumulative Layout Shift measures visual stability.
Google’s current guidance defines good thresholds as LCP within 2.5 seconds, INP at 200 milliseconds or less and CLS at 0.1 or less. Assess the 75th percentile separately for mobile and desktop rather than averaging fast and slow visits into a comfortable number.
Field data reflects real devices, networks and interactions. Lab tests remain valuable before release because they are controlled and repeatable. They are not a replacement for field measurement, especially when diagnosing responsiveness.
Keep diagnostic timings beside the outcome
Track server response time, failed requests and large asset changes to investigate a poor experience. Navigation Timing exposes browser milestones for a document request. resource data can help identify slow images, scripts or fonts.
Do not report every available metric to directors. Connect diagnostics to the affected page type or journey. A slow third-party script matters when it blocks checkout. the same delay on an unused widget has a different priority.
Monitor application and integration failures
Count server errors, validation rejections, form delivery failures, payment declines and API exceptions separately. A rise in expected customer validation errors may indicate confusing copy. a rise in server errors needs technical investigation.
Use a correlation or request identifier to follow one transaction across services without placing unnecessary personal data in logs. Track queue age and retry volume so delayed work does not appear healthy merely because it eventually completes.
Set alerts around action
An alert needs an owner, threshold, evaluation window and first response. Alerting on one slow request creates noise. Alerting when the priority journey fails repeatedly or its normal range materially shifts is more useful.
- Urgent: checkout, login or enquiry submission is unavailable.
- Investigate: failure rate or latency remains above its agreed range.
- Review: a page group’s field experience trends down over several releases.
- Capacity: queues, storage or provider limits approach a safe boundary.
- Housekeeping: monitoring agents, certificates or test credentials need renewal.
Add release and business context
Mark deployments, campaign launches, catalogue imports and provider incidents on the timeline. Without change context, a team wastes time rediscovering that a new banner doubled the largest image or a campaign changed the traffic mix.
Compare like with like. Separate page types, device classes and important regions. Low-traffic pages may lack enough field data. combine representative lab tests with direct journey monitoring rather than inventing confidence.
Review a short weekly scorecard
A useful business view can fit on one page: journey availability, valid completion count, error rate, Core Web Vitals status, open incidents and notable changes. Link to technical detail instead of crowding the summary.
For each failure, record impact, duration, cause, correction and prevention owner. The aim is not a permanently green chart. It is faster detection, honest prioritisation and fewer repeated faults.
When everything was green and nothing worked
An online pharmacy’s uptime monitor showed 100% availability across a Monday. Checkout revenue for the day was down 70%.
The monitor was requesting the homepage and checking for a 200 response. The homepage was fine. The payment provider’s script had begun failing to load for anyone on a particular mobile network. the card fields never rendered and the pay button did nothing. No server error was raised, because nothing on the server had gone wrong.
Two changes caught the next one within nine minutes. A synthetic check now completes a real test transaction every fifteen minutes rather than fetching a page. And a business-context alert fires when completed orders in an hour fall below a floor set from the same hour in previous weeks. Availability was never the thing worth watching.
Sources and further reading
- web.dev guidance on Web Vitals — the source for current metrics, thresholds, percentiles and the distinction between field and lab measurement.
- Google Search Central: Core Web Vitals — Google’s current search documentation for page-experience measures.
- W3C Navigation Timing Level 2 — the current working draft defining browser access to document navigation timing information.
Our website maintenance service can build a monitoring plan around the transactions and response process a business actually owns.
Quick website performance monitoring action plan
- Choose key page types first. Write down the result. Name one owner.
- Track phone and desktop results. Test this step. Keep proof of the test.
- Watch load and layout shifts. Use real data. Check each fact.
- Check real user field data. Ask one user. Note what feels hard.
- Test after each release. Fix each fault. Run the check again.
- Link faults to recent changes. Set a due date. Review the result.
- Keep an agreed baseline. Write down the result. Name one owner.
- Review trends each month. Test this step. Keep proof of the test.
- Choose one clear goal. Use real data. Check each fact.
- Name the owner for each task. Ask one user. Note what feels hard.
- Test the full path before launch. Fix each fault. Run the check again.
- Set the next review date. Set a due date. Review the result.
- Keep the plan where staff can find it. Write down the result. Name one owner.
- Use plain words in each note. Test this step. Keep proof of the test.
- Save proof for each key check. Use real data. Check each fact.
- Fix one issue at a time. Ask one user. Note what feels hard.
- Check the result with a real user. Fix each fault. Run the check again.
- Remove work that does not help the goal. Set a due date. Review the result.
- Share each major change with the team. Write down the result. Name one owner.
- Run the same checks after each update. Test this step. Keep proof of the test.
- Check the source of every key fact. Use real data. Check each fact.
- Keep private data out of public notes. Ask one user. Note what feels hard.
- Plan what to do when a check fails. Fix each fault. Run the check again.
- Give each choice a clear reason. Set a due date. Review the result.
- Keep old files until new work is proven. Write down the result. Name one owner.
- Ask for help when the risk is high. Test this step. Keep proof of the test.
- Check phone and desktop views. Use real data. Check each fact.
- Make the next step easy to find. Ask one user. Note what feels hard.
- Track the result that matters most. Fix each fault. Run the check again.
- Close each task when proof is saved. Set a due date. Review the result.
Use this website performance monitoring plan as a live check. Keep the notes short. Review the work after each major change.
