# Unlighthouse
> Google Lighthouse for your entire site.
Canonical Origin: https://unlighthouse.dev
## LLM Resources
- [Full Content](https://unlighthouse.dev/llms-full.txt)
Complete page content in markdown format.
- [MCP](https://unlighthouse.dev/mcp)
Model Context Protocol server endpoint for AI agent integration.
## Pages
### Unlighthouse
Source: https://unlighthouse.dev/
Description: Google Lighthouse for your entire site.
h1. **Lighthouse for your **entire site
Crawl every page, run Google Lighthouse audits, get one unified performance report.
$npxunlighthouse--siteexample.com
[**Get Started **](https://unlighthouse.dev/guide/getting-started/installation) [** GitHub **](https://github.com/harlan-zw/unlighthouse)
Node 20+ · MIT licensed · Zero config
localhost:5678
h2. **Why Unlighthouse **
h3. **Parallel Scans **
Threaded workers with opportunistic throttling for fast audits.
h3. **Auto Crawling **
Discovers URLs via robots.txt, sitemap.xml, and internal links.
h3. **Smart Sampling **
Auto-samples dynamic routes to reduce scan time.
h3. **Modern UI **
Search, sort, and re-scan pages in the Vite-powered client.
h3. **SEO Insights **
Titles, meta descriptions, share images, link analysis.
h3. **A11y Summary **
Accessibility audit with contrast issue visualization.
**3.3K**
downloads per day
98K
monthly downloads
4.4K
GitHub stars
h2. **Community Funded **
Unlighthouse is free and open-source thanks to generous community sponsors.
[**Become a sponsor **](https://github.com/sponsors/harlan-zw)
h3. **Top Sponsors **
[**Daniel Roe**](https://roe.dev) [**Laioutr GmbH**](https://laioutr.com) [**Alex**](https://alexfriesen.net)
h3. **Gold Sponsors **
[](https://localazy.com) [](https://massivemonster.co)
h3. **Backers **
[](https://itinsights.org) [](https://github.com/mgifford) [](https://github.com/timhanlon) [](https://github.com/Idrinth) [](https://github.com/milos018) [](https://github.com/aussieboi) [](https://ducrot.de) [](https://github.com/just-maik) [](https://adkit.so) [](https://reshepe.dev) [](https://froggly.pl) [](https://github.com/PetyXbron) [](https://github.com/jpsc) [](https://fume.app)
---
### Free Lighthouse & Core Web Vitals Tools · Unlighthouse
Source: https://unlighthouse.dev/tools
Description: Free bulk Core Web Vitals checker, Lighthouse score calculator, CLS debugger, LCP finder, and more. Test multiple pages at once with no signup.
h1. **Performance **Tools
Free interactive tools to understand and improve your Lighthouse scores.
[
**Bulk PageSpeed Test**
Test up to 10 URLs at once with PageSpeed Insights. Get performance scores for multiple pages in one batch.**Batch Testing****Performance****Core Web Vitals**](https://unlighthouse.dev/tools/bulk-pagespeed) [
**Core Web Vitals Checker**
Check if your page passes Google's Core Web Vitals. Test LCP, CLS, and INP with lab and real user data.**LCP****CLS****INP****Core Web Vitals**](https://unlighthouse.dev/tools/cwv-checker) [
**Core Web Vitals History**
Track real user performance over 25 weeks. See how your LCP, CLS, and INP trends change over time with CrUX data.**Field Data****Trends****CrUX**](https://unlighthouse.dev/tools/cwv-history) [
**TTFB Checker**
Test Time to First Byte with real Chrome user data. Compare field vs lab TTFB and track server response trends.**TTFB****Server Response****CrUX**](https://unlighthouse.dev/tools/ttfb-checker) [
**CWV Compare**
Compare Core Web Vitals across multiple websites. Benchmark your site against competitors with real Chrome user data.**Competitor Analysis****CrUX****Benchmarking**](https://unlighthouse.dev/tools/cwv-compare) [
**Lighthouse Report Viewer**
Upload your Lighthouse JSON report to visualize scores, metrics, and audits interactively.**All Categories****Audits****Metrics**](https://unlighthouse.dev/tools/lighthouse-report-viewer) [
**Lighthouse Score Calculator**
Calculate your performance score interactively. Adjust metrics to see how they impact your overall Lighthouse score.**FCP****SI****LCP****TBT****CLS**](https://unlighthouse.dev/tools/lighthouse-score-calculator) [
**LCP Element Finder**
Identify which element is your Largest Contentful Paint and get actionable recommendations to improve it.**LCP****Core Web Vital**](https://unlighthouse.dev/tools/lcp-finder) [
**INP Analyzer**
Analyze Interaction to Next Paint issues. Find slow event handlers and optimize responsiveness.**INP****Core Web Vital**](https://unlighthouse.dev/tools/inp-analyzer) [
**CLS Debugger**
Debug Cumulative Layout Shift issues. Identify elements causing unexpected layout shifts.**CLS****Core Web Vital**](https://unlighthouse.dev/tools/cls-debugger) [
**HAR File Viewer**
Analyze HTTP Archive files with network waterfall, request timing, resource breakdown, and protocol distribution. Entirely client-side.**Network Waterfall****Request Analysis****Performance**](https://unlighthouse.dev/tools/har-viewer) [
**JSON Size Analyzer**
Calculate JSON payload size with minification savings, gzip/brotli estimates, key contributions, and duplicate key analysis. Entirely client-side.**Size Analysis****Minification****Compression**](https://unlighthouse.dev/tools/json-size) [
**Page Size Checker**
Test page weight with resource breakdown, third-party analysis, unused code detection, and HTTP Archive percentile comparison.**Page Weight****Resources****Third Parties**](https://unlighthouse.dev/tools/page-size) [
**PageSpeed Insights Performance**
Get detailed PageSpeed Insights performance data with field and lab metrics.**Performance****Field Data**](https://unlighthouse.dev/tools/pagespeed-insights-performance)
---
### Bulk PageSpeed & Core Web Vitals Test - Free Multi-URL Tool · Unlighthouse
Source: https://unlighthouse.dev/tools/bulk-pagespeed
Description: Free bulk Core Web Vitals and PageSpeed test. Check LCP, CLS, INP for up to 10 URLs at once. Get Lighthouse scores and CWV pass/fail for multiple pages.
h1. **Bulk PageSpeed **Test
Test up to 10 URLs at once with Google's PageSpeed Insights API. Get Lighthouse performance scores, Core Web Vitals, and optimization insights.
**Bulk PageSpeed Test**
**Enter URLs **(one per line, max 10)
0/10 URLs
Device:
Enter URLs to run a bulk PageSpeed test
Test up to 10 URLs at once
h2. **Frequently Asked Questions **
**01**
h3. **What is bulk PageSpeed testing?**
Bulk PageSpeed testing lets you analyze multiple URLs simultaneously using the PageSpeed Insights API. Instead of testing pages one at a time, you can submit up to 10 URLs and get Lighthouse performance scores, Core Web Vitals, and audit results for all pages at once.
**02**
h3. **How do I use the PageSpeed Insights API for bulk testing?**
The PageSpeed Insights API (pagespeedonline/v5/runpagespeed) accepts a URL parameter and returns Lighthouse results as JSON. This tool handles the API calls for you, but for programmatic access you can call the API directly with your own API key for higher rate limits.
**03**
h3. **Is there a limit to bulk PageSpeed testing?**
This free tool allows testing up to 10 URLs at once. The PageSpeed Insights API has rate limits (400 requests per day for anonymous users, 25,000 with an API key). For scanning entire sites with hundreds of pages, use Unlighthouse CLI instead.
**04**
h3. **What metrics does bulk PageSpeed testing show?**
Each URL gets a full Lighthouse audit including: Performance score (0-100), Core Web Vitals (LCP, CLS, TBT/INP), First Contentful Paint, Speed Index, and a pass/fail summary. Results help identify which pages need optimization.
**05**
h3. **When should I use bulk testing vs full site scanning?**
Use bulk testing for quick checks of specific pages like landing pages, product pages, or comparing competitor URLs. For comprehensive site-wide analysis with all pages automatically discovered, use Unlighthouse CLI which crawls your sitemap and tests every page.
h3. **Related Guides **
[**Fix LCP Issues **](https://unlighthouse.dev/learn-lighthouse/lcp) [** Fix CLS Issues **](https://unlighthouse.dev/learn-lighthouse/cls) [** Bulk Testing Guide **](https://unlighthouse.dev/learn-lighthouse/bulk-lighthouse-testing)
h3. **Need to scan your entire site? **
Unlighthouse automatically discovers and audits hundreds of pages on your site. Get comprehensive performance insights with a single command.
$ npx unlighthouse --site example.com
[**Try Unlighthouse CLI (Free) **](https://unlighthouse.dev/guide/getting-started) [** Schedule with Cloud **](https://unlighthouse.dev/cloud)
---
### Core Web Vitals Test - Free CWV Checker · Unlighthouse
Source: https://unlighthouse.dev/tools/cwv-checker
Description: Check if your page passes Google's Core Web Vitals. Test LCP, CLS, and INP with lab and real user data. Free tool with actionable recommendations.
h1. **Core Web Vitals **Test
Check if your page passes Google's Core Web Vitals with lab and real user data.
**Core Web Vitals Assessment**
Enter a URL to check Core Web Vitals
h2. **Frequently Asked Questions **
**01**
h3. **What are Core Web Vitals?**
Core Web Vitals are three metrics Google uses to measure user experience: LCP (loading speed), CLS (visual stability), and INP (interactivity). They are a confirmed ranking factor in Google Search.
**02**
h3. **What is a good Core Web Vitals score?**
Good scores are: LCP under 2.5 seconds, CLS under 0.1, and INP under 200 milliseconds. To pass Core Web Vitals, at least 75% of page loads must meet the "good" threshold for all three metrics.
**03**
h3. **What's the difference between Lab and Field data?**
Lab data is collected in a controlled environment (Lighthouse). Field data is from real users via the Chrome User Experience Report (CrUX). Field data is what Google uses for ranking, but lab data helps diagnose issues.
**04**
h3. **Do Core Web Vitals affect SEO?**
Yes. Core Web Vitals are a confirmed Google ranking factor as part of page experience signals. Pages that pass CWV may have a ranking advantage over those that don't, especially for competitive queries.
h3. **Optimize Your Core Web Vitals **
[**Fix LCP **](https://unlighthouse.dev/learn-lighthouse/lcp) [** Fix CLS **](https://unlighthouse.dev/learn-lighthouse/cls) [** Fix INP **](https://unlighthouse.dev/learn-lighthouse/inp) [** Full Guide **](https://unlighthouse.dev/learn-lighthouse/core-web-vitals)
---
### Learn Lighthouse & Web Vitals: Performance Guides · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse
Description: Free guides to improve Lighthouse scores and Core Web Vitals. Fix LCP, CLS, INP, accessibility, and SEO audits with actionable tutorials and tools.
h1. **Learn Google Lighthouse**
Guides and tutorials for improving your site's Core Web Vitals and performance. All guides include authoritative citations from Google and real-world statistics.
h2. **Core Web Vitals **
Core Web Vitals are [Google's ranking factor](https://developers.google.com/search/docs/appearance/core-web-vitals) for measuring user experience. Only [48% of mobile sites](https://almanac.httparchive.org/en/2024/performance) currently pass all three metrics.
[**59%** mobile pass rate
**Largest Contentful Paint (LCP)**
Improve loading performance. Only 59% of mobile sites pass.](https://unlighthouse.dev/learn-lighthouse/lcp) [**79%** mobile pass rate
**Cumulative Layout Shift (CLS)**
Eliminate layout shifts. 79% of mobile sites pass.](https://unlighthouse.dev/learn-lighthouse/cls) [**New** replaced FID
**Interaction to Next Paint (INP)**
Make interactions responsive. Replaced FID in March 2024.](https://unlighthouse.dev/learn-lighthouse/inp)
h2. **Guides **
[
**Core Web Vitals Overview**
What they measure, why they matter, and how to test them.](https://unlighthouse.dev/learn-lighthouse/core-web-vitals) [
**Bulk Lighthouse Testing**
Test every page, not just the homepage.](https://unlighthouse.dev/learn-lighthouse/bulk-lighthouse-testing) [
**Lighthouse CI**
Automate audits in your CI/CD pipeline with @lhci/cli.](https://unlighthouse.dev/learn-lighthouse/lighthouse-ci) [
**PageSpeed Insights API**
Fetch Lighthouse data programmatically with Node.js or Python.](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api) [
**PSI vs Lighthouse**
Why scores differ between PageSpeed Insights and local Lighthouse.](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-vs-lighthouse) [
**Lighthouse with Playwright**
Run audits on authenticated pages and SPAs.](https://unlighthouse.dev/learn-lighthouse/playwright)
h2. **Audit Categories **
[
**SEO Audits**
All 8 Lighthouse SEO checks explained with fixes.](https://unlighthouse.dev/learn-lighthouse/seo) [
**Accessibility**
16 audit guides covering ARIA, contrast, and screen readers.](https://unlighthouse.dev/learn-lighthouse/accessibility) [
Test multiple URLs at once with the PageSpeed Insights API.](https://unlighthouse.dev/tools/bulk-pagespeed) [
**Core Web Vitals Checker**
Check if a page passes all three Core Web Vitals.](https://unlighthouse.dev/tools/cwv-checker) [
**CWV Comparison**
Compare Core Web Vitals across 2-4 sites side-by-side.](https://unlighthouse.dev/tools/cwv-compare)
h3. **Test Your Entire Site **
Most tools only test one page at a time. Unlighthouse scans your entire site and shows scores for every page.
[**Get Started **](https://unlighthouse.dev/guide/getting-started/installation)
---
### Lighthouse Scoring Calculator - Calculate Performance Scores · Unlighthouse
Source: https://unlighthouse.dev/tools/lighthouse-score-calculator
Description: Free interactive Lighthouse scoring calculator. See how FCP, LCP, TBT, CLS, and Speed Index weights and thresholds determine your Lighthouse performance score. Enter your metrics to calculate your score.
h1. **Lighthouse Score **Calculator
See exactly how each metric contributes to your performance score.
**Lighthouse v13 Scoring**
**82**
**First Contentful Paint**
1.8s**82**
0msTime until first text or image is painted9.0s
**Speed Index**
3.4s**82**
0msHow quickly content visually populates17.4s
**Largest Contentful Paint**** CWV **
2.5s**82**
0msTime until largest content element is visible12.0s
**Total Blocking Time**
200ms**82**
0msSum of blocking time for long tasks1.8s
**Cumulative Layout Shift**** CWV **
0.10**82**
0.00Movement of visible elements during load1.00
**FCP** +8
**SI** +8
**LCP** +20
**TBT** +25
**CLS** +20
=
**82**/ 100
Share:``
h2. **How Lighthouse Calculates Your Performance Score **
Lighthouse calculates your performance score using a **weighted average** of five key metrics. Each metric is scored from 0-100 using a [log-normal distribution](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) based on real-world performance data from the [HTTP Archive](https://httparchive.org/).
The scoring algorithm converts raw metric values (like milliseconds or unitless shift scores) into a 0-100 score using statistical curves. A metric value at the **10th percentile** of all sites scores 90 (good), while the **median** scores 50. This means your score reflects how your site compares to others on the web.
h3. **v10+ Score Weights **
**TBT**
30%
**LCP****CWV**
25%
**CLS****CWV**
25%
**FCP**
10%
**SI**
10%
**80%** of your score comes from TBT, LCP, and CLS.
h3. **The Log-Normal Scoring Algorithm **
Lighthouse doesn't use simple linear scoring. Instead, it applies a **log-normal distribution** to convert raw metric values into scores. This statistical approach means:
- **Diminishing returns** — Improving from 95 to 100 requires more effort than 50 to 55
- **Based on real data** — Curves calibrated against millions of real websites
- **Percentile-based** — Score of 90 means better than 90% of sites
Each metric has two key control points: the **p10 value** (scores 90) and the **median** (scores 50).
**LCP Scoring Curve (Example) **
100
90
50
0
0s
**2.5s**
**4.0s**
8s
**p10 = 90**
**Score**
**Metric Value →**
Good Needs Work Poor
Source: [Chrome Developers - Lighthouse Performance Scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring)
h3. **Core Web Vitals **
Google's essential metrics for page experience ranking
Core Web Vitals are Google's official metrics that affect your search rankings. As of March 2024, they consist of **LCP**, **CLS**, and **INP** (which replaced FID). To pass, 75% of page visits must meet the "good" threshold for all three.
**LCP****25%**
h4. **Largest Contentful Paint **
Time for the largest visible element to render—when users perceive the page as "loaded."
**Thresholds **
0s**≤2.5s**4.0s6s+
**What affects LCP **
[→ Slow server response](https://unlighthouse.dev/learn-lighthouse/lcp/slow-server-response) [→ Render-blocking resources](https://unlighthouse.dev/learn-lighthouse/lcp/render-blocking-resources) [→ Large unoptimized images](https://unlighthouse.dev/learn-lighthouse/lcp/large-images) [→ Client-side rendering](https://unlighthouse.dev/learn-lighthouse/lcp/client-side-rendering)
[**Complete LCP Guide **](https://unlighthouse.dev/learn-lighthouse/lcp)
**CLS****25%**
h4. **Cumulative Layout Shift **
Visual stability—how much elements move unexpectedly as the page loads.
**Thresholds **
0**≤0.1**0.250.5+
**What affects CLS **
[→ Unsized images](https://unlighthouse.dev/learn-lighthouse/cls/unsized-images) [→ Ads/embeds/iframes](https://unlighthouse.dev/learn-lighthouse/cls/ads-embeds-iframes) [→ Dynamic content injection](https://unlighthouse.dev/learn-lighthouse/cls/dynamic-content-injection) [→ Web fonts causing FOIT](https://unlighthouse.dev/learn-lighthouse/cls/web-fonts-causing-foit)
[**Complete CLS Guide **](https://unlighthouse.dev/learn-lighthouse/cls)
**INP****via TBT**
h4. **Interaction to Next Paint **
Responsiveness—delay between user interactions and visual response. Lighthouse uses TBT as a proxy.
**Thresholds **
0ms**≤200ms**500ms800ms+
**What affects INP **
[→ Long-running JavaScript](https://unlighthouse.dev/learn-lighthouse/inp/long-running-javascript) [→ Event handler delays](https://unlighthouse.dev/learn-lighthouse/inp/event-handler-delays) [→ Large DOM size](https://unlighthouse.dev/learn-lighthouse/inp/dom-size) [→ Third-party scripts](https://unlighthouse.dev/learn-lighthouse/inp/third-party-scripts)
[**Complete INP Guide **](https://unlighthouse.dev/learn-lighthouse/inp)
h3. **Other Performance Metrics **
Additional metrics that affect your Lighthouse score
Beyond Core Web Vitals, Lighthouse measures additional metrics. **TBT carries the highest weight (30%)** because it directly correlates with how responsive your page feels.
**TBT****30%**
**Total Blocking Time **
Main thread blocking time >50ms. Lab proxy for INP.
0≤200ms600ms1s+
**FCP****10%**
**First Contentful Paint **
First text or image rendered.
0≤1.8s3s5s+
**SI****10%**
**Speed Index **
How quickly visible content is populated.
0≤3.4s5.8s10s+
**TTFB****diagnostic**
**Time to First Byte **
Server response time—not scored but delays all metrics.
0≤200ms600ms1s+
h3. **Understanding Score Thresholds **
Lighthouse assigns color-coded ratings based on your final weighted score.
**90+ **
**Good **
Performs well for most users
**50-89 **
**Needs Work **
Some users may experience delays
**0-49 **
**Poor **
Most users will have issues
**Was this tool helpful? **
Your feedback helps us improve
h2. **Frequently Asked Questions **
**01**
h3. **How does Lighthouse calculate the performance score?**
Lighthouse calculates performance score as a weighted average of six metrics: First Contentful Paint (10%), Speed Index (10%), Largest Contentful Paint (25%), Total Blocking Time (30%), and Cumulative Layout Shift (25%). Each metric is scored 0-100 using log-normal curves based on real-world data from HTTPArchive.
**02**
h3. **Why do my Lighthouse scores vary between runs?**
Lighthouse scores can vary 5-10 points between runs due to: network conditions, server response time variations, third-party script loading, background processes on your device, and variability in JavaScript execution. Run multiple tests and use the median score for accuracy.
**03**
h3. **What is a good Lighthouse performance score?**
A score of 90-100 is considered good (green), 50-89 needs improvement (orange), and 0-49 is poor (red). Focus on reaching 90+ but don't obsess over perfect 100—the last few points have diminishing returns and normal variance makes it impractical.
**04**
h3. **Which metrics have the biggest impact on Lighthouse score?**
Total Blocking Time (30%) and Largest Contentful Paint (25%) together account for 55% of your score. CLS adds another 25%. To improve your score quickly, focus on reducing JavaScript execution time (TBT) and optimizing your largest above-the-fold element (LCP).
**05**
h3. **Why is my PageSpeed Insights score different from Chrome DevTools?**
PageSpeed Insights tests from Google's servers with a simulated mobile device, while Chrome DevTools uses your local machine and network. PSI also shows field data from real Chrome users (CrUX) which reflects actual user experience and may differ significantly from lab results.
h3. **Test Your Entire Site **
Your homepage might score 100, but what about the rest? Scan every page to find issues site-wide.
[**Get Started **](https://unlighthouse.dev/guide/getting-started/installation) [**Learn more about Core Web Vitals **](https://unlighthouse.dev/learn-lighthouse/core-web-vitals)
---
### Core Web Vitals History - Track Performance Over Time · Unlighthouse
Source: https://unlighthouse.dev/tools/cwv-history
Description: Free CrUX history viewer. Track 25 weeks of LCP, CLS, and INP trends from real Chrome users. Monitor Core Web Vitals changes over time.
h1. **Core Web Vitals **History
Track Core Web Vitals trends over time with 25 weeks of real Chrome user data.
**CrUX Historical Data**
Enter a domain to view CrUX history
Tracks real Chrome user data over 25 weeks
h3. **Optimize Your Core Web Vitals **
[**Full Guide **](https://unlighthouse.dev/learn-lighthouse/core-web-vitals) [** Fix LCP **](https://unlighthouse.dev/learn-lighthouse/lcp) [** Fix CLS **](https://unlighthouse.dev/learn-lighthouse/cls) [** Fix INP **](https://unlighthouse.dev/learn-lighthouse/inp)
h2. **Frequently Asked Questions **
**01**
h3. **What is Core Web Vitals history data?**
CrUX (Chrome User Experience Report) stores 25 weeks of real user performance data for sites with sufficient traffic. This historical data shows how your Core Web Vitals (LCP, CLS, INP) have changed over time, helping you track improvement or detect regressions.
**02**
h3. **Where does this historical performance data come from?**
Historical data comes from CrUX, Google's dataset of real Chrome user experiences. Google collects anonymized performance metrics from Chrome users who have opted in. The data represents the 75th percentile (p75) of real user experiences over 28-day rolling periods.
**03**
h3. **Why don't I see historical data for my site?**
CrUX only includes sites with sufficient traffic from Chrome users. New sites, low-traffic pages, or sites visited primarily by non-Chrome browsers may not have data. Origin-level data aggregates all pages and requires less traffic than URL-specific data.
**04**
h3. **What can I learn from Core Web Vitals trends?**
Trends help you: correlate performance changes with deployments, detect gradual degradation before users notice, measure the impact of optimizations over time, compare mobile vs desktop performance, and identify seasonal patterns affecting user experience.
**05**
h3. **How often is CrUX historical data updated?**
CrUX data is updated weekly with a new 28-day rolling window. Each data point represents the 75th percentile of user experiences during that collection period. This means changes you make today will start showing in the data within 1-4 weeks.
---
### Lighthouse Best Practices Guide · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/best-practices
Description: Master Lighthouse Best Practices audits. Learn what they measure, why they matter for security and UX, and how to pass every audit.
h1. **Lighthouse Best Practices Guide**
Master Lighthouse Best Practices audits. Learn what they measure, why they matter for security and UX, and how to pass every audit.
[Harlan Wilton](https://x.com/harlan_zw)6 min read Published **Jan 18, 2025**
Best Practices audits check whether your site follows established web standards for security, browser compatibility, and user experience. Unlike Performance metrics with thresholds and percentiles, these are binary: pass or fail.
A site can score 100 on Performance and still fail Best Practices because of a single console error or missing HTTPS. These audits catch the fundamentals that are easy to overlook but damage user trust.
h2. [What Best Practices Measures](#what-best-practices-measures)
The Best Practices score is a simple percentage of passed audits. 12 audits total, each weighted equally. Pass 10 of 12 and you score 83.
These audits fall into three categories:
- **Security** - Protecting users from attacks and data theft
- **Browser Compatibility** - Ensuring your site works across browsers and devices
- **User Experience** - Respecting user expectations and avoiding dark patterns
h2. [2025 SEO & Best Practices Landscape](#_2025-seo-best-practices-landscape)
As of 2025, adhering to these best practices is no longer just about passing a Lightouse audit—it's about survival in an AI-driven search landscape.
- **Answer Engine Optimization (AEO):** With AI Overviews now triggering for ~15% of queries, your technical foundation must support clear, structured data that AI can parse.
- **Engagement Reliability (ER):** A new 2025 Core Web Vital metric measuring interaction consistency. Console errors and layout shifts directly harm this score.
- **Ranking Factors:** "Consistent Publication of Satisfying Content" is now weighted at 23% of the algorithm, surpassing backlinks. Technical health is the prerequisite for this content to rank.
- **Zero-Click Reality:** ~60% of searches now end without a click. Rich results and schema are your only defense to capture value directly on the SERP.
- **Robots.txt & AI:** You must explicitly manage AI crawlers (e.g., GPTBot) in robots.txt separate from standard bots to control how your content feeds Answer Engines.
h2. [Security Audits](#security-audits)
Security audits verify your site protects users from common attack vectors.
| **Audit** | **What It Checks** | **Why It Matters** |
| --- | --- | --- |
| [**Uses HTTPS**](https://unlighthouse.dev/learn-lighthouse/best-practices/is-on-https) | Page loaded over secure connection | Prevents man-in-the-middle attacks, required for modern APIs |
| [**Redirects HTTP to HTTPS**](https://unlighthouse.dev/learn-lighthouse/best-practices/redirects-http) | HTTP requests redirect to HTTPS | Ensures users always land on secure version |
HTTPS is non-negotiable in 2025. Browsers flag HTTP sites as "Not Secure," many APIs refuse to work, and SEO suffers. If you're still on HTTP, this is priority zero.
h2. [Browser Compatibility Audits](#browser-compatibility-audits)
These audits check that your site works correctly across browsers and leverages modern web platform features.
| **Audit** | **What It Checks** | **Why It Matters** |
| --- | --- | --- |
| [**bfcache eligible**](https://unlighthouse.dev/learn-lighthouse/best-practices/bf-cache) | Page can use back/forward cache | Instant back navigation, better UX |
| [**Valid charset**](https://unlighthouse.dev/learn-lighthouse/best-practices/charset) | Character encoding declared properly | Prevents garbled text, accessibility issues |
| [**Valid DOCTYPE**](https://unlighthouse.dev/learn-lighthouse/best-practices/doctype) | HTML5 doctype present | Standards mode rendering, predictable behavior |
| [**Avoids deprecated APIs**](https://unlighthouse.dev/learn-lighthouse/best-practices/deprecations) | No deprecated browser APIs used | Future-proofing, avoiding breaking changes |
The bfcache audit is particularly impactful. When eligible, back/forward navigation is instant—the browser restores the page from memory rather than reloading. Users expect this behavior and notice when it's broken.
h2. [User Experience Audits](#user-experience-audits)
UX audits catch patterns that frustrate users or violate their expectations.
| **Audit** | **What It Checks** | **Why It Matters** |
| --- | --- | --- |
| [**No browser errors**](https://unlighthouse.dev/learn-lighthouse/best-practices/errors-in-console) | Console free of errors | Errors indicate broken functionality |
| [**No geolocation on start**](https://unlighthouse.dev/learn-lighthouse/best-practices/geolocation-on-start) | Geolocation not requested on load | Permission requests need user context |
| [**No notification on start**](https://unlighthouse.dev/learn-lighthouse/best-practices/notification-on-start) | Notifications not requested on load | Same principle—context before permission |
| [**Allows paste in passwords**](https://unlighthouse.dev/learn-lighthouse/best-practices/paste-preventing-inputs) | Password fields allow pasting | Password managers need paste support |
| [**Proper image sizing**](https://unlighthouse.dev/learn-lighthouse/best-practices/image-size-responsive) | Images sized appropriately for display | Prevents blurry or wasteful images |
| [**Correct aspect ratios**](https://unlighthouse.dev/learn-lighthouse/best-practices/image-aspect-ratio) | Images maintain aspect ratio | Prevents distorted images |
| [**No DevTools issues**](https://unlighthouse.dev/learn-lighthouse/best-practices/inspector-issues) | No issues flagged by DevTools | Catches various browser-detected problems |
The permission audits reflect a broader principle: never ask for permissions without user context. A geolocation prompt on page load feels invasive. The same prompt after clicking "Find stores near me" makes sense.
h2. [Scoring](#scoring)
Best Practices scoring is straightforward:
- **100** - All audits pass
- **92** - 11 of 12 pass
- **83** - 10 of 12 pass
- **75** - 9 of 12 pass
Each failed audit drops your score by about 8 points. Unlike Performance where partial improvements help, Best Practices is all-or-nothing per audit.
**Important:** A single console error drops you to 92. A missing HTTPS redirect drops you to 92. These are easy to miss during development but show up in production.
h2. [Common Failure Patterns](#common-failure-patterns)
**Third-party scripts:** Ad networks, analytics, and widgets often throw console errors or use deprecated APIs. You can't always fix these, but you can choose better vendors or load scripts conditionally.
**Development leftovers:** Debug logging, test console.log statements, and uncaught promise rejections that worked fine locally but fail in production.
**Legacy code:** Old APIs that still work but are deprecated. The site functions, but the audit fails. Refactoring takes time but avoids future breakage.
**Eager permission requests:** Marketing pressure to prompt for notifications immediately. This tanks user trust and fails the audit. Delay permission requests until users demonstrate intent.
h2. [How to Diagnose Issues](#how-to-diagnose-issues)
**Chrome DevTools:**
1. Open DevTools → **Console** tab
2. Look for red errors (not warnings)
3. Check **Issues** tab for browser-detected problems
4. Run Lighthouse audit from **Lighthouse** tab
**Key things to check:**
- Any JavaScript errors in console?
- Any deprecation warnings?
- What permission prompts appear on load?
- Is the page served over HTTPS?
- Does HTTP redirect to HTTPS?
h2. [All Best Practices Issues](#all-best-practices-issues)
Quick reference for every audit:
| **Audit** | **Category** | **Fix Guide** |
| --- | --- | --- |
| Uses HTTPS | Security | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/is-on-https) |
| Redirects HTTP to HTTPS | Security | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/redirects-http) |
| bfcache eligible | Browser | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/bf-cache) |
| Valid charset | Browser | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/charset) |
| Valid DOCTYPE | Browser | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/doctype) |
| Avoids deprecated APIs | Browser | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/deprecations) |
| No browser errors | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/errors-in-console) |
| No geolocation on start | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/geolocation-on-start) |
| No notification on start | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/notification-on-start) |
| Allows paste in passwords | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/paste-preventing-inputs) |
| Proper image sizing | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/image-size-responsive) |
| Correct aspect ratios | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/image-aspect-ratio) |
| No DevTools issues | UX | [**Fix**](https://unlighthouse.dev/learn-lighthouse/best-practices/inspector-issues) |
> [**Diagnose your specific issue**](https://unlighthouse.dev/learn-lighthouse/best-practices#all-best-practices-issues)
h2. [Test Your Entire Site](#test-your-entire-site)
The home page might pass Best Practices while blog posts throw console errors. The checkout flow might request permissions inappropriately. Dynamic pages might have image sizing issues that static pages don't.
[**Unlighthouse**](https://unlighthouse.dev/) scans your entire site and surfaces Best Practices scores for every page. You'll find console errors on obscure pages, permission prompts you forgot about, and deprecated APIs in legacy sections.
The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions—like when a third-party script update breaks your score.
[**Heading Order** Learn how to fix heading order issues in Lighthouse accessibility audits. Properly ordered headings convey semantic structure for easier navigation.](https://unlighthouse.dev/learn-lighthouse/accessibility/heading-order) [**Back/Forward Cache** Enable bfcache to make back button navigation instant. Learn common blockers and how to fix them.](https://unlighthouse.dev/learn-lighthouse/best-practices/bf-cache)
**On this page **
- [What Best Practices Measures](#what-best-practices-measures)
- [2025 SEO & Best Practices Landscape](#_2025-seo-best-practices-landscape)
- [Security Audits](#security-audits)
- [Browser Compatibility Audits](#browser-compatibility-audits)
- [User Experience Audits](#user-experience-audits)
- [Scoring](#scoring)
- [Common Failure Patterns](#common-failure-patterns)
- [How to Diagnose Issues](#how-to-diagnose-issues)
- [All Best Practices Issues](#all-best-practices-issues)
- [Test Your Entire Site](#test-your-entire-site)
---
### PageSpeed Insights API Guide · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api
Description: Complete guide to using the PageSpeed Insights API. Get Lighthouse performance data programmatically with 25,000 free requests per day.
h1. **PageSpeed Insights API Guide**
Complete guide to using the PageSpeed Insights API. Get Lighthouse performance data programmatically with 25,000 free requests per day.
[Harlan Wilton](https://x.com/harlan_zw)4 min read Published **Jan 18, 2025**
The PageSpeed Insights API returns Lighthouse performance data for any URL. Free tier gives you 25,000 requests per day.
h2. [What You Get](#what-you-get)
Every API response includes:
| **Data** | **Description** |
| --- | --- |
| Performance score | 0-100 Lighthouse score |
| Core Web Vitals | LCP, CLS, TBT lab data |
| Field data | Real Chrome user metrics (when available) |
| Opportunities | Specific optimization suggestions |
| Diagnostics | Detailed performance breakdowns |
The response combines lab data (Lighthouse synthetic tests) with field data from the Chrome User Experience Report when enough real user data exists for that URL.
**Note:** Google is [**discontinuing CrUX field data**](https://developers.google.com/speed/docs/insights/release_notes) in the PSI API. For field data, consider using the [**CrUX API**](https://developer.chrome.com/docs/crux/guides/crux-api) directly.
h2. [Quick Start](#quick-start)
Test any URL with a single curl command:
```
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&key=YOUR_API_KEY"
```
The API returns JSON with everything Lighthouse captures. No authentication beyond the API key.
h2. [When to Use the PSI API](#when-to-use-the-psi-api)
**Good for:**
- Spot-checking individual URLs programmatically
- Integrating performance scores into dashboards
- CI checks on critical landing pages
- Monitoring specific URLs over time
**Limitations:**
- Single URL per request
- Rate limited (~240 requests per minute)
- No crawling — you must provide URLs
- Lab data only for new/low-traffic URLs
h2. [API vs CLI vs Unlighthouse](#api-vs-cli-vs-unlighthouse)
| **Feature** | **PSI API** | **Lighthouse CLI** | **Unlighthouse** |
| --- | --- | --- | --- |
| URLs per request | 1 | 1 | Entire site |
| Rate limit | ~240/min | None | None |
| Infrastructure | Google servers | Your machine | Your machine |
| Cost | Free (25k/day) | Free | Free CLI |
| Field data | Yes | No | No |
| URL discovery | Manual | Manual | Automatic crawl |
The PSI API is useful when you need field data or want to avoid running Lighthouse locally. For site-wide testing, the single-URL limitation becomes impractical.
h2. [How It Works](#how-it-works)
PSI runs Lighthouse on Google's servers from [**one of four locations**](https://swiftperformance.io/tldr/pagespeed-insights-server-locations/): Oregon, South Carolina, Netherlands, or Taiwan. The location is chosen automatically based on your IP, which can affect score consistency for sites without a CDN.
- **Mobile tests** simulate a Moto G4 on a slow 4G connection with CPU throttling ([**source**](https://developers.google.com/speed/docs/insights/v5/about))
- **Desktop tests** run on a fast wired connection with no throttling
- **Lighthouse version:** Currently uses Lighthouse 13.0 — PWA category removed ([**release notes**](https://developers.google.com/speed/docs/insights/release_notes))
Scores can [**vary ±5 points**](https://support.nitropack.io/en/articles/8390477-pagespeed-insights-test-results-vary-with-a-few-points) between runs due to network conditions and server load. For accurate monitoring, run multiple tests and use the median.
h2. [Response Structure](#response-structure)
Key paths in the JSON response:
```
lighthouseResult.categories.performance.score → 0-1 (multiply by 100)
lighthouseResult.audits['largest-contentful-paint'].numericValue → LCP in ms
lighthouseResult.audits['cumulative-layout-shift'].numericValue → CLS score
lighthouseResult.audits['total-blocking-time'].numericValue → TBT in ms
loadingExperience.metrics → Field data (real users)
originLoadingExperience.metrics → Origin-level field data
```
The `loadingExperience` object contains real user metrics from CrUX. If the URL doesn't have enough traffic, this will be empty and you'll only get lab data.
h2. [Request Parameters](#request-parameters)
| **Parameter** | **Required** | **Description** |
| --- | --- | --- |
| `url` | Yes | URL to analyze |
| `key` | Yes | Your API key |
| `strategy` | No | `desktop` (default) or `mobile` |
| `category` | No | `performance`, `accessibility`, `seo`, `best-practices` (filter to reduce response size) |
| `locale` | No | Locale for the report (e.g., `en_US`) |
Request multiple categories by repeating the parameter:
```
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&key=YOUR_KEY&category=performance&category=accessibility"
```
**Tip:** Responses can be [**1-5MB**](https://www.debugbear.com/blog/pagespeed-insights-api). Filtering by category reduces response size significantly.
For origin-level CrUX data instead of URL-specific, use the [`origin:`** prefix**](https://gist.github.com/nickreese/3c3d05cc1502ea9de09c65bf7b796ced):
```
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=origin:https://example.com&key=YOUR_KEY"
```
h2. [Getting Started](#getting-started)
1. **[**Get your API key**](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api/get-api-key)** — 2-minute setup in Google Cloud Console
2. **Choose your language** — [**Node.js**](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api/node-example) or [**Python**](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api/python-example)
3. **Scale up** — [**Bulk testing guide**](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api/bulk-testing)
4. **Handle limits** — [**Rate limit strategies**](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api/rate-limits)
h2. [Skip the Complexity](#skip-the-complexity)
Testing URLs one at a time doesn't scale. Building queue systems, handling rate limits, and managing retries adds complexity that isn't your core product.
Unlighthouse crawls your entire site and runs Lighthouse on every page automatically. No API keys, no rate limits, no queue management.
```
npx unlighthouse --site https://your-site.com
```
For historical tracking and scheduled scans, [**Unlighthouse Cloud**](https://unlighthouse.dev/cloud) handles everything.
[Try Unlighthouse Cloud](https://unlighthouse.dev/)
[**Troubleshooting** Fix common Lighthouse CI issues: Chrome launch failures, score variance, shallow clone errors, upload problems, and more.](https://unlighthouse.dev/learn-lighthouse/lighthouse-ci/troubleshooting) [**Get API Key** Step-by-step guide to getting a free PageSpeed Insights API key from Google Cloud Console. Setup takes 2 minutes.](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-api/get-api-key)
**On this page **
- [What You Get](#what-you-get)
- [Quick Start](#quick-start)
- [When to Use the PSI API](#when-to-use-the-psi-api)
- [API vs CLI vs Unlighthouse](#api-vs-cli-vs-unlighthouse)
- [How It Works](#how-it-works)
- [Response Structure](#response-structure)
- [Request Parameters](#request-parameters)
- [Getting Started](#getting-started)
- [Skip the Complexity](#skip-the-complexity)
---
### Lighthouse SEO Audit: All 8 Checks Explained & How to Fix · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/seo
Description: Pass every Lighthouse SEO audit. Crawlability, canonical, meta description, robots.txt, hreflang, status codes — each check explained with fixes and examples.
h1. **Lighthouse SEO Audit: All 8 Checks Explained & How to Fix**
Pass every Lighthouse SEO audit. Crawlability, canonical, meta description, robots.txt, hreflang, status codes — each check explained with fixes and examples.
[Harlan Wilton](https://x.com/harlan_zw)6 min read Published **Jan 18, 2025**
Lighthouse SEO audits check whether search engines can find, crawl, and understand your pages. Unlike Core Web Vitals which measure user experience, SEO audits are binary: you either pass or fail.
**Important distinction:** [**Google doesn't use Lighthouse scores for rankings**](https://www.searchenginejournal.com/do-google-lighthouse-scores-affect-seo/425347/). John Mueller confirmed they use Core Web Vitals data separately from real users (CrUX), not lab scores. Lighthouse SEO audits are diagnostic tools—they help you find problems, but the score itself isn't a ranking factor.
A page can score 100 on Performance yet be invisible to Google because of a single misconfigured robots directive.
h2. [What Lighthouse SEO Measures](#what-lighthouse-seo-measures)
Lighthouse SEO focuses on technical SEO fundamentals—the stuff that makes or breaks whether your content even enters the index. It doesn't evaluate content quality, keyword optimization, or backlinks. Those matter, but they're meaningless if crawlers can't access your pages.
**SEO Score Weight:** The SEO category is equally weighted across all passing audits. One failure drops your score significantly.
h2. [Why SEO Audits Matter](#why-seo-audits-matter)
h3. [Crawlability = Visibility](#crawlability-visibility)
Google can't rank what it can't see. A `noindex` directive, broken canonical, or malformed robots.txt removes your page from search entirely. No amount of great content fixes that.
[**Research from Ahrefs**](https://ahrefs.com/blog/search-traffic-study/) shows 96.55% of pages get zero traffic from Google. Technical SEO issues are often the first barrier—fix those before worrying about content strategy.
Since [**July 5, 2024, mobile-first indexing is 100% universal**](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)—Google only uses the smartphone crawler. If your mobile version has less content or different robots directives than desktop, that's what gets indexed.
h3. [Indexability Problems are Silent](#indexability-problems-are-silent)
The frustrating part: you won't know something's wrong. Your site loads fine for users. Analytics looks normal (for the traffic you do get). But Google's crawler sees a brick wall.
Lighthouse catches these invisible issues before they cost you months of lost rankings.
h3. [Compound Effects](#compound-effects)
One bad canonical implementation affects every page using that template. One misconfigured hreflang breaks international SEO across your entire site. Technical SEO issues scale with your content.
h2. [All SEO Audits](#all-seo-audits)
Lighthouse runs 8 SEO audits. Each is pass/fail—no partial scores.
| **Audit** | **What It Checks** | **Why It Matters** |
| --- | --- | --- |
| [**Page isn't blocked from indexing**](https://unlighthouse.dev/learn-lighthouse/seo/is-crawlable) | `noindex` directives, robots.txt blocking | Blocked pages can't appear in search results |
| [**Document has a valid **`rel=canonical`](https://unlighthouse.dev/learn-lighthouse/seo/canonical) | Canonical URL validity, conflicts | Invalid canonicals confuse Google about the "real" URL |
| [**Document has a meta description**](https://unlighthouse.dev/learn-lighthouse/seo/meta-description) | Meta description presence | Missing descriptions hurt click-through rates |
| [**Document has a valid **`hreflang`](https://unlighthouse.dev/learn-lighthouse/seo/hreflang) | Language/region alternate links | Invalid hreflang breaks international targeting |
| [**Page has successful HTTP status code**](https://unlighthouse.dev/learn-lighthouse/seo/http-status-code) | HTTP 2xx response | 4xx/5xx errors prevent indexing |
| [**Links are crawlable**](https://unlighthouse.dev/learn-lighthouse/seo/crawlable-anchors) | Anchor href validity | Uncrawlable links block PageRank flow |
| [**Links have descriptive text**](https://unlighthouse.dev/learn-lighthouse/seo/link-text) | Link anchor text quality | Generic text ("click here") hurts SEO signals |
| [**robots.txt is valid**](https://unlighthouse.dev/learn-lighthouse/seo/robots-txt) | robots.txt syntax | Malformed robots.txt confuses all crawlers |
h3. [High Priority: Blocking Issues](#high-priority-blocking-issues)
These audits check whether your page can be indexed at all:
**Page isn't blocked from indexing** — Checks for `noindex` in meta tags, X-Robots-Tag headers, or robots.txt disallow rules. Failure means Google won't index the page. Note: [**noindex still wastes crawl budget**](https://developers.google.com/search/blog/2024/12/crawling-december-resources)—Google crawls the page before seeing the tag.
**Page has successful HTTP status code** — Checks for 4xx or 5xx responses. Pages returning errors aren't indexed.
**robots.txt is valid** — Parses your robots.txt for syntax errors. A malformed file might accidentally block your entire site.
h3. [Medium Priority: Ranking Signals](#medium-priority-ranking-signals)
These affect how well your page ranks and appears in results:
**Document has a valid rel=canonical** — Checks for conflicting canonicals, invalid URLs, or relative paths. Wrong canonicals can consolidate ranking to the wrong page.
**Document has a meta description** — Checks presence and content. Missing descriptions mean Google auto-generates snippets—often poorly.
**Links have descriptive text** — Flags generic anchor text like "click here" or "read more." Descriptive text helps Google understand link context.
h3. [Lower Priority: Edge Cases](#lower-priority-edge-cases)
These matter for specific use cases:
**Document has a valid hreflang** — Only relevant for multi-language sites. Checks for valid language codes and fully-qualified URLs.
**Links are crawlable** — Checks for `javascript:void(0)`, empty hrefs, or invalid URLs. Impacts PageRank flow and content discovery.
h2. [How to Measure SEO](#how-to-measure-seo)
h3. [Lighthouse (Per-Page)](#lighthouse-per-page)
Run Lighthouse in Chrome DevTools or via CLI:
```
lighthouse https://example.com --only-categories=seo
```
Check the SEO section for failing audits. Click each for specific elements causing failures.
h3. [PageSpeed Insights](#pagespeed-insights)
Enter your URL at [**PageSpeed Insights**](https://pagespeed.web.dev/). The SEO section shows both lab results and any field data issues.
h3. [Google Search Console](#google-search-console)
For production sites, Search Console is the authority:
- **Coverage report** shows indexing status
- **Core Web Vitals** shows real user data
- **URL Inspection** tests specific pages
h3. [Manual Crawler Checks](#manual-crawler-checks)
Test how Googlebot sees your page:
```
curl -A "Googlebot" https://example.com/
```
Check response headers for X-Robots-Tag:
```
curl -I https://example.com/ | grep -i x-robots
```
h2. [Common SEO Issues by Template Type](#common-seo-issues-by-template-type)
Different page types have different failure patterns:
| **Template** | **Common Issues** | **Quick Check** |
| --- | --- | --- |
| **Homepage** | Missing meta description, incorrect canonical | Usually fine |
| **Blog posts** | No canonical, generic link text | Check CMS output |
| **Product pages** | Blocked by robots.txt, 404s for variants | Test URL patterns |
| **Category pages** | Paginated canonical issues, duplicate content | Check pagination |
| **Search results** | Should be noindexed, but often aren't | Verify intentional |
| **User profiles** | Accidental noindex, thin content | Often should be blocked |
h2. [Fixing SEO Issues](#fixing-seo-issues)
Most SEO failures have straightforward fixes:
1. **Identify the scope** — Is it one page or a template affecting thousands?
2. **Check the source** — Is the issue in HTML, headers, or robots.txt?
3. **Fix at the right level** — Template fix vs. per-page override
4. **Verify the fix** — Re-run Lighthouse, check Search Console
→ [**See all SEO issues and fixes**](https://unlighthouse.dev/learn-lighthouse/seo#all-seo-audits)
h2. [Test Your Entire Site](#test-your-entire-site)
SEO issues love to hide. Your homepage passes while 500 blog posts have broken canonicals. Your main pages are fine but a template change silently added `noindex` to your product catalog.
Testing one URL at a time catches one problem at a time.
[**Unlighthouse**](https://unlighthouse.dev/) crawls your entire site and runs SEO audits on every page. You'll see exactly which pages fail each audit, which templates are misconfigured, and whether your fixes actually work at scale.
The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions—like when a deploy accidentally breaks your robots.txt.
[**Troubleshooting** Fix common issues when running Lighthouse with Playwright: port conflicts, authentication problems, flaky scores, and Chrome version mismatches.](https://unlighthouse.dev/learn-lighthouse/playwright/troubleshooting) [**Canonical URL** Resolve canonical tag errors that cause duplicate content issues and diluted page authority. Learn to implement rel=canonical correctly.](https://unlighthouse.dev/learn-lighthouse/seo/canonical)
**On this page **
- [What Lighthouse SEO Measures](#what-lighthouse-seo-measures)
- [Why SEO Audits Matter](#why-seo-audits-matter)
- [All SEO Audits](#all-seo-audits)
- [How to Measure SEO](#how-to-measure-seo)
- [Common SEO Issues by Template Type](#common-seo-issues-by-template-type)
- [Fixing SEO Issues](#fixing-seo-issues)
- [Test Your Entire Site](#test-your-entire-site)
---
### Lighthouse Accessibility Audit Guide · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/accessibility
Description: Master web accessibility with Lighthouse. Learn how accessibility audits work, why they matter for users and SEO, and how to fix common issues.
h1. **Lighthouse Accessibility Audit Guide**
Master web accessibility with Lighthouse. Learn how accessibility audits work, why they matter for users and SEO, and how to fix common issues.
[Harlan Wilton](https://x.com/harlan_zw)9 min read Published **Jan 18, 2025**
Web accessibility determines whether people with disabilities can use your site. This includes users who are blind, deaf, have motor impairments, cognitive disabilities, or temporary limitations like a broken arm.
Lighthouse tests accessibility using [**axe-core**](https://github.com/dequelabs/axe-core), the industry-standard accessibility testing engine. Each audit is binary: pass or fail. Unlike performance metrics with thresholds, accessibility either works for users or it does not.
The overall accessibility score represents the percentage of passed audits. A score of 85 means 85% of applicable audits passed.
h2. [Why Accessibility Matters](#why-accessibility-matters)
h3. [Real Users Depend On It](#real-users-depend-on-it)
Over [**1 billion people worldwide live with disabilities**](https://www.who.int/news-room/fact-sheets/detail/disability-and-health). In the US alone, [**26% of adults have some type of disability**](https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html). These are not edge cases. They are a significant portion of your potential audience.
Consider how users interact with your site:
- **Screen reader users** navigate by headings, links, and landmarks. If your heading hierarchy skips from h1 to h4, they lose context. If links say "click here" without context, they have no idea where they lead.
- **Keyboard-only users** tab through interactive elements. If a button cannot receive focus or a modal traps them, your site becomes unusable.
- **Low-vision users** rely on sufficient color contrast. Light gray text on white backgrounds is invisible to them.
- **Motor-impaired users** may use voice control or switches. Tiny touch targets and timed interactions create barriers.
Accessibility failures do not just inconvenience people. They completely lock them out.
h3. [Legal Requirements](#legal-requirements)
Web accessibility is increasingly mandated by law:
| **Region** | **Law** | **Requirement** |
| --- | --- | --- |
| United States | ADA, Section 508 | Public accommodations must be accessible |
| European Union | European Accessibility Act | Digital services must meet WCAG 2.1 AA by 2025 |
| United Kingdom | Equality Act 2010 | Service providers must make reasonable adjustments |
| Canada | AODA | Ontarian organizations must meet WCAG 2.0 AA |
| Australia | DDA | Discrimination includes inaccessible websites |
[**Web accessibility lawsuits reached over 4,000 in 2024**](https://www.essentialaccessibility.com/blog/ada-web-accessibility-lawsuit-statistics). Plaintiffs typically target violations detectable by automated tools. The same issues Lighthouse flags.
h3. [SEO Overlap: The "Proxy Signal" Effect](#seo-overlap-the-proxy-signal-effect)
While Google has stated that accessibility scores are not a _direct_ ranking factor, the signals are inextricably linked. Accessibility features often act as "proxy signals" for User Experience (UX) and content quality, which _are_ ranking factors.
| **Accessibility Feature** | **SEO Signal Proxy** | **Business Impact** |
| --- | --- | --- |
| **Headings (H1-H6)** | **Passage Ranking** | Helps Google index specific answers within long content for Featured Snippets. |
| **Link Names** | **Internal Link Equity** | Descriptive anchors pass topical authority to linked pages, boosting their ranking potential. |
| **Alt Text** | **Visual Search** | Powers Google Images and Google Lens, opening new acquisition channels. |
| **Captions/Transcripts** | **Video Indexing** | Makes video content searchable and indexable, capturing long-tail traffic. |
h4. [Future Proofing: Mobile-First & AI](#future-proofing-mobile-first-ai)
As search evolves towards AI-driven answers (SGE) and strict Mobile-First Indexing, semantic structure becomes critical. LLMs and crawlers rely on the Accessibility Tree to understand content hierarchy. If your content is hidden from screen readers (e.g., inaccessible accordions), it may be devalued or ignored by search engines.
h2. [How Lighthouse Scores Accessibility](#how-lighthouse-scores-accessibility)
Lighthouse runs axe-core against your page and evaluates dozens of rules. Each applicable rule either passes or fails. The score formula:
```
Score = (Passed Audits / Total Applicable Audits) * 100
```
Important points:
- **Binary results**: Each audit is pass/fail. There is no "partial credit"
- **Weighted scoring**: Some audits carry more weight based on user impact
- **Not applicable**: If an audit does not apply (no images on page = no image-alt check), it does not affect your score
- **Automated limitations**: Lighthouse catches about 30-50% of accessibility issues. Manual testing remains essential
A perfect 100 does not mean your site is fully accessible. It means you passed all automated checks. Screen reader testing, keyboard navigation testing, and usability testing with disabled users reveal issues automation misses.
h2. [Common Accessibility Issues](#common-accessibility-issues)
These are the most frequently failing audits across websites:
h3. [Names and Labels](#names-and-labels)
| **Issue** | **Impact** | **Fix Complexity** |
| --- | --- | --- |
| [**Missing image alt text**](https://unlighthouse.dev/learn-lighthouse/accessibility/image-alt) | High | Low |
| [**Links without discernible names**](https://unlighthouse.dev/learn-lighthouse/accessibility/link-name) | High | Low |
| [**Buttons without accessible names**](https://unlighthouse.dev/learn-lighthouse/accessibility/button-name) | High | Low |
| [**Form inputs without labels**](https://unlighthouse.dev/learn-lighthouse/accessibility/label) | High | Low |
| [**Frame/iframe missing title**](https://unlighthouse.dev/learn-lighthouse/accessibility/frame-title) | Medium | Low |
h3. [ARIA Issues](#aria-issues)
| **Issue** | **Impact** | **Fix Complexity** |
| --- | --- | --- |
| Invalid ARIA roles | High | Medium |
| [**Missing required ARIA attributes**](https://unlighthouse.dev/learn-lighthouse/accessibility/aria-required-attr) | High | Medium |
| Invalid ARIA attribute values | High | Medium |
| ARIA hidden on body | Critical | Low |
| Duplicate ARIA IDs | High | Medium |
h3. [Color and Contrast](#color-and-contrast)
| **Issue** | **Impact** | **Fix Complexity** |
| --- | --- | --- |
| [**Insufficient color contrast**](https://unlighthouse.dev/learn-lighthouse/accessibility/color-contrast) | High | Medium |
| Links not distinguishable from text | Medium | Low |
h3. [Document Structure](#document-structure)
| **Issue** | **Impact** | **Fix Complexity** |
| --- | --- | --- |
| [**Missing document title**](https://unlighthouse.dev/learn-lighthouse/accessibility/document-title) | High | Low |
| [**Missing html lang attribute**](https://unlighthouse.dev/learn-lighthouse/accessibility/html-has-lang) | High | Low |
| Invalid lang attribute | Medium | Low |
| [**Skipped heading levels**](https://unlighthouse.dev/learn-lighthouse/accessibility/heading-order) | Medium | Low |
| Empty headings | Medium | Low |
h3. [Navigation](#navigation)
| **Issue** | **Impact** | **Fix Complexity** |
| --- | --- | --- |
| [**No skip link or landmark**](https://unlighthouse.dev/learn-lighthouse/accessibility/bypass) | Medium | Low |
| [**Tabindex greater than 0**](https://unlighthouse.dev/learn-lighthouse/accessibility/tabindex) | Medium | Low |
| Duplicate access keys | Low | Low |
h3. [Tables](#tables)
| **Issue** | **Impact** | **Fix Complexity** |
| --- | --- | --- |
| Table cells missing headers | High | Medium |
| Invalid th scope | Medium | Medium |
> [**Diagnose your specific issue**](https://unlighthouse.dev/learn-lighthouse/accessibility#common-accessibility-issues)
h2. [How to Test Accessibility](#how-to-test-accessibility)
h3. [Lighthouse (Automated)](#lighthouse-automated)
Run Lighthouse in Chrome DevTools:
1. Open DevTools (F12)
2. Go to **Lighthouse** tab
3. Check **Accessibility** category
4. Click **Analyze page load**
Review the failing audits. Each includes the failing elements and a link to documentation.
h3. [Chrome DevTools Accessibility Panel](#chrome-devtools-accessibility-panel)
For deeper inspection:
1. Open DevTools → **Elements** tab
2. Select an element
3. View **Accessibility** pane in sidebar
4. Check computed accessible name, role, and properties
The accessibility tree shows how assistive technologies interpret your page. If an element is missing from this tree, screen readers cannot find it.
h3. [axe DevTools Extension](#axe-devtools-extension)
Install [**axe DevTools**](https://www.deque.com/axe/devtools/) for more detailed testing than Lighthouse alone. It provides:
- Intelligent guided tests for complex issues
- Best practice violations beyond WCAG
- Issue grouping by component
h3. [Screen Reader Testing](#screen-reader-testing)
Automated tools catch syntax issues. Screen reader testing reveals usability issues.
| **Screen Reader** | **Platform** | **Cost** |
| --- | --- | --- |
| NVDA | Windows | Free |
| JAWS | Windows | Licensed |
| VoiceOver | macOS/iOS | Built-in |
| TalkBack | Android | Built-in |
Basic screen reader test:
1. Close your eyes or turn off the monitor
2. Navigate using only keyboard
3. Can you understand the page structure?
4. Can you complete key tasks?
h3. [Keyboard Testing](#keyboard-testing)
Tab through your page:
- Can you reach all interactive elements?
- Is focus visible at all times?
- Can you operate all controls (buttons, menus, forms)?
- Can you escape from modals?
- Is tab order logical?
If any answer is no, users with motor impairments cannot use that feature.
h2. [Framework Considerations](#framework-considerations)
Modern JavaScript frameworks require extra attention for accessibility:
**Client-side routing**: When navigation happens without page reload, screen readers may not announce the new content. Manage focus on route change.
**Dynamic content**: Content added via JavaScript needs appropriate ARIA live regions to announce changes.
**Component libraries**: Third-party UI libraries vary in accessibility quality. Audit them before adoption.
**Virtual DOM**: Framework abstractions can obscure accessibility issues. The rendered HTML is what matters.
h2. [Test Your Entire Site](#test-your-entire-site)
Checking accessibility page-by-page misses patterns. Your marketing pages might pass while app screens fail. Product pages might be accessible while the checkout flow is not.
Different templates have different issues. An author creating content might leave out alt text. A developer building components might forget ARIA labels.
[**Unlighthouse**](https://unlighthouse.dev/) scans your entire site and surfaces accessibility scores for every page. You will see which templates have issues, which pages are outliers, and whether fixes actually work at scale.
The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions before users report them.
[**PSI vs Lighthouse** Why your Lighthouse score differs from PageSpeed Insights. Understand lab vs field data, scoring differences, and when to use each tool.](https://unlighthouse.dev/learn-lighthouse/pagespeed-insights-vs-lighthouse) [**aria-hidden-focus** Learn how to fix aria-hidden-focus issues in Lighthouse accessibility audits](https://unlighthouse.dev/learn-lighthouse/accessibility/aria-hidden-focus)
**On this page **
- [Why Accessibility Matters](#why-accessibility-matters)
- [How Lighthouse Scores Accessibility](#how-lighthouse-scores-accessibility)
- [Common Accessibility Issues](#common-accessibility-issues)
- [How to Test Accessibility](#how-to-test-accessibility)
- [Framework Considerations](#framework-considerations)
- [Test Your Entire Site](#test-your-entire-site)
---
### Interaction to Next Paint (INP) Guide · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/inp
Description: Master INP optimization with practical fixes for JavaScript execution, DOM operations, and event handlers. Improve responsiveness across your site.
h1. **Interaction to Next Paint (INP) Guide**
Master INP optimization with practical fixes for JavaScript execution, DOM operations, and event handlers. Improve responsiveness across your site.
[Harlan Wilton](https://x.com/harlan_zw)9 min read Published **Jan 18, 2025**
**INP**Interaction to Next Paint** CWV **
**0% weight **
Good ≤200msPoor >500ms
INP is the [**hardest Core Web Vital for mobile users**](https://almanac.httparchive.org/en/2024/performance). While 97% of desktop pages pass, only 74% of mobile pages achieve good INP. That 23-point gap matters—mobile users make up [**over 60% of web traffic**](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet).
INP [**replaced FID as a Core Web Vital on March 12, 2024**](https://web.dev/blog/inp-cwv-march-12). The bar got higher: [**93% of sites passed FID**](https://web.dev/blog/inp-cwv), but FID only measured input delay on the first interaction. INP measures everything—every click, tap, and keypress throughout the entire page session.
h2. [What is INP?](#what-is-inp)
Interaction to Next Paint measures responsiveness—how long it takes for the page to visually respond after a user interacts. Google uses this definition from the Lighthouse audit:
> "Interaction to Next Paint measures page responsiveness, how long it takes the page to visibly respond to user input."
**INP Thresholds:**
| **Score** | **Rating** | **What It Feels Like** |
| --- | --- | --- |
| ≤200ms | Good | Instant, responsive |
| 200–500ms | Needs Improvement | Noticeable lag |
| >500ms | Poor | Frustratingly slow |
**Score Weight:** INP doesn't directly affect Lighthouse Performance scores in lab mode. Instead, Lighthouse uses [**Total Blocking Time (TBT)**](https://unlighthouse.dev/glossary/tbt) as a proxy, which accounts for **30%** of the score. In field data (CrUX), INP is measured directly.
h2. [What Triggers INP](#what-triggers-inp)
INP only measures discrete interactions—events that have a clear start and end:
| **Interaction Type** | **Examples** |
| --- | --- |
| **Clicks** | Button clicks, link clicks, checkbox toggles |
| **Taps** | Mobile screen taps, touch inputs |
| **Key Presses** | Typing in inputs, keyboard shortcuts |
**Not measured:** Scrolling, hovering, and pinch-to-zoom. These are continuous interactions with different performance characteristics.
The browser tracks all qualifying interactions during the page session. Your INP score is typically the worst interaction (or 98th percentile on pages with many interactions).
h2. [Why INP Matters](#why-inp-matters)
h3. [User Experience](#user-experience)
Users expect instant feedback. [**Research shows**](https://web.dev/articles/defining-core-web-vitals-thresholds) that delays over 200ms start to feel sluggish. Past 500ms, users assume something is broken.
The consequences of poor INP:
- Users click multiple times, triggering duplicate actions
- Forms feel unresponsive, causing input errors
- E-commerce checkouts get abandoned
- Users perceive your site as low-quality
Since [**90% of user time on a page happens after it loads**](https://web.dev/articles/inp), INP captures the experience that matters most.
h3. [SEO Impact](#seo-impact)
INP officially replaced FID as a [**Core Web Vital ranking factor on March 12, 2024**](https://developers.google.com/search/docs/appearance/core-web-vitals). While FID only measured the _first_ interaction, INP influences ranking eligibility by measuring _all_ interactions.
For 2025, the bar is strict: Google treats <200ms as the "Good" threshold for ranking boosts. Sites consistently failing this metric may see reduced visibility in competitive search results.
h3. [Industry Benchmarks & Competitive Advantage](#industry-benchmarks-competitive-advantage)
Passing Core Web Vitals is harder than it looks. As of mid-2024, [**only ~47% of websites passed all Core Web Vitals**](https://almanac.httparchive.org/en/2024/performance).
| **Sector** | **INP Pass Rate** | **Opportunity** |
| --- | --- | --- |
| **eCommerce** | Low | High - most catalogs are heavy |
| **News/Media** | Medium | High - ad scripts kill INP |
| **B2B SaaS** | High | Low - usually simpler apps |
Fixing INP isn't just about compliance—it's a competitive advantage. If you're in the 47% that pass, you're likely outranking half your competitors on technical merit alone.
h3. [Business Impact](#business-impact)
Real-world improvements show direct business correlation:
| **Company** | **INP Change** | **Business Impact** |
| --- | --- | --- |
| [**Trendyol**](https://web.dev/case-studies/trendyol-inp) | 50% reduction | 1% higher click-through rate |
| [**The Economic Times**](https://web.dev/case-studies/economic-times-inp) | 3x faster | 43% lower bounce rate |
| [**redBus**](https://web.dev/case-studies/redbus-inp) | 72% reduction | Higher engagement metrics |
| [**Taboola**](https://web.dev/case-studies/taboola-inp) | Multiple optimizations | 5.5% higher ad click-through |
h2. [Understanding INP Sub-Parts](#understanding-inp-sub-parts)
Every interaction breaks down into three phases. [**Presentation delay accounts for ~42% of total INP**](https://www.corewebvitals.io/core-web-vitals/interaction-to-next-paint/presentation-delay) on average—often the overlooked bottleneck.
| **Phase** | **What Happens** | **What Causes Delays** |
| --- | --- | --- |
| **Input Delay** | Time waiting for main thread to become free | Long tasks blocking the thread |
| **Processing Duration** | Time running your event handlers | Complex handler logic |
| **Presentation Delay** | Time for browser to render the result | DOM updates, layout, paint |
**The critical insight:** Most developers focus on processing duration because that's their code. But input delay and presentation delay often account for 60%+ of total INP. A perfectly efficient event handler still fails INP if the main thread was blocked or the DOM update triggered expensive layout.
h3. [Try It: Response Time Lab](#try-it-response-time-lab)
Click the buttons to feel the difference between fast and slow responses:
Loading demo...
h2. [Common INP Issues](#common-inp-issues)
Poor INP stems from a handful of causes. Here are the most impactful:
| **Issue** | **Impact** | **Difficulty** | **Fix Time** |
| --- | --- | --- | --- |
| [**Long-Running JavaScript**](https://unlighthouse.dev/learn-lighthouse/inp/long-running-javascript) | High | Medium | Hours |
| [**Heavy DOM Operations**](https://unlighthouse.dev/learn-lighthouse/inp/heavy-dom-operations) | High | Medium | Hours |
| [**Third-Party Scripts**](https://unlighthouse.dev/learn-lighthouse/inp/third-party-scripts) | High | Low | Minutes–Hours |
| [**Total Blocking Time**](https://unlighthouse.dev/learn-lighthouse/inp/total-blocking-time) | High | Medium | Hours |
| [**DOM Size**](https://unlighthouse.dev/learn-lighthouse/inp/dom-size) | Medium | Medium | Hours |
| [**Event Handler Delays**](https://unlighthouse.dev/learn-lighthouse/inp/event-handler-delays) | Medium | Low | Minutes |
| [**Hydration Issues**](https://unlighthouse.dev/learn-lighthouse/inp/hydration-issues) | Medium | High | Hours–Days |
→ [**Diagnose your specific issue**](https://unlighthouse.dev/learn-lighthouse/inp#common-inp-issues)
h2. [How to Measure INP](#how-to-measure-inp)
h3. [Lab Testing (Proxy)](#lab-testing-proxy)
INP requires real user interaction—you can't measure it with an automated page load. Lab tools use Total Blocking Time (TBT) as a proxy because [**TBT correlates twice as well with INP than FID did**](https://github.com/GoogleChrome/web.dev/issues/8395).
**Chrome DevTools:**
1. Open DevTools → **Performance** tab
2. Check **"Web Vitals"** in settings
3. Click record → interact with the page → stop recording
4. Look for interaction events and their duration
**Lighthouse:** Check the TBT score as your INP proxy. The thresholds are:
- **Mobile:** Good ≤200ms, Poor >600ms
- **Desktop:** Good ≤150ms, Poor >350ms
**[**INP Analyzer Tool**](https://unlighthouse.dev/tools/inp-analyzer):** Enter any URL to analyze interaction responsiveness — no install required.
h3. [Field Data (Real Users)](#field-data-real-users)
Field data is what Google uses for ranking. It represents actual user experience.
**PageSpeed Insights:** Enter your URL to see CrUX (Chrome User Experience Report) INP data. This shows real-world performance from Chrome users.
**Search Console:** The Core Web Vitals report shows which URLs pass or fail INP, grouped by similar pages.
**Web Vitals JavaScript Library:**
```
import { onINP } from 'web-vitals'
onINP((metric) => {
console.log('INP:', metric.value, 'ms')
console.log('Element:', metric.attribution.interactionTarget)
console.log('Type:', metric.attribution.interactionType)
})
```
To catch regressions automatically, set up [**Lighthouse CI**](https://unlighthouse.dev/learn-lighthouse/lighthouse-ci) in your deployment pipeline.
h3. [Mobile vs Desktop Gap](#mobile-vs-desktop-gap)
The INP gap between devices is massive:
| **Device** | **Good INP Rate (2024)** |
| --- | --- |
| Desktop | 97% |
| Mobile | 74% |
This [**23-point gap**](https://almanac.httparchive.org/en/2024/performance) means mobile optimization is essential. Mobile devices have:
- Slower CPUs that struggle with JavaScript
- Touch events that can trigger more complex handlers
- Limited memory causing more garbage collection pauses
Test on real mobile devices, not just throttled desktop browsers.
h2. [Framework Guides](#framework-guides)
Framework-specific INP optimizations:
**Next.js**
Hydration strategies, Server Components, and useTransition.
**Nuxt**
Payload optimization, lazy hydration, and component islands.
**React**
startTransition, useDeferredValue, and avoiding re-render cascades.
**Vue**
Reactivity optimization, async components, and computed caching.
**Svelte**
Minimal runtime overhead and smart DOM updates.
**Angular**
Zone.js optimization, OnPush change detection, and signals.
h2. [Test Your Entire Site](#test-your-entire-site)
Most tools test one page at a time. That's a problem for INP—different pages have different JavaScript, different event handlers, and different interaction patterns.
Your homepage might pass while your checkout fails. Product pages might be fast until someone opens the image gallery.
[**Unlighthouse**](https://unlighthouse.dev/) scans your entire site and shows TBT (INP proxy) scores for every page. You'll see which templates have issues, which pages are outliers, and whether your fixes work at scale.
The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions before users report them.
[**Animations & Transitions** Eliminate CLS from animations by using compositor-friendly properties like transform and opacity instead of layout-triggering properties.](https://unlighthouse.dev/learn-lighthouse/cls/animations-transitions) [**Long-Running JavaScript** Reduce JavaScript execution time to improve INP. Learn code splitting, web workers, and task chunking to keep the main thread responsive.](https://unlighthouse.dev/learn-lighthouse/inp/long-running-javascript)
**On this page **
- [What is INP?](#what-is-inp)
- [What Triggers INP](#what-triggers-inp)
- [Why INP Matters](#why-inp-matters)
- [Understanding INP Sub-Parts](#understanding-inp-sub-parts)
- [Common INP Issues](#common-inp-issues)
- [How to Measure INP](#how-to-measure-inp)
- [Framework Guides](#framework-guides)
- [Test Your Entire Site](#test-your-entire-site)
---
### Cumulative Layout Shift (CLS): What Is a Good Score & How to Fix · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/cls
Description: Google considers a CLS score of 0.1 or less as good. Learn what causes layout shifts and how to fix CLS with proven techniques for images, fonts, ads, and dynamic content.
h1. **Cumulative Layout Shift (CLS): What Is a Good Score & How to Fix**
Google considers a CLS score of 0.1 or less as good. Learn what causes layout shifts and how to fix CLS with proven techniques for images, fonts, ads, and dynamic content.
[Harlan Wilton](https://x.com/harlan_zw)8 min read Published **Jan 18, 2025**
**CLS**Cumulative Layout Shift** CWV **
**25% weight **
Good ≤0.10Poor >0.25
CLS measures unexpected layout shifts—when visible elements move around as the page loads. It's the easiest Core Web Vital to pass: [**79% of mobile sites achieve good CLS**](https://almanac.httparchive.org/en/2024/performance) compared to 59% for LCP.
But "easiest" doesn't mean unimportant. Layout shifts destroy trust. When users click a button and hit an ad instead, or lose their reading position because a banner appeared, they leave.
[**Redbus reduced CLS from 1.65 to 0 and saw 80-100% higher mobile conversion rates**](https://web.dev/case-studies/vitals-business-impact). Visual stability directly impacts revenue.
h2. [What is CLS?](#what-is-cls)
Cumulative Layout Shift tracks how much visible content moves unexpectedly. The score is calculated by multiplying two fractions for each shift:
**Impact Fraction** × **Distance Fraction** = Layout Shift Score
- **Impact fraction:** Percentage of viewport affected by the shift
- **Distance fraction:** Distance elements moved relative to viewport
A small image shifting 50px causes less CLS than a large banner shifting 200px.
**CLS Thresholds:**
| **Score** | **Rating** | **What it means** |
| --- | --- | --- |
| ≤0.1 | Good | Stable, predictable layout |
| 0.1–0.25 | Needs Improvement | Noticeable shifts, frustrating UX |
| >0.25 | Poor | Severe shifts, users may misclick |
**Score Weight:** CLS accounts for **25%** of your Lighthouse Performance score—tied with LCP for the largest weight.
**How CLS is measured:** Since [**April 2021**](https://web.dev/blog/evolving-cls), CLS uses a "session window" approach. It captures the maximum burst of layout shifts with a 1-second gap and 5-second cap. This makes CLS [**more fair for long-lived pages and SPAs**](https://web.dev/blog/evolving-cls).
**User-initiated shifts are excluded:** Layout shifts within [**500ms of discrete user input**](https://web.dev/articles/cls) (clicks, taps, keypresses) don't count. Scroll and pinch gestures don't trigger this exclusion—those are continuous inputs.
→ [**Full CLS definition**](https://unlighthouse.dev/glossary/cls)
h2. [Why CLS Matters](#why-cls-matters)
h3. [User Experience](#user-experience)
Layout shifts cause users to:
- Click the wrong button or link (the infamous "misclick")
- Lose their place while reading
- Accidentally trigger unwanted actions like purchases
- Perceive the site as broken or low-quality
The frustration is visceral. Users don't think "this page has poor CLS"—they think "this site is garbage."
h3. [SEO Impact](#seo-impact)
CLS is one of [**Google's Core Web Vitals ranking factors**](https://developers.google.com/search/docs/appearance/core-web-vitals). Sites with good CLS can rank higher than competitors with poor CLS, especially for "Top Stories" carousel eligibility.
Google uses field data from the 75th percentile—meaning 75% of your users need good CLS for it to count as "good" for ranking purposes.
h3. [Business Impact](#business-impact)
| **Company** | **CLS Improvement** | **Business Impact** |
| --- | --- | --- |
| [**Redbus**](https://web.dev/case-studies/vitals-business-impact) | 1.65 → 0 | 80-100% higher mobile conversions |
| [**Yahoo! Japan**](https://web.dev/case-studies/vitals-business-impact) | 98% reduction | 15% more page views per session |
| [**AliExpress**](https://web.dev/case-studies/vitals-business-impact) | 10x improvement | 15% lower bounce rates |
| [**iCook**](https://web.dev/case-studies/vitals-business-impact) | 15% improvement | 10% more ad revenue |
The pattern is clear: visual stability correlates with engagement and conversion.
h2. [Common CLS Issues](#common-cls-issues)
Lighthouse identifies these root causes for layout shifts:
| **Issue** | **Impact** | **Difficulty** |
| --- | --- | --- |
| [**Images Without Dimensions**](https://unlighthouse.dev/learn-lighthouse/cls/unsized-images) | High | Low |
| [**Large Layout Shifts**](https://unlighthouse.dev/learn-lighthouse/cls/layout-shifts) | High | Varies |
| [**Dynamic Content Injection**](https://unlighthouse.dev/learn-lighthouse/cls/dynamic-content-injection) | High | Medium |
| [**Web Fonts (FOIT/FOUT)**](https://unlighthouse.dev/learn-lighthouse/cls/web-fonts-causing-foit) | Medium | Medium |
| [**Ads, Embeds, iframes**](https://unlighthouse.dev/learn-lighthouse/cls/ads-embeds-iframes) | Medium | Medium |
| [**Animations & Transitions**](https://unlighthouse.dev/learn-lighthouse/cls/animations-transitions) | Low | Low |
The audit tracks up to 15 layout shifts and shows the element that shifted most for each event, along with the root cause (unsized media, web font loaded, or injected iframe).
→ [**All CLS issues and fixes**](https://unlighthouse.dev/learn-lighthouse/cls#common-cls-issues)
h3. [Try It: Layout Shift Playground](#try-it-layout-shift-playground)
Trigger common layout shifts and see how they affect the CLS score:
Loading demo...
h2. [How to Measure CLS](#how-to-measure-cls)
h3. [Lab Testing (Development)](#lab-testing-development)
Lab tests give you controlled, reproducible results—but they capture only shifts during page load, not during longer sessions.
**Chrome DevTools:**
1. Open DevTools → **Performance** tab
2. Click record → reload page → stop recording
3. Look for pink "Layout Shift" entries in the timeline
4. Click to see which elements shifted and by how much
**Lighthouse:** Run an audit and check the CLS metric. The "Avoid large layout shifts" diagnostic shows the top shifting elements with their root causes.
**[**CLS Debugger Tool**](https://unlighthouse.dev/tools/cls-debugger):** Enter any URL to identify exactly which elements cause layout shifts — no install required.
**Console snippet:**
```
new PerformanceObserver((l) => {
l.getEntries().forEach((e) => {
console.log('CLS:', e.value, e.sources)
})
}).observe({ type: 'layout-shift', buffered: true })
```
This logs each shift with its source element—useful for catching shifts in real-time during development.
h3. [Field Data (Real Users)](#field-data-real-users)
Field data captures shifts throughout the user session, not just initial load.
**PageSpeed Insights:** Shows CrUX data for your URL—the same data Google uses for ranking.
**Google Search Console:** Core Web Vitals report groups URLs by CLS status.
**Web Vitals Chrome Extension:** Shows CLS in real-time and highlights shifting elements with red overlays.
**Web Vitals JavaScript Library:**
```
import { onCLS } from 'web-vitals'
onCLS((metric) => {
console.log('CLS:', metric.value)
console.log('Entries:', metric.entries)
})
```
To catch regressions automatically, set up [**Lighthouse CI**](https://unlighthouse.dev/learn-lighthouse/lighthouse-ci) in your deployment pipeline.
h3. [Lab vs Field CLS](#lab-vs-field-cls)
**Important:** Lab CLS can be [**artificially lower than field CLS**](https://web.dev/articles/lab-and-field-data-differences) because:
- Lab tests end at "page load" while field data captures shifts throughout the session
- Ads and third-party content may load differently in lab conditions
- User interactions in the field can trigger shifts that lab tests miss
Always verify with real user data. If field CLS is worse than lab, you have shifts happening after initial load—likely from ads, lazy-loaded content, or user interactions.
h2. [CLS Progress Over Time](#cls-progress-over-time)
CLS has improved significantly across the web:
| **Year** | **Mobile Good CLS** | **Desktop Good CLS** |
| --- | --- | --- |
| 2020 | 60% | 54% |
| 2022 | 74% | 65% |
| 2024 | 79% | 72% |
_Source: [**HTTP Archive Web Almanac 2024**](https://almanac.httparchive.org/en/2024/performance)_
Mobile sites actually outperform desktop on CLS—likely due to simpler layouts and fewer ads. Desktop pages tend to have more complex layouts with sidebars, multi-column content, and ad placements that shift.
h2. [Advanced CLS Insights](#advanced-cls-insights)
Recent research highlights the deeper connection between visual stability, SEO algorithms, and user trust.
h3. [Critical SEO Factors](#critical-seo-factors)
| **Insight** | **Source** | **Affects** |
| --- | --- | --- |
| **Robots.txt Blocking** | [**Google Search Central**](https://developers.google.com/search/docs/crawling-indexing/robots/intro) | Googlebot renders your page to check CLS. If `robots.txt` blocks CSS/JS resources, the bot sees a broken layout with massive shifts that real users might not see. |
| **Mobile-First Indexing** | [**Google Developers**](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) | Google predominantly uses the mobile version of the content for indexing and ranking. Your mobile CLS score is the primary ranking signal, even for desktop searches. |
| **Accessibility Overlap** | [**WCAG 2.1**](https://www.w3.org/WAI/WCAG21/Understanding/intro) | Poor CLS violates "Operable" and "Understandable" principles. Users with motor impairments may misclick due to shifts, failing WCAG accessibility criteria alongside Core Web Vitals. |
| **"Pogo-sticking" Signal** | Industry Studies | When users encounter layout shifts and immediately hit "Back" (pogo-sticking), it sends a strong negative quality signal to Google's ranking algorithms. |
h3. [Technical Gotchas](#technical-gotchas)
| **Gotcha** | **Impact** | **Fix** |
| --- | --- | --- |
| **Late-loading CSS** | Flash of Unstyled Content (FOUC) | Ensure critical CSS is inline or loaded in ``. Async CSS loading without critical CSS extraction guarantees layout shifts. |
| **Viewport Meta Tag** | Scaling & Layout | Missing `` causes browsers to guess dimensions, often triggering shifts on load. |
| **Cookie Banners** | 0.1+ CLS Score | Often ignored in development because "I already accepted it." Test in Incognito mode. Banners pushing content down are a top CLS cause. |
h2. [Framework Guides](#framework-guides)
Framework-specific CLS fixes:
**Next.js**
next/image with dimensions, font optimization with next/font.
**Nuxt**
NuxtImage sizing, @nuxt/fonts for font loading.
**React**
Placeholder strategies, Suspense boundary sizing.
**Vue**
v-if/v-show transitions, async component sizing.
**Svelte**
enhanced:img dimensions, transition handling.
**Angular**
NgOptimizedImage with dimensions, @angular/fonts.
h2. [Test Your Entire Site](#test-your-entire-site)
Most tools only test one page at a time. Your homepage might pass CLS while your blog template has unsized images causing shifts on every post.
[**Unlighthouse**](https://unlighthouse.dev/) scans your entire site and shows CLS scores for every page. The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions before users do.
[**Inspector Issues** Resolve browser-detected problems including mixed content, cookie issues, CSP violations, and cross-origin blocks that appear in Chrome's Issues panel.](https://unlighthouse.dev/learn-lighthouse/best-practices/inspector-issues) [**Images Without Dimensions** Images without width and height cause layout shifts. Add explicit dimensions to prevent your page from jumping around as images load.](https://unlighthouse.dev/learn-lighthouse/cls/unsized-images)
**On this page **
- [What is CLS?](#what-is-cls)
- [Why CLS Matters](#why-cls-matters)
- [Common CLS Issues](#common-cls-issues)
- [How to Measure CLS](#how-to-measure-cls)
- [CLS Progress Over Time](#cls-progress-over-time)
- [Advanced CLS Insights](#advanced-cls-insights)
- [Framework Guides](#framework-guides)
- [Test Your Entire Site](#test-your-entire-site)
---
### Largest Contentful Paint (LCP): Good Scores, Fixes & Guide · Unlighthouse
Source: https://unlighthouse.dev/learn-lighthouse/lcp
Description: LCP measures when the main content loads. Good score: ≤2.5s mobile. Fix slow LCP with image optimization, TTFB improvements, and render-blocking resource removal.
h1. **Largest Contentful Paint (LCP): Good Scores, Fixes & Guide**
LCP measures when the main content loads. Good score: ≤2.5s mobile. Fix slow LCP with image optimization, TTFB improvements, and render-blocking resource removal.
[Harlan Wilton](https://x.com/harlan_zw)9 min read Published **Jan 18, 2025**
**LCP**Largest Contentful Paint** CWV **
**25% weight **
Good ≤2.5sPoor >4.0s
LCP is the [**hardest Core Web Vital to pass**](https://www.debugbear.com/blog/hardest-core-web-vitals-metric). Only [**59% of mobile pages achieve good LCP**](https://almanac.httparchive.org/en/2024/performance) compared to 74% for INP and 72% for CLS.
Why? LCP depends on everything—server response, network, image optimization, CSS, JavaScript, and rendering. One bottleneck anywhere in the chain kills your score.
h2. [What is LCP?](#what-is-lcp)
Largest Contentful Paint marks when the main content finishes loading. It answers the user's question: "Is this page actually showing me what I came for?"
The element considered "largest" can change as the page loads. The browser reports the final LCP candidate once the user interacts or the page finishes loading.
**LCP Thresholds:**
| **Device** | **Good** | **Needs Improvement** | **Poor** |
| --- | --- | --- | --- |
| Mobile | ≤2.5s | 2.5–4.0s | >4.0s |
| Desktop | ≤1.2s | 1.2–2.4s | >2.4s |
**Score Weight:** LCP accounts for **25%** of your Lighthouse Performance score—the largest single metric weight.
**What elements can be LCP:**
- `` elements— [**73% of mobile pages have an image as LCP**](https://almanac.httparchive.org/en/2024/performance)
- `