## What's new (Apr 2026)
−- Lighthouse v13.1.0 (released 2026-04-03) adds a new "baseline" compatibility audit and includes it in the default Lighthouse config. The release also adds baseline icons and a web-feature version to the audit descriptions, making compatibility issues easier to scan. The v13.1.0 changelog notes the baseline audit PRs and related changes. Lighthouse traces now include a WebDX feature-usage trace category (v13.1.0) to make it easier to correlate feature usage with performance traces during debugging. The Lighthouse changelog and compare view are the primary sources for these details; the changelog also states the release is expected to appear in DevTools (Chrome 148 schedule) and PageSpeed Insights shortly after. (source: Lighthouse changelog — https://github.com/GoogleChrome/lighthouse/blob/main/changelog.md)
+- Lighthouse v13.1.0 (2026-04-03) adds a Baseline compatibility audit, baseline icons, and web-feature version metadata to audit descriptions, and includes the baseline audit in the default Lighthouse config. The release also adds a WebDX feature-usage trace category to Lighthouse traces to help correlate feature usage with performance hotspots. (source: Lighthouse changelog v13.1.0 — https://raw.githubusercontent.com/GoogleChrome/lighthouse/main/changelog.md)
−- LCP and INP were marked Baseline Newly available across major browsers when browsers added the required LCP and Event Timing APIs in late 2025. This improves cross‑browser field measurement outside Chromium and helps RUM tools capture more complete interactivity and load metrics. Note: CrUX remains Chromium-derived; use broader RUM where your audience includes non‑Chromium browsers. (source: web.dev)
+- Chrome: Element-scoped view transitions (Element.startViewTransition()) reached stable documentation and practical guidance in Chrome 147 (published Mar 27, 2026). Use element-scoped transitions to limit snapshotting and layering side effects compared to document-scoped transitions. (source: Chrome docs — https://developer.chrome.com/docs/css-ui/view-transitions/element-scoped-view-transitions/)
−- Navigation API (NavigateEvent.intercept()) became Baseline Newly available in early 2026. Use it to intercept navigations in SPAs instead of brittle pushState/popstate handlers; intercept() provides handler, precommitHandler, focusReset, and scroll options to control commit, focus, and scroll restoration. Feature-detect before use and provide graceful fallbacks for browsers that don't support it. (source: MDN / web.dev)
+- Navigation API: NavigateEvent.intercept() is listed as Baseline Newly available (early 2026). The API exposes handler and precommitHandler callbacks and options for focusReset and scroll; use it to implement robust SPA navigation with explicit control over commit, focus, and scroll behavior. Feature-detect and fallback to your router when unsupported. (source: MDN — https://developer.mozilla.org/en-US/docs/Web/API/NavigateEvent/intercept and web.dev announcement)
−- Element-scoped view transitions are available in Chrome Stable from version 147 (published Mar 27, 2026). Use Element.startViewTransition() to scope transitions to a subtree, enable concurrent and nested transitions, and reduce global layout shifts; always provide fallbacks where unsupported. (source: Chrome Developer Blog / Chrome docs)
+- LCP and INP: Baseline availability improved in late 2025—this broadens field-measurement coverage outside Chromium and helps RUM capture interactivity and load metrics consistently. CrUX remains Chromium-derived; if your audience uses non‑Chromium browsers, collect RUM directly or use a broader provider. (source: web.dev)
## Core concepts
@@ −36 +36 @@
- CLS: Good < 0.1; Needs work 0.1–0.25; Poor > 0.25
- INP: Good < 200ms; Needs work 200–500ms; Poor > 500ms
−These thresholds remain the recommended targets used by Google guidance and Lighthouse as of Apr 2026. For INP, refer to the INP guidance for measurement details and how the metric is calculated (it reports the longest observed interaction latency, with outlier mitigation for very interaction-heavy pages). (source: web.dev)
+These thresholds are current 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 introduces a baseline compatibility audit that:
+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.
−- Shows a web-feature version and baseline icons in the audit description to make compatibility issues easier to scan.
+- Is included in the default Lighthouse config, so standard runs will surface compatibility signals.
−- Is included in the default Lighthouse config, so unmodified runs will surface these findings.
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.
−- Treat baseline findings as compatibility signals, not optional style nitpicks. Test on the target platforms before suppressing recommendations.
+- Use the WebDX trace category in Lighthouse traces to correlate baseline feature usage with performance hotspots during triage.
−- Use the audit's web-feature name and version to determine whether to polyfill, gate features behind feature detection, or provide alternate code paths.
−- Use the WebDX trace category in Lighthouse traces (v13.1.0) to correlate feature-usage events with performance hotspots when investigating baseline-related problems.
## Rendering pipeline reminder
@@ −57 +57 @@
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
−1. Run Lighthouse (CLI or DevTools) using v13.1.0+ (released 2026-04-03) and capture a lab report. Expect v13.1.0 to appear in DevTools around the Chrome 148 update and in PageSpeed Insights shortly after the release (changelog note). Collect field data (RUM) where available. The baseline compatibility audit is present in the default config and will list platform-compatibility issues; the audit description includes a web-feature name and version to make triage faster.
+ - 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
−2. Identify the LCP element
+ - Chrome DevTools → Performance → record a page load → locate the LCP marker and the associated element in the Summary/Timings.
− - Chrome DevTools → Performance → record a page load → locate the LCP marker and associated element.
+4. Optimize the LCP element
+ - Preload critical images (<link rel="preload" as="image"> or framework-specific priority attributes)
−3. Optimize the LCP element
+ - Serve modern formats (AVIF/WebP) with CDN transforms and configure long caches
− - Preload critical images (<link rel="preload" as="image"> or Next.js priority attribute)
− - Serve modern formats (AVIF/WebP) with CDN image transforms and configure long caches
- Optimize server TTFB for critical content (edge caching, SSR tuning)
−4. Prevent CLS
+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.
−5. Improve INP
+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
−6. 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.
− - Replace fragile pushState/popstate implementations with NavigateEvent.intercept() for in-place navigations. 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 provide graceful fallback to your existing router where not supported.
−7. Audit bundle size and third-party scripts
+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
@@ −89 +92 @@
### Feature-detect element-scoped view transitions
```js
+const supportsElementViewTransition = !!(Element && Element.prototype && Element.prototype.startViewTransition);
−if (document.documentElement.startViewTransition ||
+if (supportsElementViewTransition) {
− (Element && Element.prototype && Element.prototype.startViewTransition)) {
