WordPress Core Web Vitals Guide: Improve Your PSI Score

In May 2020, Google announced its Core Web Vitals (CWV) page experience parameters that measure the overall experience of users on web pages through a set of metrics like interactivity, page load times, input delay, layout shift, etc. I will elaborate on the CWV in just a bit.

What is important to know is that CWV officially became a Google Search ranking factor with the implementation of the Page Experience update in June 2021.

Now, as things stand, you can no longer ignore how fast or slow your website loads. No more shoving speed issues under the carpet unless you are OK with a fall in your search rankings.

So, it makes good blogging and business sense to keep your page load times as low as possible. This is exactly what this WordPress Core Web Vitals guide is all about.

In this CWV tutorial, I will guide you through the exact steps that I took to bring down the page load times on PassionWP.com so that it passes the CWV assessment. What’s more, I did not hire a web developer for this task.

BTW, I also did not use any fancy CDN or high-priced hosting to achieve this feat. But I don’t want to get ahead of the story here.

All I can and will advise you is to read this WordPress CWV guide right till the end and try to implement as many suggestions and methods as possible to get the best result on your website.

Let’s get the party started.

Core Web Vitals explained

All this talk of lowering page load times is fine, but what is the acceptable page speed metric that decides whether your website speed is fast or slow?

Let’s say your homepage takes 2 seconds to load. This might be fast enough for you but slow for some of your users.

To tackle this issue and provide a benchmark for speed measurement, Google has introduced the Core Web Vitals (CWV) metrics.

The web vitals measure the overall page experience of users visiting your website and assign a score to each of these metrics.

Based on your CWV score, you can assess whether the page experience for your users is good, needs improvement, or is poor.

There are 3 CWV parameters to consider: 1. Largest Contentful Paint (LCP) 2. Total Blocking Time (TBT) or First Input Delay (FID) and 3. Cumulative Layout Shift (CLS)

Another web vital metric, which is not a core web vital, is First Contentful Paint (FCP) and is equally important.

In this post, we will focus on these 4 metrics (3 CWV metrics plus the FCP metric). If your site passes the CWV test, then your website speed is good enough for Google and your users (assuming that Google knows best).

Before we get into the nitty-gritty of lowering the page load times, I will briefly explain each CWV metric so there is no room for confusion down the road.

First Contentful Paint (FCP)

The First Contentful Paint (FCP) is the time it takes for the first text or image element to be visible on the page. A good example of the FCP would be your site logo which is usually the first to load.

The CWV benchmark for FCP is 1.8 seconds and under.

The following are the threshold parameters for measuring FCP.

FCP	Score
1.8 seconds or less	Good
Between 1.8 seconds and 3.0 seconds	Needs Improvement
More than 3.0 seconds	Poor

Make sure that the first image or text block is visible under 1.8 seconds to clear this CWV test.

Largest Contentful Paint (LCP)

The Largest Contentful Paint (LCP) is the time taken for the largest image or block element on a page to load. Prior to LCP, the entire focus of webmasters was on lowering the overall page load time.

But now we know that it’s more important to focus on the time it takes for the largest sized image or block element like text or video to load on a page.

The following are the threshold parameters for measuring LCP.

LCP	Score
2.5 seconds or less	Good
Between 2.5 seconds and 4.0 seconds	Needs Improvement
More than 4.0 seconds	Poor

So, you need to keep your LCP score lower than 2.5 seconds to pass this CWV assessment. In other words, the largest-sized element should be visible within 2.5 seconds when the page first started loading.

Total Blocking Time (TBT)

Total Blocking Time (TBT) measures the delay between the first visible element on screen like the site logo or Call to Action (CTA) element and the time it takes for the web page to become interactive by becoming responsive to user input.

A TBT score of under 50 ms is considered good by Google. The TBT is a lab metric used by Google.

The field metric based on your website’s actual data is called the First Input Delay (FID). The First Input Delay (FBD) measures the delay between the first user input and the response to that input.

