PageSpeed Insights: Complete Guide 2026

Since the publication of Core Web Vitals as a ranking signal in 2021, Google PageSpeed Insights has become the mandatory checkpoint for anyone looking to evaluate the real performance of a website. Not just another tool among many. The reference point.

PageSpeed Insights analyzes any URL and produces a structured diagnosis in seconds. It assigns a score from 0 to 100, identifies technical bottlenecks, and provides recommendations ranked by potential impact. All for free, from pagespeed.web.dev.

The true strength of the tool does not lie in the score itself. It lies in the nature of the data it leverages. Unlike most speed testing tools, PageSpeed Insights cross-references two sources: lab data generated by Lighthouse and field data collected via the Chrome User Experience Report (CrUX). Lab data for technical diagnosis, field data for real user experience. This dual perspective sets PSI apart from every other tool on the market.

In 2026, this distinction is no longer theoretical. Google uses CrUX data to directly feed the Page Experience signals in its ranking algorithms. A site can display a decent lab score while failing on field metrics, which impacts its organic ranking. Understanding PageSpeed Insights means understanding how Google perceives your site's performance.

This guide covers the entire subject: the tool's inner workings, the difference between lab and field data, metric details (LCP, INP, CLS, TTFB), score calculation, report interpretation, concrete optimizations to break past 90, the PageSpeed Insights API, CI/CD pipeline integration, and the differences between Lighthouse and PSI. The goal is to provide a complete operational framework usable by both front-end developers and technical SEO consultants.

How PageSpeed Insights Works: Lab Data, Field Data, and CrUX

PageSpeed Insights relies on two distinct analysis engines. Confusing their roles is the most common mistake when interpreting results.

Lab Data (Lighthouse)

Lab data is generated by Lighthouse, Google's open-source audit engine. When you run an analysis on pagespeed.web.dev, Lighthouse loads the page in a simulated environment with fixed parameters: an emulated Moto G Power device, a throttled 4G connection at 1.6 Mbps download and 750 ms RTT for the mobile test, and a standard desktop machine for the desktop test.

This simulation produces six performance metrics:

• First Contentful Paint (FCP): first content element rendered on screen
• Largest Contentful Paint (LCP): largest visible element in the viewport
• Total Blocking Time (TBT): cumulative time during which the main thread is blocked for more than 50 ms
• Cumulative Layout Shift (CLS): visual stability score
• Speed Index (SI): speed at which visible content progressively fills the screen
• Time to Interactive (TTI): the moment when the page becomes fully interactive (deprecated but still present in some reports)

Lab data is reproducible and deterministic. It helps identify specific technical problems: a JavaScript file blocking rendering, an uncompressed hero image, an oversized CSS stylesheet. It serves as the basis for the displayed performance score from 0 to 100.

Field Data (CrUX)

Field data comes from the Chrome User Experience Report (CrUX). This dataset aggregates performance metrics collected from real Chrome users who have opted into sharing usage statistics. The data covers a rolling 28-day period.

CrUX measures four main metrics:

• LCP: the time it takes to display the largest content element
• INP (Interaction to Next Paint): the latency at the 98th percentile of user interactions
• CLS: visual stability across the entire session
• TTFB (Time to First Byte): the delay between the HTTP request and receiving the first byte of the response

This data represents what visitors actually experience. It varies depending on devices, network conditions, geographic location, and browsing behavior. A site can achieve an excellent lab score but fail on field data if its visitors predominantly use entry-level smartphones on 3G connections.

PageSpeed Insights displays CrUX data under the "Discover what your real users are experiencing" section at the top of the report. If the site does not have sufficient traffic volume, this section does not appear and only lab data is available.

Mobile Score vs Desktop Score

PageSpeed Insights provides two separate reports: mobile and desktop. The mobile score is almost systematically lower, sometimes by 30 to 40 points. Three factors explain this gap:

• Reduced computing power: the mobile emulation simulates a CPU 4x slower than the test machine
• Restricted bandwidth: network throttling limits throughput to 1.6 Mbps versus an unlimited connection on desktop
• Network latency: 150 ms of RTT added on mobile

Google places predominant importance on the mobile score. Since the shift to Mobile-First Indexing, the mobile version serves as the reference for indexing and ranking. A desktop score of 95 with a mobile score of 45 represents a serious problem for organic search performance.

How Google Calculates the PageSpeed Insights Score

The PageSpeed Insights score is not a simple average of metrics. It results from a weighted calculation based on the Lighthouse scoring model, where each metric contributes with a specific weight to the final score from 0 to 100.

