A slow website: what to measure and fix before redesigning
A high score does not prove customers can browse and contact you quickly. Check page, device and data scope.
Test worksheet: Slow websites: Core Web Vitals priorities
A high score does not prove customers can browse and contact you quickly. Check page, device and data scope. Record inputs, expected outcome, evidence, owner and observed result.
Start with the page your buyer uses
A distributor may lose inquiries when product listings appear slowly; a service company needs its scope to be readable and contact easy to find. Choose a route and task with a test device and connection. The homepage may work while the product page shared by sales loads a huge image or a form that blocks interaction.
PageSpeed Insights distinguishes lab data from real CrUX experience over a 28-day window. Without enough page samples, it may show origin-level data or no real data. Preserve that scope: a simulated test and a whole-site aggregate are not equivalent measurements of the page being corrected.
Connect each metric to a specific difficulty
web.dev describes LCP for loading, INP for responsiveness and CLS for visual stability. Good-experience thresholds are LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, assessed at the 75th percentile separately for mobile and desktop. Use these as technical references, rather than ranking or sales promises.
| Metric | What a customer may notice | What to review first |
|---|---|---|
| LCP | Main content appears late | Main image, initial response and critical resources |
| INP | A control responds slowly after a tap | Interaction work and JavaScript tasks |
| CLS | Content or buttons move during use | Reserved space for images, ads and fonts |
| Form outcome | Uncertainty about inquiry receipt | Receipt and confirmation as well as speed |
Fictional example: lab score 93 with mobile issues
In this example a catalog page has a lab score of 93. Its real mobile sample shows 75th-percentile LCP of 3.4 seconds, INP of 250 milliseconds and CLS of 0.04. LCP and INP miss the cited thresholds despite the favorable lab result. These synthetic values are neither Nightly website measurements nor conversion forecasts.
Review finds an oversized main image and unnecessary work in a filter interaction. The proposal is to correct one cause at a time and repeat the same journey. An immediate test may show improved lab results; the real-data window does not completely change then. Record both observations without representing one as the other.
| Case | Expected result | Evidence |
|---|---|---|
| Measure critical page on mobile | Identified route, device, connection and scope | Report and date |
| Real data available only for origin | Visible limitation, no page-specific claim | Report scope |
| Optimize main image | Readable content and suitable resources without material visual loss | Same-journey comparison |
| Reduce filter work | Correct result and verified responsiveness | Interaction and comparable test |
| Reserve image space | Loading does not move the contact button | Visual journey |
| Submit inquiry after optimization | Receipt and confirmation still work | Test inquiry reference |
Fix what explains the observed problem
Do not remove a resource merely because a report lists it. Review its purpose: an image may show a finish the buyer needs, and an integration may manage appointments. Define the change, expected result and a way to return to the earlier version if the task breaks. Changing everything at once makes it hard to tell what helped.
Repeat comparable tests and retain variation, especially when isolated results fluctuate. Cache, device, connection and service load affect observations. Without enough real data, state the limitation and use controlled tests for diagnosis. Do not invent business percentiles from one execution.
Check experience and business outcomes separately
Metrics may improve while a page still explains its product poorly. Connect performance with easier buying, qualified inquiry measurement and forms that retain inquiries. For operating interfaces, see business software design.
The worksheet includes ten tests without measured data. Bring the critical page, buyer journey and dated reports to a free consultation on websites. We can review correction priorities or whether part of the experience needs changing before considering a full redesign.
Frequently asked questions
Not for all users or tasks. A score depends on a particular test. Review actual data where available, device, page and journey. Also verify interaction and inquiry receipt, which can fail despite a favorable loading audit.
PageSpeed Insights uses a 28-day CrUX window. A correction does not instantly replace that entire sample. Keep change date and scope and distinguish immediate tests from later observation.
Not for that reason alone. The sample may be insufficient. Run controlled diagnosis of critical tasks and state the limitation. A redesign needs to explain what it solves better than a resource or interaction correction.
Technical improvement alone does not establish commercial causality. Measure useful inquiries and sales with suitable definitions and periods. Content, offer, follow-up and other changes also matter; avoid assigning an unverified outcome to performance metrics.
Sources
- Web Vitalsweb.dev / Google
- About PageSpeed InsightsGoogle
Last updated: