Core Web Vitals (LCP, INP, CLS): the page experience playbook

Originally published at thatdevpro.com. Part of ThatDevPro's open SEO + AI framework library. ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio. Open-source AI citation toolkit: github.com/Janady13/aio-surfaces.

Core Web Vitals (LCP, INP, CLS), Mobile Optimization, HTTPS, Intrusive Interstitials, and the User-Side Quality Floor

A comprehensive installation and audit reference for page experience — the user-facing performance and usability layer Google uses as a ranking factor and, more importantly, the layer that actually determines whether visitors stay on a page or bounce. Dual-purpose: installation manual and audit document.

Cross-stack implementation note: the code samples in this framework are written in plain HTML for clarity. For React, Vue, Svelte, Next.js, Nuxt, SvelteKit, Astro, Hugo, 11ty, Remix, WordPress, Shopify, and Webflow equivalents of every pattern below, see framework-cross-stack-implementation.md. For pure client-rendered SPAs (no SSR/SSG) see framework-react.md. For Tailwind-specific concerns (purge, dynamic classes, dark-mode CLS, focus accessibility) see framework-tailwind.md.

1. Document Purpose

This is the canonical reference for page experience. Where framework-technicalseo.md covers the bot-facing foundation, this document covers the human-facing one. The two intersect: a slow page is bad for users and bad for crawl budget; an unstable layout is bad for users and bad for INP. Page experience is the discipline of measuring and fixing the metrics Google uses to model what users actually feel.

In 2026, page experience differs from page experience in 2020 in three ways. First, INP (Interaction to Next Paint) replaced FID (First Input Delay) as the responsiveness metric in March 2024 — INP is harder to pass because it measures every interaction, not just the first. Second, mobile-first indexing means mobile vitals are the only vitals that matter for ranking. Third, the threshold for "good" has tightened: Google now expects 75% of page loads to meet all three CWV thresholds at the 75th percentile of real-user data.

1.1 Required Tools

• PageSpeed Insights — pagespeed.web.dev — both lab and field data
• Chrome User Experience Report (CrUX) — field data source for CWV
• Lighthouse (via Chrome DevTools) — lab measurement
• WebPageTest — webpagetest.org — deeper waterfall analysis with location/device/connection control
• Google Search Console — Core Web Vitals report — sitewide field data
• Chrome DevTools Performance panel — interaction profiling for INP
• Chrome DevTools Coverage tab — unused CSS/JS detection
• Chrome DevTools Network panel — resource waterfall
• Real User Monitoring (RUM) — Vercel Speed Insights, Cloudflare Web Analytics, SpeedCurve, Calibre
• Web Vitals JS library — web-vitals npm package for custom RUM
• GTmetrix — alternative lab + waterfall

1.2 Document Scope

Covers: the three Core Web Vitals (LCP, INP, CLS), mobile usability, HTTPS posture, intrusive interstitials, image optimization for performance, font loading, JavaScript performance, third-party tag management, and validation methodology. Touches but does not exhaust: deeper performance optimization (framework-performance.md), accessibility (framework-accessibility.md), security (framework-security.md), platform-specific tuning (framework-nextjs.md, framework-wordpress.md).

2. Client Variables Intake

domain: ""
hosting: ""                            # Vercel | Netlify | Cloudflare | shared | VPS | dedicated
cdn: ""                                # Cloudflare | Fastly | KeyCDN | Bunny | none
cms_or_framework: ""                   # WordPress | Next.js | Astro | Hugo | Shopify | Webflow | static
current_lcp_p75: 0                     # in milliseconds, from CrUX or RUM
current_inp_p75: 0
current_cls_p75: 0
mobile_score_baseline: 0               # PageSpeed Insights mobile
desktop_score_baseline: 0
known_performance_issues: []
third_party_scripts_inventory: []      # GA4, GTM, ad tags, chat widgets, etc.
hsts_deployed: false
mobile_friendly_test_passes: false