In 2026, the weight distribution in Lighthouse v12 is as follows:

• Total Blocking Time (TBT): 30%
• Largest Contentful Paint (LCP): 25%
• Cumulative Layout Shift (CLS): 25%
• Speed Index (SI): 15%
• First Contentful Paint (FCP): 5%

Each metric is converted into an individual score from 0 to 100 via a log-normal function. This curve uses two parameters: the median and the interquartile range, calibrated against real web performance data collected by the HTTP Archive.

The concrete mechanism: if your LCP is 2.0 seconds, Lighthouse compares this value against the actual distribution of LCP values observed across the entire web. An LCP of 2.0 s falls within the fastest 20%, producing a high LCP sub-score. An LCP of 4.5 s falls within the slowest 25%, producing a low sub-score.

The final score is then the weighted sum of these sub-scores. The direct consequence: a single underperforming metric can drag the entire score down. A site with excellent FCP, CLS, and Speed Index but a TBT of 3,000 ms will see its overall score capped around 55-60, because TBT accounts for 30% of the total.

The overall score classification thresholds:

• 90 to 100 (green): performance considered "good"
• 50 to 89 (orange): performance "needs improvement"
• 0 to 49 (red): performance "poor"

Performance Metrics in Detail

Core Web Vitals form the foundation of the metrics that PageSpeed Insights highlights. Three mandatory metrics (LCP, INP, CLS) and one supplementary metric (TTFB) make up the framework for evaluating perceived performance.

Largest Contentful Paint (LCP)

Largest Contentful Paint measures the time needed to display the largest visible content element in the initial viewport. This element is typically a hero image, a video with a poster, a large text block, or a CSS background covering a wide area.

The thresholds defined by Google:

• Good: less than or equal to 2.5 seconds
• Needs improvement: between 2.5 and 4.0 seconds
• Poor: greater than 4.0 seconds

LCP is the metric most directly perceived by users. It determines whether visitors feel the page "has loaded" or not. A slow LCP produces the effect of a prolonged blank screen, even if other secondary elements are already visible.

The most common causes of degraded LCP:

• High server response time (TTFB): if the server takes 800 ms to respond, LCP cannot drop below that value
• Render-blocking resources: synchronous CSS and JavaScript files that delay the first render
• Unoptimized hero images: heavy formats (PNG, uncompressed JPEG), excessive dimensions, missing preload
• Late loading of web fonts: the main text can be the LCP element, and its display depends on font loading

For a deeper dive into LCP improvement strategies, see our dedicated guide to Largest Contentful Paint optimization.

Interaction to Next Paint (INP)

Interaction to Next Paint replaced First Input Delay (FID) as a Core Web Vital in March 2024. This evolution marks a fundamental shift: where FID only measured the delay of the first interaction, INP observes all interactions throughout the browsing session.

For each interaction (click, tap, keypress), INP measures three phases:

1. Input Delay: waiting time before the browser begins processing the event (often caused by a busy main thread)
2. Processing Time: execution duration of JavaScript event handlers
3. Presentation Delay: time needed to recalculate layout, apply styles, and paint the result

The reported INP value corresponds to the 98th percentile of observed latencies. The thresholds:

• Good: less than or equal to 200 ms
• Needs improvement: between 200 and 500 ms
• Poor: greater than 500 ms

INP is the metric most directly impacted by JavaScript. Every third-party script (analytics, advertising pixels, chatbots, consent widgets) adds work to the main thread and can degrade responsiveness. "Long Tasks" (JavaScript tasks exceeding 50 ms) are the primary culprits behind a high INP.

Our article on INP as a Core Web Vital details specific remediation strategies.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift quantifies the visual stability of a page. It measures unexpected shifts of visible elements during loading and navigation. The score is calculated by multiplying the impact fraction (proportion of viewport affected) by the distance fraction (pixel displacement relative to viewport height).

The thresholds:

• Good: less than or equal to 0.1
• Needs improvement: between 0.1 and 0.25
• Poor: greater than 0.25

Common causes of a high CLS:

• Images and videos without explicit dimensions: the browser cannot reserve space before loading
• Ads and dynamic embeds: banners injected after the initial render push existing content down
• Web fonts causing FOUT (Flash of Unstyled Text): text changes size when the custom font replaces the system font
• Dynamically injected content above the fold: cookie banners, notification bars, pop-ups

CLS uses a sliding session window for its final calculation. The retained score is that of the window with the highest total shifts, which prevents excessively penalizing pages where users scroll for a long time.

For an in-depth treatment, see our guide on CLS and its correction strategies.

