Especially arbitrary when considering their own website gets points knocked off: https://testmysite.thinkwithgoogle.com/

They remembered to cover Google.com (it gets perfect scores), but forgot the testing site itself.

The site itself is an abomination on a low end pc. That thing lags, drop frames, etc.

And it pretends to have a better score than a static html page without any ressources.

I only see 79/100 mobile friendliness for google.com (tried two times with same results).

The screenshot shows some text among the lines of "We're sorry... ...but your computer or network may be sending automated queries. [...]". It looks like some kind of abuse/DoS protection was triggered.

Youtube gets 54/100 on mobile speed and 70/100 on desktop..

PageSpeed, which this is based on, uses a relative metric last I checked. I.E. If you have a 2 byte site and can remove 1 byte, you'd get ~50 points off.

It's not quite that simple, but that's the basic idea.

Sadly, I think, it is that simple.

> 374 bytes of CSS

Put it <style> tags in the <head>. No reason to use an external file for so little. It's not worth the overhead.

Counterpoint, there's no reason to uglify something simple and clean by copy-pasting CSS into it to just to shave the remaining hairs off the dog's balls* when we already have a nice interface for read-once-use-everywhere references.

* - I don't know if that's a real expression. It doesn't even seem to fit, but I like it so I'mma keep it.

If it's on http2 and/or preloaded that certainly isn't true.

That's certainly true, but to his point - it's an 8ms call - is it worth the number of points Google knocks off?

What size cutoff would you use for the <style> tag? In other words, at what point is the tradeoff worth it?

I think its around 30kb.

https://www.smashingmagazine.com/2015/08/understanding-criti...

I do it for sizes less than 10KB (completely arbitrary) for most websites because the fact of the matter is that most websites don't get repeat visits often, and visitors rarely visit more than the page/article they arrived at.

There's no point making all visitors cache a CSS file when only a tiny minority will need it.

Note that I live in the middle of the Pacific Ocean, so HTTP round-trip times are terrible for most users. If you're on a first-world connection, it shouldn't matter as much.

It doesn't necessarily have to be about size. The goal is to let the browser paint the above-the-fold content without any external round-trips. Using the least possible seams sensible, especially if you do it on every page. This lets caching work as intended for the majority of the CSS.

This is exactly why I stopped using page speed insights for testing. The last time I used it, which was at least a year ago, I was losing points for serving too large an image file size on mobile. Only problem was I use converting to webp 'on the fly' with mobile browsers.

I could kind of get it if webp was an apple or ms solution but it isn't??

> Seems arbitrary

It's always going to be arbitrary to have an absolute measure given the diversity of sites. Large/slow images are going to be normal for photography sites for example but worth knocking points off for coding sites. You're better off using it as a relative measure to see if the same site is improving when you make changes.