Website Speed Test — Core Web Vitals, TTFB and Page Structure
A full performance report for any page: Lighthouse performance score, LCP, CLS, TBT and Speed Index, plus server response time, page weight, request breakdown, compression, caching and security headers.
How to read your speed report
A speed report is really two reports. The lab metrics tell you how a page performed in one controlled load, and the structural checks tell you why. Improving the score means acting on the second half — the first half is only the scoreboard.
The metrics that matter
- TTFB (Time to First Byte) — how long the server takes to start responding. Under 200 ms is good, over 600 ms points at the server, the database or a missing page cache. This is the metric hosting controls most directly.
- LCP (Largest Contentful Paint) — when the main image or headline finishes rendering. Google's threshold for a good score is 2.5 seconds.
- CLS (Cumulative Layout Shift) — how much the layout jumps while loading. Aim for under 0.1. Images without width and height attributes are the usual culprit.
- TBT (Total Blocking Time) — how long the main thread was blocked and unable to respond to input. It is the lab proxy for responsiveness and is driven almost entirely by JavaScript.
- Speed Index — how quickly content appears visually across the whole load, rather than at one moment.
- Page weight and request count — total transferred bytes and how many files it took. Weight is where most easy wins live.
The structural checks
Alongside the metrics, this test inspects the response itself: whether compression is enabled and which algorithm, whether static assets carry cache headers, whether the connection uses HTTP/2 or HTTP/3, how many redirects sit in front of the page, whether images are served in modern formats, whether render-blocking scripts appear in the head, and which security headers are present. Each check is graded so you can see at a glance which ones are already fine and which are costing you time.
What to fix first
Work top down. Cut redirects, then fix TTFB with server-level caching, then compress and resize the largest images, then defer JavaScript that is not needed for first paint. Plugins can help with the last three. The first one is a hosting decision: no amount of front-end tuning will fix a server that takes 800 ms to answer.
Frequently asked questions
What is a good website loading time?
Aim for a Largest Contentful Paint under 2.5 seconds and a Time to First Byte under 200 milliseconds. Beyond about three seconds, measured bounce rate climbs sharply on every device class, and mobile users on slower networks feel the difference first.
What are Core Web Vitals?
Core Web Vitals are Google's three user-experience metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. They form part of Google's page experience signals. This test reports LCP and CLS directly, plus Total Blocking Time as the lab stand-in for responsiveness.
What is TTFB and why does it matter?
Time to First Byte measures how long the server takes to send the first byte of the response after the request arrives. Everything else in the page load waits behind it, so a slow TTFB delays every other metric. It is driven by server hardware, database performance, PHP execution and whether a page cache is active — which is why it is the metric that changes most when you switch hosting.
Why is my score different each time I test?
Lab tests measure a single load, and network conditions, server load, cache state and third-party scripts all vary between runs. A cold cache alone can move a score by twenty points. Run the test two or three times and treat the trend as the real result rather than any single number.
How can I make my website faster?
In order of impact for most sites: remove unnecessary redirects, enable server-level caching to cut TTFB, compress and correctly size images and serve them in WebP or AVIF, enable Gzip or Brotli compression, defer non-critical JavaScript, and reduce third-party scripts. If TTFB stays high after caching is in place, the server itself is the bottleneck.
Does web hosting affect page speed?
Substantially. Hosting determines server response time, available CPU and memory, storage speed, HTTP protocol support and how far the server sits from your visitors. Front-end optimisation cannot compensate for a slow origin server, which is why TTFB is usually the first thing to improve when moving to better hosting.