Why a fast website is still important

Performance is part of the service you provide

A website should help someone complete a task, not merely display a polished design. When reviewing performance, start with the work a visitor is trying to do: read a service explanation, compare products, open a menu or submit an enquiry. Ask whether the page becomes useful promptly, responds to input and stays visually stable while that task is under way.

Google’s Web Vitals initiative provides metrics for important aspects of user experience. Its Core Web Vitals focus on loading, interactivity and visual stability. These measures give business owners and developers a shared language for some common problems, but they are not a complete assessment of whether a website is useful, accessible or commercially effective. ^[1]

Avoid building a business case around an unsupported claim that each fraction of a second produces a fixed revenue increase. Your priorities should come from the actual website, its users and the journeys that matter. The practical aim is a more dependable experience, supported by measurement, not a universal promise about conversion or ranking gains.

Know the three current Core Web Vitals

Largest Contentful Paint, or LCP, measures loading performance by identifying when the main content has likely loaded. The good threshold is 2.5 seconds or less. Interaction to Next Paint, or INP, measures responsiveness; its good threshold is 200 milliseconds or less. Cumulative Layout Shift, or CLS, measures visual stability, with a good threshold of 0.1 or less. ^[1][2]

CLS is a unitless score, not a duration. For all three metrics, the threshold assessment uses the 75th percentile of page views. Google’s guidance recommends assessing this separately for mobile and desktop. In practical terms, a single quick test on an office connection does not establish that the website meets the real-user thresholds. ^[1][2]

The poor thresholds are LCP above 4 seconds, INP above 500 milliseconds and CLS above 0.25. Values between the good and poor boundaries need improvement. Keep the exact boundaries in your reporting: a value of 200 milliseconds for INP meets the good threshold, while 500 milliseconds does not fall into the poor category until it is exceeded. ^[2]

• LCP: good at or below 2.5 seconds; poor above 4 seconds.
• INP: good at or below 200 milliseconds; poor above 500 milliseconds.
• CLS: good at or below 0.1; poor above 0.25.
• Assess the 75th percentile rather than relying on an average.

Replace outdated FID reporting with INP

Interaction to Next Paint replaced First Input Delay, or FID, as a Core Web Vital on 12 March 2024. If your current dashboard still presents FID as the active responsiveness metric, ask for it to be updated. Historical FID records may have context, but they should not be presented as the current Core Web Vitals assessment. ^[3]

The change matters because FID did not capture aspects of interactivity that INP was introduced to measure. INP considers responsiveness through interactions across a visit rather than serving as a simple renamed version of the older measure. Do not compare an old FID number with a new INP number as though both described precisely the same experience. ^[3][1]

Give your developer a list of interactions to investigate: opening navigation, choosing a product option, applying a filter and submitting a form, for example. Include the actions specific to your website. A performance review should reproduce meaningful tasks, not stop at watching the first screen load without touching anything.

Combine real-user evidence with controlled testing

Field data describes experiences observed from real users; lab testing provides controlled conditions for diagnosis and repeatable checks. Web.dev recommends both, with field measurement capturing variations that a laboratory environment cannot fully represent. Use the distinction when reviewing a report: a good controlled test does not automatically prove a good experience across your audience. ^[1]

PageSpeed Insights can surface field data from the Chrome User Experience Report alongside diagnostic information. Web.dev also discusses real-user monitoring as a way to measure experiences on your own site. Ask which evidence is available for the pages you care about and make the limits explicit if the report cannot show an adequate page-level picture. ^[1][3]

Choose representative templates, not only the homepage. Include a main service page, a content-heavy page and a key transactional journey where relevant. Agree the test conditions and record them so that a later comparison is meaningful. Avoid comparing unrelated pages or different testing setups and attributing the entire difference to one code change.

Prioritise fixes around the affected experience

Use the metric as a starting point for diagnosis, not as the diagnosis itself. If LCP is weak, ask which content element is being measured and what delays it. If INP is weak, investigate the interactions visitors actually use. If CLS is weak, reproduce the unexpected movement and identify what triggers it. Request a specific finding before approving a generic speed package.

Possible investigation areas include image delivery, script execution, page structure and space reserved for content. Treat these as questions for the developer to test, not an assertion that every site has the same bottleneck. Hosting is one area to examine where the evidence points towards delivery delays; a hosting upgrade should not be sold as a universal fix for every metric.

Turn each confirmed issue into an acceptance criterion. For example, specify that a known layout movement must no longer occur during a defined journey, then verify it after deployment. Where a metric is the target, record the starting measurement, the testing conditions and the follow-up evidence. Keep functional checks in the same release plan.

Make performance an ongoing responsibility

Google says its ranking systems seek to reward good page experience and recommends looking beyond one or two aspects. Its guidance includes security, mobile presentation and avoiding intrusive experiences as well as Core Web Vitals. A good performance report is therefore not permission to ignore unclear content, broken forms or a difficult mobile layout. ^[4]

Build performance checks into routine changes. Before adding a new campaign component, tracking tool or interactive feature, agree how it will be tested and who will review the result. This is a governance recommendation: it helps your team make the trade-off visible rather than assuming that every additional feature arrives without a cost to the experience.

Finish the review with a short action plan rather than an isolated score. The plan should identify the affected journey, the evidence, the responsible person and the next check. That gives performance work a useful place in ordinary website maintenance without suggesting that a perfect score guarantees rankings, enquiries or commercial success.

• Check LCP, INP and CLS using the current thresholds.
• Replace obsolete FID-led reporting with current INP assessment.
• Review field evidence and document any gaps.
• Diagnose problems on representative pages and interactions.
• Retest functionality as well as performance after changes.
• Assign ownership and repeat checks after significant releases.