Why is your website slow?

If the main content appears late, check LCP. If buttons respond late, check INP. If text and buttons move around, check CLS. These are the three Core Web Vitals: loading, responsiveness and visual stability. A problem with one does not necessarily mean the whole page loads slowly. Images, the server response, JavaScript or fonts may be responsible.

What do the three metrics measure?

Google publishes three ratings for each metric: good, needs improvement and poor. First identify which metric falls outside the good range. Each points towards a different problem.

Largest Contentful Paint (LCP) measures when the largest visible image, text block or video appears. A good result is 2.5 seconds or less. Above 2.5 and up to 4 seconds needs improvement; above 4 seconds is poor.

LCP has four parts: time to first byte (TTFB), the wait before the required resource starts downloading, the download itself and the delay before it is rendered. Text using a system font may need no separate resource download. A smaller image will not solve the whole problem if the browser still waits for JavaScript before displaying it.

Interaction to Next Paint (INP) measures responsiveness to interactions such as a click, tap or key press, through to the next screen update. A good result is 200 milliseconds or less. Above 200 and up to 500 milliseconds needs improvement; above 500 milliseconds is poor.

Cumulative Layout Shift (CLS) measures unexpected movement of page elements. It is a score without a unit, rather than a time in seconds. Shifts can happen after the initial page load too. A good result is 0.1 or less. Above 0.1 and up to 0.25 needs improvement; above 0.25 indicates poor visual stability.

Real-user assessment uses the 75th percentile, separately for mobile and desktop. When that result is in the good range, at least 75% of recorded visits meet the relevant threshold. One fast test on your own computer does not describe every visitor.

How does this relate to Google ranking?

Google uses Core Web Vitals in its ranking systems. Good results do not guarantee a top position. Content still needs to be useful and relevant to the search; no single metric determines the position on its own.

Fix measured problems because they make the page harder to use. An improvement in LCP, INP or CLS does not establish a promise of a particular ranking, traffic increase or more enquiries.

Where can the delays come from?

Four groups of causes covered in web.dev’s documentation provide a starting point. Check them against the particular metric and page.

Heavy images. A file may be larger than the screen needs, or its download may start late. Check dimensions, compression, WebP or AVIF formats and when the browser discovers the resource. An image CDN is an option for suitable cases, rather than a required fix for every site.
A slow time to first byte. TTFB includes the wait before the first data arrives. The server, network, redirects and cache can all matter. Check whether URL parameters, such as utm_, interfere with caching too. A high TTFB leaves less time for the remaining parts of LCP.
Too much work on the main thread. Long JavaScript tasks can delay the response to an action. Keep the work needed for the next screen update in the handler and defer other work to later tasks where appropriate for the code.
Fonts that delay text or shift the layout. Check requests, loading time, the fallback font and font-display. WOFF2 and subsets containing the required characters can reduce transferred data. A subset must retain the characters actually used by the site’s languages.

Real-user data or a lab test?

Field data describes use across different devices, networks and interactions. PageSpeed Insights can show this data from the Chrome User Experience Report (CrUX) where it is available. Check whether it describes the specific URL or the whole origin. Insufficient URL-level data is neither a good nor a poor result.

A lab test helps reproduce a problem and check a change. The usual Lighthouse page-load test measures LCP and CLS, but does not measure INP without interaction. Its Total Blocking Time (TBT) can help diagnose responsiveness problems; it is not measured real-user INP. Record the type of data alongside the result.

Questions

Are the thresholds the same for mobile and desktop?

Yes. The numerical thresholds are the same, but results are reported separately. A page can meet the good range on desktop and miss it on mobile.

Does a faster page necessarily rank above a more relevant one?

No. Core Web Vitals contribute to the assessment, but a good result does not guarantee a higher position than a page with more relevant content.

Why does TTFB matter when it is not one of the three main metrics?

It is the first part of LCP. If the first data arrives late, there is less time left to download and display the main content. That makes TTFB useful when finding the cause.

Do we need to remove all web fonts?

Not necessarily. You can reduce requests, use a system font or a suitable variable font, and serve the required characters in WOFF2. Check loading and font-swap behaviour before abandoning the font.

Sources

Measure the pages your customers use

A Website Review measures LCP and CLS on key pages, on mobile and desktop. It adds INP where Google has data from real visitors. You receive a Fix List ordered by severity.

Request a Website Review

or write to contact@ergostrat.com