Google Lighthouse V8 – Improved CLS metrics(github.com)
github.com
Google Lighthouse V8 – Improved CLS metrics
https://github.com/GoogleChrome/lighthouse/releases/tag/v8.0.0
62 comments
And some PM is probably looking at those misclicks and seeing “engagement”
And on mobile Google likes to switch the order of the nav buttons: "All, Images, Maps" to "All, Maps, Images" depending on the search query.
They do that on desktop as well, and I hate them for it. For anyone who's never noticed it, try googling "backpack" and then "backpacker".
I tried so many ways to avoid that "feature" but they keep changing their implementation every few weeks.
It's super frustrating.
This is my current uBlock filter against it, I think it still works?
google.com#?#div:has( > div > div > h4:-abp-contains(People also))
It's super frustrating.
This is my current uBlock filter against it, I think it still works?
google.com#?#div:has( > div > div > h4:-abp-contains(People also))
I'm guessing google search doesn't care about SEO
This trips me up at least a few times a week. Infuriating!
[deleted]
ha, yes, absolutely. That shift of content is beyond frustrating.
Curious how HN itself stands now.
Pretty well on performance: https://onlineornot.com/perf-results/bZe4p1de7R.html
Well, clearly sites with no images or ads or javascript will score highly!
HN uses JS for the voting buttons.
I assume also for thread collapsing. For some reason, it is pretty slow on large threads.
Yeah I looked at the code once and I believe it was recursively collapsing every single comment under when you clicked collapse, and also storing the state of each in localstorage I think. It didn't quite make sense. I think it has been fixed though it's much faster now.
Also not sure when we're finally get non-paginated page loads.
Also not sure when we're finally get non-paginated page loads.
Why? HN is one of the most bare bones and barely usable sites.
It's good to see that they've added a Content-Security-Policy related test. I checked and Lighthouse 8.0.0 still penalizes you on "best practices" if your CSP does not allow inline styles.
Something that Lighthouse injects for testing tap-targets has inline styles, and Chrome will log a warning to the console, and Lighthouse penalizes you for that: https://github.com/GoogleChrome/lighthouse/issues/11862
Something that Lighthouse injects for testing tap-targets has inline styles, and Chrome will log a warning to the console, and Lighthouse penalizes you for that: https://github.com/GoogleChrome/lighthouse/issues/11862
The title's use of V8 is misleading because Google uses the name V8 to refer to its Javascript engine. It should be v8.0.0.
This is so exhausting, infuriating and perplexing.
Just 1 week after managing to claw our LightHouse score up to 90 - its shot back down 72. The arbitrary nature of their weighting is just tiring - and its compounded by the fact that noone actually knows how much this actually impacts SEO.
Just 1 week after managing to claw our LightHouse score up to 90 - its shot back down 72. The arbitrary nature of their weighting is just tiring - and its compounded by the fact that noone actually knows how much this actually impacts SEO.
Looks to me that you are not. using Lighthouse for the right reasons.
Lighthouse isn't there to improve your SEO. It's just a set of heuristics that make you website performance - as perceived by end users - measurable, and thus improvable. They add a quantitative score on a very qualitative process.
If you clawed your Lighthouse score to 90, you should have improved your end users experience, and that's what matters. Your score shot back down to 72, you know have new areas to investigate, super cool ! Your SEO will not suddenly improve or worsen due to this change. If you don't, however, address the new advices given by Lighthouse over a long period of time, other websites will, and their UX will be better than yours. And your SEO will reflect that. But that's the game with technology: over time, technology evolves, requirements change, and expectations shift.
Lighthouse isn't there to improve your SEO. It's just a set of heuristics that make you website performance - as perceived by end users - measurable, and thus improvable. They add a quantitative score on a very qualitative process.
If you clawed your Lighthouse score to 90, you should have improved your end users experience, and that's what matters. Your score shot back down to 72, you know have new areas to investigate, super cool ! Your SEO will not suddenly improve or worsen due to this change. If you don't, however, address the new advices given by Lighthouse over a long period of time, other websites will, and their UX will be better than yours. And your SEO will reflect that. But that's the game with technology: over time, technology evolves, requirements change, and expectations shift.
Google's Web Vitals page tracks things like Cumulative Layout Shift (CLS), First Contentful Paint (FCP), and Largest Contentful Paint (LCP). -- All of those metrics are visible in the Performance tab and are recorded by lighthouse.
From [1]: "The first reason is that cumulative layout shift will become a ranking factor in May 2021."
[1] https://huckabuy.com/2020/12/30/introduction-to-cumulative-l...
From [1]: "The first reason is that cumulative layout shift will become a ranking factor in May 2021."
[1] https://huckabuy.com/2020/12/30/introduction-to-cumulative-l...
But notably the SEO is based on those measurements as reported by actual Chrome users who choose to share data back to Google, which isn't necessarily the same as what lighthouse measures.
Also it hasn't happened yet. They pushed the implementation date to a slow rollout starting in "mid-June"
Also it hasn't happened yet. They pushed the implementation date to a slow rollout starting in "mid-June"
All the publishers I know (being one myself) only care about CWV for SEO.
> Your score shot back down to 72, you know have new areas to investigate, super cool !
I generally do not find it "super cool" when I suddenly/unexpectedly have new areas to investigate.
In most cases, the developer dealing with lighthouse scores is someone who just built a website to a client's spec, only to find out that there are things that it flags which are very time consuming to deal with. Set expectations all you want, but they want a near 100%.
To do all that work only for the score to drop later makes you as a developer look bad. A client who doesn't know any better will suspect you did faulty work.
I generally do not find it "super cool" when I suddenly/unexpectedly have new areas to investigate.
In most cases, the developer dealing with lighthouse scores is someone who just built a website to a client's spec, only to find out that there are things that it flags which are very time consuming to deal with. Set expectations all you want, but they want a near 100%.
To do all that work only for the score to drop later makes you as a developer look bad. A client who doesn't know any better will suspect you did faulty work.
Be proactive and inform your clients of the change. You get to do performance work, they feel taken care of by an expert, their visitors have a better experience, everyone wins!
> You get to do performance work, they feel taken care of by an expert, their visitors have a better experience, everyone wins!
Really though? It usually means:
* The fixes can require non-trivial changes that take an unknown amount of time to fix
* The client has to pay you for something that probably wasn't budgeted
* You have to fit in more work. If you're good at getting clients and you have a full schedule, it can throw a wrench in.
I'm not sure most freelance devs delight in doing suddenly imposed "performance work." Maybe the first time or two it's interesting, after that it's just annoying.
Really though? It usually means:
* The fixes can require non-trivial changes that take an unknown amount of time to fix
* The client has to pay you for something that probably wasn't budgeted
* You have to fit in more work. If you're good at getting clients and you have a full schedule, it can throw a wrench in.
I'm not sure most freelance devs delight in doing suddenly imposed "performance work." Maybe the first time or two it's interesting, after that it's just annoying.
Google needs to market Lighthouse to only developers. No good comes from your customers running these tests.
Is there any indication that Lighthouse affects SEO at all?
When it completely rolls out during this month, it's going to be tie-breaker which, supposedly, happens a lot more often than people think.
Additionally, it's not the Lighthouse score that you need to worry about, but WebVitals (FID, LCP, CLS) and only that for Field data, if your main concern is SEO.
Lighthouse is just a general tool that can hint you at performance issues.
Additionally, it's not the Lighthouse score that you need to worry about, but WebVitals (FID, LCP, CLS) and only that for Field data, if your main concern is SEO.
Lighthouse is just a general tool that can hint you at performance issues.
Your performance affects SEO, and people take the Performance Score as measured by Google Lighthouse to be a proxy for how Googlebot will rank their site.
If you're running Google Lighthouse manually, you might want to check out a tool I'm building - https://OnlineOrNot.com - it automatically monitors your page speed (as well as uptime, and soon Puppeteer checks). It uses Google Lighthouse v8.0.0 as of this morning (Australian time).
We have a free tier with no time limit or credit card required, if you want to check it out.
We have a free tier with no time limit or credit card required, if you want to check it out.
It seems Accessibility measurement broke on web.dev/measure (the report mentions lighthouse 8.0.0):
Background and foreground colors have a sufficient contrast ratio - Error!
axe-core Error: Cannot read property 'filter' of undefined
This website had ~80 in accessibility before.
Edit: this issue was known before release: https://github.com/GoogleChrome/lighthouse/issues/11384
Background and foreground colors have a sufficient contrast ratio - Error!
axe-core Error: Cannot read property 'filter' of undefined
This website had ~80 in accessibility before.
Edit: this issue was known before release: https://github.com/GoogleChrome/lighthouse/issues/11384
All of the reported URLs showing this issue no longer do, in the latest version of Lighthouse or on web.dev. Can you provide the URL (either here or in that issue) for which you still get this error? Thanks!
Not sure if it's just me, but the Lighthouse CLI is so buggy that I've resorted to setting to up to run in a docker container so that it doesn't crash when trying to load certain sites/configurations. Hope that they work on improving stability at some point. That being said, kudos to the team on the release, I'm sure this is a challenging project to work on!
Ironically I've found the CLI to be the only stable channel of Lighthouse. What do you see that docker fixes?
Fixes this issue basically:
https://github.com/GoogleChrome/lighthouse/issues/6512#:~:te....
Tried all of the proposed solutions and this error still pops up on certain sites and certain configuration settings. Felt totally random when it started happening.
Tried all of the proposed solutions and this error still pops up on certain sites and certain configuration settings. Felt totally random when it started happening.
Do you have a good record of these sites/configurations? We suspect it's related to the host environment in some way that we can't reproduce on our machines. It'd be useful information for debugging if you can share it. Thanks!
I’ve experienced the same as you, I’ve lost many hours to fixing different protocol time out errors. We’re running it in ECS now and it’s pretty stable, every now and then one pops up but is fixed by retrying the job.
Is there a way to run lighthouse 8.0.0 on older versions of Chrome for local (development) websites, so we can test them now instead of waiting until Chrome 93 is released?
In addition to the other comment, you could also install Chrome Canary to use the latest Lighthouse + Chrome.
If you don't have Canary installed, the CLI will use Chrome Stable. If Canary is present, that is the default. This can be configured with CHROME_PATH.
If you don't have Canary installed, the CLI will use Chrome Stable. If Canary is present, that is the default. This can be configured with CHROME_PATH.
This explains why our Lighthouse score went from 100 to 67 overnight with marginal code changes... Phew
[deleted]
Is CLS still broken for single page apps?
Can you elaborate? If you are referring to the long duration of a SPA, we resolved that by making CLS windowed: https://web.dev/evolving-cls/
Yes that is what I was referring to. Do you know if the Chrome User Experience report will use this windowing?
Lighthouse is great though :)