Last month we were performing a Page Speed Optimization for a client; during testing, we noticed that our Page Weight was actually going up while using Imagify, our standard Image Optimization Plug-in. This didn’t make sense because Imagify should always decrease Page Weight and Load Time using WebP versus JPEG or PNG, as WebP is a more compressed but higher-quality image format.
So we investigated, and it turned out that because the site we were working on was using images in backgrounds, specifically the “Full-Size” version, it was actually increasing Page Weight. And Imagify promises to “Speed up your website with lighter images”, so what is going on?
The Problem with Imagify
One of the few things you can set in Imagify is the maximum width. This allows content managers to upload a high-quality image they’ve sourced from a photographer or stock photo library (Adobe Stock, Unsplash, Shutterstock,etc.) without worrying about the resolution of those images. They can just go ahead and upload, and it will automatically resize that image to the maximum size for the website, typically around 2560 pixels in either dimension. That is important because those pixels really aren’t discernible to the human eye on most screens and very few people use a browser viewport that large. So, no wasted pixels.
When we looked further, by using Chrome’s Dev Tool Network panel, we found that the WebP file was quite large compared to the JPEG. And that the WebP version of the file was not actually getting resized despite the maximum width setting.
So we ran some tests, and sure enough, Imagify would resize the JPEG or PNG file down to the maximum size, but the WebP version would be left at the original size. Then because the site serves the WebP file, if this file was huge, say a 20-megapixel image which is not uncommon from a stock photo, it would send a 20-megapixel WebP file to the browser.
Bug Reporting & Support
The next step was getting support because it was clearly a bug. We went and reported it on the Imagify Support Forum on WordPress.org where we received no response for several days.
Needing to get this fixed and Imagify being a Plug-in with a Service that we pay for, we used the support chat and reported the bug. We waited a couple of days and finally received a response.
Their response was that they were aware of the problem and that it was in their queue of things to be fixed, but they hadn’t gotten to it yet. And that there was actually a bug report on the Plug-in GitHub. Upon visiting this issue, we found that it was opened on October 8, 2020, about 23 months ago! WP Media/Imagify have known for 23 months that they could potentially be increasing the size of pages, inflating bandwidth costs, and potentially slowing down pages across multiple sites.
Perhaps, the most concerning part of this is that according to WordPress.org, the Plug-in has been installed over 600,000 times!
During that back-and-forth with support, they said, “It is not that bad as it might look at the first sight.” Here we disagreed, of course, knowing that this could impact thousands, tens of thousands, or even hundreds of thousands of websites. Website owners that, in good faith, are using their Plug-in and Paying for their service to help speed up their website “with lighter images”. But Imagify is literally doing the opposite.
And how many users is it impacting?
Testing, Testing … 1, 2, Jeez!
Given Imagify’s laissez-faire attitude, we thought we should test whether or not this was a real problem, so we created a very basic WordPress website with 11 posts, each with five royalty-free images and a screenshot in various formats. We chose Twenty-Twenty One, one of the included WordPress Themes, and hosted it on a DreamHost Shared platform.
In addition to the site that used standard WordPress compression and scaling, we created two more versions, one using Imagify with Non-WebP (only JPG and PNG) compression and one using WebP compression.
We tweaked the theme’s code to turn off lazy-loading, so we could easily see where the difference is and how much Imagify is actually exploding Page Weight. We also deliberately set images to “Full-Size” from the editor, which, while not best practice, is not uncommon to have a content manager do in pursuit of “best quality” … unfortunately, not uncommon at all.
To be perfectly clear, all tests are meant to exaggerate results and be illustrative of how bad this bug could be if a content manager didn’t resize images before uploading.
Imagify Balloons Total Page Weight Using WebP
To create a simple test, we used Chrome’s Dev Tools, set our Network panel to “Preserve log”, and visited the Homepage and the 11 posts of the website to get the total Page Weight of the Site.
Total Page Weight Comparison
| Device Size | Unoptimized (MB) | Non-WebP (MB) | WebP (MB) |
|---|---|---|---|
| Mobile | 9.9 | 5.9 | 5.4 |
| Tablet | 33.1 | 18.5 | 48.6 |
| Desktop | 93.8 | 26.3 | 75.6 |
Of the three sites we created, the Non-WebP version had the lowest Page Weight at Tablet and Desktop Dimension, and the WebP version was only smaller in Mobile dimensions. But the WebP version was up to 2.9X size! The Unoptimized version came in 3rd but was actually smaller than the WebP version on Tablets and only 24% larger than the WebP Desktop version. This was enough to confirm our suspicions.
But How Big Is Imagify’s Impact on Popular Themes
We wanted to confirm that this wasn’t due to something in the Twenty-Twenty One Theme. So we built 11 additional Websites using the 9 Most Popular Themes with more than 100,000 installs plus two Popular Premium Themes, Divi and Extra.
Number of Installs of Popular WordPress Themes (with links to Test Sites)
| Theme | Installs |
|---|---|
| Astra | 2.1+ Million |
| Divi | 2.3+ Million |
| Extra | Unknown |
| GeneratePress | 500,000+ |
| Hello Elementor | 1.3+ Million |
| Hestia | 100,000+ |
| Kadence | 100,000+ |
| Neve | 300,000+ |
| OceanWP | 700,000+ |
| PopularFX | 100,000+ |
| Sydney | 100,000+ |
| Twenty-Twenty One | 1+ Million |
We also felt it was important to build some sites using a Website Builder plug-in due to the popularity, so Divi, Elementor and Pagelayer are represented in this research.
On average, at Desktop dimensions, the Page Weight of WebP optimized version of the site was 2.9X larger than the non-WebP version. And in 3 cases (PopularFX, Kadence, and Extra) the WebP versions of the site were larger than the original Unoptimized files.
When looking at builder-based Themes, there wasn’t as big a difference as we suspected. One thing we did note during setup was that Divi requires a maximum image dimension of 2880 pixels, and some modules on Elementor (over 7.5 million installs) default to the “Full-Size” version of the image, so some novice and intermediate users might assume that is the correct setting.
Imagify’s Potential Impact on Google Web Vitals
We also wanted to know how this might impact real-world performance because not only can it impact SEO, but it impacts User Experience. We tested the 3 Twenty-Twenty One websites’ 12 pages against the Pagespeed Insights API. The tests were performed five times at different times of day to avoid resource issues with both Google APIs and our testing platform. And then averaged the Web Vitals scores.
| Site | Average Mobile Score | Average Mobile FCP | Average Mobile LCP | Average Desktop Score | Average Desktop FCP | Average Desktop LCP |
|---|---|---|---|---|---|---|
| Unoptimized | 88.98 | 1.228 | 3.697 | 97.85 | 0.32 | 1.045 |
| Non-WebP | 93.68 | 1.227 | 2.88 | 99 | 0.316 | 0.788 |
| WebP | 93.58 | 1.248 | 2.847 | 99.48 | 0.315 | 0.743 |
Tenacity Note: Pagespeed Insights’ Standard Desktop Test uses an emulated display of 1350×940, which may result in better overall scores due to Responsive Images. However, 1920×1080 is the most common desktop resolution.
There wasn’t a large enough difference in Scores or Web Vitals to draw conclusions, so we wonder if this is what Imagify did to check to determine that it was “not that bad”.
One thing we found interesting, though, is because of the way Responsive Images work on the site; the problem was less severe than we had anticipated because the smaller versions of the images are WebP compressed. This is why the site’s “Unoptimized” version is slightly larger. However, we suspect this results from using a standard WordPress Gutenberg-based theme and all the default settings, which are well optimized. We wondered if you had a WordPress Theme or Builder that used a lot of images in the background or didn’t use Responsive Images properly, would this be significantly exacerbated?
While we didn’t have time to do full testing against all of the Themes, we wanted to do an anecdotal investigation of the impact of the Non-WebP vs. WebP on Homepage Speed.
Theme Comparison on Homepage Speed with Imagify Installed (Desktop)
| Theme | Desktop FCP (Non-WebP / WebP) | Desktop LCP (Non-WebP / WebP) | Desktop Page Weight (Non-WebP / WebP) |
|---|---|---|---|
| Astra | 0.3 / 0.3 | 0.7 / 0.7 | 739 / 750 |
| Divi | 0.8 / 0.8 | 0.8 / 0.9 | 1905 / 2269 |
| Extra | 0.8 / 0.8 | 1 / 11.1 | 4413 / 14373 |
| GeneratePress | 0.3 / 0.3 | 1 / 1 | 1720 / 1757 |
| Hello Elementor | 0.7 / 0.7 | 2.8 / 2.6 | 5192 / 8079 |
| Hestia | 0.8 / 0.8 | 1.7 / 1.5 | 2106 / 2124 |
| Kadence | 0.8 / 0.8 | 1 / 1 | 666 / 714 |
| Neve | 0.8 / 0.8 | 1.3 / 1.3 | 1530 / 1574 |
| OceanWP | 0.4 / 0.4 | 0.8 / 0.5 | 2069 / 2106 |
| PopularFX | 0.8 / 0.8 | 4.2 / 15.8 | 7719 / 31113 |
| Sydney | 0.5 / 0.5 | 1.9 / 2.8 | 2806 / 5186 |
| Twenty-Twenty One | 0.3 / 0.4 | 0.8 / 0.6 | 1738 / 1775 |
After reviewing the Desktop data, it’s clear that the Theme selection will greatly impact whether or not this bug will worsen Largest Contentful Paint and Page Weight. In one case, LCP increased by more than 10 times! One could imagine what these scores might look like if Google’s emulator used 1920×1080.
Then we checked them on Mobile.
Theme Comparison on Homepage Speed with Imagify Installed (Mobile)
| Theme | Mobile FCP (Non-WebP / WebP) | Mobile LCP (Non-WebP / WebP) | Mobile Page Weight (Non-WebP / WebP) |
|---|---|---|---|
| Astra | 1.1 / 1.2 | 1.4 / 3 | 1077 / 991 |
| Divi | 2.9 / 2.9 | 2.9 / 2.9 | 1818 / 2075 |
| Extra | 2.6 / 2.6 | 4.3 / 19.1 | 4413 / 14373 |
| GeneratePress | 1 / 1 | 2.7 / 1.2 | 1066 / 980 |
| Hello Elementor | 2.5 / 2.5 | 2.5 / 2.5 | 4935 / 7674 |
| Hestia | 2.8 / 2.8 | 2.8 / 6.7 | 1757 / 1660 |
| Kadence | 2.8 / 2.8 | 4.1 / 5 | 1159 / 1085 |
| Neve | 2.6 / 2.6 | 4.1 / 4.1 | 988 / 925 |
| OceanWP | 1.6 / 1.9 | 2.5 / 6 | 1341 / 1255 |
| PopularFX | 2.8 / 2.8 | 2.8 / 2.8 | 7714 / 31109 |
| Sydney | 2 / 2 | 10.2 / 15.9 | 2963 / 5284 |
| Twenty-Twenty One | 1.2 / 1.2 | 3.9 / 3.1 | 1084 / 998 |
Mobile Data confirms the impact on LCP and Page Weight in spite of Responsive Images. One thing to note is that while Hello Elementor WebP Page Weight is almost 74% larger, this doesn’t affect Largest Contentful Paint because the Page Headline is the Largest Element.
So What Do We Do Now? Or the Non-terrible Advice Imagify Won’t Give You.
Does this mean that we would stop recommending Imagify to people, and are we, as a company going to stop using them? It’s a tricky question because we’ve been a customer for years, and it’s integrated into many projects, making this such a disappointment.
Imagify might still be a good option if the following are true:
- Your theme uses Responsive Images, and most traffic is mobile.
- Your theme does not use “Full-Size” background images or many background images.
- Your content manager sizes the images appropriately before uploading.
Conversely, if you use a lot of image backgrounds or you use “Full-Size” images often, Imagify using WebP, at the moment, is not a good solution. Imagify will increase the Page Weight on your site, Bandwidth costs and likely make the User Experience worse by slowing it down.
If you are currently using Imagify, we recommend doing a simple test with WebP enabled or disabled to determine whether your site is impacted by this bug.
Tenacity Note: Let us know in the comments if you want us to do a quick tutorial on this process. Or if you prefer, give us a shout.
Until we’ve tested other solutions, we will continue using it on our own website because we resize our images before uploading as part of our best practices. While our clients’ average Page Speed and Load Time are excellent, we are reviewing all of their websites at our own expense to ensure that we weren’t inadvertently slowing them due to the Imagify Plug-In bug.
Here’s the Sad Part
All of this is because WP Media/Imagify will not have a Developer take 30 to 60 minutes to fix this problem. This should be a trivial update for someone familiar with the codebase, as we reviewed both the Plug-in code and the API.
Potential fixes would be:
- Images can be resized directly on Imagify API.
- The Plug-in could resize them on the server before compressing.
- The Plug-in could use the “-scaled” version of the image that WordPress creates.
It’s very concerning that WP Media/Imagify has not addressed this issue in almost two years.
They did, however, find the time to implement “Smart Optimization,” a feature that no one asked for, which supposedly automatically optimizes your image to the best compression. If you look on WordPress Support, a group of vocal users hates this feature, and unlike many of WP Media’s other solutions, there is no way to turn it off. In our opinion, removing the ability to control compression and quality from your customers’ websites is terrible, especially for us in the Page Speed community, who tend to prefer more options.
On September 5, 2022, Imagify dismissed the issue as, “Our investigations show that it’s not as critical issue as it looks” and marked our WordPress.org Support Ticket as “Resolved”.
It is not.
And it’s pretty clear that it could be bloating tens of thousands of websites, and it’s not hard to imagine that it’s giving millions of users a poorer experience.
Moving On
Because of all of this, Tenacity is reviewing other Image Optimization strategies so that we can build the fastest websites possible for our clients. We are going to report to you which one we think is the best and compare them with Imagify; stay tuned for that in the coming months. If you have one you like, let us know in the comments.
From more than 15 years of WordPress experience, the worst-case scenario is incredibly common and, as reported, sometimes built right into the Theme or Builder. So, were we biased in all of this?
Absolutely. We want the bug fixed and to continue to recommend Imagify.
Test Sites and Images
(Update: September 23, 2022)
Despite including a link above to the Unoptimized Version of the original site previously, in the interest of transparency and in response to Jonathan Buttigieg, Co-founder of WP Media, we have updated this post with links to our sites in the post. For ease, here are all of the test sites we have available.
Twenty-Twenty One Sites
Additional Theme Sites
Unfortunately, additional Theme sites are not available for both WebP and Non-WebP since we just collected the Unoptimized data, then “optimized” with Imagify and toggled WebP on and off to collect our data. But here are all of our test Theme sites, so their layout can be reviewed. We would be happy to give WP Media access to these sites, so they can do their own testing.
- Astra Theme (WebP)
- Divi Theme (WebP)
- Extra Theme (WebP)
- GeneratePress Theme (Non-WebP)
- Hello Elementor Theme (Non-WebP)
- Hestia Theme (WebP)
- Kadence Theme (Non-WebP)
- Neve Theme (Non-Web)
- OceanWP Theme (WebP)
- PopularFX Theme (WebP)
- Sydney Theme (Non-WebP)
All The Data
(Update: September 24, 2022)
Further, we wanted to provide all of our data about every “Full-size” image used in this test in an easily digestible format, so we added a page to our website with all the information and links to every image. And since the goal is to document everything about the issue so that it gets fixed, we’ve also collated all of our data collected while writing this post and have shared it below.
One more thing… after gathering all of the image data for sharing, we found that when comparing the WebP optimized files with the Non-WebP optimized files, 65% of the Imagify WebP files were larger than their corresponding Non-WebP files at the same image dimensions. Our best guess is that JPGs are being very aggressively optimized as opposed to an issue with WebP compression.
WP Media Has Added the Bug to Milestone 2.1
(Update: September 24, 2022)
We’re pretty curious after stating the issue as “the resize option is not the problem”, we found that Buttigieg appears to have added the bug discussed in this post to Milestone 2.1.
Regardless, we appreciate that WP Media will be addressing this in the future.
