Analyzing website performance metrics
A useful performance report shows whether visitors can load your important pages, use them comfortably and complete the tasks that matter to your business. Start with a small set of measurements, understand where the data comes from and turn each finding into an action with an owner.
A single speed score cannot explain every slow visit or lost enquiry. This guide separates loading, responsiveness, availability and business outcomes so you can decide what to investigate without treating every dashboard number as a problem.
1. Start with a customer task and a measurable question
Choose a few representative pages: a campaign landing page, a service page, a product page and the route to an enquiry or purchase. Include mobile visitors and pages built from different templates. Testing only the homepage can miss a heavy product gallery or a slow booking widget.
Write down what you want to learn. For example: does the main product image appear promptly on mobile, can visitors open the menu without a delay, and do completed enquiry forms reach the right team? Each question needs a suitable measurement and a way to verify the result.
Keep technical quality and business outcomes connected but distinct. A slow page may deserve attention even when sales rise during a promotion. A fall in enquiries could come from tracking changes, a different audience or an unavailable service. Look for evidence before attributing either result to speed.
2. Read the current Core Web Vitals
Google’s Core Web Vitals guidance focuses on loading, responsiveness and visual stability. These are the current “good” thresholds:
| Metric | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | When the largest eligible content element in the viewport is rendered | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to user interactions during a visit | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Unexpected movement of visible page elements | 0.1 or less; this is a score, not seconds |
Evaluate the 75th percentile separately for mobile and desktop. This means looking beyond the average: at least 75% of the measured experiences should meet the good threshold for each metric. Record any missing metric data instead of treating it as zero. INP is the current responsiveness metric; older First Input Delay guidance is no longer the Core Web Vitals standard.
Use other measurements to investigate causes. Time to First Byte (TTFB) concerns the wait for the first response byte, not the time until the page is usable. First Contentful Paint (FCP) concerns the first content rendered, not necessarily the main content. Transfer size and request details help explain the work required to load a page; fewer requests alone do not prove a better experience.
3. Separate real visitor data from a lab test
PageSpeed Insights combines real visitor data from the Chrome User Experience Report with a Lighthouse lab test. Its field view covers a rolling 28-day period. Check whether the result describes the specific URL or the broader origin: origin data can include other pages on the same scheme, host and port.
If a URL does not have enough eligible data, PageSpeed Insights may show origin data instead. Sometimes neither has sufficient coverage. “No data” does not mean the site passed or failed. Read the assessment’s available metrics; when INP data is insufficient, the displayed assessment can use LCP and CLS. Keep that limitation visible in your notes.
A lab test runs under particular device and network conditions. It is useful for diagnosing a page and checking a proposed change. It is not a summary of all visitors. A fresh lab result can improve while the field view still includes weeks of earlier visits.
Record the URL, date, test settings and whether a result is field or lab data. Compare several runs under similar conditions rather than picking the best score. Test results can vary with server load, network conditions and third-party content. Avoid comparing a desktop lab run with a mobile field report as if they measured the same thing.
4. Give each tool a specific job
Use PageSpeed Insights to review available field information and an initial lab diagnosis. Use Chrome DevTools to inspect requests and investigate rendering or JavaScript activity. Lighthouse findings should lead to a question about the page, not a demand to change every flagged item without checking its purpose.
A normal Lighthouse navigation run does not exercise the page like a real visitor clicking through it. Total Blocking Time can help diagnose responsiveness during loading, but it is not interchangeable with INP. Test important interactions deliberately, and use real-user measurement when you need evidence across actual visits.
Use Search Console’s Core Web Vitals report to review groups of URLs with similar experience, then inspect representative pages. Use GA4 for recorded engagement and business events. Server logs and hosting metrics help explain response errors or resource pressure. These sources answer different questions; one dashboard does not replace the others.
Keep page availability in the uptime and reliability checklist. A page that occasionally loads quickly can still be unreliable, and an always-reachable page can still be difficult to use.
5. Interpret GA4 engagement and key events correctly
In GA4, bounce rate is the percentage of sessions that were not engaged. An engaged session lasts longer than ten seconds by default, includes a key event, or has at least two page or screen views. The engagement timer can be configured. This differs from treating every single-page visit as a bounce. Check Google’s engagement and bounce-rate definitions before comparing older reports.
For a useful action such as a completed enquiry, define the event around confirmed success. A button click alone may not establish that the form was submitted or received. Test that successful actions are recorded once and that errors do not trigger the same success event. Keep customer details and free-text form content out of analytics events.
Specify the denominator when reporting a rate. GA4’s session key event rate is sessions containing a key event divided by total sessions. If 20 of 1,000 sessions include the selected successful action, the rate is 2%. That is an arithmetic example, not a measured result for this website. Multiple events in one session do not create multiple successful sessions.
Compare like-for-like periods and segments: device, landing page and traffic source can change the picture. Note campaigns, seasonality, consent choices, tracking changes and missing data. Analytics only reflects what its setup can observe; reconcile important outcomes with appropriate operational records before drawing a business conclusion.
6. Prioritize the cause, then verify the change
Choose work based on affected visitors, the importance of the page, the strength of the evidence and implementation effort. A shared template problem across key pages may be more useful to address than a small score improvement on a rarely visited page. Assign a responsible person and define what should improve before making the change.
For slow LCP, inspect the actual LCP element and its request timing. Investigate response delay, image size, resource discovery and render delay as separate possibilities. LCP optimization guidance explains why changing image format alone may not address the cause.
For poor INP, reproduce the slow interaction and inspect the work occupying the browser’s main thread. Heavy scripts, long tasks or expensive updates may be involved. Use the INP optimization guidance to investigate before removing functionality. For CLS, look for content appearing without reserved space, missing image dimensions or other unstable layout behavior; the CLS guidance provides diagnostic starting points.
Check the changed page in staging, then verify the live release under comparable conditions. Confirm that menus, forms, accessibility and checkout still work. Keep a rollback route. A higher score is not an improvement if a necessary customer function has broken.
7. Work through a slow-page example
Illustrative example: mobile visitors report a slow service page with a booking widget. Work through the issue in a sequence that separates observation from explanation:
- Establish the scope. Record the affected URL, device conditions, recent changes and the task visitors are trying to complete.
- Collect a baseline. Save available field metrics and repeat a comparable lab test. Mark origin-level or missing data clearly.
- Investigate one finding. If request timing suggests the main image arrives late, investigate that path. If the delay occurs when opening the widget, inspect that interaction separately.
- Make and test a focused change. Have the developer verify the suspected cause, apply the change safely and check the full booking flow.
- Review the evidence. Compare lab diagnostics after release, watch subsequent field data and review correctly recorded bookings over an appropriate period. Record remaining uncertainty.
The useful output is an evidence-backed task and a verified result. Do not turn an estimated saving in a diagnostic tool into a claim that your visitors or business already achieved it.
8. Keep a small monthly website health report
Use this template with your own measurements. Enter “not available” where evidence is missing, and keep links to the original reports so someone else can understand the comparison.
| Report item | What to record | Decision it supports |
|---|---|---|
| Scope and changes | Dates, URLs, devices, campaigns, releases and tracking changes | Whether periods are comparable |
| Real visitor experience | LCP, INP and CLS at the 75th percentile, field period and URL/origin scope | Which page groups need investigation |
| Lab diagnosis | Tool/settings, repeated results and the specific bottleneck | What the developer should inspect next |
| Availability | Failed checks, affected functions, duration and response notes | Whether detection or recovery needs work |
| Business outcomes | Defined key event, successful sessions, total sessions and rate | Whether recorded customer tasks are completing |
| Actions and verification | Owner, due date, change, validation result and remaining gaps | What to do next and whether to keep the change |
Review the pattern rather than demanding every number improve each month. Keep unresolved causes visible and recheck after major releases or campaigns. A report that produces one useful action is better than a larger collection of unexamined scores.
InterProWebHost Website Monitoring provides availability, response-timing, SSL, DNS and page-content signals, with plan-dependent alerts and full-site checks. Use those observations alongside browser experience and analytics data. Network or response timing is not the same measurement as LCP or INP, and monitoring does not automatically repair a slow page. Confirm coverage and who will act on findings before relying on the service.
Frequently asked questions
Is a PageSpeed score of 100 necessary?
Treat the score as a diagnostic summary, not the business goal. Improve the experience on important pages and verify useful functions. Google’s page-experience guidance makes clear that good scores do not guarantee top search rankings.
Why do mobile and desktop results differ?
They can represent different devices, networks, layouts and visitor behavior. Lab tests also use different settings. Compare each segment consistently instead of averaging away a mobile problem.
Why is there no field data for my URL?
There may not be enough eligible observations for the report. Check whether origin data is available and label it as broader evidence. Use lab diagnostics and suitable real-user measurement without calling missing data a pass or failure.
Does a high bounce rate prove the page is slow?
No. GA4 bounce rate depends on engagement criteria and tracking setup. Audience, intent and content also matter. Investigate the page experience and customer task instead of diagnosing speed from bounce rate alone.
When should I expect field results to change after an update?
PageSpeed Insights uses a rolling 28-day field window, so earlier experiences remain in the data as newer observations arrive. Check the release in the lab immediately, then review field trends with the deployment date recorded.
Will faster pages guarantee more sales or enquiries?
No. Better performance can remove friction, but the offer, audience, content and successful tracking also influence recorded outcomes. Measure the result and avoid claiming causation from a single before-and-after comparison.