When a user lands on a page, he or she will make some inputs like a mouse click or tap a button, etc. However, the browser is not able to respond straight away to the user input since it might be busy downloading other resources on the page.

Hence there is a lag or delay between the user input and the browser response. This delay is measured using the FID metric.

The following are the threshold parameters for measuring FID.

FID	Score
100 ms or less	Good
Between 100 ms and 300 ms seconds	Needs Improvement
More than 300 ms	Poor

So, you need to keep your FID score lower than 100 ms to pass this CWV assessment.

But let’s not get confused between TBT and FID. Since you will be carrying out speed tests using online tools that only have access to the lab reports and not the field reports, you should concern yourself with Total Blocking Time (TBT) only.

Remember, we will focus on keeping the TBT to less than 50 ms to pass the CWV assessment.

Now, let’s move on to the final CWV metric.

Cumulative Layout Shift (CLS)

Have you ever been in a situation where you’re reading something on a webpage and suddenly the page shifts unexpectedly resulting in a poor experience?

Let’s face it, we’ve all been in such situations on more than one occasion. And now, Google Lighthouse has a metric to measure such unexpected layout shifts on web pages called the Cumulative Layout Shift (CLS).

The CLS measures unexpected shifts in the layout of a page resulting in poor user experience.

The following are the threshold parameters for measuring CLS.

LCP	Score
0.1 or less	Good
Between 0.1 and 0.25	Needs Improvement
More than 0.25	Poor

So, you need to keep your CLS score to 0.1 or lower to pass this CWV assessment.

Of the 3 CWV metrics, CLS is the easiest to tackle as I shall explain later in the eBook.

You should note that the 4 web vitals do not carry equal weight in determining your overall CWV score. LCP and TBT have the largest share in the CWV assessment followed by FCP and CLS.

The weights assigned to the different web vitals is constantly reassessed and keeps changing. You can find out the latest scores for each CWV metric from the Lighthouse Scoring calculator. 

Summary

Let’s now quickly summarize what we have learned so far.

1. Page speed matters and is a search ranking factor.
2. Google places utmost importance to user experience on web pages and has introduced metrics called the Core Web Vitals (CWV) to measure the user experience.
3. CWV has a direct correlation with website speed. So, when CWV improves, your website speed also improves.
4. The three CWV are Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Additionally another web vital, the First Contentful Paint (FCP), is also important.
5. We will focus on improving these 4 CWV metrics to improve our website speed.

How to measure the Core Web Vitals

Before you get started with improving your CWV score, you should choose the right tools to analyze your CWV.

There are tons of speed measurement tools available of which the three most popular ones are:

1. Lighthouse (Google’s own CWV measurement tool)
2. WebPageTest (Recommended CWV tool by Google)
3. GTmetrix (most popular speed measurement tool)
4. Google Search Console

We will largely use Google’s Lighthouse on the Page Speed Insights page to analyze the Core Web Vitals. For some purposes, the WebPageTest tool will be useful as well.

The Search Console CWV report provides details about the number of pages on your site that pass the CWV assessment or need improvement.

Once your CWV metrics improve, the orange URLs will turn green as they did in our case.

Let me quickly acquaint you with the Page Speed Insights (PSI) CWV measurement tool. Once you run your site through PSI, you can check your speed score for mobile and desktop.

Below this, it displays the CWV summary for the webpage.

You can instantly know whether the page passes the CWV assessment or not.

The four web vitals are listed here. A blue bookmark icon is appended to the three CWV metrics: FID, LCP, and CLS.

But we are most interested in the page audits that are relevant to the four web vital metrics that are listed further down.

In order to improve your WordPress CWV score, you need to work on the issues highlighted in the audit report for each CWV metric.

Remember, you don’t have to resolve all the audit errors; just the ones that have the biggest impact on your Core Web Vitals.

Identifying the LCP on a page

Since LCP is a tangible element like an image or an HTML block, it can be identified using the PSI tool. In the audits panel (refer to the above image), click on the LCP tab and then the dropdown that says “Largest Contentful Paint element – 1 element found”.

