Understanding Google Core Web Vitals for law blogs
Illustration by Greg Storey
Many readers will be familiar with Google’s AMP, a standardized way to publish websites such that Google can detect that they are secure, fast, and user-friendly. Google has offered several incentives for providing an AMP version of your pages, including:
- Preferred placement in search results, such as in the carousel.
- “Signed Exchanges”: Lightning-fast page loads, since AMP pages are cached in Google’s CDN and pre-loaded as soon as they appear on the search results page. The page load is as fast as a native gesture on your device.
- A little gray lightning bolt icon next to AMP search results, signaling to users that when they click this link, they will see a website that abides by best practices. No annoying overlays or obnoxious dark patterns.
However, AMP is soon dropping support for points one and three, above. It’s still a perfectly fine front-end framework, but without overt SEO advantages, AMP is much less compelling.
Why is this news? Because much of this SEO juice is being replaced by Google’s Core Web Vitals (CWV).
Do we have to learn more acronyms?
Yes.
Web development professionals don’t need to be experts on every bleeding edge front-end concept. And web platforms certainly don’t need to support every latest technology. That said, CWV is an idea whose time has come.
CWV is a new set of website performance measurements authored by Google. They measure the way a website actually behaves for a human user, rather than assess things that might look statistically significant to a machine, but don’t affect people as much. The CWV are detailed at Web.dev.
Google claims these measurements will begin to affect SEO in June, 2021:
We’ll begin using page experience [as in, CWV] as part of our ranking systems beginning in mid-June 2021. However, page experience won’t play its full role as part of those systems until the end of August.
At LexBlog, we began to introduce support for CWV in late 2020. I’ve been measuring that progress in Google’s excellent Lighthouse tool. I’d like to share a few things I’ve learned.
It wasn’t that bad.
Before making any changes, I first gathered a batch of scores from various sites on our network. I was pleasantly surprised to see that most of our sites scored in the 60-70 range, out of 100, as measured by Lighthouse. This might sound a bit low, but in my experience that’s a pretty good opening score for an assessment tool you’ve never before attempted to please. I attribute our half-decent initial scores to:
- By default, every single blog on our core platform enjoys massive performance optimization thanks to our unique integration between Cloudflare and WP-Engine.
- Very few or no scripted ads.
- No analytics tracking beyond basic Google Analytics.
- Very little third-party tooling. We mostly make our own stuff, and therefore we don’t have to worry about scripts that call scripts that call scripts, etc.
Like most developers though, if you show me a number, and tell me that I need to solve problems in order to make that number increase toward a particular limit, I get … involved.
There was a lot of low-hanging fruit.
We designed and developed the front-end for our core platform a few years ago, and in the ensuing period, many HTML/CSS/JavaScript features have gained browser support. Some of these impact front-end performance and it was easy to introduce platform-wide support for them:
- More nuanced font-loading.
- Responsive images.
- Lazy-loading.
By just quickly shoring up those three things, maybe a couple others, I immediately started to see scores in the 80’s and low 90’s.
There were only a couple of annoying problems.
One of the more time-consuming problems was transitioning off of Font Awesome icons, in favor of individual SVG images, for certain modules. Not a terribly deep problem, but labor intensive. There’s a reason why we chose Font Awesome: The developer experience is highly scalable and convenient.
Another snag was that some performance improvements were merely a Cloudflare setting or two away — but we have over 1,000 properties on Cloudflare and we like them to all work the exact same way. Fortunately, a few years ago we built a custom dashboard for configuring a variety of CloudFlare settings across our entire network with one click.
Simpler is still better.
After all these years on and around the web, I still believe content is king. I think almost anything other than content and primary navigation is likely unnecessary. This intuition bore out well during the CWV process. Sites that insist on loading third-party scripts for things like image sliders, custom email marketing or ads hit a ceiling on their CWV scores that is not present on our core platform sites. For our core sites — that is, sites with no custom functionality — the ceiling is quite literally 100. After resolving a total of probably 10-12 issues, I started to see scores like this all across our network:
This site has a large body background image, high-resolution logos, custom fonts, yet it still scores 100 in the performance category.
Why stop at 100?
This is an addicting, highly gamified task. I’m finding it hard to want to move on to our next major initiative. Probably the next steps for improving our CWV even more are the various Cloudflare features that are tucked away at a higher tier than what our core platform uses. Things like next-gen image formats, for example. That’ll be something we examine later on this year.