Core Web Vitals explained. The three metrics, the thresholds and what Google actually measures.

What Core Web Vitals are

Core Web Vitals are three performance measurements Google introduced in 2020 as part of the Page Experience initiative. The three are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Each one captures a different aspect of the load experience: how fast it visually loaded, how fast it responds to input, and how stable the layout is while loading. Together they form the closest thing the industry has to a standardised "is this page actually nice to use" score.

The metrics replaced a long list of older speed indicators (Time to First Byte, First Contentful Paint, Speed Index, Total Blocking Time) that were technically informative but did not reflect the felt experience well. A page can have a slow TTFB and still feel fast if the visible content paints quickly. A page can have a fast FCP and still feel terrible if the hero image flashes in at 4 seconds. Core Web Vitals were designed to fix that mismatch by measuring what users actually perceive.

Google folded Core Web Vitals into the ranking system in 2021 under the Page Experience update. The signal is small (we cover the honest framing in the pillar guide) but it is confirmed and has stayed in the system across multiple algorithm updates. INP replaced First Input Delay in March 2024 as the responsiveness metric, but the broader three-metric structure has not changed.

LCP in detail

Largest Contentful Paint measures the render time of the largest content element visible in the viewport during initial page load. The "largest" is calculated by pixel area within the visible window, not by HTML semantics. The element type is usually an image, a video poster, a background image, or a block-level text node such as a hero headline. Most Perth client sites we audit have the LCP element being a hero image at the top of the homepage.

The threshold to pass is 2.5 seconds or less. Between 2.5 and 4.0 seconds is Needs Improvement. Over 4.0 seconds is Poor. The number Google uses is the 75th percentile of real-user data across mobile and desktop, which means the slowest quarter of your visitors define your score. A site can have a beautiful 1.8-second median LCP and fail the metric if a tail of mobile users on patchy connections hits 5 seconds.

Common LCP failure modes in 2026:

• Oversized hero image. A 4MB JPG served full-resolution to a 400px-wide phone. The fix is correct format (WebP or AVIF), correct dimensions via srcset, and fetchpriority="high" on the image tag. See image SEO and LCP optimisation.
• Render-blocking resources. Render-blocking CSS and JavaScript in the document head delay everything underneath. The fix is to inline critical CSS, defer non-critical scripts, and preload the LCP image.
• Slow Time to First Byte. A cheap shared host with no CDN and a heavy CMS database query can deliver the HTML in 2 seconds before anything paints. The fix is server-side caching, a CDN, and reducing the work done in the request-response cycle.
• Late-discovered hero image. If the hero image is referenced inside a CSS file, the browser only discovers it after the CSS arrives and parses. The fix is to either inline the image reference, use a <link rel="preload"> hint, or move it into the HTML markup.

INP in detail

Interaction to Next Paint measures the latency between a user interaction and the next visible update to the screen. Interactions include taps, clicks and key presses, but not scrolling and not hovering. The metric records the time from the user action to the browser actually painting the visual response.

The threshold to pass is 200 milliseconds or less for the worst observed interaction during the session (technically the 98th percentile interaction for sessions with many interactions, but for most pages it is the single worst one). Between 200 and 500ms is Needs Improvement. Over 500ms is Poor.

INP replaced First Input Delay in March 2024 because FID was too easy to game. FID only measured the input delay for the very first interaction on a page, and only the delay until the browser started processing the event (not the time to actually paint the result). INP measures the full round trip on every interaction, which is much more honest.

The result of the FID-to-INP transition is that many sites that passed FID now fail INP. The culprit is almost always JavaScript: heavy third-party scripts, blocking event handlers, layout-thrashing event responses, and synchronous work that should be asynchronous. The INP chapter covers the JS-pruning workflow in detail. The related JavaScript SEO chapter covers the broader JS picture.

CLS in detail

Cumulative Layout Shift measures how much the layout of the page moves around unexpectedly during the load. The score is a unitless number calculated from the area of the moved content times the distance it moved, summed across all unexpected shifts.

The threshold to pass is 0.1 or less. Between 0.1 and 0.25 is Needs Improvement. Over 0.25 is Poor. A score of 0 means nothing visible ever moved unexpectedly during load, which is the goal.

The four typical causes of CLS:

1. Images without dimensions. An <img> tag without width and height attributes leaves the browser guessing at the height. When the image arrives, the layout reflows. The fix is adding width and height (or a CSS aspect-ratio) to every image. Trivial change, massive impact.
2. Ad slots that load late. An empty ad container loads at 0px height, then expands to 250px when the ad arrives 800ms later, pushing all the content below it down. The fix is reserving a minimum height for every ad slot in CSS, even if the ad is sometimes shorter.
3. Embedded content (YouTube, Instagram, TikTok, maps). Embeds typically resize after their content arrives. Same fix: reserve space in CSS up front.
4. Web fonts swapping. A custom web font arriving 1 second after the fallback font has rendered causes a flash of styled text that reflows the layout. The fix is font-display: optional or careful use of font-display: swap with size-adjusted fallback fonts.