I also recommend running your page URLs through the WebPageTest tool that provides a detailed breakdown of each CWV score for your site.

Now, let’s go through the steps to rectify the most commonly highlighted issues (that are also the most important) in the PSI audit report to improve our CWV score.

Minimize the server response time

Your website is hosted on a web server that serves the information requested by the browser when a user lands on one of your website pages.

Now, how fast or slow your hosting server responds to the user request is crucial to determine your page load times. In terms of CWV, the First Contentful Paint (FCP) Largest Contentful Paint (LCP) metrics are directly impacted by your server response time.

You might see the following warning in your PSI audit: “Reduce initial server response time“.

Remember that I mentioned that FCP is the time required for the first element (text or image) to be visible on screen and LCP is the time it takes to load the largest sized image or block element on a page.

FCP should be under 1.8 seconds and the LCP should be under 2.5 seconds. If your server is slow to respond to the browser request, it will delay the FCP and LCP or in simple words, the first and the largest text or image elements on the page will take longer to load.

To measure the server response time, you can use a tool like GTmetrix or WebPageTest. Google recommends the latter, so let’s stick with it.

On the webpagetest.org site, you have to input the URL of the page whose speed you wish to check and the location of the test.

Since your homepage is usually the most important page on your site, it’s a good idea to start optimizing it first. So, pop in your homepage URL.

Next, select a location that’s closest to the majority of your website users.

Start the test.

After the tool finishes running through the page, it presents a detailed performance report. Under the Details tab, you can check out all the vital parameters of the page.

Check the First Byte time.

The first byte time is dependent upon the initial response from your server. It is the time taken to receive the first byte by the browser from the server.

If the initial response time is higher, consequently the first byte time will increase and vice-versa. Higher the first byte time, higher will be your FCP and LCP times.

The first byte time should be lower than 600 ms. Ideally, it should be under 200 ms.

For the sake of average, let’s consider 300 ms as the benchmark score. If your first byte time is under 300 ms, you are clear on this count. If not, you need to consider switching over to a faster server or web host.

Solutions to high server response times

A fast hosting can help minimize the initial response times.

Managed WordPress hosting platforms usually offer fast shared servers to host your site. If you’re already using a managed WordPress host, then you shouldn’t have to switch hosting unless the first byte time is really slow.

However, if you’ve recently launched your website and there’s no earning yet, there’s no point in switching over to costly web hosting.

Rather, I will recommend Dreamhost which we use to host PassionWP with excellent results. It offers truly unlimited hosting, including, storage, bandwidth, and email on its shared hosting plans.

By truly unlimited, I mean there are no Fair Usage Policy (FUP) limits or inodes to worry about (as in shared hosts like Hostinger).

Using a combination of Dreamhost + Cloudflare + WP Rocket, we have been to get a Page Experience score of 100% in Search Console.

However, one drawback of Dreamhost is that all its data centers are located in the US. So, if your site receives traffic from outside the US, the server response time may be higher for those regions.

That’s why I recommend using a free Content Delivery Network (CDN) like Cloudflare that offers CDN + firewall for free.

Use a Content Delivery Network (CDN)

A CDN stores the most frequently requested files on its servers and serves these files to the users from a server or location that’s closest to them.

This reduces the number of requests made to your hosting server since most of the information will be served from the CDN.

Secondly, it reduces the time taken to serve the information since it’s being served from a location that’s closest to the user instead of your web server that might be situated thousands of miles away.

For this reason, a CDN will help to reduce the server response time greatly and also speed up your website. In terms of CWV, the FCP and LCP scores will benefit from the use of a CDN. Since the content will be delivered faster owing to lower server response times, it will take lesser time to load the first element (FCP) and the largest element (LCP) on the page.

ad

Summary

• The server response time directly impacts the FCP and LCP Core Web Vital metrics
• To reduce the server response times, a combination of a fast web host and a CDN are vital for any WordPress website

Use an efficient cache plugin

