In this experiment, I’m going to see what I can do to shave off some time on the LCP for WriterSanctuary. Right now, the core web vitals are pretty bad. And I don’t want to lose momentum in search results.

Fixing LCP Issues

Finding the LCP and Testing

First off, we’ll start with a test in PageSpeed Insights.

As you can see, it’s not all that stellar of a score. And the CLS is triggering yet again. I’m half tempted to remove everything from the site and start over from scratch.

Well, except for the content. Deleting the entire thing would just be stupid at this point.

LCP, or Longest Contentful Paint, is essentially the load time of the largest element on the website. This is usually the hero, header, or featured image above the fold.

In this case, it’s the large image that starts the article.

In this instance, it’s a 164kb JPG. It’s funny how mobile devices can choke on such a small file. Well, according to Google.

Adding EWWW Image Optimizer

The EWWW Image Optimizer plugin was able to shave off a bit of load time on this blog. And it supports WebP…which is something Google loves. Especially since it’s their technology.

At any rate, let’s see what installing the plugin does and upload a new image for the header of the article.

In this case, I create an entirely new header image as I want EWWW to convert it upon upload. That is part of the plugins features.

In this case, I was able to shave off a bit of file size as I saved it as a high-quality JPG and not the Maximum. Essentially, I saved it as an “8” if you’re using Photoshop.

The new image rests at around 139KB, and is of a larger (suggested for the theme) size. This new one is smaller thanks to dropping the JPG quality from maximum to high.

And there really isn’t much of a difference in quality between the two. Outside of saving 30kb, anyway.

Side Note: I may want to try EWWW’s Lazy Loading as it supports CSS background images and auto-scaling. I’m not sure if Jetpack does these things.

WebP Deliver Across Cloudflare

Since I use Cloudflare CDN for, I am advised to either use: JS WebP Rewriting or <picture> WebP Rewriting. At the moment, I’m not sure which is going to be the better option.

So, I suppose I’ll give JS WebP Rewriting a try and see what happens in the next text.

Uploading the New Header

With EWWW installed and ready to go, I’m going to upload the new header image. It should optimize and convert upon upload. So, I’ll check the size afterward to see how much was shaved off.

I’ve deleted the cache in Autoptomize and I’m going to give it a bit of time before running the next test in PageSpeed Insights.

According to EWWW, the original image was reduced by 8.6%. Though, I’m not really sure if that’s anything to write home about. It’s only a reduction of 10KB.

However, the WebP version is only 53.9kb…which is considerably smaller than the upload.

But in the grand scheme of things, I went from a file nearly 170kb in size to one that is almost 123kb during this experiment. No matter what, I saved 47kb of loading time.

Hey, when it comes to Google, every millisecond counts.

Retesting in PageSpeed Insights

Moment of truth. I cleared the cache and gave the system about 15 minutes or so. Let’s run the speed test to see what happens.

So…we gain a single point in speed, but the LCP is still the same. Even though we’re running WebP from a smaller file size than before.

According to the Lab Data, though, we did shave off half of a second and reduced the blocking time by 50ms.

Setting Lazy Load for EWWW

I’ve decided to give EWWW’s lazy load feature a try. Currently, I’m using Jetpack’s built-in ability (formerly Photon). But, if EWWW can add all those bells and whistles it claims, maybe it’ll make a difference.

Retesting Again

To make sure EWWW’s lazy load feature is worthwhile, I’m testing the site yet again. I want to make sure it’s not going to inadvertently break something.

I’ve seen it happen before.

So, we were able to shave off another 0.6 seconds from the LCP in the Lab. And, the cumulative shift got a bit better…like 0.001 points. Eh, I’ll take it.

Oddly enough, the element is still showing it’s being pulled from Jetpack’s Photon servers. I wonder if I should try removing Jetpack optimization altogether.

Removing Jetpack’s Optimization

I disabled Jetpack’s Site Accelerator options and refreshed the cache. Though, enabling it in the first place is what boosted my score by 10 points a few months ago.

However, I’ve added quite a few optimization tools since then. I wonder if there are conflicts happening. At any rate, I’m going to test the site yet again.

Seriously, Jetpack?

So, I ran the test a few times to be sure. But, since removing Site Accelerator, the website is no longer serving the WebP version of the images. But, isn’t that what EWWW is supposed to do?

In fact, the speed is back up to 6.6 seconds.

