Optimizing WordPress for Core Web Vitals

The following excerpt is taken from Optimizing WordPress for Web Core Vitals. You can read the introduction to the guide here.

In our final section, I’ll dig into each of the six Core Web Vitals metrics and show you which elements of your website are usually to blame for poor performance.

First Contentful Paint and Largest Contentful Paint

These two metrics are all about your above-the-fold content on the typical mobile device. (If you need help determining the location of “the fold,” Google’s PageSpeed Insights tool will show you a screenshot of what it thinks your page looks like on mobile.) Google measures how long it takes for the first text or imagery above the fold to be visible and uses that as your “First Contentful Paint” score. Then it looks at how long it takes for the largest single element (an image, headline or paragraph) above the fold to be visible.

You can speed up your First Contentful Paint score by improving your hosting infrastructure since your server’s response time is a big factor in when that first visible element is displayed. If your Largest Contentful Paint element is an image, you can either optimize your images or simply remove images entirely from the above-the-fold area on the mobile version of your site.

Speed Index

This is a similar metric to First Contentful Paint, but it measures the timing for all of the page’s content to become visible. This “fully visible” event generally takes place after First Contentful Paint but before the Time to Interactive marker described below.

Cumulative Layout Shift

This metric measures how much the layout of your site changes as each element loads. For example, if you have a big image that’s zero pixels tall when it hasn’t yet loaded, but then grows to 200 pixels when it finally downloads, that’s going to cause a big shift in how your page looks over the course of the loading sequence. Resolve this by ensuring that your HTML, CSS and JavaScript don’t cause this “jumpy” behavior, especially on mobile devices above the fold. This one may not be easy to solve without a developer, since it often involves getting under the hood with the code, but tightening up your above-the-fold design on mobile is a good start.

Time to Interactive and Total Blocking Time

Time to Interactive attempts to measure when a page is functional for the user. It doesn’t have to be 100% fully loaded, but the vast majority of JavaScript and other interactivity is up and running, so you can scroll, click buttons, interact with forms, and do everything a user might expect to do on a typical page. Because this is usually the last event in the loading sequence, this is usually the metric with the highest raw number (i.e. the number of seconds it takes your page to become fully interactive). Total Blocking Time is a simple matter of arithmetic — it’s the difference between your Time to Interactive and your First Contentful Paint values. In other words, Total Blocking Time is the duration from the point when the user sees content to the point where the user can interact with the page.

The following excerpt is taken from Optimizing WordPress for Web Core Vitals. You can read the introduction to the guide here.

In the heady days of my youth, I spent hours debating the virtues of Times New Roman, Arial and Verdana. It was a simpler time, with three universally available web fonts.

Today, we have thousands of fonts at our fingertips – but they’re not all created equal when it comes to your site’s speed. First, I encourage you to use fonts from a top-tier provider, such as Google Fonts or Adobe Fonts (formerly Typekit). As you venture beyond those two, you’re more likely to encounter fonts that will slow down your site more than they spice up your design. Both Google and Adobe provide most of their fonts for free, and they’re generally well-optimized or able to be optimized with a few lines of code added by a developer.

Fonts contribute to your overall page time, and can also have a significant influence on several of the Core Web Vitals metrics. They can cause a layout shift, they can make your page take longer before it becomes interactive and they can slow you down in other ways that affect your score. When you’re working with your developer on font optimization, they should be able to set up your fonts to “swap” after they’ve loaded, but show a fallback font (such as trusty old Times New Roman) for the first second or two, ensuring that readers can still see your page in full while they’re waiting for the custom font.

There are other custom fonts out there that are used solely as icon sets. These are super cool and I love them for their ease of implementation, but they’re generally bad news for Core Web Vitals. If you’re using a font icon set, you should work with your developer to replace the icons with SVGs to avoid loading an additional and unnecessary font on your site.

The following excerpt is taken from Optimizing WordPress for Web Core Vitals. You can read the introduction to the guide here.

Once you’ve handled your images, above-the-fold layout and hosting, it’s time to crack open the hood and start working with your code. While some of the earlier improvements are accessible without full-stack web development skills, for this section you’ll likely need to work with a professional web developer to get to the finish line.

There are three major areas where you’ll need to streamline and optimize your code. Your HTML (hypertext markup language) is the core code that creates the structure of your site; the CSS (cascading stylesheet) is the code that applies colors, fonts and visual styles to your elements; and, the JavaScript (JS) is the code that makes your site interactive, handling animations, tracking scripts, some visual styles and some form-submission behavior.

I’ll talk about some handy tools in this section that usually help. However, as you get deeper into your code, you may find that some of these “automatic” optimizations actually break things on your site. If that happens, you’ll need to work with a web developer to modify your code so it can be optimized without any functionality falling apart.

For HTML optimization, the minification tool built into Cloudflare is a great first step — once you’re on Cloudflare, it’s as simple as checking a box. You can also experiment with two of our favorite WordPress plugins, Autoptimize and WP Rocket, which have similar features. In short, they carve out all the comments and unnecessary white space to slightly reduce the file size of your page when it is delivered to a visitor’s web browser.

The tools above will also help you “lazy load” your images, ensuring that large image files aren’t downloaded until the user actually scrolls far enough to see them on the page. This reduces the total load time of your page and improves your Core Web Vitals score.

With CSS, things get a bit trickier. You can and should minify your CSS using the tools above, but carefully check that nothing breaks, such as complex animations or areas that use unique or out-of-the-box design elements. Taking your CSS optimization to the next level can also include breaking your CSS into separate files and only calling styles when they’re actually used on a page – for example, if you have an elaborate member-login area, there’s no need to call styles for that area on your home page when people aren’t logged in. Breaking apart your CSS can mean that less CSS is loaded on any given page, which is usually a plus for your Core Web Vitals scores.

