It's not me who says it, it's Google.
But first let's review a few basic rules of the Internet:
Thou shalt not make slow websites
— The book of Zhiheng Wang and Doantam Phan 2018:1:17
This certainly does not come as a surprise, since Google makes endless statements about speed.
The PageSpeed of Google
And how nice from Google, they do provide tools to help us making our websites faster. Surely they must be showing the way. Let's take a look.
Starting easy, what about the blog post quoted above saying that speed will impact your SEO? It's a blog post, just text and a few boxes. Nowadays Webpack will optimize the shit out of your code and assets without you lifting a finger, so on that kind of website it's almost impossible to get less than 95% right?
Okay wait. But it's an old website. They didn't necessarily know at the time. Let's have a look at something else. Surely when they created the website for Google Lighthouse they had all the tools and optimizations in mind.
Damn. There certainly is a reason for that. There is a lot of content on that webpage and at some point you need to make sacrifices. Could we get a look at a representative website for "a lot of content"? Wikipedia looks very suited for this kind of comparison. It's full of old PHP code and will probably be bloated from all sides.
Apparently not. Wikipedia is completely in the green. And if you look at the warnings, most of them seem to be perfectly conscious decisions.
Whilst speed sounds pretty important for Google, looking at their websites reveals that they are far from the standards that they set on their own. And I'm not even talking about how the AMP webpage only gets 83% nor how google.com has a 70ms input latency.
The Embeds of Google
Of course the Lighthouse is just one of the tools. There is many others provided by Google like Google Analytics, YouTube or Google Fonts. As they're destined for outside use — and indeed wildly used — the only expectation you can have is that they provide the state of the art experience.
In order to check this out, I've created a few benchmark pages.
-
A baseline which only contains a
h1 - A Google Analytics (via gtag.js) version of that page
- A Google Fonts version as well
- And for videos
You can run all those in PageSpeed and you'll notice that neither Google Analytics nor Google Fonts will hurt your website's speed. Though there is a few warnings creeping at the bottom of the report but they don't actually seem to affect the score.
On the other hand, if you run it with YouTube... Well the page's score drops to 75%! YouTube is just killing your web page. Is this inherent to video playing? That's why I also benched Plyr which still gets a 99% score.
Key learnings
Google has always been putting a very strong emphasis on speed, yet you can see a double standard emerging.
- Things that can sell advertisement is very, very fast. The Google Analytics/gtag embed shows just that.
- Key products, like Google itself, stay quite fast while you can see some compromises made which impact performance in a non-noticeable manner.
- But other products, like the developer website or the YouTube player have a disastrous performance score.
We've also shown that whilst those secondary products have bad performance there is alternatives which can display a much higher score.
From afar, Google seems mighty and powerful but it seems that they are unable to produce high-quality work on several areas that are important to us commoners. There is probably reasons for that but I don't really care about them: the stand they're taking is way too strong to go away with excuses.
In the end, what I'll remember from this research is:
- Don't swallow Google's hypocritical crap
- Believe in yourself, doing better than Google is really not so hard 💪
Top comments (3)
Performance was one of the reasons we went down the path of offering our own video embed features on dev.to. It will continue to take a while before we can offer the experience of YouTube, but it's a good path to go down. YouTube is not great for pages.
Also tracking scripts and ads—we didn't need to be serving Google's tracking scripts and ads if we didn't have to be.
Kudos to the dev team!
So I'll just drop this here just in case but I coded like last week a video sharing platform based on AWS S3 + ElasticTranscoder. It's surprisingly easy to do (let's say 1~2 weeks of work on the video upload/play system). To handle uploads I use tus (with the official tusd implementation) and to manage the transcoding I forked videofront (mostly to upgrade the dependencies). And of course plyr for the video player (as seen above, very low performance impact). Works well for me!
Same 😄
And yeah, it's been great! We still have some UX to work out but the nuts and bolts have been awesome.