About 90% of the information on our websites is static, which is not changing constantly. This static information can be cached or stored in the visitor’s browser so that your website loads much faster on subsequent visits since the static information will be retrieved from the visitor’s cache and not your server. This method is called browser caching.

Some web hosts like Kinsta and SiteGround include caching at the server level, which is ideal.

If your host does not provide server-level caching, don’t worry. There is another method to leverage server-side caching by using a WordPress cache plugin that stores the most frequently accessed information on your server (WordPress installation).

Besides caching static resources, a cache plugin performs many other optimization tasks and therefore should be used even if your host provides its own caching mechanism.

There are many free and premium cache plugins available. We earlier used the WP Fastest Cache plugin on PassionWP. While it did a decent job, we were still not satisfied with our website speed since PassionWP failed to clear the Core Web Vitals (CWV) test on page speed tools and obtained average scores in the Google Search Console (GSC) user experience reports.

Then we switched over to WP Rocket, the most popular premium plugin available today.

It offers the following benefits:

1. Ease of use
2. Page and browser caching
3. Cache preloading
4. GZIP compression
5. Database optimization
6. Lazyload images
7. JavaScript and CSS minification
8. Loads JavaScript deferred
9. Preload fonts and prefetch DNS
10. Supports multiple CDNs
11. And much more

Frankly speaking, WP Rocket is the number one reason why our previously average Core Web Vitals transformed to “Good” CWV. In other words, PassionWP went from average loading speed to fast loading speed within 30 days of activating WP Rocket.

Look at the image containing the Search Console CWV report screenshot below for confirmation.

I advise you to go through my detailed tutorial on the ideal WP Rocket settings.

There are multiple free alternative cache plugins available, but they don’t even come close to the level of optimization achieved using WP Rocket. Some of the notable free cache plugins include:

1. W3 Total Cache: One of the popular free cache plugin for WordPress but with a clunky interface that is not very user friendly. Also, the settings are somewhat hard to understand and configure.
2. LiteSpeed Cache: When used on a website running on a LiteSpeed web server, it offers similar levels of optimization as WP Rocket. However, configuring LiteSpeed Cache is tricky and it can break things easily on your site if not configured properly.
3. WP Fastest Cache: This is another good free cache plugin to consider. The layout is simple, and you get the basic cache features for free. The premium version is a one-time payment, but it cannot compete with WP Rocket when it comes to speed.

Whether you choose a free or premium plugin, don’t forget to pair it with a free CDN like Cloudflare for optimal results. Every cache plugin offers built-in support to integrate a CDN, so it’s pretty easy to set up a CDN on your WordPress website.

Related: The 7 best speed optimization plugins for WordPress

My final advice is if you use a free cache plugin that offers limited optimization features, you can pair it with a performance plugin like Perfmatters which takes care of many optimization tasks explained below.

 Optimize the JavaScript and CSS files

Every page on your website loads a number of JavaScript and CSS files that are required by your theme and different plugins to function properly as well as scripts like Google Analytics.

Each JavaScript and CSS file makes a separate request to your web server. If there are a large number of such files, the number of requests can shoot up quickly putting a lot of strain on your server. This will result in slow communication between the server and the user’s browser making your site load slowly.

For this reason, you need to optimize your JavaScript and CSS file delivery. There are many things that can be done here like:

• Combine the JavaScript and CSS files: This combines multiple JavaScript and CSS files into single JavaScript and CSS files helping to reduce the number of HTTP request made to your server.
• Minify JavaScript and CSS files: Minification reduces the size of your JS and CSS files by removing the comments and blank spaces within these files making them smaller in size and quicker to load.
• Load JavaScript deferred: By default, all the JavaScript files are loaded simultaneously on page load. This can block other resources from loading since JavaScript tends to be render blocking i.e. it blocks the loading of other files till the JavaScript file has completely loaded. To overcome this problem, JavaScript loading should be deferred until other essential files are loaded first.

Now, it’s simply not possible to carry out these optimizations manually. Rather, you can use a cache plugin like WP Rocket to optimize the delivery of your JavaScript and CSS files.

