GoogleChrome / GoogleChrome/lighthouse

Computed speed index far beyond reality in some cases

Open
#6,867 6 comments 4 reactions 0 assignees View on GitHub
bug P2
Dominant language
JavaScript
Stars
30.8k
Forks
9.8k
Avg merge
1d 20h
Merged PRs (30d)
19

Description

See this static HTML test file which fills any screen (above the fold) by delivery of the first 14 kB:
https://netzklad.de/test.html

It contains at its bottom a very large inline image. I prepared this months ago to prove that the first 14 kB **matter for speed perception** - and that browsers render to screens even if the rest of a HTML file is still not downloaded yet. That worked perfectly and shows what browsers do; see WPT waterfall:

![proven](https://user-images.githubusercontent.com/6112236/50388188-d3af2f00-06ed-11e9-9d1c-8aaed838165d.png)

Now look at **what Lighthouse computes** for this case, both the same in PageSpeed Insights and in Chrome:

![lighth](https://user-images.githubusercontent.com/6112236/50388282-d14dd480-06ef-11e9-83ca-75fd7b0917d3.png)

This is a huge difference compared to reality. For me it looks like a bug. Test it yourself. After receiving first data the page is interactive instantly (scrollable in this case), the speed index even on crappy mobile phones is far below 5 sec's, JS is not involved.
The score of the old Google Insights version (before the Lighthouse update in November was applied) showed for this scenario 100 points. And this had met reality.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.