Performance report
How fast does your
page really load?
A full front-end performance analysis — lab Core Web Vitals, a speed filmstrip, a request waterfall and Google PageSpeed Insights — in one report.
All measurements are lab data from a single automated load, clearly labelled as such.
Core Web Vitals
Lab LCP, TBT/INP and CLS from a real Chromium render, plus Google PageSpeed Insights and Chrome UX Report field data.
Speed visualization
A frame-by-frame filmstrip of the page painting, with TTFB → FCP → LCP → fully-loaded milestones.
Request waterfall
Every request with its DNS / connect / TLS / wait / download phases, filterable by type.
Browser timings
Redirect, DNS, connection, backend, DOM-interactive, onload and fully-loaded — the full connection story.
Page weight & compression
Total transfer size broken down by resource type, with per-type gzip/brotli coverage.
Structure audits
Lighthouse best-practice checks ranked by impact, with a GTmetrix-style Structure score.
What does the speed test measure?
It loads your page once in a real Chromium browser on our servers and records lab metrics: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT), First Contentful Paint (FCP) and Time to First Byte (TTFB), plus page weight, request count, compression and JavaScript errors. You also get a filmstrip of the page loading and a request waterfall.
Is this the same as my Core Web Vitals in Search Console?
No. Search Console reports field data: what real Chrome users experienced over the last 28 days. This test is lab data from one load, which is what you need to find the cause of a slow page. Only LCP and CLS here are Core Web Vitals. The third, Interaction to Next Paint (INP), needs real user interactions, so a lab test reports TBT instead as the closest stand-in.
What this tool checks
Largest Contentful Paint
Lab measurement of Largest Contentful Paint against the Core Web Vitals thresholds (good ≤ 2500ms, poor > 4000ms).
Why it matters: LCP marks when the main content becomes visible. Slow LCP makes the page feel unresponsive. This is a lab measurement from a single automated load — it is not real-user (field) data and will differ from Chrome UX Report values.
If it fails: Optimise the LCP element: serve a right-sized, modern-format image, remove render-blocking resources, and use a fast server/CDN.
Source: web.dev/articles/lcp
Cumulative Layout Shift
Lab measurement of Cumulative Layout Shift against the Core Web Vitals thresholds (good ≤ 0.1, poor > 0.25).
Why it matters: CLS measures unexpected layout movement. High CLS causes mis-taps and a jarring experience. This is a lab measurement from a single automated load — it is not real-user (field) data and will differ from Chrome UX Report values.
If it fails: Set width/height on images and embeds, reserve space for ads, and avoid inserting content above existing content.
Source: web.dev/articles/cls
Total Blocking Time
Lab measurement of Total Blocking Time against the web.dev thresholds (good ≤ 200ms, poor > 600ms).
Why it matters: TBT approximates how long the main thread was blocked during load. It is not a Core Web Vital: it is the usual lab stand-in for Interaction to Next Paint (INP), which needs real user input to measure. This is a lab measurement from a single automated load — it is not real-user (field) data and will differ from Chrome UX Report values.
If it fails: Reduce and defer JavaScript, break up long tasks, and remove unused third-party scripts.
Source: web.dev/articles/tbt
First Contentful Paint
Lab measurement of First Contentful Paint against the web.dev thresholds (good ≤ 1800ms, poor > 3000ms).
Why it matters: FCP marks when the first text or image is painted — the first sign to the user that the page is loading. This is a lab measurement from a single automated load — it is not real-user (field) data and will differ from Chrome UX Report values.
If it fails: Reduce server response time, eliminate render-blocking resources and inline critical CSS.
Source: web.dev/articles/fcp
Time to First Byte
Lab measurement of Time to First Byte against the web.dev thresholds (good ≤ 800ms, poor > 1800ms).
Why it matters: TTFB is how long the browser waited for the first byte of the document — dominated by DNS, connection and server processing time. This is a lab measurement from a single automated load — it is not real-user (field) data and will differ from Chrome UX Report values.
If it fails: Use a CDN, cache HTML where possible, and speed up backend/database work.
Source: web.dev/articles/ttfb
Total page weight
Lab measurement of the total bytes transferred to load the page.
Why it matters: Heavy pages are slow on mobile networks and cost users data. Around 1.5–2 MB is a common budget; well over that is worth reviewing.
If it fails: Compress and right-size images, remove unused JS/CSS, lazy-load offscreen media, and audit third-party scripts.
Number of requests
Lab measurement of how many network requests the page made.
Why it matters: Each request has connection and scheduling overhead. Very high request counts often mean unbundled assets or heavy third-party usage.
If it fails: Bundle assets where sensible, use HTTP/2+, and remove unnecessary third-party embeds.
Text resources are compressed
Lab check for script/style/document responses served without gzip/brotli.
Why it matters: Uncompressed text is typically 3–4× larger than it needs to be, directly slowing the page.
If it fails: Enable gzip or brotli for all text responses at the server or CDN.
No JavaScript errors on load
Reports uncaught JavaScript errors and console errors captured while rendering the page.
Why it matters: Script errors can break interactive features, tracking and content that is injected by JavaScript — which search engines may then not see.
If it fails: Investigate and fix the reported errors; test the page with a real browser console open.
Source: developer.chrome.com/docs/devtools/console/understand-messages
Performance score (PageSpeed Insights)
Reports the Lighthouse performance score — from Google PageSpeed Insights (mobile + desktop) when configured, otherwise the local Lighthouse run.
Why it matters: The performance score aggregates several lab metrics into one 0–100 number. It is a lab result; treat CrUX field data as the real-user picture.
If it fails: Work through the specific opportunities below for the biggest wins.
Source: developer.chrome.com/docs/lighthouse/performance/performance-scoring
Server responds and how fast
Queries the site and reports whether it responded and how long the response took.
Why it matters: A slow or unreachable origin blocks everything downstream — crawling, rendering and every visitor. This is response time over HTTP, not an ICMP ping.
If it fails: Investigate hosting, DNS or firewall issues if the origin is slow or unreachable.
Source: web.dev/articles/ttfb
Why is my score different from PageSpeed Insights?
Lab results vary with the test location, network, device emulation and the moment of the test. When PageSpeed Insights is enabled for a report, we show Google’s own numbers next to ours. Compare trends on the same tool rather than single numbers across tools.
What should I fix first?
Start with whichever Core Web Vital is in the poor range. A slow LCP usually comes from a slow server response (check TTFB), a large hero image or render-blocking CSS and JavaScript. Layout shift usually comes from images, ads or embeds without reserved space. The speed checkers test each cause on its own, and our methodology explains how lab results are scored.