Fixing Longest Contentful Paint (LCP) in WordPress

One of the many issues that I have with a couple of my blogs is how Google is detecting a high LCP, Longest Contentful Paint. This means Google thinks it’s taking more than 4 seconds to load the largest element on the page. How can I fix this?

Search Console is detecting the issue and PageSpeed Insights shows a high load time, but neither of them is very intuitive to figure out the answer.

PageSpeed says it’s an image that is less than 64kb in size. How does it take that long to load a 64kb WEBP image? Something else has got to be triggering the LCP response.

In any case, let’s see if we can figure out the LCP problem and clear some of these issues with Google.

Selecting the Test Page

For this experiment, I’m going to use one of my blog posts that is currently not indexed by Google. That is a bit of a shame considering I believe I wrote an amazing piece on the topic.

At any rate, I’m aiming at improving: https://writersanctuary.com/skyscraper-technique-blogging/

Before Changes

I would like to point out that during our own tests on various mobile devices that have never accessed this site before, the time to interactive is under 5 seconds. I don’t know why Google thinks it takes longer.

Never trust an algorithm.

Reducing Initial Server Response Time

Initial Server Response Time is the common culprit between both mobile and desktop versions of the site. While the desktop LCP isn’t nearly as high, it’s still too high according to Google.

Because I have a slew of things on this particular blog, it’s going to be a bit of a pain to cut back on things that I may want to keep on the site.

Disabled Buy Me a Coffee Popup Widget

I added the Buy Me a Coffe popup widget in the hopes to generate some revenue. It seemed when I had it live last time, I actually made a few tips from visitors.

I removed it again as it does hit the site speed a bit harder than I’d like. Plus, I don’t like the way it appears on mobile devices anyway.

Removing Autoptimize from Render Blocking

Another issue that I’ve had for a while is how Autoptimize has been render-blocking for CSS. After setting Autoptimize to defer JS and defer inline JS, as well as changing the setting to Inline All CSS, Autoptimize was no longer render-blocking.

This, by itself, made a big improvement in PageSpeed Insights in terms of registering JavaScript.

Using WP Meteor

I just spent about five hours reading through a barrage of blogs and tutorials to not much avail. However, I did decide to look up deferring JavaScript and whether it can be done with Autoptimize.

Unfortunately, Autoptimize no longer has that function built-in. So, I decided to give WP Meteor a try. It’s a very basic plugin with just one setting: how long before JavaScript launches.

I set WP Meteor to: “Delay until first interaction.” Afterward, I ran another speed test.

Deferred JavaScript Test

I’ve even run the test several times throughout the day to ensure the numbers are accurate.

Using WP Meteor has made the biggest improvement to the blog since installing Autoptimize to deal with Cumulative Layout Shift. I am quite blown away by the current score, to be honest.

I decided to test one of the site’s other pages in GTMetrix just to get a second opinion of the performance score…

GTMetrix Score

There is a bit of an odd duck in the results, though. After viewing the website from my phone, it seems to hide the images and other elements until I start to scroll through the site.

So, it looks great according to online speed tests but is a bit wonky in reality. I’ll have to dig a bit more to see if there is a way to find a happy medium.

No to mention that I was trying to reduce the overall LCP and seemed to have made it worse by 0.2 seconds. The speed index is AMAZING though.

Published by Michael