The CLS fixes chapter covers each pattern in detail with code examples.

Field data versus lab data

This is the most-misunderstood part of Core Web Vitals, and the cause of most wasted speed-optimisation budgets we see.

Field data is collected from real Chrome users hitting your site. Google aggregates the data into the Chrome User Experience Report (CrUX) and publishes a rolling 28-day window per URL or per origin. Field data is what Google uses for ranking. It is also what the GSC Core Web Vitals report shows and what the top half of the PageSpeed Insights output displays.

Lab data is a simulated page load run by a tool like Lighthouse against a single URL with a fixed throttling profile. The lab simulates a mid-range mobile device on a fast 3G connection. The score is reproducible on demand but does not reflect what real visitors experience. Lab data is the bottom half of the PageSpeed Insights output and the entire Lighthouse panel in Chrome DevTools.

The two often disagree. A site with a Lighthouse score of 95 can still fail field-data Core Web Vitals because the real-world devices and connections of its actual users are slower or more varied than the lab simulation. A site with a Lighthouse score of 60 can pass field-data Core Web Vitals because its real users mostly hit it from cached CDN edges on fast home WiFi.

The honest workflow:

1. Start with field data from the GSC Core Web Vitals report. This tells you which URL groups are failing and which are passing in the real world.
2. Pull the failing URLs into Lighthouse for diagnosis. Lighthouse identifies the LCP element, the layout shifts, the long tasks. It tells you what to fix.
3. Ship the fix, deploy to production, wait 28 days.
4. Re-check field data. Lighthouse will show improvement immediately; the field-data report will show it gradually as the 28-day window rolls.

The trap is starting with Lighthouse, chasing a green score on a single URL, declaring victory, and never noticing that the rest of the site still fails the field data. See Google Search Console for the field-data report workflow and the technical audit chapter for the wider audit context.

The 75th-percentile threshold rule

Google does not score your site on the median user. It scores on the 75th percentile, which means the slowest quarter of your users define your score. This is a deliberate choice: a metric that only reflected the median would make slow tails invisible.

The practical effect is that you cannot ignore the slow end of your user distribution. A site that has 80 percent of users at 2 seconds LCP and 20 percent at 5 seconds will have a 75th percentile somewhere around 3 to 4 seconds and will fail the metric, even though most users feel like the site is fast.

The slow tail is usually one of three things: mobile users on patchy connections, users on older mid-range Android phones with slower CPUs, or users in geographies far from your origin servers. For Perth-based sites, the slow tail is often regional WA users on satellite or 4G, plus international users from Asia and Europe hitting the site without a CDN edge nearby.

How to check your scores

Three free tools cover the entire workflow.

PageSpeed Insights

Paste a URL into pagespeed.web.dev. The top of the page shows the CrUX field data for that URL or origin. The bottom of the page shows a Lighthouse lab run. This is the fastest way to see both data sources side by side for a single page.

Google Search Console Core Web Vitals report

The Experience section in GSC has a Core Web Vitals report that groups URLs by similarity (template-style grouping) and shows pass/needs-improvement/poor counts for mobile and desktop separately. This is where you find your worst URL groups and can see trends over time. See Google Search Console for the broader GSC workflow.

Chrome DevTools Lighthouse + Performance panel

Open DevTools on the page, run Lighthouse for a quick summary, then use the Performance panel for deeper traces. The Performance panel shows the actual rendering timeline, the LCP element highlighted, the long tasks tied to INP, and the layout shifts that drive CLS. Use CPU throttling at 4x to simulate a mid-range Android phone. The Lighthouse explained chapter covers the audit category breakdown.

Perth and WA context

Two patterns specific to Perth and WA sites.

Regional WA users push the 75th percentile. A Perth-based site with a mostly metropolitan audience sees clean field-data Core Web Vitals. The same site once it picks up regional WA traffic (mining sector, agricultural sector, remote tourism) sees the 75th percentile drift toward Needs Improvement, because regional connections are slower and the CDN edges sometimes fall back to Sydney or Melbourne. The fix is usually a CDN with better regional Australian coverage and aggressive caching of static assets.

International browsing falls back to Singapore. Australian sites without a CDN often serve direct from a single AWS Sydney region. Users from Asia hit cached edges at decent speed; users from Europe and North America hit the origin slowly. Most Perth SMB sites do not care about international traffic, but professional services and e-commerce sites with overseas customers see this in their field data immediately.

For the broader Page Experience context, the Core Web Vitals pillar covers the whole ranking signal, the LCP optimisation chapter covers the most common Vitals fix, the INP chapter covers the responsiveness metric end to end, and the CLS fixes chapter covers the layout-shift fixes. For sites with broader technical-health issues feeding into Vitals, see the technical audit chapter. New properties should start with a free SEO audit; clients who already have a real Vitals problem can engage the speed optimisation service. For service-area context, see Perth services and Local SEO Perth; for industry context, mining SEO and e-commerce SEO both deal with Vitals constraints unique to their sectors.