Hello again from the depths of the Google Page Experience Update! My last post was written around the time that this update began to roll out, and it was intended to explain the update and define a “good” page experience in as complete a way as I could manage without pitching the reader into a swamp of details. This one is coming not long after the rollout was expected to be complete, but since I don’t feel any closer to understanding the algorithm’s basis for assessing page experience than I did in June (as I don’t believe anyone in SEO does), I’m going to use this occasion to offer up a list of five tactics for improving your page experience (however good or bad it might be now) that are universally applicable, measurably valuable, and above all, easy. After all, we’ve never needed to “understand” the algorithm before in any kind of meaningful depth in order to be able to do SEO, so let’s take the same attitude now. Here are five things you can do right now that are guaranteed to improve your page experience.
1. Audit Your Site for Legacy Third-Party Scripts and Remove As Many As You Can
Many of the granular page experience reports (such as PageSpeed Insights) assess types of code clutter and recommend delicate remediation techniques, but there is one type of code clutter that you can eliminate with a chainsaw instead of with surgical tools: third-party JavaScript from services that you no longer use. This is both the most effective and the simplest measure you can take to de-clutter your code and get every page to load faster. Take a look through the <head> of your major page templates and look for the <script> tags that call third-party servers. Are there any in there that you no longer need?
Maybe you installed a beefy plugin for social sharing buttons back when those were all the rage, and then years later you hired someone to oversee a redesign that included taking those buttons out. And maybe that designer scrubbed the buttons themselves from the template tag by tag, but failed to take out the script that those buttons relied on to communicate with their home server. This kind of thing happens all the time, and if your website has been online for long enough, there is probably at least one story of this kind of oversight that has left a trace in your codebase. It could have been a comments plugin, an advertising platform, an A/B testing tool, heatmap software, or truly anything else that anyone who ever worked on your site thought to try out once. Go peek under the hood and I bet you’ll find something that doesn’t need to be there anymore.
2. Upgrade Your Images to Next-Gen Formats
Here’s one that nobody seems to know about, because it comes up in every audit of this type that I’ve done since Google started calling it out a few years ago. By the standards of the web in 2021, the familiar digital image formats (JPEG, PNG, and GIF) are ancient and bulky. There are newer web-optimized image file types that deliver the same clarity of resolution in smaller file sizes thanks to advanced lossless compression techniques, and your site should be using them instead.
Google’s own WebP is the best-known among these, and according to their literature, a WebP image can offer the same resolution as a traditional image format, but at a filesize reduction of 25–35%. If you’re willing to downgrade your resolution slightly, a more aggressive “lossy” compression script can make your files even smaller. Conversion can be achieved with either a CLI or a build plugin called Imagemin (currently compatible with Webpack, Gulp, and Grunt), and both tools will allow you to set your chosen quality (degree of loss) to optimize precisely for the reduction in page load time that you’re after. By all accounts, this is a surprisingly low-friction effort for something that significantly changes what is almost certainly your site’s most important media type. Take a few minutes to read about it; I bet you’ll be convinced!
3. Be Absolutely Sure That Every URL Is Called in HTTPS
Google’s been beating this drum for years now, and we’ve been right there with them, but while broad adoption of HTTPS continues to rise, sites are still at great risk of failing this audit because of mixed content cases: cases in which every actual page on the site loads in HTTPS, but one or more subresources requested by their source code — scripts, stylesheets, iframes, image or video files, or anything else — are called over insecure HTTP. These calls constitute security holes insofar as they leave pages vulnerable to man-in-the-middle attacks, which can expose users to malicious tracking, spam redirects, or, if the requested resource is significant enough, theft of login credentials and other sensitive information — in other words, the very same worst-of-the-worst stuff that you fear might happen if hackers were to go after your server directly. They can also lead Google to classify your page or your whole site as insecure, despite being majority-HTTPS, and ranking and warning users about your pages accordingly.
Luckily, the major browsers’ developer toolkits are set up to flag mixed content on your site during page loads, so your efforts to eradicate it don’t have to require a lot of laborious digging on your part. Chrome DevTools prints mixed content warnings in the JavaScript console, and increasingly auto-upgrades or blocks it altogether for users, and Firefox does much the same. Let these tools tell you where the holes are in your resource requests, and patch them up!
4. Set Far-Future Cache Expiry Dates for Static Assets
Most sites have at least a few “immutable static assets” — pillars of their experience that don’t change from one visit to the next (or at least not until the next redesign). These generally take the form of image/media files, fonts, stylesheets, and scripts, and all can be cached by a user’s browser and loaded from the cache on return visits instead of being called fresh from the server, which can speed page load times dramatically. This is nothing new or strange, but to take full advantage of it, you would set the cache expiry date on your static assets to something in the far future, e.g. one year or more from time of capture. Very few sites do this, and I suspect lots of webmasters didn’t even know it was possible!
To do it, you need to configure your server to return the Cache-Control HTTP response header, and set a max-age directive to your desired duration (expressed in seconds). This Google dev help page walks you through it, and even explains how certain assets that you might want to update more frequently than your long cache duration accounts for can be set so that the browser “checks” with the server for an update before loading from cache, but still loads from cache if no update is found… which is still faster than downloading the file fresh. Take a look through the assets that constitute your site’s aesthetic and set a long max-age on any that you don’t intend to change anytime soon. All your returning visitors will thank you!
5. Do Not Request Permission to Send Push Notifications on Page Load
Here’s the only one of these five that might have actually provoked an animal response of some kind in you as soon as you read it. The collective loathing that so many of us feel for the experience of pulling up a page on a site we’ve never visited before and being pestered to allow it to push notifications to our device within one second of arriving — before we’ve had a chance to see or do anything — is so powerful that Google now officially recognizes it a marker of a bad page experience.
I feel I don’t have to explain how this one works, because you almost certainly know what I’m talking about, but I do need to state Google’s official counter-suggestion, which is to offer an opt-in on the page, and only for a specific type of notification, and then to fire the permission request only after the user has opted in. The same goes for geolocation permission. If your site doesn’t handle this kind of user solicitation this way, please consider changing your ways. When a page on your site brings in someone new, leave them in peace to read it, and trust in its quality to win them over and bring them back.
I hope this post alerted you to at least one relatively easy, concrete, and universal method by which you can improve your page experience immediately. These measures might not seem like much, but they do matter; applied on your site, they will make your users happier to be there, and in aggregate, they add up to a better capital-E Experience of the whole web for everyone. That’s a time investment always worth making.
