Articles

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.

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

I got my start in the newspaper industry, where placing a story or image “above the fold” means giving it the most prestigious real estate of the day. In a newspaper, the space “above the fold” is what’s viewable on the top half of the front page — no need to open or unfold the paper to start reading.

Since many web designers transitioned from print design, I’d often have conversations in the early years of the web about whether we needed to apply the same “above the fold” concept to our web sites. In general, my position was no – because there are so many different device sizes and users are so accustomed to scrolling, the “above the fold” space on a web page was not really equivalent in terms of user-experience to being on the front page of the newspaper or on the cover of a magazine. You could count on users to scroll down, and you couldn’t really measure where the “fold” was across thousands of differently-sized devices anyway.

That’s changed a bit in the past few years. Although I still think “above the fold” is less important on the web than in print from a content-engagement perspective, the question of what lands on the first screen of a mobile device has become very important in terms of site speed and Core Web Vitals.

In Google’s parlance, the speed of the “above the fold” area is measured by the “First Contentful Paint” metric. Maybe I’m old fashioned, but I much prefer the newspaper jargon (which at least has some connection to a real, tangible object) to the Silicon Valley jargon, so I’ll stick with accessible language like “above the fold” wherever possible throughout this guide.

Side note: “Contentful” is a made-up word! Actually, it has an archaic definition, but it used to mean “full of contentment,” as in happiness, not “full of content,” as in the words on a web page. Hey, Silicon Valley coders: stop “consuming content” and start using real words!

Because what’s “above the fold” on mobile is really meaningful for your rankings now, there will be some design trade-offs in boosting your speed scores. The good news is that, for the most part, you can apply these changes only on mobile sizes. Because the rules are less stringent on desktop, it’s OK to use big images, for example, whereas I will encourage you not to do that on mobile.

As a quick example, we have a large hero background image on the desktop version of the Howard Development & Consulting home page. I think it looks awesome, but it was dramatically reducing our First Contentful Paint score on mobile so we replaced it with a similar CSS gradient (which requires no images whatsoever). It’s definitely a trade-off, but in my view, the higher ranking is worth sacrificing a small design flourish on mobile.

These decisions are different for every site, but we’ve consistently found that reducing imagery above the fold is a huge help for your Core Web Vitals score and the real-world experience of your mobile users. There are a lot of cool opportunities to use CSS styles to add color and flourish to your mobile pages without images, too.

But when you do use images, you’ll want to make sure they’re optimized in the newest formats. We’ll talk about that in the next chapter.