[Blog]()Website performance # 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. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** Before redesigning, measure a business-critical page and task on mobile and desktop. Separate lab data from real experience, identify the main problem and test a specific correction. Verify browsing, navigation and contact still work; a score change does not establish more sales. ## 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. [Download CSV worksheet]() In this guide - [Start with the page your buyer uses]() - [Connect each metric to a specific difficulty]() - [Fictional example: lab score 93 with mobile issues]() - [Fix what explains the observed problem]() - [Check experience and business outcomes separately]() ## 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. ## Review the page your buyer needs Your critical page and dated reports help discuss which problem affects the buyer’s task. In a free consultation, review page versus origin scope, device, and the resources that must remain when prioritizing a correction. - Critical page and the buyer's task - Dated reports with device and page/origin scope - Resources or integrations that must remain during correction [Book a free consultation]()[Ask on WhatsApp]() Related - [Websites and online stores]() - [Software consulting]() ## Frequently asked questions ### Does a score of 100 guarantee speed? 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. ### When should real data reflect a change? 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. ### Should we redesign when real data is missing? 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. ### Can improved Core Web Vitals promise sales? 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 1. [Web Vitals]()web.dev / Google 2. [About PageSpeed Insights]()Google Last updated: October 8, 2026 ## Keep reading [Inquiry measurementOct 8, 2026 ### Measuring website inquiries: useful contacts, appointments and verified sales]()[Website formsOct 8, 2026 ### Website forms: filtering spam without losing customer inquiries]()[GuidesOct 4, 2026 ### How much does a website cost in Mexico? (2026)]() --- Canonical: https://nightlysoftware.com/en/blog/website-core-web-vitals-priorities Updated: 2026-10-08 Description: Separate lab tests from real experience, choose a critical page and check improvements without breaking inquiries. Includes a performance worksheet.