Misleading PageSpeed Performance score and Core Web Vitals Score

[Amit]

Hi Barry,

I am seeing many persons, plugins and apps providing misleading pagespeed performance score and core web vitals score to clients.Google must punish  and stop those websites which are using it.

Thanks

[Barry Pollard]

It's a tricky topic!

In general we prefer not to "punish" but to encourage good behaviour.

Saying that, we do keep an eye on the various hacks out there and we have updated the metrics when they don't measure the actual UX (for example we've removed `opacity:0` elements from the LCP algorithm, and similarly for low-entry images). But for every change we do like this, there are also cases where we exclude things where the algorithm was working so we need to be careful not to "punish" those legitimate use cases just to catch the bad actors (who will no doubt move on to another hack). The Lighthouse user agent is another example of this. When we've tried to tone that down (to avoid bad actors changing content when they see Lighthouse), developers not using it for that but for other uses complain.

Luckily tricking the field Core Web Vitals is often more difficult than lab tests like Lighthouse. Not impossible, but more difficult.

Ultimately we feel that sites that try to "hack" their scores or Core Web Vitals are doing themselves more harm than good (as they lose valuable information on what their actual performance is!) and there's a question as to how much time and resources we should spend pushing back against that, versus helping those actually interested in using these metrics to improve.

Where that gets more difficult is where site owners don't realise what they are doing (for example installing a plugin that tricks Core Web Vitals, but they don't realise that's what's happening).

When you do see plugins and apps using hacky practices, I would encourage you to raise issues with the appropriate plugin or app stores, or support channels. While some are undoubtedly doing so with bad intentions, sometimes they are inadvertently doing this. Or sometimes, they are just not making clear enough the downsides of certain settings. For example, blocking all JavaScript until interaction on a client-rendered site that needs that for the main content is not a performance win (even if some lab tools that don't do interactions might make it look like it is) and a more surgical use of that feature is required.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/45118e27-0e7d-4c22-a09f-4080d5098753n%40googlegroups.com.

[Tony McCreath]

I've also found some solutions that specifically detect the testing tools and alter behaviour to try to improve scores. These solutions typically disable scripts, sometimes as a plugin, sometimes added manually by the hired developer.

I feel this is done to fool their customer (the site owner) into thinking their solution works better than it does.

When we see it, we inform the site owner.

In one case, we contacted the developer we know. We still see him doing it, so I don't expect much results from asking them to stop.

I use a little script to fool some of these hacks into thinking the browser is a testing tool. It makes it easy to see what the hacks do:

        <script>
            Object.defineProperty(navigator, "platform", {get: function () { return "Linux x86_64"; },set: function (a) {}});
        </script>

I suspect these hacks will break functionality for Linux users!

I also frequently crawl our clients' sites to look for known hack patterns.