How To Improve Your First Contentful Paint (FCP) In WordPress

0:00What FCP (First Contentful Paint) Means

WP Speed Fix. I'm back with a video to talk about FCP time: improving, fixing, reducing and optimizing FCP time, or FCP issues, in WordPress. FCP stands for First Contentful Paint. What this time represents is when the first piece of content on the page has loaded. So it's when the visitor perceives the site as starting to load.

It's important because it's all about user experience. It's not a Core Web Vitals metric. It's not one of the three Core Web Vitals metrics, but it is a web vital metric. So it's still a speed metric, and it's still important because it represents how users are experiencing the website, and their interpretation of how fast the website loads. We want this metric to be fast because we want the visitor to feel like the site is loading quickly, or that it's starting to load.

0:47What a Good FCP Time Is and Why You Need Traffic

So let's talk about what is a good FCP time. Google have a really good technical article about this, but basically with all the Core Web Vitals metrics, they're based on the top 75% of visitors to the site. A good FCP time is under 1.8 seconds. That's when the site appears to start loading, when the first piece of content appears within 1.8 seconds. In the scheme of things, in relation to Core Web Vitals metrics, Google wants to see 75% or more of your visitors have an FCP time of under 1.8 seconds. 1.8 seconds to 3 seconds means it needs improvement, and over 3 seconds is poor and slow. That's a user sitting there for 3 seconds or more waiting for something to appear on the screen, so that's poor.

It's important to remember that the Core Web Vitals data set needs traffic. It is the real speed that users are getting on the website, and it's data collected by Google from Google Chrome-based browsers. To have a Core Web Vitals data set for your website you need 50 to 100 visits a day. It's not an exact number, because those will not all be Chrome browsers, so I can't say 50 is the cutoff. You need roughly that much traffic to have a Core Web Vitals data set.

There are two scenarios. If you have a new website, or a new domain name, you're not going to have Core Web Vitals data. Or if you don't have enough traffic, you won't have Core Web Vitals data. If you don't have enough traffic, then while you want to check the box for speed optimization, you're probably better off spending time on other optimizations, unless there's a really specific speed issue you want to fix, like the back end of the site is slow, or particular things are slow, like search. If you don't have enough traffic, you're probably better off spending your time and energy on getting more traffic before tackling Core Web Vitals stuff.

3:08Measure First and Don't Trust PageSpeed Insights Scores

Before you do anything with Core Web Vitals, you always want to measure it. One of the biggest mistakes we see people make is going and doing a bunch of speed optimization and just randomly changing things, or finding a blog article online and changing things, and it doesn't make sense. You need to start with where the site is now and troubleshoot from there, so find the specific things you need to do to fix that metric.

We get a lot of inquiries at WP Speed Fix from people who want to do speed stuff, or they want speed optimization, and their site is actually fast. They're using the wrong tool to measure speed. They might be using Google PageSpeed Insights and not understanding what they're looking at, or the SEO guy told them their site was slow. It's important when you're looking at speed test tools to understand that Google PageSpeed Insights is what's called a lab test. It's trying to approximate what people are doing in the real world. It's not the real world speed. So you can have a 100 score in PageSpeed Insights, and the test can be cheated. That's how a lot of agencies that are guaranteeing you a 100 score in PageSpeed Insights are doing it. They're cheating the test. Cheating the test is bad because it breaks the website in other ways and will likely break your SEO.

You can have a high PageSpeed score and still be failing Core Web Vitals. You can have a low PageSpeed score and be passing Core Web Vitals fine. So don't use that as your test. Use the Core Web Vitals data set, because that's what matters.

4:16Reading the Core Web Vitals Report: Poor TTFB Drives Poor FCP

I've got two links for you here, two different types of reports. There's one at our website that is much more simple. There's no opt-in required, it takes 10 seconds to run. Stick the URL in there and it'll spit out this report. It'll give you the three Core Web Vitals metrics. On this site, the LCP time is poor. That's not good, it needs work, it's in the fail zone. The average of 75% of the users is 3.6 seconds. You can see here these other two metrics are bad too. You can see here time to first byte is bad, which means FCP time is bad too. In this case the FCP is actually very poor. It's in the poor zone. This report also shows you the historical site speed. For FCP we can see it's dipping in and out of the poor zone, but it's still not great.

