How To Improve, Fix & Optimize For LCP Issues In WordPress

0:00What LCP Is And What Counts As Good

WP Speed Fix here, back with another video. In this video we're going to talk about LCP, Largest Contentful Paint: how to improve it, how to fix it, how to optimize it, how to reduce the LCP time. This is a Core Web Vitals metric. In this video we're going to talk specifically about WordPress, but the principles here apply to any website. Most of the stuff you read online is not great around LCP, and a lot of it misses some key things, which we'll get to. So let's get started.

What is LCP? Largest Contentful Paint is basically the time at which the largest piece of content on a page has loaded. The best way to think of it is as the metric for load time. It's when the visitor perceives the page as having been loaded, or the load having finished. It's important because it's one of the three Core Web Vitals metrics from Google, and it is essentially the speed of the page. When we're talking about loading speed on the modern web today, this is the metric you should be looking at. This is essentially the load speed, and it's the most important metric for speed.

Now, what is good? You'll see here I've got this page up from Google. Good is an LCP time of under 2.5 seconds. Anything that is 2.5 seconds to 4 seconds, Google would class as needs improvement, and over 4 seconds is poor or slow. In terms of Core Web Vitals metrics, a passing grade for a website or a page is where over 75% of the visits got an LCP time of under 2.5 seconds. Core Web Vitals data is also an average. It's a 28 day average, and depending on what tool you're using, it might use the last 28 days or it might use the last month. Just be careful when you're looking at this data that you are aware that if you're making changes, it won't necessarily appear in whatever tool you're looking at straight away.

2:00Lab Data Versus Field Data

It's also important to remember there are two different data sets. We've done a video on this: the difference between running a PageSpeed Insights or Lighthouse test and the Core Web Vitals data itself. One of them is a test that is trying to equate reality, or trying to match what's happening in the real world. That's lab data, so that's a test like Pingdom or GTmetrix or Google PageSpeed Insights. That's not the real world speed. It's trying to give you the real world speed, but it's not what is happening with real users on the website. The Core Web Vitals data is what's called field data, or real user measurement data, and that's the actual speed users are getting. Regardless of whether your PageSpeed score is 100 or whatever, if you're not passing Core Web Vitals, you have a problem. That's the real speed that Google is collecting from Chrome-based browsers visiting your website. There are a lot of browsers based on Chrome, for example Microsoft Edge, so it's probably the best measurement we have of how fast your website is.

It's also important to note that the PageSpeed test can be cheated. You'll see a lot of companies out there guaranteeing you a 100 score in PageSpeed Insights, and that's not great. What they're effectively doing is pausing a lot of the stuff on the page, particularly the JavaScript, and not running it until the user interacts with the site. The problem there is that when Google runs that test, it's only loading half the page or even a quarter of the page. It's not the real page. While it makes the site look good in a test and you check that box and get a 100 score, you'll probably still fail Core Web Vitals, and it may actually make the speed worse in the real world for real users. So what we care about is Core Web Vitals data, and that's field data. Where you see it around the web, it'll be noted as field data.

There are two Core Web Vitals data sets as well, just to be more confusing. You have origin data, which is the entire website, and then you have individual page level data, but the page needs to have enough traffic to have data just for the page alone. Keep that in mind if you're a small business website. It may just be the homepage that has enough traffic for its own set of metrics, or maybe the whole site doesn't have enough traffic on an individual page, so you have to use the origin data. So there is sitewide data, a collection of the entire site, which is origin data, and then you have individual URL data if you have enough traffic. Just remember that. If you're running a PageSpeed Insights test, you'll see that if there is enough traffic on a particular page it'll have this URL, or it'll have origin as a toggle. So remember origin versus individual URL. I'll just write a note here, and I'll put these notes in the video description.

Also, you need 50 to 100 visits per day on average. If you don't have that many visits, there won't be enough data to create a data set. If you're under that threshold, then you might not have Core Web Vitals data. It's not an exact number, because not all browsers are Chrome. For example Safari, or someone on an iPhone: the data won't be collected from them. So it's not an exact figure either, and that's why I gave you a range of 50 to 100 visits a day. Generally that's what we see. We've optimized thousands of sites now and that's what we see in our work.

5:09How To Measure LCP With Core Web Vitals Reports

Okay, so that's all about LCP and what it is. Let's talk about how to measure it, or how to get the data. I've got two options here. On our website we have a tool that will give you the Core Web Vitals data, and I'll link you up to it. It takes 10 seconds to run and there's no opt-in required. So here it is, this is the Core Web Vitals report page. Again, like I said, you need to have that 50 to 100 visits a day threshold for data to be here. I've just got a URL in here that I know has bad data. This site is slow, so we're going to use it as our example. We just generate the report and it will take, yeah, there you go, it's less than 5 seconds. There's no opt-in, so you can use it as much as you want.

