Core Web Vitals for WordPress Websites

Core Web Vitals for WordPress Websites

You’re reading this, so you probably already know what Core Web Vitals and Page Experience are. But just in case you don’t – it’s Google’s way of forcing website owners to make their websites less slow and more pleasant to use. You make your website faster, Google can crawl it more efficiently, as a reward it sends its users your way. Win-win-win.

This is not the first time Google has pushed an update that is focused on user experience. Way back in 2015. there was Mobilegeddon – the update that marked beginning of the mobile era, one that started prioritizing websites that looked good on mobile phones.

This new update is no different in a way that it prioritizes websites that offer a better experience to the users, this is why it’s called Page Experience update, after all.

What is Google Page Experience?

Google wants to give its users the best experience possible, so when it shows a website in the search results page, that website needs to be good, and not frustrating, otherwise it makes Google look bad. So what does Google do? It defines a set of signals it uses to know if the page will provide a nice experience to its users before it sends them to your website. Those signals are:

  • Core Web Vitals
  • Mobile-friendliness
  • Safe-browsing
  • HTTPS
  • No intrusive interstitials

I’ll get to Core Web Vitals in a second, but first let’s have a brief look at the other four. It really isn’t that complicated, and the bar is set extremely low.

Make your pages look good and work well on mobile, make sure there’s no malicious or deceptive content anywhere, serve everything over a secure connection (HTTPS) and chill with the full-page popups. None of this is ground-breaking and we didn’t really need Google to warn us about it.

Core Web Vitals

By now you’re already familiar with, or at least heard of LCP, FID and CLS. They all sound fancy, even scary, so let’s have a look at each one of these.

LCP – Largest Contentful Paint

Paint equals pixels in this context. Largest Contentful Paint element is simply the largest element above the fold. Could be an image, a paragraph, heading, anything. Largest Contentful Paint tells you how many seconds it takes the browser to display that element. This is not only about faster server or more caching, you also need to make sure the page itself is light and easy to render (more on this later). For the page to be rendered, you need:

  • Server to generate and return the page as quickly as possible
  • Browser on user’s device to be able to render that page as quickly and efficiently as possible

You can control the server, but you can’t control the device or the browser, this is why it is essential to make the page easy to render.

Largest Contentful Paint is used to quantify perceived load speed. Most users will not care if parts of the page are still loading in the background if you give them the important content as soon as possible. Ideally in 2.5 seconds or less.

FID – First Input Delay

Input is anything a user does on the page (excluding scrolling or zooming in). Everyone hates websites that don’t respond to their input. Buddhist monks lose their cool when they tap the hamburger icon and the menu doesn’t expand. First Input Delay measures how long it takes the page to respond to that first interaction. Why only first? Measuring all interactions would be counter-intuitive and first impressions matter most.

If the browser has to do a lot of work processing complex JavaScript tasks while the page is loading, you can expect it will not be able to respond to user inputs quickly.

First Input Delay is used to measure load responsiveness. Even if the page loads quickly, it not being responsive while it loads is a bad thing. You want your first input delay to be under 100ms.

CLS – Cumulative Layout Shift

This could be the most frustrating one, but also the easiest one to fix. When the elements are moving around while the page is loading, more specifically when one element loading causes the ones below it to get pushed down – that’s a layout shift.

Combine all layout shifts that occur in a session window of page that has the highest cumulative layout shift – that’s your CLS score.

Session windows are a bit hard to explain, so let me try again. User loads the page, a few things move around, that’s one session window, for CLS calculation. Then the user scrolls down, more content is loaded dynamically and things move around again – that’s a separate session window. Which ever window gets the highest CLS score, that’s your page’s CLS.

Field Data and Lab Data

This one is extremely important.

Field Data is what Google measures from users who visit your website with a Chrome browser, mobile or desktop. There’s no emulating slow connections, CPU slowdown, nothing like that. The numbers represent what the users experience.