3. Core Web Vitals — The Three Metrics

3.1 LCP — Largest Contentful Paint

The time until the largest visible content element finishes rendering. Measured in seconds.

Thresholds (75th percentile of users):

• Good: ≤ 2.5 seconds
• Needs improvement: 2.5 – 4.0 seconds
• Poor: > 4.0 seconds

What counts as the LCP element?

Usually the hero image or the largest text block. Watch the LCP candidate in DevTools Performance panel — the element flagged with the LCP marker is the one to optimize.

Common LCP causes:

Measurement approach:

• Lab measurement (Lighthouse, WebPageTest) catches gross issues.
• Field measurement (CrUX, RUM) is what Google uses for ranking.
• A site can have great lab scores and bad field scores (or vice versa). Both must pass.

3.2 INP — Interaction to Next Paint

The 75th-percentile latency between a user interaction (click, tap, key press) and the next paint reflecting the result. Replaced FID in March 2024.

Thresholds (75th percentile of interactions):

• Good: ≤ 200 ms
• Needs improvement: 200 – 500 ms
• Poor: > 500 ms

Why INP is harder than FID:

FID measured only the first interaction. INP measures every interaction across the page lifecycle and reports the worst (or near-worst) one. A page that responds fast to the first click but stalls on the third scrolls a poor INP.

Common INP causes:

INP attribution:

Use Chrome DevTools Performance panel. Record an interaction. The "Interaction" track shows input delay + processing time + presentation delay. Identify which is dominant and fix accordingly.

3.3 CLS — Cumulative Layout Shift

A measure of visual stability — how much the page jumps around as it loads. Unitless score; lower is better.

Thresholds (75th percentile of users):

• Good: ≤ 0.1
• Needs improvement: 0.1 – 0.25
• Poor: > 0.25

Common CLS causes:

The cookie banner exception:

Cookie consent banners that appear after a delay are a major CLS source. Either render the banner with reserved space from page load, or apply it as a fixed-position overlay that doesn't shift content.

4. Mobile Usability

Since 2023 Google indexes the mobile version of every site. Mobile vitals are the only vitals that matter for ranking.

4.1 The Viewport Tag

Every page must include:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Without this, mobile browsers render the page at desktop width and zoom out, failing nearly every mobile usability check.

4.2 Tap Target Size

Tap targets (buttons, links) must be at least 48 × 48 CSS pixels. Targets smaller than 48px or with less than 8px spacing between them fail mobile usability.

.btn, .link-as-button {
  min-height: 48px;
  min-width: 48px;
  padding: 12px 20px;
}
nav a {
  padding: 12px 16px;  /* generous click area */
}

4.3 Text Size

Body text on mobile should be at least 16px. Smaller text triggers automatic zoom on iOS form fields and fails mobile usability.

4.4 Content Width

Content must fit the viewport. Horizontal scrolling on mobile fails the test.

img, video, iframe { max-width: 100%; height: auto; }
.container { max-width: 100vw; overflow-x: hidden; }

4.5 The Mobile-Friendly Test

Run every important page through search.google.com/test/mobile-friendly (deprecated; replaced by URL Inspection in GSC). The Lighthouse mobile audit covers most of the same checks.

5. HTTPS

Page experience requires HTTPS. The full implementation is in framework-technicalseo.md Section 11; the page-experience-relevant pieces:

• Valid certificate (no browser warning)
• HSTS deployed
• No mixed content (HTTPS page loading HTTP resources)
• HTTP/2 or HTTP/3 enabled (performance benefit, not strict requirement)

6. Intrusive Interstitials

Pop-ups, overlays, and interstitials that block content access on mobile are a ranking penalty. The penalty applies to:

• Pop-ups covering the main content immediately on page load
• Standalone interstitials the user must dismiss before reaching the page
• Above-the-fold layouts where the visible portion is dominated by an ad or pop-up

Exempted:

• Login dialogs on pages that legitimately require login
• Age verification on pages that legitimately require it
• Cookie consent banners (provided they don't dominate the viewport)
• Small banner ads that don't dominate the visible area

Common offenders:

• Email signup overlays triggered immediately on landing
• "Subscribe to our newsletter" full-screen modals
• Discount-offer pop-ups before user has read anything
• Chat widgets that auto-expand to fill the screen

The fix is timing and proportion. Show the overlay after engagement (15+ seconds, 50%+ scroll, exit intent) and keep it under ~30% of the viewport.

7. Image Optimization for Performance

Images are usually the LCP element and often the biggest CLS contributor. Optimize aggressively.

7.1 Format Selection

The <picture> pattern serves the right format per browser:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="800" loading="eager" fetchpriority="high">
</picture>

7.2 Responsive Images

Serve different sizes per viewport:

<img src="hero-800.jpg"
     srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
     sizes="(max-width: 768px) 100vw, 50vw"
     alt="..." width="1200" height="800">

7.3 Lazy Loading

<img src="..." loading="lazy" alt="..." width="..." height="...">

Critical: the LCP image must NOT be lazy-loaded. Lazy-load below-the-fold images only. Use loading="eager" (or omit; eager is default) for the hero image and add fetchpriority="high" to signal priority.

7.4 Dimensions Always

Every <img>, <video>, and <iframe> requires width and height attributes (or CSS aspect-ratio). This reserves layout space and prevents CLS.

7.5 Image CDN

For sites with many images, an image CDN (Cloudinary, imgix, Cloudflare Images, Vercel Image Optimization, Next.js next/image) provides:

• On-the-fly format conversion
• On-the-fly resizing
• Automatic AVIF/WebP serving
• Caching at the edge

Cross-reference: framework-imageseo.md for SEO-side image considerations.

8. Font Loading

Fonts are a frequent LCP and CLS culprit.

8.1 font-display

Always specify font-display:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;  /* show fallback immediately, swap when font loads */
}

8.2 Preload Critical Fonts

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Only for fonts used above the fold. Preloading too many resources hurts LCP.

8.3 Font Subsetting

Modern Google Fonts are typically already subset. Self-hosted custom fonts: subset to the character set you actually use (Latin, Cyrillic, etc.). A 200KB unsubset font becomes 30KB after Latin subset.

8.4 Variable Fonts

Variable fonts (Inter, Fraunces, etc.) deliver multiple weights from one file. Net win at scale.

8.5 size-adjust and Fallback Metrics

Match fallback font metrics to web font to eliminate CLS on swap:

@font-face {
  font-family: 'fallback-inter';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}
body { font-family: 'Inter', 'fallback-inter', sans-serif; }

The fontaine library automates this for popular fonts.

9. JavaScript Performance

9.1 Bundle Size Budget

For mobile-first 2026:

These are aggressive targets and not always achievable, but they're the bar.

9.2 Code Splitting

Load only what's needed for the initial route. Defer route-specific bundles:

// Next.js dynamic import
const HeavyChart = dynamic(() => import('./HeavyChart'), { ssr: false });

9.3 Tree Shaking

Modern bundlers (esbuild, Vite, Rollup, Turbopack) tree-shake automatically. Verify by checking final bundle for unused imports — Coverage tab in Chrome DevTools shows unused JS.

9.4 Defer and Async

<!-- Async: download in parallel, execute as soon as ready -->
<script src="analytics.js" async></script>

<!-- Defer: download in parallel, execute in order after HTML parsing -->
<script src="enhancement.js" defer></script>

Most third-party scripts should be async or defer. Inline blocking <script> tags are the worst case for LCP.

9.5 Long Tasks

A "long task" is any JS execution over 50ms. Long tasks block input and hurt INP. Find them in Chrome DevTools Performance panel — they appear as red-flagged blocks. Common sources:

• Heavy initial render (React/Vue hydration)
• Large state updates
• Synchronous loops over big arrays
• Third-party SDK initialization