When you look at these metrics, and we talked about this in the LCP video and the recommendations in this video will be very similar to that video, quite often bad FCP and bad LCP is actually related to the time to first byte not being good. The core issue, or the thing to fix, is the time to first byte. You can see here the graphs match near exactly. So the problem here with this site is the time to first byte is not great. You can see that the peaks and troughs match, and that's actually causing poor LCP time too. This site has a caching issue, or something wrong, where a lot of the pages are taking a long time to load for visitors. That's why these metrics are bad: because the time to first byte is bad.

This data is reported week to week, so there's a bit of a lagging indicator here. The time to first byte is bad and then the FCP is bad. This data is based on averages, so keep in mind if you make a change, this data might take 28 days to reflect that change, depending on what the change is, where you're looking at that data and what report. So those are the two reports there. Run those. You can run the free Core Web Vitals report at our website. Like I said, no opt-in required. It will update weekly, and it takes like 10 seconds to run.

6:32How To Fix FCP: Preload the Logo and Remove Lazy Loading

Like I said, poor time to first byte is often the issue. In this case for this site, the issue is actually time to first byte. If we want the FCP metric to be better, we want to fix the time to first byte first, so we would start there. We have a video on time to first byte, so if that's your issue, go and watch that before dealing with this video. If the time to first byte is good, then look at the FCP fixes below, or in this video, which are essentially the same as the ones in the LCP video. Let me talk through these. I did a bit more detail in the LCP video, the Largest Contentful Paint. FCP is the First Contentful Paint, so the start of the site render or start of the site load, and LCP is Largest Contentful Paint, so the end of the site load. That's the difference between the two.

The number one thing to do here, if the time to first byte is good, and let's assume it is, to speed this up or improve this metric is to preload the logo file, because the logo file is almost always the first piece of content on the page, and remove lazy loading from it so it's not lazy loading. We do this on WordPress using the plugin Perfmatters, and we talked about some of these features in the LCP video. In here under preloading, in Perfmatters on our website, we are preloading the logo. We are also setting the logo fetch priority to high. That basically tells the browser this is one of the most important files, so load that first.

You'll see here, we talked about this in the LCP video, we're preloading the critical images. Now, this might catch the logo anyway, but just to be safe, we just add it manually. Then lazy loading. Again, Perfmatters can exclude lazy loading for an X number of images on the page. We're just excluding it from the first five, which is the most you can choose. We've manually added the logo into the lazy loading exclusions here. That means the logo is given the opportunity to load as fast as it can.

An important thing to point out here: we are using multiple speed plugins. You'll see here we've got WP Rocket, Flying Pages, Flying Scripts and Cloudflare. I've pointed this out in several of the videos we have about Core Web Vitals optimizations that it's okay to have multiple speed plugins. It's not okay to duplicate the optimizations inside them across multiple plugins. You don't want to be doing the same thing in two different plugins. We're using Perfmatters for lazy loading specifically. There are a few other minor optimizations we're doing, but it has really good lazy loading, so that's why we use it for that instead of WP Rocket. I hope that makes sense. Broadly speaking, as a rule, do not duplicate optimizations. That goes for content delivery networks: don't use Cloudflare and RocketCDN, use one CDN. Don't use lazy loading in two plugins. Same as you don't use two SEO plugins. So don't duplicate the speed optimizations in multiple plugins or tools.

Okay, so that's preloading, and that is the number one thing to do. We have a separate video on that. It's an older video from before we started using Perfmatters, when we used Autoptimize. It's the similar thing where we're preloading the logo and disabling the lazy loading on it.

9:40Hosting Quality and HTTP/2 and HTTP/3 Support

