The Core Web Vitals guide

Most London business owners meet Core Web Vitals as a red number on a PageSpeed Insights report, usually forwarded by someone selling something. The number is real, but it is often the wrong number to look at, and the fixes proposed are often the wrong fixes. This guide is the version we wish every client had read before the first meeting: what the three metrics measure, where the trustworthy data lives, and what moves each metric on the two platforms most of our clients run.

What the three metrics measure

Core Web Vitals are Google’s chosen measures of page experience. Google says they "are used by our ranking systems", that there is "no single signal", and that good scores do not guarantee a top position because "Google Search always seeks to show the most relevant content, even if the page experience is sub-par" (Understanding page experience). In other words: speed will not rescue a weak page, but a slow page handicaps a strong one, and the people on your site feel it either way.

The thresholds are measured at the 75th percentile of real page loads, separately for mobile and desktop, so a page passes when three in four visits meet the target (web.dev: Web Vitals).

INP is the newest of the three. It replaced First Input Delay as a Core Web Vital in March 2024 because it addresses "many of the shortcomings of First Input Delay (FID)" by measuring every interaction on the page, not just the first (web.dev). If a report you are reading still talks about FID, it is out of date.

How to read PageSpeed Insights without being misled

PageSpeed Insights shows two different things on one page, and confusing them is the most common mistake we see. At the top is field data: what real Chrome users experienced over the "previous 28-day collection period", drawn from the Chrome User Experience Report (CrUX). Below it is lab data: a single simulated load by Lighthouse "in a simulated environment", which produces the performance score out of 100 (About PageSpeed Insights). The score is lab data. Google’s ranking systems use field data. A page can score 55 in the lab and pass every Core Web Vital in the field, and the reverse.

The pass rules are simple: a page passes when "The 75th percentiles of INP, LCP, and CLS are all Good". If there is not enough INP data it passes on LCP and CLS, and if LCP or CLS lack data the page is not assessable (About PageSpeed Insights). Small London sites often see "not assessable" on inner pages: CrUX only reports pages with "a large enough number of visitors in order to create a statistically significant dataset" (Chrome UX Report). When a page has no data, the origin-level data for the whole site is your guide.

Search Console’s Core Web Vitals report groups URLs "into pages that have a similar user experience", so a slow product template shows up as one group rather than four hundred rows, and a group takes the status of its worst metric. After you fix something, start validation; "If this issue is not present in any URLs on your site during the 28-day window, the issue is considered fixed" (Core Web Vitals report). Budget a month to see a change land.

LCP: getting the main thing on screen

LCP "reports the render time of the largest image, text block, or video visible in the viewport". The candidates are images, images inside SVG, video poster frames, elements with a CSS background image, and block-level text containers (web.dev: LCP). On most London business sites the LCP element is the hero image or the hero headline. Find it in the PageSpeed Insights diagnostics ("Largest Contentful Paint element") before you change anything.

web.dev breaks LCP into four parts and suggests how the time should split: around 40 percent waiting for the first byte of HTML (TTFB), under 10 percent resource load delay, around 40 percent downloading the LCP resource, and under 10 percent render delay. These are relative guides, not absolute targets (web.dev: Optimize LCP). Separately, a TTFB of "0.8 seconds or less" is the web.dev "good" threshold (web.dev: TTFB). The fixes follow the parts:

• Cut TTFB: better hosting, server-side page caching, fewer redirects before the page (a visitor who types the domain should reach the final URL in at most one hop), and a CDN close to London visitors.
• Make the hero image "discoverable from the HTML source", as a plain img in the markup, not injected by JavaScript or hidden in a CSS background, so the browser finds it immediately.
• Add fetchpriority="high" to that one image and never to more than one or two; the attribute loses its value when everything is high priority.
• Never lazy-load the LCP image; web.dev says doing so "will always lead to unnecessary resource load delay". Many WordPress themes and plugins lazy-load every image by default, hero included.
• Shrink the resource: serve the hero at the displayed size, in WebP or AVIF, with responsive srcset so a phone does not download the desktop file.
• Remove render-blocking CSS and JavaScript from the head where you can, so the element is not waiting behind a chat widget script.

INP: responding to the tap

INP "assesses a page’s overall responsiveness to user interactions" by looking at clicks, taps and key presses throughout the visit and reporting the worst, after discounting outliers. Scrolling, hovering and zooming are "not observed for the purposes of INP". Each interaction has three phases: input delay, "the time before any callback for an interaction is handled"; processing duration; and presentation delay, "the time after the callbacks have been executed until the frame is presented on the user’s screen" (web.dev: INP).

The usual culprit is JavaScript on the main thread. "Any task that takes longer than 50 milliseconds is a long task" (web.dev: Optimize long tasks), and a page with a dozen third-party scripts has plenty of them. The fixes, in rough order of payoff for a business site:

• Remove scripts you do not use: old chat widgets, heatmaps, a second analytics tag, review carousels, social feeds. Each one runs on every page view whether or not anyone interacts with it.
• Defer what remains so it loads after the page is interactive, and load the heavy things (video embeds, maps, booking widgets) only when the visitor reaches or clicks them.
• Break up long tasks: web.dev advises doing "as little work as possible" in callbacks, yielding to the main thread after the visual update, and using scheduler.yield() where supported (web.dev: Optimize INP).
• Keep the DOM small; "Large DOMs do require more work to render than small DOMs". Page builders that nest every element in six wrappers are a common cause on WordPress.
• Use content-visibility for long pages so the browser is "lazily rendering elements as they approach the viewport" rather than laying out the whole page on every interaction.
• Avoid rendering large blocks of HTML with JavaScript on the client; it blocks the frame the visitor is waiting for.

CLS: stopping the page from jumping

CLS is "a measure of the largest burst of layout shift scores" for shifts the visitor did not cause. Each shift scores as impact fraction times distance fraction: how much of the viewport moved, times how far (web.dev: CLS). The common causes are images or videos "with unknown dimensions", fonts that render "larger or smaller than its initial fallback", third-party ads or widgets that "dynamically resize themselves", and elements "dynamically added to the page before existing content".

• "Always include width and height size attributes on your images and video elements" so the browser reserves the space before the file arrives (web.dev: Optimize CLS).
• Reserve space for anything that loads late (a review widget, a map, a cookie banner, an embedded booking form) with min-height or aspect-ratio, and keep the placeholder if the content fails to load.
• Never inject content above existing content after load: a promotional bar that pushes the page down, a late-arriving notice, a logo that appears once the font loads. Put it lower or trigger it only on a click.
• Use font-display: optional for web fonts where the brand allows it, or choose a fallback with matching metrics and tune it with size-adjust so the swap does not reflow the text.
• Animate with transform rather than top, left, width or height; "Changing the top and left properties also cause layout shifts".

Fixes on WordPress

WordPress itself is rarely the problem; the hosting, the theme and the plugin stack are. The WordPress developer handbook’s own advice is the right order: "Your hardware capability will have a huge impact on your site performance", a page cache so pages are served as static files, a "persistent" object cache, "Deactivate and delete any unnecessary plugins", "A fast lightweight theme will perform much more efficiently", images in "a more modern image format like WebP", a CDN ("most effective if used with a WordPress caching plugin"), a current PHP version and an opcode cache (WordPress Advanced Administration Handbook).

Our WordPress SEO guide covers the rest of the platform. If the theme is the problem, the honest answer is sometimes a rebuild rather than another optimisation plugin; the redesign checklist keeps that from costing rankings.

Fixes on Shopify

Shopify manages the things WordPress owners struggle with: hosting on "fast, global servers", "a world-class CDN at no additional charge", browser caching, compression and minification. What it cannot manage is what merchants add. Shopify’s own guidance says to "remove any that aren’t essential for sales" of your apps, warns that "Uninstalling an app doesn’t automatically remove its code from your theme", to "Avoid adding too many sections to page templates", that "Animations can slow down pages", to "Audit your tag manager to remove any unused or low-value tags", and that poor interactivity usually means "too much JavaScript in your store" (Shopify Help Centre).

The Shopify SEO guide covers collections, variants and the rest.

What speed does for rankings, and what it does not

Three honest statements. First, Google uses Core Web Vitals in ranking, alongside many other signals, and relevance comes first; a fast page about the wrong thing does not rank. Second, moving a page from Poor to Good can produce a visible change where you were otherwise level with a competitor, and usually produces a better conversion rate regardless of ranking, because fewer people give up. Third, moving from Good to very good is for your visitors, not for Google: once a page passes, there is no extra ranking credit for passing harder, and we would rather you spent the budget on content.

London adds one practical point. Your customers search on phones, often on mobile data that drops in and out between stations, in a hurry, near your shop. The 75th percentile measurement captures those visits. A site that feels fine on the office Wi-Fi can be failing for the people who matter, which is why we read field data on mobile before anything else.

A monthly routine

1. Open the Search Console Core Web Vitals report, mobile tab. Note any group that is Poor or Needs improvement.
2. For each group, run one representative URL through PageSpeed Insights and read the field section first. Identify the LCP element and the longest tasks from the diagnostics.
3. Make one change per metric per template. Record what you changed and the date.
4. Start validation in Search Console and check back in 28 days. Do not judge by the lab score the next day.
5. Every quarter, audit apps, plugins and tags: for each one, who uses it, what it costs in milliseconds, and whether it stays.

This is the work our technical SEO service does month by month, with field data in the report so you can check it yourself. We work from the Tower 42 office in the City, by appointment, and visit clients across London. The free review reads your field data and names the three changes that would move it; it does not quote a lab score.

Get your free SEO auditA person reads your Core Web Vitals field data by hand and sends three fixes within two working days. No automated score, no call required.