WP Rocket performs all of the above-mentioned optimizations effortlessly. It also offers the additional two features:

• Remove unused CSS: Not all CSS needs to be loaded on a page. Too many CSS files only add to the page size and interrupt the loading of the other page resources. That’s why this feature in WP Rocket removes the unused CSS files on a page making it load faster.
• Delay JS execution: This feature delays the loading of JavaScript until user interaction.
• Preload: The preload feature loads the most important resources on a page like fonts, images, media, etc. beforehand. It will help in optimizing your LCP score.
• Preconnect: The preconnect directive tells the browser to connect to external resources like Google fonts even before they are actually requested on the page. This saves round tripping time when the server makes a request to the external site, connects with it and then receives the requested information.
• Prefetch: Prefetch helps to reduce the DNS lookup time. Whenever a resource like JavaScript is hosted on an external site (like Google Analytics), a DNS lookup will be initiated which requires a small amount of time. Prefetch anticipates the DNS lookup request and processes it in the background thus saving precious time.

Impact on your Core Web Vitals

The JavaScript and CSS optimization that I have explained has the biggest impact on your CWV metrics. Right at the beginning of this tutorial, I mentioned that you should keep your server response times low and that the Total Blocking Time (TTB) should be under 50 ms.

By optimizing the delivery of your JavaScript and CSS files, the number of requests to your server will reduce. Also, by combining and minifying the JS and CSS files, the overall page size will reduce. Lower the page size, lesser will be the time required for the server to process the page file.

Hence, again the server response time is impacted by this.

Further, deferring and delaying the loading of JavaScript will consequently reduce the Total Blocking Time (TBT) since the render-blocking JavaScript is now deferred till the page becomes interactive for the user.

The following warnings in the PSI audit report will be taken care of:

• Minify JavaScript
• Eliminate render-blocking resources
• Reduce unused CSS and JavaScript
• Enable text compression (Gzip)
• Preconnect to required origins

So, your WordPress CWV metrics will definitely improve after implementing all the optimizations that I have explained.

Optimize your images

By optimizing the delivery of your JS and CSS files, you’ve already done the heavy lifting. Now, there’s some light but equally important tasks that you should carry out to further improve your WordPress Core Web Vitals.

Images enhance the look and feel of our websites. But too many unoptimized images on a page can make it crawl since they add to the page bloat.

The solution is to optimize the images using the following recommended practices:

1. Compress images
2. Lazyload images
3. Specify image dimensions
4. Serve images in WebP format

Image compression

All your website images should be optimized using lossless compression. This method compresses images without causing a quality loss.

Image compression reduces the size of the images which in turn directly impacts the First Contentful Paint (FCP) and Largest Contentful Paint (LCP) web vital metrics.

Your logo image is usually the first element to show up on screen (FCP). Also, images usually are the largest sized page elements (LCP). Compressing the images will lower the FCP and LCP thereby boosting your Core Web Vital WordPress score.

Must Read: The 10 best image optimization plugins for WordPress

Lazyload images

The lazyload property loads an image only when it appears in the viewport of the user and not earlier. This practice prevents all the images from loading at once thus reducing the stress on your server and making the page load faster.

Specify image dimensions

When the browser displays an image on a page, it needs the exact dimensions to display the image correctly by reserving the space for the image based on its height and width attributes.

If the image dimensions are missing, there will be unexpected movements on the screen as the browser tries to fit the image in the available space. This results in unexpected layout shifts, also known as Cumulative Layout Shift (CLS), a CWV metric.

To keep the CLS under 0.1, you should specify the exact dimensions (width and height attributes) of all the images beforehand.

Serve images in WebP format

The default image formats that WordPress supports are PNG and JPG. While these are the most widely used image formats, they are not optimized for web browsing.

So, when images load in the PNG, JPG, or other formats, the PSI tool will display the following warning: “Serve images in next-gen formats”.

For this reason, Google has developed an image format called WebP which offers greater compression than PNG and JPG.

