I posted the text below in the Google webmaster forum and got no answer!
I think at the beginning of a day you should know in which direction you should steer your work, right?
I hope now that I get a valuable answer here. Many thanks in advance.
Eric
"I have over 40 customer websites, all of which I created and optimized myself.
Since everyone knows that the performance values are an important criterion for the Google Ranking, I always invested a lot of time.
Meanwhile the setup of my pages is so good that I always reached 100/100 in the Google Pagespeed Insights Test (PSI). On GT Metrix 99%.
Now, however, the usual PSI link has been used to carry out another test recently, namely with Lighthouse.
With this test, suddenly none of my pages comes over 45% (aarrrgg).
The curiosity is that I get three different results.
via the already mentioned link to /speed/pagespeed/insights = 45%.
with the DEV-Tool in the Googlebrowser via Audits (also Lighthouse) = 68%.
via the PSI extension in the browser = still 100/100
My question is therefore quite simple:
WHICH OF THE THREE TEST OPTIONS IS THE ONE THAT WILL HAVE TO GUIDE ME IN THE FUTURE?
After all, one of the three must serve as the basis for the ranking!
By the way, I tested 20 of my 40 pages with all three Google tools and the results were identical different.
I’d be happy to wait for the answer if this still has to be researched internally at Google.
Besides me, many of my web designer colleagues are waiting for this answer,
because we’re all completely insecure."
The lighthouse, PSI tools etc are used to give ideas on what could be done to help speed up a website and shouldn’t be associated with search engine ranking.
I haven’t looked into lighthouse thoroughly but the scores on PSI don’t relate to the load time nor is there any evidence it correlates to search engine ranking i.e a higher score doesn’t mean the site will rank higher in search results.
From information Google has released only very slow websites are penalised in search results. However it also depends on the type of search query. Sometimes people are willing to wait longer for certain search queries.
That being said faster load times have been linked to better conversion rates, so it’s definitely worth improving the load time based on the real load time experienced by end users. Webpagetest is a great way to test this and to see where the bottlenecks are in the waterfall.
Maybe not the answer but it may help you to fix some issues that lighthouse may be suggesting from low grades.
From my understanding to get a full breakdown of the Lighthouse report, here on webpagetest carry out a test, click advanced testing then Chrome, then tick ‘Capture Lighthouse Report’ , yes it is the same/similar lighthouse, however the resulting test report is very detailed and from that i’m almost certain you will improve your score over on pagespeed/insights.
Further don’t be so caught up on grades as many say, actually you are very correct, which way is best to test, right now I can only agree with Patrick’s suggestion, as on the link below and various other articles. I interpret this as measuring the actual/perceived rendering/painting of the page is far more important and can be measured more accurately than by the overall scores;
BTW: The argument that score is not related to speed is kind of strange. At least for me “score” it’s a way to describe how well a page load would work under even worse user related conditions like a very slow mobile connection. This cannot be mapped to time because there are lots of load times for one and the same page under complete distinct conditions.
For me both PSI and WPT are messed up at the moment. I see numbers which are simply not true. E. g. look at this result:
I mean: if I interpret the chart right then the server connect happend after start render - cool, never seen before
Also PSI performs very strange things. ATF-content, completely delivered within the first 14 kB of a page and instantly shown in browsers (even slow mobile), lets PSI say now: both “start render” and “speed index” happen after 5.7 sec which is simply wrong. Moreover, the page is instantly interactive, scrollable and clickable. https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnetzklad.de%2Ftest.html
It is a test page, yes. I wanted to demonstrate by means of this page that even if the HTML download is still going on the ATF content will render instantly (well, after having received the first roundtrip’s data).
This was interpreted completely the way you’d expect before - until Lighthouse came into play and WPT got some updates recently (results see above).
There are more like bugs in PSI-Lighthouse. On the Desktop Tab the “lab data” are talking about an “emulated 3G” device … but values differ, compared to mobile tab. Pffff …
Lighthouse seems not to recognize the “font-display” attribute and treats web fonts always like render blocking.
So: the confusion is complete?! At least on my side it also kind of tends to go there
I really wonder how Google managed to mess up the only 2 tools I use at the same time. I mean: this looks like Beta stuff, beyond the nerd aspect. The old PSI had 10 criteria only and was a really simple tool compared to Lighthouse. Will this even more complicated software turn the web into a faster one? I’m afraid, the only thing that goes faster here is people running away and give up even faster.
BTW: The argument that score is not related to speed is not logical. At least for me “score” is a way to describe how well a page loads under even worse user related conditions like a very slow mobile connection. This cannot be mapped to time because there are lots of load times for one and the same page under complete distinct conditions. So score is kind of a substitute that is like a percentage of work already done to improve load time step by step which is reflected in score.
For me both PSI and WPT are not accurate at the moment. I see numbers which don’t look like probable. E. g. look at this result:
I mean: if I interpret the chart right then the server connection happend after start render - cool, never seen before
Also PSI performs very strange things. ATF-content, completely delivered within the first 14 kB of a page and instantly shown in browsers (even slow mobile), lets PSI say now: both “start render” and “speed index” happen after 5.7 sec which is simply wrong. Moreover, the page is instantly interactive, scrollable and clickable. https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnetzklad.de%2Ftest.html
It is a test page, yes. I wanted to demonstrate by means of this page that even if the HTML download is still going on the ATF content will render instantly (well, after having received the first roundtrip’s data).
This was interpreted completely the way you’d expect before - until Lighthouse came into play and WPT got some updates recently (results see above).
There are more like bugs in PSI-Lighthouse. On the Desktop Tab the “lab data” are talking about an “emulated 3G” device … but values differ, compared to mobile tab. Pffff …
Lighthouse seems not to recognize the “font-display” attribute and treats fonts further like render blocking - if they’re there or not.
So: the confusion is complete?! At least on my side it also kind of tends to go there
I really wonder how Google managed to mess up the only 2 tools I use at the same time. I mean: this looks like Beta stuff, beyond the nerd aspect. The old PSI had 10 criteria only and was a really simple tool compared to Lighthouse. Will this even more complicated software turn the web into a faster one? I’m afraid, the only thing that goes faster here is people running away and give up even faster.