What you'll see here is that we have mobile, desktop, and all devices, so there's another way we can slice and dice the data, by device type. By default we've got this as all devices, and you'll see there's a note at the top: FCP and time to first byte are poor, in the red zone. FCP, this means users are going to see a blank screen for too long. FCP is First Contentful Paint, that's when the site starts loading, and then we have a time to first byte issue. These two are related. That's one quick way to see the speed, and if you scroll down you get the historical graphs here. There's about 6 months of data it's pulling in. You can see that the LCP is in and out of the poor zone. Back in October, November, it went into the poor zone, so it was bad, then it was nearly down into the good zone at 3 seconds, and then it's going back up again. So definitely some work to do. The site is generally in the needs improvement zone here for LCP, and that's not great.

You see here the three colors with Core Web Vitals: red, yellow or orange, and green. LCP needs work, time to first byte is poor, and FCP is poor. That's a really quick report you can do, and it's very easy to see what's going on here. You've got markers to tell you where it's in the poor zone or good. There is another report from Google which is similar, CrUX Vis, but it's much more technical. I've run the same report here and I've just gone to loading performance, and you can see again it's got the same six months of data and it's up and down very similar. Because they're pulling from the same data set, they'll be essentially identical. So there are two reports there. Just remember that PageSpeed Insights is not necessarily a great test here, because it's not giving you the detail you need, and I'll show you why now.

7:46Time To First Byte Is Often The Real LCP Problem

A poor time to first byte is more often than not the problem, or the root cause, that is causing LCP issues. If you look closely here, LCP is bad and time to first byte is bad. If you look at these two graphs, here's the LCP graph, and you can see the peaks and troughs follow the time to first byte. The actual root cause of the LCP issues in this case is time to first byte issues, and you can see it more clearly in CrUX Vis, which is a much more technical report. It's got a lot of stuff you can dig into. You can see here the LCP and the time to first byte graphs are near identical in the ups and downs, the peaks and troughs. That means there's some sort of caching issue. A large proportion of users are hitting pages that are not cached, or they're slow from the server itself. The server is slow to push them out.

There is more detail you can get in the CrUX Vis report. When Google collects this data, it grabs a whole bunch of information. You can see the LCP time here in the subparts, broken down into what is making up that number. You can see this is the time to first byte. The LCP is, whatever it is, 4 seconds, and time to first byte is 3.2 of those seconds. The resource load delay is 410 milliseconds, the resource load duration is 222 milliseconds and the render delay is 184 milliseconds. So the problem that needs to be fixed here is time to first byte. It's really important when you're diagnosing and fixing LCP issues to first check whether time to first byte is the issue or not, and this is the way to do it.

Either use our tool and have a look at those reports. This one, as you saw, took 3 seconds to load. Look at the graphs and see if they're similar in terms of the peaks and troughs. If so, it's most likely a time to first byte issue. Then you can dig in here to CrUX Vis and look at this LCP subparts section, and that'll tell you what component of that 4 seconds or 3 seconds is time to first byte. In this case that's what the problem is. I hope that makes sense. It's a bit difficult to explain. If it is a time to first byte issue, you need to go and fix that first. The root cause of the problem is not an LCP related issue, it's time to first byte. Until you fix that time to first byte, anything you do from the rest of this video is a waste of time. I hope that makes sense.

10:27Fixes When Time To First Byte Is Fine: Hosting And Caching

Let's talk about some fixes if it is not a time to first byte issue. Quite commonly it's bad hosting: no HTTP/2 protocol support, which is one we see quite often, no HTTP/3 support, or the hosting is just slow. Probably the most common one is no HTTP/2 support, where the hosting just doesn't support this protocol. The difference between version 2 and version 1.1 is that in version 1.1, for every file the browser has to download, say there are 100 files on a page, the browser has to make 100 connections to the hosting. It downloads each file over a new connection. With HTTP/2 it makes one connection and downloads all the files over that, so all that overhead from connecting over the network is gone. Generally, the download speed of a web page off a provider or web host that supports HTTP/2 versus HTTP/1.1 will be anywhere from 50 to 100% faster with that HTTP/2 protocol. It's a really easy optimization and every host should support it.

