Page experience is what happens after the click. Google says good Core Web Vitals align with what its ranking systems seek to reward, and a Google and Deloitte study tied tiny speed gains to more visitors reaching the next step. Measure real users first, fix the slowest actual cause and test the full mobile journey, not just a score.

Begin with the reader’s task

Everything in this playbook ends at the same place: a person on a page, trying to do something. If the page loads late, jumps as they read or ignores their first tap, the work that got them there is wasted. Google frames it this way too. Its page experience guidance says its core ranking systems look to reward content that provides a good page experience, and that site owners should not focus on only one or two aspects. Its self-check asks whether pages have good Core Web Vitals, are served securely, display well on mobile, avoid excessive ads and intrusive interstitials, and make the main content easy to tell apart from everything else.[1]

21.6%more visitors on lead-generation sites reached the form submission page after a 0.1-second speed improvement, with 7% more page views. Google and Deloitte, 37 brand sites, 2020.[2]
0.1 swas the improvement tested, applied across four speed metrics. Small changes were enough to move people through the funnel.[2]

Treat those figures as evidence of direction, not as a forecast for your site. They come from one study of large brands, on a particular set of speed metrics, and a service business with a short form will see a different effect. The useful reading is that visitors are sensitive to speed differences far smaller than most teams bother to chase.

Know what the metrics describe

Core Web Vitals are three measurements of real user experience. Largest Contentful Paint (LCP) is how long the main content takes to appear. Interaction to Next Paint (INP) is how quickly the page responds to clicks, taps and key presses. Cumulative Layout Shift (CLS) is how much the layout moves unexpectedly. Google recommends aiming for an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, measured at the 75th percentile of page loads and segmented by mobile and desktop.[3] INP replaced First Input Delay as a stable Core Web Vital in 2024.[4]

LCPLargest Contentful Paint: loading ≤ 2.5 s≤ 4 s> 4 s INPInteraction to Next Paint: responsiveness ≤ 200 ms≤ 500 ms> 500 ms CLSCumulative Layout Shift: visual stability ≤ 0.1≤ 0.25> 0.25 GoodNeeds improvementPoor
The published thresholds. A page passes when its 75th-percentile experience meets the “good” target for all three metrics.[3][5]
48%of mobile sites had good Core Web Vitals in 2025, up from 44% in 2024. HTTP Archive Web Almanac.[6]
56%of desktop sites did, up from 55%. So roughly half of the web still has something to fix.[6]

Measure real users before you tune anything

Two kinds of data answer different questions. Lab data comes from a controlled test, such as Lighthouse, on one device and network. Field data comes from real visitors. web.dev warns that the two can disagree: your lab score may look great while real users are struggling, or the reverse.[7] Start with field data to learn whether a problem exists and which pages have it, then use lab tools to work out why.

Where to look
SourceDataUse it to
Search Console, Core Web Vitals reportFieldSee groups of URLs that fail, by metric and device.[3]
PageSpeed InsightsField and labCompare real-user results with a lab test of one URL.
Chrome DevTools Performance panelLabFind which task, request or element causes a slow result. It can show your local LCP beside field data.[8]
web-vitals library on your own siteFieldCollect LCP, INP and CLS from your visitors into your analytics.[9]

Remember the segment. A site whose desktop results are good and mobile results are poor has a mobile problem, and the mobile pages are the ones Google indexes first.

Fix the cause, not the score

Each metric has a small number of common causes. Diagnose before you change anything.

LCP. web.dev breaks LCP into four subparts that never overlap and add up to the full time: time to first byte, resource load delay, resource load duration and element render delay. A high time to first byte can make a 2.5-second LCP hard or impossible, and a large gap between first byte and first paint is a classic sign of heavy client-side rendering.[8]

Navigation startsMain content painted Time tofirst byte Resourceload delay Resourceload duration Elementrender delay Together: the LCP time Slow server,redirects Image foundtoo late Big file orslow network Blockingscripts
The four subparts of LCP and where each tends to go wrong. The widths are equal for clarity and do not show typical proportions.[8]

