What is simulated throttling?
When Google’s PageSpeed Insights tests a page with Lighthouse, it doesn’t actually load it on a slow phone. It opens the page in Chrome on a fast connection and records what happens. The figures from that load are called observed metrics.
Then Lighthouse works out which requests held up the page, and estimates how long the same load would have taken on a slow connection and a slower processor. Those estimates are the simulated metrics, and they are the ones you see in a Lighthouse report. That is why a report can say a page takes three seconds when it opened in under one on your computer.
For a phone, Lighthouse’s default is a round trip time of 150 ms, a bandwidth of 1.6 Mbps and a processor four times slower than the test machine.
How this test works
We ask PageSpeed Insights to run Lighthouse on your page once. From its report we take two metrics, each in both forms, observed and simulated: First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Those four figures are Google’s.
Then we take the list of requests the page made and work out how the two metrics would change at other speeds: ten round trip times from 10 to 500 ms, and eight bandwidths from 1 to 50 Mbps. The result is a table for each metric. The outlined cell is Lighthouse’s default for a phone.
How the tables are worked out
The tables come from Seokla’s own model, not from Lighthouse’s. For FCP we take the page and the stylesheets and scripts that Lighthouse reports as holding up rendering. For LCP we add the image that appears to be the largest element, if there is one. For each speed we add up what those requests cost: round trips to look up each site’s address and open a connection to it, the server’s response time, round trips to deliver the data, and the time the bandwidth needs to let the bytes through.
To keep our model in step with Lighthouse, the outlined cell is set to Lighthouse’s own simulated figure. The difference between that figure and our model is kept the same in every other cell. It stands for what our model leaves out, mainly the time the processor needs to run scripts and draw the page, which doesn’t change with the network.
The report also shows what each estimate counts: how many files the metric waits for, how much they weigh as downloaded, and the time that is the same at any speed. It also lists those files, and the image we took as the largest element when there is one.
What is a good result?
Cells are coloured by Google’s marks for each metric. FCP is good up to 1.8 seconds and poor above 3. LCP is good up to 2.5 seconds and poor above 4.
The two scores at the top use the same marks, applied to Lighthouse’s simulated figures. A metric at or under Google’s “good” mark scores 100. At the “poor” mark it scores 50, and between and beyond the two it changes in a straight line: FCP reaches 0 at 4.2 seconds, LCP at 5.5. The marks are Google’s; turning them into a score from 0 to 100 is Seokla’s. This is not Lighthouse’s performance score, which also counts other metrics.
The tables are most useful for their shape. If the figures change a lot from row to row and little from column to column, the page is held back by round trips: chains of requests, connections to many sites, a distant server. If they change mostly from column to column, it is held back by the amount of data.
What this test can’t tell you
Apart from the outlined cell, the tables are estimates from a simple model. Lighthouse’s own simulation follows every request and every task on the processor; ours takes the requests level by level and treats processor time as fixed. Our figures will not match what Lighthouse would give at the same settings, and they are less reliable the further a cell is from the outlined one.
Which image is the largest element is our guess from the list of requests. If we pick the wrong one, the LCP table is off. Lighthouse itself notes that simulation isn’t always accurate, and no two runs give identical figures.
None of this is real-visitor data. To see what your visitors experience, look at the Core Web Vitals report in Google Search Console.