Core Web Vitals: preparing for the 2021 page experience signal

Core Web Vitals are a small set of user-centric metrics drawn from the broader Web Vitals initiative. Each has a "good" threshold, and Google evaluates them at the 75th percentile of real page loads, so the slowest quarter of your visitors decides your score.

LCP replaces the older debates about "page load time" with a single question: when did the main thing appear? FID catches pages that look ready but are frozen while JavaScript runs. CLS gives a number to the experience everyone recognizes, where you go to tap a button and an ad or image loads above it and pushes it down.

Google has said the thresholds and the metric set may evolve annually, with notice. For 2020, these three are the targets.

Field data, meaning measurements from real Chrome users, is what the ranking signal will use. Lab data from a tool is useful for diagnosis but does not count. Use both.

1. Search Console's new Core Web Vitals report (replacing the Speed report) groups your URLs into poor, needs improvement and good, for mobile and desktop, based on Chrome User Experience Report field data. Start here; it tells you which templates have a problem.
2. PageSpeed Insights shows field data for a single URL when enough exists, plus a Lighthouse lab run with specific recommendations. Lighthouse 6, released in May, now reports LCP and CLS and uses Total Blocking Time as the lab stand-in for FID.
3. The Web Vitals Chrome extension shows the three numbers live as you browse your own site, which is the fastest way to feel what the metrics mean.
4. Chrome DevTools has a new Performance panel section for layout shifts and the elements that caused them.

Check your top ten landing pages on mobile first. Most sites find that one or two templates, typically the product or article page, account for almost all the poor URLs.

After a few weeks of looking at these reports on client sites, the causes cluster into a short list.

Slow LCP

• Hero images that are 1 to 3 MB, uncompressed, served at desktop size to phones.
• Slow server response. A shared hosting plan or an unoptimized CMS can spend over a second before sending the first byte.
• Render-blocking CSS and JavaScript loaded in the head, including tag managers and chat widgets.
• Web fonts that block text from appearing until they download.

Poor FID

• Large JavaScript bundles from the theme, apps and plugins, all executing on load. Ecommerce themes with a dozen installed apps are the classic case.
• Third-party scripts: analytics, A/B testing tools, heatmaps, social embeds, ad tags.

High CLS

• Images and embeds without width and height attributes, so the browser cannot reserve space.
• Ads, banners and cookie notices injected above existing content.
• Web fonts swapping in and changing text size.
• Content loaded late by JavaScript, such as reviews or recommendations, inserted above the fold.

Work from cheapest and biggest to hardest and smallest.

1. Images. Compress everything, serve responsive sizes with srcset, convert to WebP where supported, lazy-load images below the fold (the native loading="lazy" attribute now works in Chrome and Firefox), and never lazy-load the hero image.
2. Dimensions on everything. Add width and height to images, iframes and video elements. Reserve space for ad slots and embeds with CSS aspect-ratio boxes.
3. Server and caching. Move off underpowered hosting, enable full-page caching, put a CDN in front of the site. Target a time to first byte under 500 ms.
4. Fonts. Self-host where possible, preload the one or two files used above the fold, and use font-display: swap or optional so text appears immediately.
5. Third-party audit. List every script the site loads, name who asked for it and why, and remove what nobody can justify. Defer the rest. This often cuts JavaScript weight by half.
6. Theme and app cleanup. On Shopify, WordPress and similar platforms, uninstalled apps often leave code behind; remove it. Replace heavy page builders on key templates with leaner markup.
7. Code splitting and deferral of your own JavaScript, which is a developer task and belongs last because it is the most expensive per point gained.

Measure after each step with the field data where possible. Chrome User Experience Report data is a 28-day rolling window, so Search Console will lag your changes by about a month.

Google's own guidance is worth repeating because the market is already producing breathless claims. Page experience will be one signal among many. It will matter most where pages are otherwise similar in relevance. Great content with a poor score will still outrank thin content with a perfect one. There is no bonus for exceeding the thresholds; "good" is good enough.

The reasons to act anyway are commercial. Faster, more stable pages convert better, and the data on that is old and consistent: every additional second of load time on mobile costs conversions, and layout shifts cause mis-taps that abandon carts. Google's announcement also said that when the signal launches, the Top Stories carousel on mobile will no longer require AMP, and page experience will be used as eligibility instead, which gives publishers a path off AMP if they can meet the bar.

Act this year if Search Console shows a meaningful share of poor URLs on mobile, if you run ecommerce or lead generation where conversion rate is the business, if you are planning a redesign or replatform anyway (build the standards in rather than retrofitting), or if you are a publisher relying on Top Stories.

You can move more slowly if your pages are already mostly good, if your traffic is dominated by brand searches where relevance is not in question, or if a larger rebuild is already scheduled for early 2021. Even then, fix images and dimensions now; they are cheap.

We handle Core Web Vitals as part of a site's ongoing health rather than a one-off sprint. In discover we pull Search Console and Chrome User Experience Report data, identify which templates are responsible for poor URLs, inventory every third-party script and app, and establish conversion baselines so improvement can be measured in revenue as well as milliseconds. In plan we rank the fixes by impact and cost, decide what belongs in a quick remediation release and what belongs in the next design or platform work, and agree targets per template. In build our web and infrastructure team handles hosting, caching and CDN, image pipelines, font loading, layout reservations and the script cleanup, working with the growth team so that no tracking or campaign depends on a tag that is being removed. In improve we monitor field data monthly, keep the third-party inventory current, and fold the standards into our design system so new pages launch good rather than needing repair.

The connection between teams matters here because most page experience problems are caused by marketing tools, not by developers. When the people adding tags, the people designing pages and the people maintaining the platform share one plan, scores stay good after the project ends.

A representative engagement was a content-led brand whose article template dominated its traffic but showed almost entirely poor mobile URLs once the new Search Console report arrived, driven by a heavy ad stack, unsized images and late-loading related-content modules. We reserved space for every ad slot and embed, rebuilt the image handling, deferred the non-essential scripts and moved the site behind a CDN with full-page caching. Over the following quarter field data moved most article URLs into good, and the same work shortened time on page to first scroll and lifted newsletter sign-ups. The approach is described in our content case study.