Time to First Byte (TTFB)

Time to First Byte measures the delay between the browser sending the HTTP request and receiving the first byte of the server response. It is not an official Core Web Vital, but it is a fundamental diagnostic metric because it directly conditions all other metrics.

Recommended thresholds:

• Good: less than or equal to 800 ms
• Needs improvement: between 800 ms and 1,800 ms
• Poor: greater than 1,800 ms

A high TTFB has a cascading effect. If the server takes 1.2 seconds to respond, LCP mathematically cannot be lower than 1.2 seconds, regardless of how optimized the front-end is. The main causes:

• Undersized hosting: overloaded shared servers, no object cache (Redis/Memcached)
• No CDN: every request must travel the full geographic distance to the origin server
• Slow database queries: unindexed queries, no page cache
• Redirect chains: each HTTP redirect adds a full network round trip

For an overview of the impact of Core Web Vitals on SEO, see our Core Web Vitals and SEO in 2026 guide.

Deciphering a PageSpeed Insights Report: Opportunities, Diagnostics, and Audits

The PageSpeed Insights report breaks down into three categories of information below the performance score. Knowing how to read this report correctly determines the effectiveness of your optimizations.

Opportunities

Opportunities represent high-impact recommendations. Each recommendation comes with an estimated time savings on load time in seconds. They are sorted by decreasing impact.

The most common opportunities:

• "Defer offscreen images": enable lazy loading for images located below the fold
• "Eliminate render-blocking resources": identify synchronous CSS and JS files that delay First Contentful Paint
• "Efficiently encode images": compress images or migrate to modern formats like WebP or AVIF
• "Reduce unused JavaScript": remove dead code or apply code splitting
• "Reduce unused CSS": purge CSS selectors not referenced in the DOM

The optimal strategy is to address opportunities in order of estimated savings. An opportunity showing a potential gain of 2.4 seconds deserves immediate attention. An opportunity at 0.15 seconds can wait.

Diagnostics

Diagnostics provide additional technical information about the page's structure and behavior. Unlike opportunities, they do not display a direct savings estimate. Their role is to flag potentially problematic configurations.

Common diagnostic examples:

• "Avoid an excessive DOM size": a DOM exceeding 1,500 nodes slows down style calculations, layout, and repainting
• "Avoid long main-thread tasks": Long Tasks exceeding 50 ms block user interactions and degrade INP
• "Minimize main-thread work": total time spent parsing, compiling, and executing JavaScript
• "Reduce the impact of third-party code": identifies third-party domains (analytics, ads, widgets) and their contribution to load time

Diagnostics often reveal the root cause of poor scores. A poor LCP score may be caused by a high TTFB (visible in diagnostics) rather than an image problem (visible in opportunities).

Passed Audits

The passed audits section lists best practices already implemented. It confirms that certain optimizations are in place: Gzip/Brotli compression enabled, properly sized images, HTTP cache configured, etc. This section serves as a reference for identifying what does not need to be changed.

A "passed" audit does not necessarily mean the implementation is perfect. A browser cache may be configured with too short a duration (a few hours instead of several months) and still appear as passed. Manual verification remains necessary on critical points.

Concrete Optimizations to Break Past 90 on PageSpeed Insights

Achieving a PageSpeed Insights score above 90 requires addressing multiple optimization areas simultaneously. Here are the most impactful levers, ranked by operational priority.

Eliminate Render-Blocking Resources

CSS and JavaScript files loaded synchronously in the <head> block the page from rendering. The browser must download, parse, and execute these resources before displaying a single pixel.

Remediation strategies:

• Critical CSS: extract the CSS needed for above-the-fold rendering and inline it directly in the HTML. The remaining CSS is loaded asynchronously via media="print" onload="this.media='all'"
• defer and async attributes on scripts: defer executes the script after the HTML parsing is complete. async executes the script as soon as it is downloaded, without blocking parsing
• Preconnect to third-party origins: <link rel="preconnect" href="https://fonts.googleapis.com"> reduces the connection establishment delay for external resources

Advanced Image Optimization

Images account for an average of 50% of a web page's total weight. Optimizing them is often the fastest lever for improving the score.

Priority actions:

• Migrate to WebP or AVIF: WebP offers 25 to 35% better compression than JPEG. AVIF pushes the gain to 50% with equivalent visual quality
• Size images to the viewport: serving a 3,000 px wide image for an 800 px container wastes bandwidth. The srcset attribute and the <picture> element allow serving the appropriate size
• Preload the LCP image: <link rel="preload" as="image" href="/hero.avif" fetchpriority="high"> tells the browser to download the main image with absolute priority
• Enable lazy loading: loading="lazy" on all images below the fold avoids downloading resources that are not immediately visible

