Skip to content
Core Web Vitals specialists

Core Web Vitals & measurement

Without reliable measurement, optimisation becomes guesswork. This category explains the metrics Google uses for user experience — Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift — and how they come about. We show the difference between lab data and field data from real visits, explain percentiles and why an average misleads, and describe how to set up measurements realistically on mobile connections. Added to this are debugging approaches: reading waterfall charts, spotting main-thread blocking, tracing layout shifts and documenting results so improvements remain provable over time. We additionally show how to automate measurements so that regressions after a release are noticed immediately rather than weeks later.

One SPA session: what gets measured and what is missingWithout soft navCrUX today1 entry for the whole session — LCP only at document loadCLS and INP accumulate across the entire page lifecycleRoutes: invisibleHeuristic1 · user interaction2 · history change3 · visible paintWith soft-navigationfrom Chrome 151/categoryHard navigationnavigationId · real TTFB/product/a12Soft nav 1navigationId · TTFB 0/cartSoft nav 2navigationId · TTFB 0/checkoutSoft nav 3navigationId · TTFB 0LCPmeasured again per route,via getLargestInteractionContentfulPaint()CLSrestarts at every routeboundary at 0INPper route instead of acrossthe whole page lifecycle151Chrome version withunflagged API7entry types receivea navigationId48 %of mobile websites withgood Core Web VitalsSources: Chrome for Developers · HTTP Archive Web Almanac 2025

Soft Navigations: Measuring Core Web Vitals in SPAs

Single-page apps only report the first load to CrUX. How the Soft Navigations API from Chrome 151 measures route changes and splits LCP, INP and CLS per route.

14 min read
Slim down the DOM - from a deep tree to a lean structureBefore: deeply nested DOMcontentWrapper div per level1,900 nodesDepth 38 · 90 children/listStyle recalc 92 msAfter: flat and paginatedheadercardcardcardlist (paginated)Flat siblings720 nodesDepth 12 · paginatedStyle recalc 24 msNode count against the Lighthouse thresholds7201,900800 - warning1,400 - errorgoodcriticalWhy DOM size matters800+nodes where Lighthousestarts warning (Google Lighthouse)40 msstyle/layout work above whichthe insight fires (Chrome for Developers)594DOM elements on a medianmobile page (HTTP Archive)

Reduce DOM Size: Fewer Nodes, Faster Interactions

Reduce DOM size: cut style and layout work with pagination, virtualization, content-visibility and flatter markup to improve INP and Core Web Vitals.

12 min read
Core Web Vitals: Same Device, Two WorldsShare of origins passing all three vitals (CrUX)MobileLCP62%largest paint slowINP77%touch responseCLS81%layout stabilityDesktopLCPOKINP97%CLSOKAll three vitals passing48%mobile56%desktopvsMobile audit simulatedCPU 4x slowerNetwork Slow 4G57%of e-commerce revenue mobile53%abandon after 3 s load48 percent of origins pass all Core Web Vitals on mobile, 56 percent on desktop (Web Almanac 2025) --around 57 percent of worldwide e-commerce revenue happens on mobile (Statista 2024).

Mobile Performance: Speeding Up Shops on Phones

How throttled CPU, slow networks, viewport and touch shift mobile Core Web Vitals and which levers speed up your shop on the phone where revenue happens.

13 min read
Interaction to Next Paint - Anatomy of an InteractionClick / Tap / Key press until the next frame1. Input Delay40msMain thread busy with a long task2. Processing Time95msEvent handler execution3. Presentation Delay30msRendering until next frameINP ThresholdsGood< 200msNeeds Work200-500msPoor> 500msSum = INP value165msInputProcessingPaintSlowest interaction is reported (75th percentile)Break up long tasksscheduler.yield()Chunking, yieldingSlim down handlersrequestIdleCallbackOffload to Web WorkerTame third partiesasync, deferLazy on interactionBatch DOM workcontent-visibilityAvoid layout thrashingMeasure in the field, not the labField data | web-vitals.js | Lab and field measurement | Long Animation Frames API

Optimizing INP: Improving Interaction to Next Paint

Optimizing INP: how to bring Interaction to Next Paint below 200 milliseconds. Targeted relief for long tasks, event handlers and third-party scripts.

13 min read
Reading and Prioritizing a Lighthouse ReportOnly five metrics weight the score - opportunities act indirectlyPerformance score68out of 1006805090100These five metrics weight the scoreTotal Blocking Time30 %Largest Contentful Paint25 %Cumulative Layout Shift25 %First Contentful Paint10 %Speed Index10 %TBT, LCP and CLS together make up 80 percent of the scorePrioritize by estimated savings, not by red colorAn opportunity does not count directly - it lifts the metric that counts.OPPORTUNITYUnused JS: 0.9 sLIFTS WEIGHTED METRICTBT - 30% weightRESULTScore rises

Reading a Lighthouse Report and Prioritizing Fixes

How to read a Lighthouse report correctly: which five metrics weight the score, why opportunities act indirectly and how to prioritize by estimated savings.

14 min read