A homepage can return in 200 milliseconds while the booking form fails for every customer. 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, while 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, while 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, so 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.
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.
Xapner’s website maintenance service can build a monitoring plan around the transactions and response process a business actually owns.