Hence, you should convert all your PNG and JPG images to WebP at the time of uploading.

There’s an excellent free plugin called EWWW Image Optimizer that takes care of all the four image optimization tasks on your WordPress website. It’s the plugin we use on PassionWP with very good results.

EWWW Image Optimizer does the following:

• Compresses images
• Lazyloads images
• Adds missing image dimensions
• Converts images to WebP format

I also need to mention here that the WP Rocket plugin also has image lazyload and add missing image dimensions features built-in. So, if you’re using WP Rocket for these two optimization tasks, you can turn off these features in the EWWW Optimizer plugin or vice-versa.

Optimizing your images will resolve the following PSI warnings:

• Properly size images (specifying the image dimensions)
• Defer offscreen images (enabling lazyload)
• Efficiently encode images (image compression)
• Serve images in next-gen formats (WebP)

Minimize the Cumulative Layout Shift (CLS)

Up until now, we have focused on reducing the page load times to improve the Largest Contentful Paint and Total Blocking Time CWV metrics.

Now, I will show you how to reduce the CLS metric to 0.1 and under. The CLS web vital is directly linked to page stability i.e. how stable your page is when a user browses it. The higher the stability, the lower will be the layout shift and vice-versa.

Hopefully, you have already installed the EWWW plugin and turned on the Add Missing Dimensions setting to minimize unexpected layout shifts when users browse your website.

But this is not sufficient. An important cause of unexpected jerks in the page layout is your WordPress theme. A poorly coded theme or a theme that tries to accomplish too many things often results in a poor user experience.

Let me explain how.

Badly coded themes are not mobile responsive causing content overflow on mobile screens. They also result in warnings like “clickable elements are too close together”, or “text is too small to read”, etc.

In the PSI report, you can see the following warning: “Avoid large layout shifts”.

For this reason, you should only use a lightweight, mobile responsive theme that is regularly updated like GeneratePress which delivers fast performance with the lowest CLS.

We are using GeneratePress on PassionWP and our CLS has never gone past 0.1. You can also read my GeneratePress review to check out its performance metrics.

Another source of high CLS are slider plugins.

When a mobile user visits your site, the shifting slides often cause sudden jerks to the page layout. Thich distracts the user from reading or watching your content resulting in a poor on-page experience.

For this reason, you should sidestep the slider plugins that are known to increase the CLS or, better still, completely avoid the use of slider widgets.

Fortunately, improving your CLS score is quite easy. Once you follow these best practices, your CLS will quickly fall in line.

Avoid using resource hungry plugins

The WordPress plugin repository is full of useful plugins for every imaginable requirement. However, we frequently install plugins on impulse without doing a background check on their size, memory consumption, updates, etc.

Installing too many resource-intensive plugins can undermine your website performance and Core Web Vitals.

How? You may ask.

Plugins function by making requests to the server. These HTTP requests can be JavaScript or CSS files or HTML (block) elements.

The higher the number of requests, the longer it will take for a page to load completely, resulting in slower page speed and CWV metrics like FCP, LCP, and TBT.

Recommended: 15 Essential Plugins for WordPress

Hence, it is not only important to keep the plugin count low, but equally important to only use plugins that do not degrade your website performance.

There are two simple ways to whet the plugins before installing.

1. Use the Query Monitor plugin: The Query Monitor plugin lists the size of all the requests being executed by a plugin and the memory utilization of that plugin. Based on this, you can remove or replace the memory intensive plugins on your site.
2. Use the WP Hive Chrome extension: This extension provides a useful report for every plugin on the WordPres.org repository listing different attributes like impact on memory resources, size, whether frequently updated or not, PHP compatibility, etc. This will help you make a informed decision before installing a plugin.

Remember, it’s not the number of plugins on your site rather it’s the number of slow or resource-intensive plugins that is more important here.

Optimize the web fonts

The PSI report also displays warnings for unoptimized font files. You might see the following warnings in your report: “All text remains visible during webfont loads”.

