Google's Core Web Vitals Reflect Google's Needs, Not Yours
This past summer I wrote a blog post for my employer about Google's Core Web Vitals initiatives as a primer for our clients about what the metrics are, what they mean for individual sites, and how much site owners and maintainers should worry about them. The answer to that last one is: not that much. You can read the post for all the details, but my point was that this is one tiny factor among many that affect your search rankings, and sweating that more than accessibility, structured data or great content is a waste of time.
But of course, as a web developer, I have to worry about them a lot.
I've been using this site for a lot of things in recent years: playing with comics data, making my photos available under a creative commons license, exposing my weird tastes in music — almost everything except writing. But one of the things I've spent the most time on is getting good scores from Google's various speed tests. I added caching, I stripped back my styles and scripts, I kept up to date with http/2, and I tried out a lot of the various tips and tricks that Google suggests.
And it has sucked.
Not that I haven't been successful! Straight 100s across mobile and desktop performance, best practices, accessibility and SEO, year after year for almost every page on the site. It helps that I have pretty ancient ideas about what makes a site good: high contrast colors, narrow columns of text, and simplicity above all else. That's a pretty big head start. But there are a lot of things you just can't do if you want to get perfect performance scores, and Google is no help. In fact, they're a hindrance.
As an example, I tested my site today and got my usual great scores. Then I tried to change the font I use from Helvetica Neue to Atkinson Hyperlegible, a new highly-readable and accessible typeface from the Braille Institute. So I did what anyone would do: I went to the Google Fonts Atkinson Hyperlegible page, followed the instructions, updated my site, and was unsurprised to see that I had dropped at least 5 points on my performance scores for every page on the site. Not great, Google!
But wait a minute, I am testing my site with Google, using resources from Google, and following the instructions that Google gave me, and my performance got worse? How can that be? Let's see what Google suggests:
Eliminate render-blocking resources: Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles.
What are the resources? The font files for Atkinson Hyperlegible. Is the font file that is used for all of the mostly-text content of my page critical? I would say yes. Should I use it inline, AKA somehow delivering code from Google's servers in my code? That is not possible. Maybe I should defer it? Doing that would lower my score by increasing my Cumulative Layout Shift metrics.
Avoid chaining critical requests: The Critical Request Chains below show you what resources are loaded with a high priority. Consider reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load.
What's the critical chain? The CSS file that Google loads from their server for Atkinson Hyperlegible. It's two elements in the "critical chain" for files that I can't load any other way.
Here's a fun one:
More than 2
<link rel=preconnect>connections were found. These should be used sparingly and only to the most important origins.
Let's go look at the code that Google suggested I use to load the font:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Don't use too many preconnect links, but also you have to use at least 2 or Google Fonts will be slow. And Google is the one who decided to host their files across two different subdomains, but you're wrong for following their lead.
Okay, that's all pretty complicated, but surely there's a way around it, right? Well, the Internet has some ideas. You could:
- Download the font files.
- Find a really fast CDN or server to host them.
- Set up your CSS to use another font that is likely to be available on visitor's computers and is very close in size and spacing to the font you want to use.
- Defer loading the fonts you want until after the page has loaded and use javascript to enable them.
- Hope that you don't get too much layout shift.
Google loves that method. It means that when somebody visits your page, the whole page loads quickly so you can start using it right away, and hopefully does not give you the dreaded Cumulative Layout Shift. But it sucks for users, because now you get a flash when the fonts switch on every single page load on every page of your site.
Why would Google favor that? Well, from their perspective, what matters is not a visitor browsing around on your site and enjoying your content. They get nothing from that. What they want to optimize for is the way that people searching for information behave: search Google, click on a link, determine quickly if it does not give you want you want, and then go back to your search results and try again. Maybe click an ad while you're there!
That's just one example. What if I told you that using Google Analytics lowers your performance scores? That they intentionally do not allow caching of their files and host them on a domain that uses cookies, so you get dinged for both? Why would they do that? Because their priorities are more important than yours.
Careful readers will note that when I was praising my site, I said that almost every page gets perfect scores on all of Google's measures. But which ones? The ones with dozens of images? The ones with a hundred YouTube video embeds? Nope. It's the ones with Google Charts on them, which immediately drops your score into the 80s. Why?
- Google says that 63% of three of the javascript files they load is just useless junk that I should get rid of. Somehow.
- On top of that, Google thinks I should use better compression software on their files served on their server which would reduce the transfer size from 700KB (of which 63% is useless) by more than half.
- They load 14KB of CSS which they never use, and I guess that's my fault. (Note that all of the CSS from my site is 3KB.)
And they go on and on about the performance hit of using their very own code:
- Reduce the impact of third-party code: Third-party code blocked the main thread for 810 ms
- Does not use passive listeners to improve scrolling performance: Consider marking your touch and wheel event listeners as `passive` to improve your page's scroll performance.
- Avoid an excessive DOM size: 2,781 elements (most of my pages without Google Charts have about 200)
- Serve static assets with an efficient cache policy: 12 resources found (All from Google)
What's the point of all of this? Google is judging the value and usefulness of your site based on metrics that their own tools worsen, and rules that they refuse to follow.
Every client I have wants to use Google Tag Manager (lowers your score), Google Analytics (lowers your score), other trackers like Google's DoubleClick (lowers your score) and then asks me why Google thinks their page is slow. Want some charts? Lowers your score. Google Maps embed? Lowers your score. A YouTube (Google) embed? Lowers your score UNLESS you read Google's advice and write custom code to display the video in a more performant.
When I put interactive features from Google on a site, I do it while knowing that they will probably cause a hit to performance. And I'm fine with that! They provide a lot of great tools, for free, that add a ton of utility. But the fact that they do not care enough to serve their files in keeping with their own guidelines? That they can't trim down their code so that you aren't downloading useless code? That they use techniques that they know lead to lousy performance? It's infuriating.
But it's also freeing. I'm over here sweating every single point in every single metric on every single page. Meanwhile, Google's own performance documentation pages get lower score than my site across the board, even for pages that are nothing but text. And one of the problems?
Ensure text remains visible during webfont load: Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.
Great job, Google. Oh, and since I took Google's webfonts off my site, this page gets perfect performance scores.
