Core Web Vitals and the three changes that actually move LCP
Google published Core Web Vitals in May 2020 with good thresholds of 2.5 seconds for LCP and 0.1 for CLS. Three changes move LCP on a real site: server response, render-blocking code and hero delivery.
Contents
- Key takeaways
- What the three metrics measure
- The ranking signal is announced, not shipped
- Server response time is the floor
- Render-blocking CSS and JavaScript
- The hero image is usually the LCP element
- Field data decides the score, lab data explains it
- What changed in this update
- FAQ
- Start with the server, then the head, then the image
Updated 22 January 2024 — First Input Delay is being retired as a Core Web Vital and replaced by Interaction to Next Paint.
Core Web Vitals are the three field metrics Google published in May 2020: Largest Contentful Paint, First Input Delay and Cumulative Layout Shift. On a real site, only three changes move LCP by a meaningful margin — faster server response, fewer render-blocking resources in the head, and earlier delivery of the hero image.
Key takeaways
- Google scores Core Web Vitals at the 75th percentile of page loads. The "good" boundary is 2.5 seconds for LCP and 0.1 for CLS.
- The page experience ranking signal was announced on 28 May 2020 and has not launched. Google promised at least six months' notice first.
- LCP has a short list of causes: server response time, render-blocking CSS and JavaScript, resource load time, and client-side rendering.
- Images were 893 KB of the 1,745 KB median mobile page in the 2019 Web Almanac, which is why hero delivery dominates most LCP work.
What the three metrics measure
Google introduced Core Web Vitals through the Chromium blog on 5 May 2020, with an open-source web-vitals JavaScript library for collecting the values from real users. LCP marks when the largest content element becomes visible. FID measures the delay before the browser can respond to a first interaction. CLS quantifies unexpected layout movement during load.
The thresholds are not round numbers picked for a slide. Bryan McQuade and Barry Pollard published the reasoning on web.dev on 21 May 2020, including the case for scoring at the 75th percentile rather than the median.
Google evaluates Core Web Vitals at the 75th percentile of page loads, so three of every four visits meet the target. The "good" boundary for Largest Contentful Paint is 2.5 seconds and the "poor" boundary is 4 seconds (web.dev, 21 May 2020).
The ranking signal is announced, not shipped
On 28 May 2020 Google said Core Web Vitals would be folded into its existing page experience signals to form one ranking factor. It also promised notice before the change took effect. No launch date has been published as of September 2020.
That gap is useful. It lets the work be justified on the ground that holds up commercially. Load time is part of what a business actually buys when it buys a website, not a phase bolted on after launch.
On 28 May 2020 Google announced a combined page experience signal. Core Web Vitals would join mobile-friendliness, safe browsing, HTTPS and intrusive-interstitial checks, with at least six months' notice before rollout (Google Search Central, 28 May 2020).
Server response time is the floor
Nothing paints before the first byte arrives. If the server takes 900 ms to respond, the rest of the page has 1.6 seconds left inside a 2.5-second budget. web.dev's LCP optimization guide, published on 30 April 2020, puts slow server response at the top of its causes.
The fixes are unglamorous. Cache the HTML response, put a CDN in front of it, and delete the redirect chains between the requested URL and the document finally delivered.
Render-blocking CSS and JavaScript
A stylesheet in the head blocks rendering until it downloads and parses. A synchronous script in the head blocks parsing of everything after it. Both delay the paint of the LCP element no matter how fast the image arrives.
Inline the small amount of CSS the first screen needs, load the rest without blocking, and defer scripts not required for the first paint. A brief that names a target Largest Contentful Paint and a measurement date gets this scoped properly. That is one more argument for asking a supplier for outcomes instead of a feature list.
The hero image is usually the LCP element
On most marketing pages the largest content element is a hero image, or a headline sitting on one. Image weight is therefore not a side issue.
In the 2019 HTTP Archive Web Almanac, the median mobile page weighed 1,745 KB. Images were 893 KB of that, more than half the payload (Web Almanac, 11 November 2019).
Four things move hero delivery: compression, a modern format, dimensions matched to the rendered layout, and discoverability in the initial HTML. A hero injected by client-side JavaScript cannot start downloading until the framework has run.
Field data decides the score, lab data explains it
Lighthouse runs one simulated load on one device profile. Core Web Vitals are scored on what real visitors experienced, split between mobile and desktop. When the two disagree, the field data counts.
Instrument the site with the web-vitals library and send the values into the analytics tool that already exists. Deciding that before the build rather than after it is one of the questions that decide whether a project fails.
What changed in this update
Google announced on 10 May 2023 that Interaction to Next Paint would replace First Input Delay as the responsiveness Core Web Vital. INP moved from experimental to pending, with the swap due in March 2024. It measures interaction latency across the whole visit rather than only the first interaction, and its "good" threshold is 200 ms at the 75th percentile (web.dev). The LCP guidance here is unchanged, including for teams choosing between Jamstack and WordPress.
FAQ
What counts as a good LCP score?
2.5 seconds or less, measured at the 75th percentile of real page loads and split between mobile and desktop. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor. A single lab run is a diagnostic, not the number Google evaluates.
Do Core Web Vitals affect Google rankings yet?
Not yet. Google announced on 28 May 2020 that they would join the existing page experience signals, and committed to at least six months' notice before the change took effect. As of September 2020, no launch date has been published.
Which change should we make first?
Measure server response time. If time to first byte is high, nothing in the browser compensates for it. Then remove render-blocking resources from the head, then fix hero image delivery. Reversing that order produces work that never shows up in field data.
Start with the server, then the head, then the image
Fix server response first, remove render-blocking resources second, change image delivery third. Anything else is measurement theatre until those three are settled. Six months of field data will show whether the 75th percentile moved, and a site collecting no field data today has already found its first task.