A web developer can also help you generate “critical CSS,” which goes hand-in-hand with your above-the-fold optimizations. This ensures that the styles for the content above the fold on your pages loads almost instantly since it’s separated from the other, less critical styles that are used for elements lower on the page. In other words, the stuff you need first is separated so that it loads faster.

JavaScript is where things can get really rough because it’s much more fragile than HTML and CSS. Your goal is to “defer” as much of your JavaScript as possible until the end of your page’s loading sequence. However, you need to think about using a scalpel rather than a sledgehammer when you do this because loading things in the wrong sequence will sometimes break all the scripts on your page. We spend a lot of time parsing through JavaScript to determine which pieces we can fully remove, which we can defer to the end of the loading sequence, and which are truly essential. Again, you can often make some progress on this with automated tools like the ones I mentioned above, but if stuff starts to break or you can’t quite get PageSpeed Insights to stop complaining about scripts on your page, you’ll want to work with a developer.

There’s one more big trade-off about JavaScript — it’s used for almost all tracking tools, including Google Analytics, the Facebook Pixel and similar tracking scripts from just about every social network and software-as-a-service tool under the sun. We often find clients with a dozen or more of these scripts on their site, and unfortunately, that really hurts their Core Web Vitals scores.

You should be continuously assessing which of these tracking scripts are essential for your business needs and removing the ones that aren’t. (Alternatively, you can put some scripts on just one or two pages, rather than adding them globally to all your site pages, to reduce their impact.) For example, we use only Google Analytics on our site. Clients who purchase social media ads might need the Facebook Pixel, but could eliminate tracking from Twitter, LinkedIn or Hotjar. This will be different for every site, but the bottom line is that the more tracking scripts you have on your site, the worse your pages will perform.

Likewise, anything you embed on your site – such as a YouTube video, an animation from GIPHY or an e-mail subscription form from Mailchimp — is going to generate JavaScript and sometimes add heavy elements that will slow down your page load. As with tracking scripts, some of these are necessary (and we use well-optimized signup forms on our site while still achieving scores in the high 90s), but too many will inevitably bog you down.

The following excerpt is taken from Optimizing WordPress for Web Core Vitals. You can read the introduction to the guide here.

Earlier in the guide, I mentioned that your Core Web Vitals scores might change from moment to moment based on the response time of your web server. While many of the changes we discuss in this guide are generally “fixed” once you finish them – for example, changing your above-the-fold imagery or converting your JPGs to WebPs — you’ll need to keep a constant eye on the speed and quality of your web hosting provider and other pieces of your infrastructure.

If you’re struggling with your server’s “initial response time” or seeing consistently low scores on any of the key Core Web Vitals metrics, it makes sense to consider a migration to a faster web host.

For the vast majority of our clients, we recommend WP Engine. They have WordPress-specific security and performance optimizations, really great built-in caching and high-quality 24/7 live-chat support. They’re a little more expensive ($30/month rather than the $5/month you’ll get from a budget host), but unquestionably worth the investment for the speed improvements.

The second key piece of your infrastructure is Cloudflare, which provides a wide array of services, but for our purposes provides built-in caching and speed optimization, including automatically making your HTML, JavaScript and CSS files smaller. Cloudflare, which is free, will become your DNS provider and also add lots of helpful firewall and security features to make it less likely your site will suffer from downtime related to a cyberattack.

The combo of Cloudflare and WP Engine means you’ll have a strong foundation, and switching will probably boost your Core Web Vitals score immediately if you’re currently on a budget host.

The vast majority of our clients are running lightning-fast on WP Engine (that’s where we host our own site as well), but for some of our larger-scale clients we set up custom Amazon Web Services  (AWS) hosting environments. This usually doesn’t make sense until you’ve maxed out the higher-end WP Engine plans ($600+ per month), but if your traffic warrants it, a custom AWS stack can be a cost-effective upgrade to increase your site’s speed.

If you need help migrating to WP Engine, Cloudflare or AWS, feel free to contact us and we’ll help you get set up with a higher-quality infrastructure.

The following excerpt is taken from Optimizing WordPress for Web Core Vitals. You can read the introduction to the guide here.

Back in the good old days of the Internet, there were only two types of images, JPG (pronounced jay-peg) and GIF (which I pronounce with a “j” sound, although controversy continues to rage between the “g” and “j” camps). JPGs are great for photos, GIFs are great for animations or images that contain text. The third “legacy” option, PNG (pronounced “ping”), is like a supercharged version of a GIF with better transparency and higher quality for similar file size.

Google says you can just throw all your JPGs, GIFs and PNGs in a dusty corner next to your DVD player and 14.4 modem because there are new and improved “next-gen” image formats in town.

The first is SVG, which means Scalable Vector Graphics. An SVG is not really an image file, but a textual map of the exact vector dimensions and colors you want to display on the site. (If you’ve used Photoshop or similar tools, a GIF is raster, while an SVG is vector.) This means it loads way faster, produces a crisper image, and can be resized more easily than a PNG or GIF.

Google loves SVGs, so you should use a modern design tool (or one of the many converters you can find on the web) to turn your logo and any other PNGs or GIFs into SVG files wherever possible.

The new photo format is WebP, which is intended to provide high quality with lower file size than the JPG. It’s quite time-consuming to convert all your JPGs to WebP, but it’s a necessity to get your Core Web Vitals scores to where they need to be. We use a tool called Imagify, which is both a WordPress plugin and a web interface where you can upload JPGs and download them as WebPs.

The irony here is that you’ll spend a lot of time converting images and your site won’t look any different to the naked eye. But it will load faster and score much higher on Google’s Core Web Vitals measurements.