Core concepts

Core Web Vitals targets

• LCP: Good < 2.5s; Needs work 2.5–4s; Poor > 4s
• CLS: Good < 0.1; Needs work 0.1–0.25; Poor > 0.25
• INP: Good < 200ms; Needs work 200–500ms; Poor > 500ms

These thresholds are the recommendations used by Google guidance and Lighthouse as of Apr 2026. For INP, refer to INP guidance for measurement details and how outliers are mitigated.

Baseline audit (new)

Lighthouse v13.1.0's baseline compatibility audit:

• Flags web features used by a page that may not meet the Baseline compatibility definition.
• Shows a web-feature name and version in each audit description and adds baseline icons for faster scanning.
• Is included in the default Lighthouse config, so standard runs will surface compatibility signals.

Actionable advice:

• Treat baseline findings as compatibility signals, not optional style notes. Test on target platforms before suppressing recommendations.
• Use the audit's web-feature name/version to decide whether to polyfill, feature-detect, gate features, or provide alternate code paths.
• Use the WebDX trace category in Lighthouse traces to correlate baseline feature usage with performance hotspots during triage.

Rendering pipeline reminder

Browser → Parse HTML → Build DOM → Resolve CSS → Layout → Paint → Composite

Reduce blocking work, avoid forced reflows, and animate properties that can be composited (transform, opacity) where possible.

Workflow (updated)

1. Run Lighthouse (CLI or DevTools) using v13.1.0+ and capture a lab report. Confirm the Baseline compatibility audit appears in the report. Collect field data (RUM) where available.

2. Inspect traces for feature usage

   • Open the recorded trace in Chrome DevTools Performance panel or the Lighthouse trace viewer. Filter or search trace events for the WebDX category/name to see which features were used during the recording and correlate them with CPU, main-thread tasks, and long tasks.

3. Identify the LCP element

   • Chrome DevTools → Performance → record a page load → locate the LCP marker and the associated element in the Summary/Timings.

4. Optimize the LCP element

   • Preload critical images (<link rel="preload" as="image"> or framework-specific priority attributes)
   • Serve modern formats (AVIF/WebP) with CDN transforms and configure long caches
   • Optimize server TTFB for critical content (edge caching, SSR tuning)

5. Prevent CLS

   • Add explicit width/height attributes or CSS aspect-ratio placeholders
   • Use skeletons/placeholders for async-rendered content
   • Use element-scoped view transitions (Element.startViewTransition()) to animate changes inside a subtree instead of triggering global reflows in Chrome 147+. Feature-detect before calling and provide CSS-transition fallbacks for other browsers. When transitioning nested content, prefer nested transition groups to limit snapshot size and avoid costly layer creation.

6. Improve INP

   • Profile event handlers for long tasks and split or offload heavy work (Web Workers)
   • Use React startTransition/useTransition for non-urgent updates and debounce input handlers
   • Break up long tasks (50+ ms) into smaller tasks using cooperative yielding where possible

7. For SPAs: adopt the Navigation API

   • Replace fragile pushState/popstate implementations with NavigateEvent.intercept() for in-place navigations where supported. Use handler and precommitHandler to control fetch/update ordering and use focusReset/scroll options to preserve or customize the browser's default focus/scroll behavior. Feature-detect before using and fallback to your existing router where not supported.

8. Audit bundle size and third-party scripts

   • Code-split heavy libraries, lazy-load third-party widgets after LCP, and measure the impact of third-party scripts with third-party-bundle telemetry.

Quick actionable examples

Feature-detect element-scoped view transitions

const supportsElementViewTransition = typeof Element !== 'undefined' && 'startViewTransition' in Element.prototype;
if (supportsElementViewTransition) {
  // safe to call element.startViewTransition()
} else {
  // fallback animation (CSS transition) or no-op
}

Navigation API — intercept a navigation (pattern)

navigation.addEventListener('navigate', (event) => {
  const url = new URL(event.destination.url);
  if (url.pathname.startsWith('/articles/')) {
    event.intercept({
      async handler() {
        const html = await fetch(event.destination.url).then(r => r.text());
        document.getElementById('app').innerHTML = html;
      },
      // Optionally use precommitHandler to warm caches or prepare state before commit
      // Use focusReset: 'manual' or 'after-transition', scroll: 'after-transition' to
      // coordinate with view transitions and custom focus/scroll behavior.
    });
  }
});