INP. An interaction has three phases: input delay, until the event handlers start; processing time in the handlers; and presentation delay until the next frame appears. Input delay often comes from long tasks on the main thread, such as scripts loading, parsing and running.[10] CLS. Layout shifts typically come from images without dimensions, ads, embeds and iframes without dimensions, injected content and web fonts, and the basic fix is to set width and height, or aspect-ratio, so the browser reserves the space.[11]

Symptom to first thing to try
SymptomLikely causeFirst try
Hero image appears lateLarge file, discovered late, or lazy-loaded by mistakeCompress it, load it early and do not lazy-load the main image.
Slow first byteServer work, redirects or no cachingCache the HTML, remove redirect hops, use a nearby edge.[8]
Taps feel ignoredLong tasks on the main threadShip less JavaScript and break up long tasks.[10]
Text jumps when fonts loadLate web fonts without a stable fallbackPreload the key font and match the fallback’s metrics.[11]
Content shifts as you scrollEmbeds or images without reserved spaceSet dimensions or an aspect ratio on every media element.[11]

Test the complete mobile interaction

Metrics miss things a person notices at once. Run the real task on a mid-range phone, on a throttled connection, starting from the search result: open the page, read the first screen, tap the main call to action, open the form, fill a field with the on-screen keyboard showing and submit. Note anything that makes you hesitate, such as a sticky bar covering the field, a tap target too close to another or a cookie dialog that fills the screen. Google’s self-check lists intrusive interstitials and excessive ads for exactly this reason.[1]

The UX & UI Playbook covers the interaction side in depth: Core Web Vitals, Mobile and thumbs and Speed and feedback. Use them together with this chapter.

Review the result in context

After a fix, compare field data before and after, allowing for the time it takes real-user data to accumulate. Then compare the outcomes that matter: engagement on the page and the share of visitors who take the next step. Do not expect a ranking jump from a speed fix. Google describes good page experience as something its core ranking systems look to reward across many aspects, so one improvement is one input among several, and the visitors you already get are the more reliable place to see the benefit.[1] Record what you changed and when, so a later regression can be traced to a release.

Apply it to your website

  • You know whether real users get good LCP, INP and CLS on mobile and on desktop, for your most important pages.
  • Fixes are chosen from a diagnosis of the actual bottleneck and not from a generic checklist.
  • Every image, video and embed reserves its space with dimensions or an aspect ratio.
  • The main image is not lazy-loaded and is discoverable early. Scripts do not block the first interaction.
  • The whole mobile task has been run on a throttled mid-range phone, including the form and the keyboard.
  • The site is served over HTTPS, with no intrusive interstitials and no excess of ads.
  • Before-and-after field data and next-step rates are recorded for each performance change.

Sources and further reading

Sources were consulted in October 2026 and the numbered notes above point here. Platform documentation changes often, so check the linked page before you act on a platform-specific detail. Worked scenarios are illustrative unless identified otherwise; methods and worksheets are Vantle’s editorial guidance.

  1. Google Search Central: Understanding page experience in Google Search resultsThe self-assessment questions and the statement about core ranking systems.
  2. Google and Deloitte: Milliseconds make millions (web.dev case study)A 2020 study of 37 brand sites and the effect of 0.1-second speed improvements.
  3. Google Search Central: Understanding Core Web Vitals and Google Search resultsThe recommended LCP, INP and CLS targets and how they relate to Search.
  4. web.dev: Web VitalsThe metric lifecycle, including INP becoming a stable Core Web Vital in 2024.
  5. web.dev: Defining the Core Web Vitals metrics thresholdsThe good and poor thresholds, and classification at the 75th percentile.
  6. HTTP Archive: Web Almanac 2025, PerformanceThe share of sites with good Core Web Vitals on mobile and desktop.
  7. web.dev: Why lab and field data can be differentHow controlled tests and real-user data disagree.
  8. web.dev: Optimize Largest Contentful PaintThe four LCP subparts and diagnostic guidance.
  9. GoogleChrome/web-vitalsAn open-source library for measuring Core Web Vitals in the field.
  10. web.dev: Optimize Interaction to Next PaintThe phases of an interaction and the causes of input delay.
  11. web.dev: Optimize Cumulative Layout ShiftCommon causes of layout shifts and how to fix them.