I'll run through the rest of these. These are quick, and I'll go through them point by point, but again we dug into them in detail in the LCP video. Bad hosting is always going to be a problem. Bad hosting is slow. The way that I would frame bad hosting versus good hosting is that bad hosting is basically the price of a cup of coffee. It's like five bucks a month, maybe 10 bucks if it's an expensive Starbucks coffee. Good hosting is the price of maybe a nice lunch or dinner, 50 bucks or 100 bucks a month. That would be how you delineate between good hosting and bad hosting.

If your hosting costs a few bucks a month, it's probably cheap. It's like a low-cost airline. It'll do the job and it will get you there, but it'll be no frills and may not necessarily be the best or fast. When you're running a business on top of a website, you probably don't want the cheapest option.

You also need to make sure that your website, or hosting, sorry, supports the HTTP/2 and HTTP/3 protocols. They speed up how quickly the browser can download stuff from the website. There are three versions of this protocol: 1.1, 2 and 3. Most hosting should be supporting, or all hosting should be supporting, HTTP/3. We still see web hosts that are running version 1.1 of the protocol. There's a huge speed jump going from version 1.1 to version 2. The reason for that is with version 1.1, when you connect to the website, if there are 100 things to download, the web browser needs to make 100 connections. There's a lot of overhead to make those 100 connections. With the HTTP/2 protocol, it makes one connection and downloads everything over that one connection, so it's a lot faster.

Depending on how many images and how complex the layout of your site is, the speed difference could be 50 or 100% with version 1.1 versus version 2. HTTP/3 is another 10 to 20% faster on top of that, but it's not going to make or break things. But definitely if your hosting doesn't support HTTP/2, it is a problem and your site will be slow regardless of any other speed optimizations, simply because the browser has to do more work and there's more network overhead to download files from the hosting.

We talked about this as well: enabling HSTS. This will speed up the second visit that a user is making to a site, because it forces on security. It forces the browser to use those newer protocols. It also avoids redirects in some cases.

11:58Caching Plugin and Cloudflare CDN Choices

Next, a caching plugin or optimization plugin. These are the two plugins we use: WP Rocket or FlyingPress, so wprocketplugin.com or flyingpress.net. WP Rocket is more stable and reliable, but it is less aggressive in terms of the optimizations it does. FlyingPress is faster, but if you have a more complex site like a WooCommerce site, you need to be careful, because it can break things with some of its more aggressive optimizations. Just keep that in mind. We have a video comparing the two as well, and we have individual videos on the YouTube channel with the settings for each one and how we configure them.

Use a content delivery network. We use Cloudflare. That's probably the only game in town from a WordPress perspective. Cloudflare is the biggest CDN in the world. We also do a lot with security rules in there, particularly for WordPress. We can filter a lot of garbage traffic like brute force attacks, or crawlers and scrapers hitting things they shouldn't be. Cloudflare is really good at that. It also has a bunch of speed optimizations built in on top of its content delivery network stuff, and it does something called edge caching, where the entire page is cached on the Cloudflare layer. It moves a lot of workload off the hosting, and if you're serving a worldwide audience it brings the content closer to them. It effectively removes the impact of geography on site speed, for the most part. So use a CDN, use Cloudflare.

FlyingPress has a very tight integration with Cloudflare, and you can get the APO feature for free, basically. Otherwise you have to pay five bucks a month to Cloudflare for it. That's another reason to use FlyingPress.

13:57Page Weight, Logo Compression and Lazy Loading

Look at the page sizes, the page weights. Basically you want to be under 3 megabytes. Pages that are over 3 megabytes generally will start to fail Core Web Vitals just because of their size. From the perspective of the FCP time, the First Contentful Paint, make sure the logo file is compressed. We're using SVG, which is very small. If you have a JPEG or PNG file, compress it, but just be careful not to break the logo and make it look grainy or bad. Basically you want that file as small as possible.

Other things: you want to compress images generally across the site. You want to use lazy loading, so stuff below the fold doesn't load until the user scrolls down there. Above the fold is the viewable area when the page first loads. So this stuff here would be above the fold, and everything below, that you can't see, is below the fold. You want to lazy load below the fold and not lazy load above the fold. I hope that makes sense. That's why we use the Perfmatters plugin. So it's preload above the fold images. I should say fold, not folder. We talked about that in the Perfmatters plugin: include the logo.