Break into smaller tasks with setTimeout(0), requestIdleCallback, or scheduler.yield.

10. Third-Party Tag Management

Most page-experience problems on real client sites trace to third-party scripts: analytics, ads, chat widgets, A/B testing tools, marketing automation pixels.

10.1 The Audit

For every site, inventory every third-party script and ask:

• What does it do?
• Does the client actually use the data it produces?
• What's its INP impact?
• Can it be loaded later (defer, async, post-interaction)?
• Is there a lighter alternative?

Common removals after audit:

• Old A/B testing platforms no longer in use
• Multiple competing analytics (GA4 + Adobe + Heap + Hotjar + Mixpanel)
• Chat widgets the client doesn't monitor
• Pixel tags from agencies long since departed
• "Just in case" tags whose purpose nobody remembers

10.2 Tag Manager Hygiene

If using GTM:

• Audit triggers — many fire on every page load even when only relevant on specific pages
• Audit tags — disable or remove unused tags
• Use built-in tag templates rather than custom HTML where possible
• Set "Wait for tags" thresholds that don't block CWV

10.3 The Self-Hosted Pattern

For high-impact third-party scripts (especially analytics), self-hosting can reduce DNS, TCP, and TLS overhead. Plausible, Fathom, Cloudflare Web Analytics all support self-hosting.

For Google Analytics, gtag.js itself can't be self-hosted easily, but the analytics.js payload can be proxied via Cloudflare Worker / nginx to reduce third-party origin connections.

10.4 Privacy and Performance

EU privacy law (GDPR) and US state laws (CCPA) increasingly require consent before tags fire. The consent gate has a side benefit: tags don't load until interaction, which is great for CWV. Consent Mode v2 in GTM is the conventional implementation.

11. Server-Side Performance

11.1 Time to First Byte (TTFB)

While not a CWV metric directly, TTFB feeds into LCP. Good TTFB is under 600ms; great is under 200ms.

11.2 Caching Layers

In order of preference (cheapest to most expensive lookup):

1. CDN edge cache — Cloudflare, Fastly, etc. — milliseconds, free at scale
2. Application-level page cache — WP Super Cache, Vercel ISR, Astro static — single-digit ms
3. Object cache — Redis, Memcached — for query results, session data
4. Database query cache — built into MySQL/PostgreSQL — invalidate carefully
5. Database itself — last resort

11.3 HTTP/2, HTTP/3, Brotli

• HTTP/2 — supported everywhere, multiplexes connections.
• HTTP/3 — emerging; supported by Cloudflare, Fastly. Minor performance gain on lossy mobile networks.
• Brotli compression — better than gzip for text resources. Enable at server or CDN level.

12. Real User Monitoring (RUM)

Lab tests catch some problems. Field data catches the rest. Set up RUM on every client site.

12.1 Free Options

• Google Search Console — Core Web Vitals report — sitewide CrUX data, no setup
• Cloudflare Web Analytics — free, privacy-respecting, includes CWV
• Vercel Speed Insights — free for Vercel-hosted sites

12.2 Paid Options

• SpeedCurve — comprehensive RUM with synthetic monitoring
• Calibre — performance budgets, alerting
• Pingdom RUM — basic monitoring

12.3 DIY with web-vitals

For full control, use the web-vitals library:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  navigator.sendBeacon('/rum', JSON.stringify({name, value, id, url: location.href}));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Ship to your own endpoint and analyze with whatever tooling suits.

13. The Validation Workflow

For every client engagement:

1. Baseline (week 0) — record LCP, INP, CLS at 75th percentile from PageSpeed Insights field data, GSC CWV report, and any RUM available. Document mobile and desktop separately.
2. Diagnose — Lighthouse audit on representative pages. WebPageTest for waterfall. Identify top 5 contributing issues.
3. Fix — implement changes. Verify in lab tests first.
4. Measure — wait 28 days for CrUX field data to update (CrUX uses 28-day rolling window).
5. Iterate — if not yet "good," continue diagnosing.
6. Monitor — RUM and GSC CWV report ongoing.

