Skip to content

core(emulation): bump chrome UA to m109 and drop LH identifier #14384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Jan 26, 2023

Conversation

paulirish
Copy link
Member

Sorry for the inconvenience folks. But we had to make this change due to some developers who prioritize gaming over user experience.

Relevant: b/244577753

@paulirish paulirish requested a review from a team as a code owner September 12, 2022 22:34
@paulirish paulirish requested review from brendankenny and removed request for a team September 12, 2022 22:34
@benschwarz
Copy link
Contributor

@paulirish gaming is definitely a thing, but does it actually outweigh people using the UA header to identify LH traffic for bot detection/WAF?

@connorjclark
Copy link
Collaborator

connorjclark commented Oct 7, 2022

@paulirish gaming is definitely a thing, but does it actually outweigh people using the UA header to identify LH traffic for bot detection/WAF?

Are you saying you know of usecases where a firewall allows traffic just because a header says a request is from Lighthouse?

@benschwarz
Copy link
Contributor

Are you saying you know of usecases where a firewall allows traffic just because a header says a request is from Lighthouse?

Yep, absolutely. People check for presence of Chrome-Lighthouse as the default easy way to identify incoming traffic (I suspect this is because PSI and other tools do not provide another mechanism to do so). They do so to either alter the response (score hacking), or to let traffic through to staging/preview URLs.

@connorjclark connorjclark changed the title core(emulation): bump chrome UA to m107 and drop LH identifier core(emulation): bump chrome UA to m109 and drop LH identifier Jan 26, 2023
@devtools-bot devtools-bot merged commit e98258f into main Jan 26, 2023
@devtools-bot devtools-bot deleted the bumpua branch January 26, 2023 19:21
@fevangelou

This comment was marked as off-topic.

@BuslikDrev
Copy link

Когда ждать обновление https://pagespeed.web.dev/? А то конкуренты по оптимизации дурят людей =)

@arnespremberg
Copy link

Hi colleagues, this update made it virtually impossible for our pages to be measured since i.e. cookie banners will destroy the lighthouse score. Could you maybe at least allow for users on https://pagespeed.web.dev/ to set cookies so it does not break their testing routines and KPIs?

@subhajeetdey
Copy link

HI, colleagues we are using this header checks to detect if we should run PSI tests on staging environments without this header we wont be able to identify

@Xowap
Copy link

Xowap commented Nov 9, 2023

some developers who prioritize gaming over user experience

Can you try to phrase it in a more judgmental way, @paulirish?

This kind of comment is enraging. I understand that you don't personally care about the score produced by this tool since the web.dev page gets a score of 29 and even the test tests itself at a measly 73 while being basically just a text bar. Don't even get me started at other Google products like YouTube or Google Fonts that immediately cost you 50 points when you put them on your page.

But a lot of us don't get to make an opaque tool that judges the rest of the web dispensing advice that more often than not will actually lower your score — usually doing the opposite will get the score up. When you work in an agency and that all your clients ever heard about SEO is that "if the score is too low Google will penalize you" you have no choice but to get the score up.

And it doesn't mater that in real-life scenarios the whole section above the fold gets painted before 400ms, because the test will keep on telling your client that it takes 7 seconds and they won't care that their own eyes show them that the website is fast because they are told that this will hurt their SEO.

So even if you want to pretend that your test is neutral, reproducible and relevant, please don't post this kind of insults for millions of developers that are trying to make a living...

@benschwarz
Copy link
Contributor

@Xowap I can understand that you have frustration, though your comments here are both unhelpful and misguided.

Don't even get me started at other Google products like YouTube or Google Fonts that immediately cost you 50 points when you put them on your page.

The Lighthouse team aren't responsible for YouTube or Google Fonts. If you add third party resources to your pages, they have a performance cost, just like any resource on your pages. That's on you and your team to decide what's reasonable, plan and adapt.

As an alternative to YouTube, you could use lite-youtube-embed, written by @paulirish 🙃

As an alternative to Google Fonts, you can self host fonts, or use less web fonts.

When you work in an agency and that all your clients ever heard about SEO is that "if the score is too low Google will penalize you" you have no choice but to get the score up.

Lighthouse / PageSpeed has no impact on SEO rankings. Site speed is determined by analyzing the Chrome User Experience Report (CrUX).

@fevangelou
Copy link

fevangelou commented Nov 10, 2023

To all those frustrated with this change, who used the user agent for Lighthouse to filter out third party content, I recommend the following:

a) Educate your clients. If your work is great (like 80+ score) without ads, analytics, widgets etc., make a page variant (/?nocrap) that doesn't load them. This will reveal the true score of YOUR work. In turn this exposes the laziness of others and of course the true cost of crap (eg FB page widget in 2023? Twitter/FB share buttons? Come on...).

b) If one of your clients says "but website X has a score of 90 with ads blah blah", check that site's code. Their devs mostly resort to gimmicks to fool their clients, like loading ads, analytics etc. when the user starts interacting with the page (eg scrolls - in comparison the LH bot cannot scroll as far as I recall). Which is pointless eventually as true users will count over the actual site score.

And in the end, what matters is THIS aggregate score of real user data that is presented in the Search Console.

It doesn't take a genius to understand why Google is pushing for performance so much. Sure, there was a time that slow sites may have caused practical issues in Google crawl bots. I believe the incentive is somewhat different nowadays, now that 3rd party generative AI is essentially competing with Google products on many fronts.

You see, large sites that generate ad revenue for Google may utilize multiple ad networks all competing (bidding) for ads, from the same ad pool. Google seems to have improved their performance on their third party code added via DFP, AdSense and so on. Other ad networks and Google ad brokers haven't. So when publishers are cornered by performance, they will have to make a choice: either continue with multiple ad networks hoping to maintain revenue, or ditch all but Google in the hopes that their traffic will improve, offsetting Google paying less for ad display compared to specialized ad networks that do "header bidding".

Put all these into perspective and move on.

@adamraine
Copy link
Member

Using the UA identifier to remove certain content for Lighthouse is exactly what this patch is designed to prevent. Users can still experience a negative impact to performance regardless of if the content first party or third party. Ignoring the effects of third parties isn't justifiable just because those third parties are Google products. That's a kind of bias we should prevent, not encourage.

As @benschwarz said, Lighthouse/PageSpeed scores are not a heuristic used by search engines to rank your page. Gaming the score won't improve SEO, it will just present an inaccurate assessment of performance.

So why do we care if you intentionally test different content than what users see? It's because it isn't always intentional, sometimes developers don't even realize it's happening (example).

@GoogleChrome GoogleChrome locked and limited conversation to collaborators Nov 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.