For an exhaustive treatment of formats and compression techniques, our guide on WebP and AVIF image optimization covers every aspect in detail.

Reduce Unused JavaScript

PageSpeed Insights frequently flags unused JavaScript as a major issue. On an average site, 30 to 50% of downloaded JavaScript is never executed during the initial page load.

Reduction techniques:

• Code splitting: divide the JavaScript bundle into chunks loaded on demand. Modern frameworks (Next.js, Nuxt, Remix) integrate this functionality natively
• Tree shaking: eliminate unused exports at build time. Bundlers like webpack, Rollup, or esbuild handle this step automatically with ES modules
• Third-party script audit: every tracking pixel, every chat widget, every analytics tool adds JavaScript to the main thread. Inventory these scripts and remove those that no longer provide measurable value
• Conditional loading: load certain scripts only on the pages that need them rather than globally

Reduce Unused CSS

The problem is similar to JavaScript: CSS frameworks (Tailwind in non-purge mode, full Bootstrap) and CMS themes often load thousands of unused selectors on the current page.

Solutions:

• PurgeCSS / CSS Purge: analyze the rendered DOM and remove unreferenced selectors
• Tailwind CSS v4: purging is natively integrated into the compiler, producing only the classes actually used
• Route-based splitting: load only the CSS needed for the current page, not the entire site stylesheet

Caching and Compression

Caching and compression are two complementary optimizations that reduce the volume of transferred data and the number of network requests.

• HTTP cache: configure Cache-Control headers with long durations (1 year) for versioned static resources (JS, CSS, images). Use immutable to avoid unnecessary revalidations
• Brotli compression: Brotli offers a compression rate 15 to 25% better than Gzip for text files (HTML, CSS, JS). The majority of modern servers and CDNs support Brotli
• CDN: distributing static resources from edge servers geographically close to the user reduces network latency and TTFB

Web Font Optimization

Poorly configured web fonts cause two distinct problems: a text rendering block (FOIT - Flash of Invisible Text) or a text size change (FOUT - Flash of Unstyled Text), the latter degrading CLS.

Best practices:

• font-display: swap: displays text immediately with a system font, then switches to the web font once loaded
• Preload critical fonts: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter.woff2" crossorigin>
• Host fonts locally: avoids the additional connection to fonts.googleapis.com or fonts.gstatic.com
• Subsetting: load only the glyphs used (latin, latin-extended) to reduce file size

PageSpeed Insights API and CI/CD Integration

The PageSpeed Insights API: Automating Performance Monitoring

The PageSpeed Insights API allows you to programmatically query the tool without going through the web interface. It returns the same data as the browser version: Lighthouse score, lab metrics, CrUX data (if available), and the list of audits.

The basic call is a simple GET request:

https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&key=YOUR_API_KEY

Main parameters:

• url: the URL to analyze
• strategy: mobile or desktop
• category: performance, accessibility, best-practices, seo (can be combined)
• key: Google API key (free, obtained via Google Cloud Console)

The JSON response contains all metrics, detailed audits, and CrUX data. It can be parsed to extract specific values: overall score, LCP, INP, CLS, TTFB, and each recommendation with its estimated savings.

Concrete use cases:

• Monitoring dashboard: run daily analyses on strategic pages and store results in a database to track score trends over time
• Alerting: trigger a notification (Slack, email) when a score drops below a critical threshold
• Competitive benchmarking: regularly analyze competitor URLs to compare performance
• Client reporting: automatically generate weekly or monthly performance reports

The API is limited to 400 requests per 100 seconds with a free API key. For intensive monitoring, calls must be spaced out sufficiently or multiple keys used.

Integrating PageSpeed Insights into a CI/CD Pipeline

Integrating performance into the CI/CD pipeline (Continuous Integration / Continuous Deployment) allows you to detect performance regressions before they reach production. Rather than reacting after a deployment, you prevent the problem.

The most common approach uses Lighthouse CI (lhci), a command-line tool that runs Lighthouse in a CI environment and compares results against predefined thresholds or a historical baseline.

Typical configuration in a GitHub Actions workflow:

- name: Lighthouse CI
  run: |
    npm install -g @lhci/cli
    lhci autorun --config=lighthouserc.json

The lighthouserc.json file defines the assertions:

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["warn", {"maxNumericValue": 300}]
      }
    }
  }
}