Usually when we see setups where it's not supported, it's either just poor quality hosting or a bad host. There's something wrong with the server on the host and it just needs some configuration or some fixing, or somebody's built a custom VPS and hasn't built it very well and this protocol support isn't in place. The simple thing to do is go and check for that support. There are plenty of HTTP/2 checkers around the web, so that's an easy way to check that one. HTTP/3 is even faster again, but it's not faster by that much. It'll speed up the time to first byte, it probably has a bigger impact on the time to first byte, but it is another 10 or 20% speed boost on top of HTTP/2. It's not going to be a make or break deal, but it's a free optimization and all hosts should really support it by now as well. So get those two protocols in place. There are checkers around the web, and I'll put some links in here to some checkers so you can use those and make sure your hosting supports them.

I'd also make a point here, and I'll put HSTS enabled as well. This is another optimization that will speed up connectivity to the website, and it's kind of important for time to first byte. While you're checking protocols, it's sort of a protocol, or it's a flag on the SSL that it should be enabled as well. In terms of bad hosting, we'd probably classify bad hosting as any web host that costs about the same as a cup of coffee. You're paying $2, $5, $8 a month, expensive Starbucks coffee. If you're paying under $10 a month for hosting, it's probably not great quality. The price difference between a good host and a bad host isn't that much. It's really the difference between a cup of coffee and a nice lunch. It's 5 or 10 bucks a month versus maybe 30 to 50 bucks a month at the small business level. That's what we're talking about here, not bigger businesses or bigger sites. But if you're paying less than 10 bucks a month, you're probably not on great hosting. There's a reason why it's cheap, so it's probably worth checking that. A lot of hosts are like low-cost airlines. Bluehost, HostGator, GoDaddy, they're all like low-cost airlines. They're cheap for a reason, so just keep that in mind.

All right, let's continue. You've got no caching or no optimization in place. If you had no caching, the time to first byte would be poor and you'd circle back around to the top there. But without an optimization plugin, even if your host has caching, if you're on a Kinsta or WP Engine, you're going to have speed issues. The two caching plugins we recommend are WP Rocket or FlyingPress. We have videos on both of those settings on our channel, WP Rocket settings and FlyingPress settings, and also a video just talking them through in more detail. WP Rocket is a bit more DIY friendly. It's a bit more of a safe, reliable plugin, and that's generally the plugin we use in our speed work because it's more reliable. We always talk about how reliability beats speed. We always want the site to be stable and reliable as opposed to going for the most aggressive optimizations.

FlyingPress is more technical. It's a little bit less reliable, or I wouldn't say unreliable or not reliable, it's more that it doesn't deal with complex sites as well. WP Rocket is a bigger plugin with a bigger customer base, so reliability is more their focus, whereas FlyingPress is more aggressive in terms of speed. Being the fastest is the focus of FlyingPress. So keep that in mind, one or the other. If you're more technical, go for FlyingPress. If you're really a DIYer, WP Rocket is the way to go. Those plugins do a lot of different optimizations, so they're not just caching plugins, they're speed optimization plugins. They do a lot of things on top of caching. If your host has caching already, like WP Engine or Kinsta, it'll help manage the caching better. So you really need to be using one of these plugins.

15:28Why You Need A CDN Like Cloudflare

Let's talk about no CDN. You need to use a content delivery network in 2026. This is kind of a no-brainer. Cloudflare is what we use and recommend, not just for speed but because of security as well. It has a whole bunch of security features that are important. You need a CDN, a content delivery network, and even the free plan on Cloudflare will do a lot. It does a few different things. A CDN removes the impact of geography on speed, so international traffic will have the site or pages loading from the server closest to them. Probably more important on the modern web, with a lot of AI crawlers and things like that, is that a lot of the workload gets moved off the hosting. With a CDN, you move a lot of the work of serving the files off onto the CDN servers, and that leaves the WordPress hosting free to do only the things it can do. You're getting more resources and beefing up the hosting stack by using a CDN. Again, even on the free plan, you'll get that.

With Cloudflare there are some manual custom Cloudflare rules that I'll link you up to. We add them to boost security and boost speed. Two things we do: we filter the login page, running it through the Cloudflare security filter, a kind of CAPTCHA, and that will reduce or eliminate brute force attacks on the site. Then, particularly for small business sites, we filter traffic outside the target countries. For example, we have a lot of Australian companies and a lot of Australian customers, so for a lot of sites there, any traffic outside Australia we run through the Cloudflare filter, which eliminates a lot of the junk and garbage. Same for North America: anything outside North America, we filter through and it gets rid of all the garbage, junk, crawlers and scrapers.