Also lazy load videos. Videos, particularly YouTube videos, are very heavy. They're about 0.6 of a megabyte each. So you want to lazy load those as well. JavaScript and CSS optimizations are useful, but they're not going to help the FCP time much. I'd just say those are minor optimizations, and they're probably not going to move the needle from an FCP time perspective.

15:08Instant Preloading and Speculative Loading

These guys here will help once a user is on the site. Just-in-time preloading. Let me just show you. If you go to this website, instant.page, you'll see there's a demo. What just-in-time preloading does is this: there's a time gap between me hovering over something and clicking on it. You see I hovered there, there was a 4-second gap. That means the browser can actually load that entire page in that 4-second time gap without me seeing anything. When I actually click on that link, the browser has already loaded it. That will make the page load much faster. It reduces the time to first byte to almost nothing, which then improves the FCP time. So that's just-in-time preloading.

There is also a version of this where you can load all the links that are in or above the fold on the page, and it does a similar thing where it's background loading them. The plugin from the FlyingPress guys, called Flying Pages, does all that. It will add the just-in-time preloading and then it will also preload everything you can see in that viewable area.

Speculation rules, or speculative loading, is kind of a newer version of that. With just-in-time preloading it only loads the HTML file. With speculative loading it will load the entire next page. It will load all the files, all the images, everything, so that more of the page is downloaded and ready to go in the browser. It will speed things up even further. Keep in mind that if you use these two tools, it will do something like 3x to 5x the load on the hosting. You need to have good hosting to use them. If you don't, you're going to knock your hosting over, so keep that in mind. But they will make a big difference, particularly if you have a high-traffic site or if you have users logged into the website. So those are big optimizations.

17:04What Does Not Help FCP and Can Make Things Worse

Let's talk about a few things that don't do anything and actually can make things worse. Minifying anything. Don't waste your time with minifying. It doesn't do anything. It doesn't make things faster, and it potentially introduces issues with caching on the modern web. The main reason for that is that if you minify a file like a CSS file or a JavaScript file, the site, or WordPress, or the plugin, whatever you're using to minify, will rewrite the file name. So it's a different file name. That breaks caching, and it also ends up in a scenario where, when Google crawls the site, it might be trying to load old versions of the CSS and JavaScript, which then generates a whole bunch of 404 errors, which is not good. We want to avoid that.

The same thing with combining files. Combining CSS and JavaScript doesn't do anything for speed on the modern web, and it has the same issue where it makes new file names that change all the time, which then interferes with caching and then upsets the Google crawler and AI crawlers. So we just want to avoid that. It doesn't do anything for speed, and it can break stuff. It makes the site less reliable. We've talked about before in other videos that we never want to sacrifice reliability for speed, because reliability is more important. If the site loads slowly, that's better than the site just not loading at all. You always want to check the reliability box first, and you never want to sacrifice reliability for speed or a small gain in speed.

These two here, pausing and delaying JavaScript aggressively. This is an optimization, like I said before, that some agencies out there use to guarantee you a 100 score on PageSpeed Insights. They do that by basically not firing any of the JavaScript on your site until the user interacts with it. That makes the load time look good in the speed test but will break things in the real world. It may also break your SEO, because when a crawler comes along, it doesn't see the entire site. It's not loading the whole thing until the user moves a mouse or hits a key on the keyboard. So you want to avoid that. You don't want to do that aggressively.

There is a place to do that for optional scripts or third-party scripts that are not mission critical. That would be things like live chat tools, or analytics tools, or tracking tools that you're not too worried about if they don't fire immediately when the visitor hits the site. So there is a place for delaying or pausing JavaScript, but don't do it for the entire site. If anyone's guaranteeing you a 100 score in PageSpeed Insights, one, they're focused on the wrong thing, you should be focused on passing Core Web Vitals, and two, they're probably doing something to break the website, or they're probably delaying all the JavaScript so things don't load. So just keep that in mind. It won't make the FCP time better in the real world.