What you see when you do a Lighthouse assessment, using PageSpeed Insights, Chrome DevTools, or anything else powered by Lighthouse, is Lab Data. Mobile score here is likely to be pretty bad for a lot of websites because of throttling done for the assessment. Slow network speed and slowed down CPU. Probably to the point of it not being realistic in 2021.

What Google takes into account for Page Experience update is the field data. This means you are in better position if most of your users are on fast network and modern devices. A great application of design for the users you have. But also, just make it perform well for everyone, so you don’t have to sweat over what your users are on.

WordPress and Core Web Vitals

I’m a bit of a WordPress purist. To me, WordPress does not equal the junk you can add on top of it. WordPress is what you can download here, everything else is not. The all-in-one themes, magical visual editors, plugins on top of plugins, they are all ways to extend WordPress, but the are not WordPress.

This is why saying WordPress is slow is unfair. It’s like saying broccoli is unhealthy because you dip it in mayo.

Core Web Vitals for a fast WordPress website
Not perfect, but certainly fast, WordPress download page, powered by WordPress

Let’s look at each one of the Core Web Vitals and see how WordPress makes them worse. In theory at least.

First you have Largest Contentful Paint (LCP). And while you may argue WordPress (the thing you download from WordPress download page and then install) loads some junk that probably shouldn’t be there let’s be honest and say most of the junk that makes the browser work longer to render the page is provided by your theme or plugins.

Then there’s First Input Delay (FID). Caused by non-optimized JavaScript code, with long tasks preventing the browser from responding to user input. Again, can’t really fault WordPress much, even if things could be better.

JavaScript files loaded by WordPress
All JavaScript assets loaded by WordPress, not a lot of them

Finally, Cumulative Layout Shift (CLS). Unless you’re using one of the default themes, WordPress is not in charge of displaying your content, so let’s just forget about WordPress causing layout shifts.

What Makes WordPress Slow and How to Make it Fast?

Poor hosting and a clean WordPress installation, with no caching plugins or any kind of optimization will most likely pass all three Core Web Vitals and almost certainly get you an 80+ PageSpeed mobile score. That’s the starting point.

One you start adding tons of plugins plugins or third-party themes that “do it all”, you’re in trouble. One thing about WordPress ecosystem – not WordPress itself, the ecosystem around it – is most people learn how to do it on their own, from online tutorials that are not always great. There’s getting it done so it works, and then there’s getting it done properly.

This is why it’s very common for WordPress websites to have dozens of both CSS and JavaScript files loaded on every page. Most of them completely unused in a lot of pages. Simply because most tutorials only show you how to load a file, not that you should load it only when it is needed (a tutorial can’t make that decision for you).

Most page builders are where you’ll say goodbye to good Core Web Vitals scores. I’ve spent a lot of time fixing websites that used one particular popular page builder at my old job, that also had a Pro and an Ultimate version plugins, and the hole those things dig for you will be to deep for most people to climb out of.

Massive CSS files with 95%+ of unused CSS rules, similar thing with JS files, but also overly complex HTML structure, all of that means the browser needs to spend a lot of time rendering the page, this will hurt your Largest Contentful Paint and First Input Delay scores badly.

If you are dealing with a WordPress website that is already made slow, this simple process is how you make it faster, crushing those Core Web Vitals scores in the process:

Eliminate everything you can, optimize delivery of everything that’s left.

Do this for every key page of your website. Homepage, landing pages, product category pages, product pages, and so on.

Critical Rendering Path

If you want to have a low LCP number, this is one of the few things you need to work on, the other one being server response time. To display (render) a page, the server first needs to return it, then the browser needs to convert it to pixels. This second part is where most WordPress websites get into trouble.

Critical Rendering Path is everything the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen. Out of the box WordPress has minimal JS and CSS overhead and a very simple HTML structure. When you introduce a “do-it-all” theme, complex plugins you’re not sure are essential, and especially page builders JS, CSS and HTML become cluttered and complex.

The Key to Making a WordPress Website Fast is to Not Make it Slow

That said, this will make your website better for the users, so even if you completely ignore what Google thinks about your website, by optimizing your website for CWV you will make it better.