What this warning implies is that when you use certain external fonts like Google fonts that are fetched from an external site, the text on the page could be invisible to the user until the file is fetched and rendered on screen.

Don’t Miss: How to Add Google Fonsts Locally to WordPress

This expectedly will cause a poor user experience that you should avoid.

One easy way to fix this error is by using the font-display: swap; CSS feature that loads the system fonts on the user’s device until the Google font or other 3^rd party font file is loaded. This way there is no invisible text to worry about and it also takes care of FCP and LCP issues arising out of delayed font rendering.

If your theme is already using the system fonts by default or one of the web-safe fonts, then you won’t receive this PSI warning.

Font preloading

I have already explained preloading earlier. It’s recommended to preload external font files like Google fonts that you have added locally.

Preloading loads the font files before they are requested on a page to minimize the Total Blocking Time. But before preloading fonts, I would advise you to first add the Google font locally to your WordPress installation.

After this, you can simply use a cache plugin like WP Rocket that allows you to preload font files hosted locally. Check out my WP Rocket settings tutorial on how to preload locally hosted font files.

Other important warnings

By now, you have taken care of the majority of the tasks required to beef up your WordPress Core Web Vitals performance.

But there are a few other warnings highlighted by Page Speed Insights that can result in a poor CWV score. Let’s go through them now.

Avoid an excessive DOM size

DOM stands for Document Object Model. Simply put, it is the sum total of all the HTML elements on a page.

The more the number of HTML elements like blocks, images, headings, JavaScript, and CSS files, the higher will be the DOM size and the longer it will take to render the web page.

Lighthouse highlights pages when it detects that the total number of DOM nodes exceeds 800 and issues a warning when the DOM size exceeds 1500 nodes or elements.

Ideally, you should try to keep the DOM size to under 800 elements.

This can be achieved by minimizing the number of images, and other HTML tags added by page builders. Page builders are notorious for adding HTML tags for every text, image, or style element on the page.

If you must use a page builder, I suggest that you go with GenerateBlocks which when paired with the GeneratePress theme, offers great page-building features without hindering the website performance.

Keep the request count low

Lighthouse also issues a red alert when it finds that the total page size exceeds 300 KB and also the page makes numerous HTTP requests. The higher the number of requests, the higher will be the time required for the server to process all the requests. This will adversely impact your FCP and LCP scores.

An easy way to determine your page size is by running the URL through GTmerix. Under the Waterfall tab, you can see every request made on the page, the total number of requests, and the total page size.

Take a look at the PassionWP homepage Waterfall report on GTmetrix. It makes only 15 requests and the total page size is just 121 KB, which is well under the limit of 300 KB set in Lighthouse.

There are a few tips that you can follow to keep your page size small and requests count low:

1. Avoid the use of large-sized images and always compress your images.
2. Enable Gzip compression using a cache plugin.
3. Optimize your JavaScript and CSS files using the steps outlined earlier.

Avoid chaining critical requests

This warning pops up when the page makes additional requests for JavaScript, CSS, or font files that are critical for page load and without which the page load will not be complete.

The easiest way to minimize the number of network chains is to eliminate the external file dependencies. This can be achieved in the following ways:

1. Host scripts like Google Analytics locally using a plugin like Perfmatters
2. Avoid using scripts and files that are hosted on external sites
3. Host your Google fonts locally to reduce the latency

The FCP, LCP, and TBT metrics are directly impacted by this CWV error.

Wrapping Up

First, there was AMP, now it’s Core Web Vitals and we have no choice but to go along. Ranking higher on Google is all about user experience nowadays and the best way to measure the user experience on your WordPress website is through the Core Web Vitals metrics.

We have covered almost all the factors affecting the CWV for a WordPress website and discussed ways on how to resolve the CWV warnings in the Lighthouse report of the Page Speed Insights tool.

Hopefully, this Core Web Vitals guide for WordPress has helped boost your CWV score and your overall site speed. If you have specific queries or feedback to share, please use the comment form below. Thanks for reading.