In any scenario where the time to first byte is the root cause of a poor FCP time, anything you do outside of improving that time to first byte is a waste of time. In many scenarios, like I've shown you with this site, the time to first byte is actually the problem to fix, not the FCP time. The poor FCP time is a symptom of the bad time to first byte.

So that's it. I'm going to try and keep this video short because we talked about this in the LCP video. If you need help with your site, you can run this report here over at our website. Just go to wpspeedfix.com and under the free tools menu you'll see free Core Web Vitals report. If you want help with your site, head to our homepage and fill out this form here. Tell us what you're looking to solve, what you want to do, give us some detail, and one of the team will review your site and come back to you within a day or so. We also have some other tools here: a free SEO audit, a free WordPress speed test, and also our mailing list. All of those are free to use. There's no opt-in required apart from the mailing list. So yeah, go check it out. If you have any questions, just post in the comments below. Happy to come back to you. I hope you found this video useful. Let me know how you go. Cheers.

0:00What Preload Does and Why It Helps FCP

Hey, it's Brendan from WP Speed Fix. Short video here. I'm going to explain two things. One, the preload command, or preload directive: how to use it and why to use it. Two, a simple way to hack the FCP timing, or First Contentful Paint timing, in relation to your site speed. The FCP time is the time at which something displays to the user, so they see something loading.

There's a very simple way that we can hack this or speed it up. It's not even hacking it, it's genuinely speeding it up, using this preload directive. You'll see on my screen I've got WordPress open, I've got the Autoptimize plugin open, and I've got the Extra tab here. On the Extra tab there's this field, "Preload specific requests".

0:45Preloading Your Logo to Drop FCP Time

The preload directive is a piece of HTML that sits in the head code of the website, and basically it rearranges the order in which files load. We can use this command to override the default loading sequence, so we can tell the browser to load a file earlier than it would. One way we can use this is to improve the FCP timing. We can tell the browser to load the logo earlier. On 99% of sites the logo is the first thing on the page, or it's at the top of the page, but in the code it's not necessarily the first file the browser loads.

In this case, on this website, I've added the logo as a preload. That means the browser will probably load it as the first file after the HTML, which makes the logo appear faster and drops the FCP time. Typically when we do this it drops the FCP time down to 0.6 to 0.9 of a second.

1:33Excluding the Logo From Lazy Loading

There are actually two parts to doing this. One is to add the logo in there to the preload, save that and clear the cache. The other is to exclude the logo file from any lazy loading you have. We typically use the WP Rocket caching plugin and the lazy loading function there, so we have to exclude that logo file from the lazy load.

The reason is that if we don't, the plugin will actually lazy load the logo, so the logo will load slower because it has to wait for the lazy load JavaScript file to process. If we disable lazy loading on it, the logo will appear almost instantly. So that's a way to hack that FCP timing.

2:18Other Uses: Fonts and Slow Third-Party Files

Another way to use it is to preload fonts. You'll see here I've got a few font files in here. I've added them to speed those up, because they're coming off Google Fonts, so they're a bit slower. So that's another way to use it, to load fonts earlier. Another way might be if you have a third-party file that's loading really, really slow and blowing out the overall load time. You can add a preload in here and speed that up as well. It's not always the case, but it can be useful for that too.

2:55WebP Gotcha and What Result to Expect

That's pretty much it. If you do that, add the logo file in and disable lazy loading on the logo file. Just be aware, if you're using a tool like ShortPixel to inject WebP files, you probably want to get rid of or delete the WebP file for the logo. Otherwise you're going to have to preload both the WebP and the original PNG or JPEG.

If you do that, usually you'll see the FCP time drop to 0.6 to 0.9 of a second and you'll get a green score, or check, or I think it's a dot in Google PageSpeed Insights. You'll also see, in the Chrome User Experience Report, the FCP time fall into the green range for a large proportion of the users.

I hope you found that useful. I hope that all made sense. It's a little bit technical, so it can be difficult to explain in a short video like this, but if you get stuck just post it in the comments and I'll come back and clarify.