Notes: intercept() accepts handler, precommitHandler, focusReset, and scroll options. Use focusReset and scroll to match the browser's default behavior where needed.

Element-scoped View Transitions — scope a transition to a container (Chrome 147+)

const container = document.querySelector('#list');
if (container?.startViewTransition) {
  container.startViewTransition(() => {
    container.innerHTML = renderNewList(items);
  });
} else {
  // fallback: animate via CSS transitions on opacity/transform
  container.innerHTML = renderNewList(items);
}

Preload critical image (non-Next)

<link rel="preload" as="image" href="/hero.avif" type="image/avif" fetchpriority="high">

Use startTransition for responsiveness (React)

import { startTransition, useState } from 'react';

function Search({ onFilter }) {
  const [q, setQ] = useState('');
  function handleChange(e) {
    const v = e.target.value;
    setQ(v);
    startTransition(() => onFilter(v));
  }
  return <input value={q} onChange={handleChange} />;
}

Decision tree

• LCP > 2.5s → Run Lighthouse v13.1.0+ → identify LCP element → preload + modern formats → check server/TTFB
• CLS > 0.1 → Add explicit dimensions / aspect-ratio placeholder → use skeletons → consider element-scoped view transitions
• INP > 200ms → Profile handlers → startTransition / debounce → offload to Web Worker
• SPA navigation issues → Replace manual history handling with Navigation API intercept() and integrate view transitions when available
• Baseline compatibility warnings in Lighthouse → follow audit suggestions for polyfills or feature-gating; verify behavior on target browsers before suppressing

Edge cases and gotchas

• Baseline audits may surface platform-specific feature gaps; don't suppress findings without testing — they can cause user-visible regressions.
• Element-scoped view transitions are documented and recommended in Chrome 147, but not all browsers implement them. Always provide graceful fallbacks for older browsers and prefer nested groups where it limits snapshot scope.
• Navigation API intercept() changes how focus/scroll restoration is handled — use focusReset and scroll options to preserve expected behavior.
• Use WebDX trace signals as diagnostic hints: they point to feature usage in traces but do not automatically identify causation — correlate with CPU, long tasks, and priority tasks.
• Lighthouse's Baseline audit and WebDX trace category are diagnostic tools — verify findings with real-device RUM when the user base includes non-Chromium browsers.

Evaluation checklist

• Run Lighthouse (v13.1.0+) and address Baseline audit findings
• LCP element identified and preloaded or prioritized
• Images/videos have width/height or aspect-ratio placeholders
• Skeletons reserve space for async content
• Fonts use display: swap or next/font equivalents
• Heavy work moved to Web Worker when necessary
• Non-urgent updates use startTransition
• SPAs use Navigation API intercept() (where supported) instead of custom pushState hacks
• Element-scoped view transitions applied where they reduce CLS

Examples and tooling

• Next.js Image: use priority, sizes, and width/height
• Code-splitting: dynamic imports and analyze with source-map-explorer or Next.js ANALYZE tooling
• Web Workers: move CPU-heavy tasks off main thread
• Virtualization: use @tanstack/react-virtual for long lists

Research-backed signals (sources)

• Lighthouse changelog — v13.1.0 (2026-04-03): Baseline compatibility audit added, baseline icons and web-feature version added, Baseline audit added to the default config, and WebDX trace category added to traces. (https://raw.githubusercontent.com/GoogleChrome/lighthouse/main/changelog.md)
• Chrome Developer Blog / Docs — element-scoped view transitions (Chrome 147 stable, Mar 27, 2026). (https://developer.chrome.com/docs/css-ui/view-transitions/)
• web.dev — "Navigation API - a better way to navigate, is now Baseline Newly Available" (Feb 17, 2026). (https://web.dev/blog/baseline-navigation-api?hl=en)
• MDN — NavigateEvent.intercept() documentation (options: handler, precommitHandler, focusReset, scroll). (https://developer.mozilla.org/en-US/docs/Web/API/NavigateEvent/intercept)

Follow-up experiments

• A/B test element-scoped view transitions on representative pages to quantify CLS and engagement changes across Chrome vs. other browsers.
• Track CrUX and RUM datasets for LCP/INP after wider Baseline availability to compare Chromium-only CrUX vs. fuller RUM coverage.
• Validate Lighthouse Baseline audit findings across three major frameworks (Next.js, React SPA, SvelteKit) and document common remediation patterns.