14. Audit Mode

Score: 30. World-class: 28+/30.

15. Common Mistakes

1. Lazy-loading the hero image. Slows LCP dramatically.
2. No image dimensions. Largest CLS source.
3. Cookie banner injected late, pushing content. Reserve space or use overlay.
4. Multiple analytics SDKs running concurrently. Pick one, remove the rest.
5. Synchronous third-party scripts. Use async / defer.
6. Optimizing only desktop. Mobile is what Google ranks.
7. Lab scores look great, field scores poor. Field data is what counts.
8. Long-running click handlers. INP killer; break into chunks.
9. font-display: block (or unspecified, which defaults to block). Hides text until font loads.
10. JavaScript-heavy "interactive" landing pages with sub-second blocking work. INP catastrophe on mid-tier mobile devices.
11. No CDN. Origin server in one region serves users globally; LCP suffers everywhere except near the origin.
12. Render-blocking CSS. Inline critical above-fold CSS; defer the rest.
13. Web fonts loading from external CDN with no preconnect. Add <link rel="preconnect"> for font origin.
14. Poll-based polling JavaScript. Use server-sent events or WebSockets.
15. Unused JS frameworks loaded. "We're using React for one widget" but shipping the whole bundle.
16. <iframe> embeds without dimensions. Major CLS source.
17. Treating CWV as a checkbox once and never again. CWV regress over time as features are added.

16. Maintenance

Weekly:

• Spot-check PageSpeed Insights for representative pages
• Review GSC Core Web Vitals report for new errors

Monthly:

• Sitewide GSC CWV review
• RUM dashboard review
• New third-party scripts audit
• Lighthouse audit on top 10 pages

Quarterly:

• Comprehensive performance audit (WebPageTest + Lighthouse)
• Third-party tag inventory refresh
• Image/font/CSS/JS budget review
• CDN configuration review
• Cache hit ratio review

Annually:

• Full performance budget reassessment
• Hosting/CDN evaluation
• New CWV metric watch (Google revises CWV periodically)
• Major framework / CMS update planning

17. Companion Documents

• framework-technicalseo.md — Indexing, HTTPS, server-side foundation
• framework-performance.md — Deeper performance optimization beyond CWV
• framework-imageseo.md — Image SEO including format and alt text
• framework-mobileseo.md — Mobile-specific deep dive
• framework-accessibility.md — A11y patterns (overlap with mobile usability)
• framework-security.md — HTTPS, HSTS, security headers
• framework-nextjs.md — Next.js performance patterns
• framework-wordpress.md — WordPress performance patterns
• framework-headless.md — Headless architecture performance
• framework-cro.md — Performance and conversion correlation

Document version: 1.0
Last updated: 2026-05-05
Owner: Joseph W. Anady — ThatDeveloperGuy — SDVOSB

About this framework library

This article is the Dev.to republish of a framework reference document from ThatDevPro's SEO + AI engineering library. Canonical source: https://www.thatdevpro.com/insights/framework-pageexperience/

ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio operating from Cassville, Missouri. The studio runs the full 14-tier Engine Optimization stack and ships open-source tooling for AI citation engineering.

Companion 14-tier Engine Optimization stack (each tier is its own article):

1. Tier 1 — Foundation
2. Tier 2 — Search Visibility
3. Tier 3 — AI Domination
4. Tier 4 — Entity and Authority
5. Tier 5 — Local Domination
6. Tier 6 — Content and Multimedia
7. Tier 7 — Social and Community
8. Tier 8 — Data, Analytics, Conversion
9. Tier 9 — Monitoring and Intelligence
10. Tier 10 — Workflow and Operations
11. Tier 11 — Marketplace and Retail
12. Tier 12 — International
13. Tier 14 — Advanced and Immersive

Need this framework implemented on your site? See the Engine Optimization service or hire through ThatDevPro contact.