Reading a Page Speed Result
A page speed result shows more than scores. Below the score gauges you find panels that explain why the page was fast or slow: which element was the Largest Contentful Paint, what moved, which scripts kept the CPU busy, and the order in which every request loaded. This guide walks through each panel and what to do about what you see.
A panel only appears when the run has data for it. For example, a run without layout shift data has no Elements that shifted card.
Load replay
Next to the score gauges, the final screenshot of the page sits in a small player. Click it to play the page load, so you see when content appears. The expand icon (View full screenshot) opens the final screenshot full size.
Use it as a quick check before you read any numbers. If the page stays blank for a long time, or a banner pops in late and pushes the content down, you see it here.
Performance diagnostics
The Performance diagnostics section reads the Lighthouse trace of this run and shows what held it back. It has up to four cards.
Largest Contentful Paint element
This card names the element that was the Largest Contentful Paint (LCP) and shows its HTML snippet. It also crops the page screenshot around the element and draws a box on it. The value next to the title is the LCP time.
Under LCP breakdown, the LCP time is split into four phases, each with its time and its share:
| Phase | What it covers | If it takes the biggest share |
|---|---|---|
| Time to first byte | Until the first byte of the HTML arrives | Speed up the server: caching, a CDN, fewer redirects |
| Resource load delay | From that first byte until the browser starts loading the LCP resource, such as the hero image | Make the resource easy to find: put it in the HTML, preload it, do not lazy-load it |
| Resource load time | Downloading the LCP resource | Make it smaller: compress the image, use a modern format, serve the right size |
| Element render delay | From the resource being ready until the element is painted | Cut render-blocking CSS and JavaScript and long main-thread tasks |
A text element has no resource to download, so most of its time sits in the first and the last phase. More on the metric in Largest Contentful Paint (LCP).
Elements that shifted
The five elements that added the most to Cumulative Layout Shift (CLS), biggest first. Each row shows the element, its CSS selector and its shift score. The score uses the Core Web Vitals thresholds: below 0.1 is good, from 0.1 it needs improvement, from 0.25 it is poor. If nothing moved, the card says No layout shifts recorded.
Typical fixes: give images, videos, ads and embeds a width and height or a reserved space. Do not insert banners or other content above what is already on screen.
CPU time by script
The five scripts that used the most main-thread CPU time, with their host and a bar to compare them. Other (unattributable) is work Lighthouse cannot pin on a single script.
Main-thread work is what drives Total Blocking Time. If a third-party host tops the list, check whether this page needs that script at all, or load it later. If it is your own bundle, split it and defer the code the first view does not need.
Page weight
The total transferred size and the number of requests. Below that, a bar and a list split the weight by resource type (Document, Script, CSS, Image, Font, Media, Other), each with its size, requests and share. The last line shows how much came from third parties, for example "Third-party: 1.2 MB in 40 requests (35% of the weight)".
Images and scripts are usually the biggest share. To get an alert when the page grows, set a budget on Page Weight (KB) or Requests. See Performance budgets.
Request waterfall
The Request waterfall lists every request the page made, in the order they started. The line under the title gives the number of requests and the transferred size.
The timings come from the real, unthrottled load. They can be shorter than the throttled lab metrics on the gauges. Use the waterfall for the order of the requests and what waited for what, not for absolute times.
What you see:
- Filmstrip: screenshots of the page as it loaded, on the same time scale as the waterfall. The first frame at or after First Contentful Paint is tagged FCP, the first one at or after Largest Contentful Paint is tagged LCP. Hover a frame to draw its time as a line across the waterfall.
- Type filter: a chip for All and one for each resource type on the page, with a count. Click a chip to show only that type.
- Markers: vertical lines for First Contentful Paint, Largest Contentful Paint and Load event. The legend gives their times.
- Rows: each request shows its file name, host, browser priority (Highest to Lowest), the status code when it is not 200, and its transferred size. The pale part of the bar is time spent waiting before the request started. The solid part is the request itself. Hover the bar for its start and end time.
- Render-blocking: the request held up the first paint, for example a stylesheet or a synchronous script in the head.
- Preload: the page asked for the request early with a
rel="preload"link. - Not loaded: the request never finished. It was in the test's Block requests list, or it failed on the network.
The list starts with the first 30 requests. Click Show all N requests under the list to see the rest, and Show fewer to fold it again.
How to use it:
- Look at what loads before the FCP marker. Every Render-blocking request there delays the first paint. Inline the critical CSS and add
deferorasyncto scripts that do not need to block. - Find the LCP resource, often an image. If it starts late, after a chain of CSS and scripts, preload it. Once it carries the Preload tag, check that it now starts near the top.
- Filter on Script to see how many scripts load and from which hosts.
- A long stretch with no new requests often means the main thread is busy. Compare it with CPU time by script.
Server Response Time (TTFB)
The metric cards on the result include Server Response Time (TTFB): the time the server took to start sending the main HTML document. Like the other cards, it shows the Latest value and the Median. Good values are 0.8 seconds or less. Values above 1.8 seconds are poor. The history charts have a Server Response Time (TTFB) chart too, and it includes older runs.
A slow TTFB delays every other metric, because nothing can start before the HTML arrives. Look at server-side caching, slow database queries, a CDN in front of the site, and redirects.
In the PDF report
The printable report includes the Performance diagnostics and the Request waterfall. In the PDF the waterfall lists every request, not only the first 30, and leaves out the filter chips and buttons. See Branded PDF reports.