That traffic is often slow. You have some guy in India trying to crawl the site to send spam or whatever, and that traffic is going to be slow, which is going to drag down the Core Web Vitals metrics as well. There are a lot of different benefits to using a CDN there. It's a must-have on the modern web. Without that, if you have moderate traffic, you're probably not going to pass Core Web Vitals. Just keep that in mind.

17:48Page Weight, Lazy Loading And Preloading

What else do we have? Look at the page weights. We want page sizes to be under 3 megabytes, so let's just write there, under 3 megabytes ideally. Broadly speaking, pages that are over 3 megabytes will start to fail the LCP metric just because of the size. This obviously changes over time with internet connections getting faster, but it's still a physical limit. If the page is over 3 megabytes, it just takes time to download, particularly on slow connections. I'll run through some steps here that we're not going to elaborate on. You can Google these, there's tons of stuff around the web on them. Reducing the page weight means compressing the images and making sure the images aren't huge. This is still a common problem we see, where you have a big image above the fold that's 5 megabytes or something like that. If that is the case, the page will probably fail the LCP metric just because of the stuff to download above the fold. Above the fold is the bit on the website that appears when the page first loads. If that image or element is too big or too fat, then it's going to be slow. So compress those images, make sure the page is under 3 megabytes, and make sure whatever the LCP image is, it's as small as possible.

Use lazy loading, but avoid using lazy loading above the fold. Lazy loading is basically anything that's outside of the viewable area. Again, above the fold would be this section here that displays on the page. Anything I have to scroll to see is below the fold, and we want to lazy load anything below the fold, so it doesn't load until we scroll down to that part of the page. That will reduce the weight of the initial load of the page and get us under that 3 megabytes. We want to preload above the fold images and exclude them. This is two things: exclude the logo from lazy loading, and preload above the fold images. We use this plugin on WordPress, Perfmatters, on top of WP Rocket. This is our website here, WP Speed Fix, and we're using WP Rocket because, again, reliability is key for us and we've got a lot of complex things going on, particularly the lead forms on our website. But there are some features in Perfmatters that we like. One is this preloading. It will automatically preload the images at the top of the page. We've got it set to five, which is the maximum here, so it will preload the first five images on the page. It preloads them and gives them priority, so the browser loads those first. That's what preloading is.

You can also add manual preloads in here. We don't need it in this case because the automatic one works fine for us, but you might want to add the logo in there, or you might want to preload things on particular pages. If there's a particular page that's slow, you could preload the LCP element there, set the page ID, set the device type and mess around there. You can do it manually, but we've got this in automatic mode. It works fine for our site, but it might be different for you. Then for lazy loading, it will do it automatically. We've talked about this in another video: you have lots of different speed optimization techniques, and you can use more than one plugin, but you never want to duplicate the features. We're using WP Rocket and Perfmatters, and we're actually using the lazy loading features inside Perfmatters, and they're turned off in WP Rocket. In this case we've got image lazy loading on, and we have excluded the first five images on the page from lazy loading. We've also excluded some manual images here, which are related to the lead form at the top of the page.

The reason why we want to exclude lazy loading is that lazy loading will slow down the load for anything that's in the visible area, or above the fold, when the page loads. We want to avoid that for above the fold images or elements. We want to preload them and exclude them from lazy loading so they load as fast as possible. Those are two techniques combined there. We also want to lazy load videos. Videos are particularly heavy and slow, particularly YouTube embeds. We have a separate video for that, but we want to make sure they're lazy loaded as well. Other things that will help are deferring JavaScript and CSS optimization. These are probably secondary optimizations. They're probably not going to be the key to getting you over that LCP threshold. Maybe the JavaScript defer, because third party code like live chat and some analytics tools is very heavy, so optimizing those in particular may get you over that threshold. But usually these two are not the root cause of bad LCP issues or a poor LCP time. I've put them in there anyway.

22:05Just-In-Time Preloading And Speculative Loading

These next two will speed up the site once somebody's on it. We've got two things here. One is just-in-time preloading, which is an early version of something called speculative loading. I'll load up this website and show you, it's probably the easiest way to do it. We've got instant.page. This was an early just-in-time preloading script, and it has a good example here. There is a gap between when you hover over something on a page and when you click on it. If I hover over this button and click on it, you'll see there's a 1.1 second time delay from my hover to my click. In that time delay you can actually start background loading the page before I click on that link. That's what just-in-time preloading is.