With this configuration, the build automatically fails if the performance score drops below 90 or if LCP exceeds 2.5 seconds. Development teams receive immediate feedback on the performance impact of their changes.

This approach falls under the concept of performance budgets: defining non-negotiable performance thresholds and automating their verification. Each pull request is validated not only functionally but also on performance.

PageSpeed Insights vs Lighthouse: What Are the Differences?

The confusion between PageSpeed Insights and Lighthouse is persistent. Both tools are developed by Google and share the same audit engine, but their scope differs.

Lighthouse is the technical diagnostic tool. It allows you to debug a specific problem by configuring test conditions, recording performance traces, and inspecting the loading waterfall. It runs locally or in a CI pipeline.

PageSpeed Insights is the reference tool for measuring performance as Google perceives it. It combines lab diagnostics with real field data, providing a complete picture of the situation.

In practice, both tools are complementary. You use PSI to assess the overall situation and verify CrUX data, then Lighthouse locally to diagnose and fix the identified issues.

Common Errors and Their Solutions

The most frequent errors identified by PageSpeed Insights appear on the vast majority of audits. Understanding their root cause allows you to fix them effectively rather than applying superficial patches.

Third-Party Scripts and Their Impact on Performance

Third-party scripts (Google Analytics, Facebook Pixel, live chat tools, GDPR consent widgets, A/B testing solutions) often represent the primary source of performance degradation. On an average e-commerce site, third-party scripts can constitute 60 to 70% of the total JavaScript executed.

The problem is structural: each third-party script adds network requests, JavaScript parsing, and main-thread work. Accumulating five or six third-party tools is enough to drop the mobile score by 20 to 30 points.

Concrete solutions:

• Utility audit: list each third-party script and verify whether it is still used and whether it generates measurable value. Remove those that are no longer needed
• Deferred loading: load non-critical scripts (chat, analytics) after the page has fully loaded via defer or dynamic injection after the load event
• Server-side tagging: migrate tracking pixels to a server container (Google Tag Manager server-side) to reduce client-side JavaScript
• Facade pattern: replace heavy widgets (chat, video players) with a lightweight static facade that only loads the full script upon user interaction

Excessive DOM Size Issues

A DOM exceeding 1,500 nodes slows down style recalculations, layout, and browser paint operations. WordPress page builders (Elementor, Divi, WPBakery) are the main offenders: they generate dozens of nested div elements for each visual component.

Reducing the DOM requires a templating refactor: using semantic, flat HTML structures rather than deeply nested generic containers.

Redirect Chains

Each HTTP redirect (301, 302) adds a full network round trip. A chain of three redirects (http > https > www > final page) can add 600 ms to 1.5 seconds to the TTFB. The solution is to point directly to the final URL in all internal links and DNS configurations.

FAQ: Frequently Asked Questions About PageSpeed Insights

What Is the Difference Between the PageSpeed Insights Score and Lighthouse?

The score displayed by PageSpeed Insights is identical to the Lighthouse score because it uses the same calculation engine for lab data. The fundamental difference lies in the additional data: PSI displays CrUX metrics (real field data over 28 days) that Lighthouse alone does not provide. The numerical score is based on lab data, but CrUX data is what Google uses for ranking signals.

How to Interpret a Bad Score and Where to Start?

A score below 50 indicates structural problems. The recommended methodology:

1. Check TTFB: if the server is slow, no front-end optimization will compensate
2. Address opportunities in order of estimated savings: start with the one showing the most recoverable seconds
3. Identify Long Tasks in diagnostics: they reveal the most penalizing JavaScript
4. Measure after each change: one change at a time to isolate its impact

Can You Improve Your Score Without Modifying the Source Code?

Yes, several levers do not require changes to the application code:

• Switch hosting providers to a more performant server with object cache and built-in CDN
• Enable Brotli compression at the server or CDN level
• Configure HTTP cache headers via the .htaccess file or Nginx configuration
• Optimize images via an image CDN service (Cloudinary, Imgix) that compresses and resizes on the fly

How to Automatically Monitor Your PageSpeed Insights Score?

Several approaches enable automated monitoring:

• PageSpeed Insights API: run scheduled analyses (cron) and store results in a database
• Lighthouse CI in the CI/CD pipeline to block regressions before deployment
• Google Search Console: the "Core Web Vitals" section displays CrUX metrics for the entire site
• Third-party tools: platforms like Calibre, SpeedCurve, or DebugBear offer continuous monitoring with configurable alerts

If you want a complete performance diagnosis of your site by specialists, our headless performance audit covers all these metrics with prioritized recommendations. To discuss your project, contact our team.