Re-enabled Site Accelerator for Now

I re-enabled the Site Accelerator module in Jetpack to see if I can get back a bit of the progress I made today. And the images for WebP came back.

So, is EWWW dependent on Site Accelerator to show WebP? Or, maybe that’s why some suggest using Cache Enabler in conjunction with EWWW. This would make sense if Site Accelerator is acting as a mediator.

But, that doesn’t explain how this website works just find without Jetpack installed while EWWW is serving WebP. And this website has no other optimization in place, save for AMP and Autoptomize.

In fact, this site is using the native WordPress lazy loading in the newest version.

So, why does Jetpack control so much of what EWWW is supposed to do correctly? Instead of answering questions, it looks like I just added more.

Preload Largest Contentful Paint Image

One thing that has been popping up in PageSpeed Insights is how I should “preload” the image. This is something that doesn’t show up on any of my other websites.

So, why is PageSpeed suggesting it on WriterSanctuary, but none of the others? Especially since this blog as WriterSanctuary are using the same theme and some of the same plugins.

What is the difference between ICC and WS?

  • Lazy Loading
    ICC is using native WP lazy load
    WS is now using EWWW, was using Jetpack – Preload shows up when using either one.
    CrossingColorado is using Autoptomize for lazy load – no preload messages during test.

From what I can tell, this Preload message appears when the header image is set to lazy load in code. If that’s true, then why doesn’t it do the same thing to the other websites?

There is a work around by adding a code snippet to the header, which means I’ll have to install yet another plugin to add code or go in and do it myself.

Either way, it’s a pain in the ass.

Adding Cache Enabler

Before I call it a day, because I do have other things I need to do today, I’m going to install Cache Enabler and see if it solves the issue with Jetpack.

I enabled all Clearing and Variants options in Cache Enabler. And, it does work with Autoptomize. Once I saved the settings, it did, indeed, cleared the cache.

I am now running a test to see what happens, and…no change. I still don’t understand why it’s taking 6.4 seconds to load an image that is only 53kb in size!

OK, so I am removing Jetpack from the equation again. Cache Enabler should pick up where Site Accelerator left off.

So, removing Site Accelerator gets rid of the Preload request, but then doesn’t pull up the WebP images and gives the error to Reduce the impact of third-party code. (Which it did last time I removed Site Accelerator.)

I wonder if it has something with uploading the image before I disabled Site Accelerator.

Adding a New Header Image

I’m going to try one last thing before I move on today. I’m going to create a new hero image and upload it to the post. This will trigger EWWW to create a new WebP version, and Cache Enabler should store it.

But this time, I’ll actually visit the site to see if it needs a visitation before caching. One plugin I was messing around with yesterday needed a visitor.

Cross our fingers, let’s test the site again…though, that is pretty cool that Cache Enabler clears Autoptomize automatically. After I uploaded that image, the cache was emptied.

Well, the error for third-party code is gone, but it still isn’t pulling the WebP versions of images.

I’m running out of ideas, and no one seems to know why Jetpack has so much control over WebP. I guess I’ll have to keep looking.

Duplicating This Blog’s Settings

So, I am going to try one more thing before I call it a day. That is to use the same settings on this website for WriterSanctuary. Since this means I’ll probably break WriterSanctuary, I am going to backup and copy all settings I change in this post.

  • Disable “Also aggregate inline CSS?” in Autoptomize.
  • Disable Async JavaScript plugin.
  • Disable Cache Enabler (bummer)

Those are the only differences between ICC and WS. Ok, so, now let’s test it one last time and see if WebP is being delivered.

I just checked by inspecting the page with Chrome, and yes, WebP images are now being pulled on WriterSanctuary. Now for the speed test.

This is maddening! PageSpeed Insights is still saying the images are JPGs. I just verified they’re not!

For this go around, I am going to purge the page from Cloudflare and force it to grab a new version of the site. This is kind of stupid considering that I am accessing the page from home and showing WebP images.

I just ran another test after purging the page from Cloudflare and it PageSpeed still says it’s showing JPGs when in fact they are WebP. In fact, the size of the file that PageSpeed is saying is a JPG is the file size of the WebP image itself!

I’m done with this for now. I’m getting too aggravated.

I think what I’ll try next is to create a new child theme. Something has got to be causing an issue as to what this blog will use WebP with no problem while WriterSanctuary is completely ignored by PageSpeed Insights.