That's this first one here. The guys who make the FlyingPress plugin have a separate plugin that does this, but it also does something else, where it automatically loads all the links on the page one by one. The just-in-time preloading is already built into FlyingPress and built into WP Rocket, but this extra feature, where it will background load all the pages without having to click on them or hover over them, will speed things up even further. Like I said, you can have an optimization tactic or technique enabled in one plugin, but you shouldn't have it enabled in another. We disabled those features in these two, and then we install this plugin and run it separately. I think we have it installed, let me see if I can find it here. Yes, Flying Pages. We have it installed here on our website. You can see we have a delay to start preloading of 3 seconds, then we load one page per second, and we have exclusions. These are the built-in exclusions, but it's excluded on these pages. That will basically load those pages in the background. It loads the HTML only, but it caches them at Cloudflare, and it speeds things up under the bonnet if I'm already on the site. That's one way to help that LCP time, and it largely fixes it by reducing the time to first byte to almost nothing.

The second one is speculative loading. This is a similar thing where background loading is happening, but instead of just loading the HTML file, it's loading the entire page. Images, CSS, JavaScript, everything is loaded. There are a couple of different ways to do this speculative loading. There's this plugin here from Automattic. It's free and built into WordPress. Once you've installed it and enabled it, there are some settings under Settings and Reading to control it. We have it running in prefetch mode and eager, so it's aggressive, and only for logged out visitors. Prerender is much more aggressive and we don't recommend using it. It will make the site faster, but it will break all your analytics and tracking. What prefetch does is load the files. What prerender does is load the files, build the page and fire all the JavaScript. You'll get an insanely big amount of page loads showing in analytics tools, and it'll mess up your ads tracking. So you don't want to use prerender unless you know what you're doing. Just use prefetch. Eager is good, but you need good hosting for it and you really need a CDN, because it's probably going to 5x the load on the hosting. Just keep that in mind. Those two will help dramatically, particularly if you have more traffic, but like I said, it'll put a lot more load on the hosting.

25:58What Doesn't Work For LCP

Stuff that doesn't work. Okay, let's talk about this. Minifying anything: don't minify anything. It's a waste of time. It's an optimization that does nothing. It breaks caching on the modern web. It is not worth doing. It'll introduce problems and cause reliability issues, so that's enough said there. We've talked about that in other videos. Combining CSS or JavaScript is the same thing as minifying. It is an old optimization that on the modern web makes things slower, so don't do it.

Pausing or delaying JavaScript aggressively: be careful with this. Like I said at the top of the video, you can make the site get a 100 score in PageSpeed Insights almost immediately by delaying all the JavaScript on the site and not loading it until the user moves the mouse or interacts with the site. That will likely break things. It'll break things in ways you don't immediately see, like menus on mobile, which is a very common one, but it'll actually make the site slower in the Core Web Vitals field data in the real world. The reason for that is that once the user gets to the site and moves the mouse, all the JavaScript and everything has to download and fire and do stuff. So it's actually delaying some of the work the browser is doing when it loads the page. There is a case for this, where you want to pause or delay some JavaScript. Like I said before, live chat code is very heavy, and that's one type of JavaScript that I would say is worth delaying. But just be mindful with this one. You'll see in all plugins now, FlyingPress and WP Rocket, they have options to do this. Use the safest possible option, exclude most of the stuff, and only have delay JavaScript on things that you know are not going to break your site or marketing if they're delayed. Another error here is delaying things like Facebook pixels or Google Ads pixels. It'll break the ad tracking if you're doing that, because a lot of the bad quality traffic isn't interacting with the site, so the pixel doesn't track that properly. Just be careful with that.

The last one is any scenario where the time to first byte is the root cause of the issue. Again, it is critical to check the subparts of the LCP to make sure it's not a time to first byte issue, because more often than not, with the sites we see (and we've seen thousands of sites), the LCP time is bad because the time to first byte is bad. The issue lies with the time to first byte, not with the LCP itself.

28:23Tracking LCP And Getting Help

All right, this video is 30 minutes long, so it went a bit over what I expected. If you want better tracking, our Vital Signs Tracker tool would be the way to go. If you really want to track this metric, or if you're running paid traffic, head to vitalsignstracker.com and you can see all about that. If you need help with your site, if you want to pay us to help you, you can claim a free audit on our website. Go to wpspeedfix.com and claim your free site audit. Click that button and you'll see there's a short form to fill out, and one of the team will have a look at your site and tell you how we can help.

There are also some free tools under the free tools menu. These are all no opt-in required, they take 60 to 90 seconds to run, and you'll get detailed reports on various things. Like I said, if you go back to that Core Web Vitals report, it will give you a breakdown of the site speed and the historical site speed, and tell you what's going on in less than 5 seconds. If there's anything else, just put a note in the comments below and we'll be happy to come back to you. I hope you found this useful. Cheers.