Site Speed Audit

Requires server processing

Enter a URL to run a real Lighthouse audit — Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time, and a 0-100 performance score with opportunities — plus a full CDN, cache, compression, and security-headers report for the same URL.

Strategy

    

Overview

This is the deep version of a performance check: a live, self-hosted Lighthouse audit reporting the three metrics a single-page audit can actually measure — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Total Blocking Time (TBT, a lab proxy for responsiveness) — alongside the overall 0-100 performance score and Lighthouse's ranked opportunities for making the page faster.

Alongside the Lighthouse run, the same URL's response headers are checked for CDN usage, cache behavior, compression, and baseline security headers — the same four checks Site Headers Report runs, included here in one combined report since you're already waiting on the audit.

Important: the Lighthouse metrics are lab data from one simulated run, not the real-user field data (from actual Chrome visitors) that Google's own Core Web Vitals assessment and Search ranking signal are based on. Use this to catch obvious regressions during development, not as a substitute for field data from a tool like Google Search Console.

Examples

Auditing a URL

https://example.com
Score: 94/100 · LCP: 1.2s (good) · CLS: 0.02 (good) · TBT: 80ms (good) · CDN: Cloudflare · Security headers: B

How It Works

  1. Enter a full URL, including https:// or http://.
  2. Choose Mobile or Desktop — results differ meaningfully between them.
  3. Complete the verification check if shown.
  4. Click Run Audit to run a Lighthouse audit and header report together, then review the full result.

Use Cases

Full pre-launch performance review

Check Core Web Vitals, the overall score, and the header-level basics (CDN, caching, compression, security headers) for a page in one pass before shipping.

Catching a regression before deploy

Run a quick check after a change that adds a hero image, a web font, or a large layout shift to confirm it didn't regress LCP or CLS.

Comparing mobile vs desktop

Mobile Lighthouse runs use a slower simulated network and CPU, so a page that looks fine on desktop can fail on mobile — check both.

Tips

  • The Lighthouse portion is cached for about 20 minutes per URL and strategy; the header portion for 60 seconds — re-checking the same page shortly after reuses both.
  • If the header portion fails for any reason, the Lighthouse results are still returned — the two checks run independently so a header-fetch hiccup doesn't discard a completed audit.
  • Total Blocking Time (TBT) is shown as a lab proxy for Interaction to Next Paint (INP) — true INP can only be measured from real user interactions, which a single-page lab audit cannot produce.

FAQ

Both ran the exact same underlying Lighthouse audit and just presented different slices of it, so they're combined into this one tool, which now also includes the CDN/cache/compression/security-header results for the same URL.

No. Search Console reports real-user field data collected from actual Chrome visitors over 28 days (the Chrome UX Report). This tool runs one simulated lab audit instead, which is useful for catching regressions but won't exactly match field data.

INP requires measuring real user interactions on a live page over time — a single automated audit has no user to interact with it, so it can't be measured this way. TBT is shown instead as Lighthouse's lab-only proxy for responsiveness.

Each check runs a real headless browser audit, which is far more expensive than a typical lookup, so a quick bot check helps keep this tool available for everyone.

No. Every URL is checked against Google Safe Browsing before the browser audit runs, and known malware/phishing/unwanted-software URLs are rejected outright.

Related Tools