WordPress incompetence adds non-features that slowdown page loads and annoys us to death. But there is worse, Google telling WordPress to add stupid non-features. What non-feature are we talking about and what the heck is a non-feature?

A non-feature is gewgaw engineers and programmers imagine is cool. But it serves no purpose and makes things work worse – not better.

Has WordPress done this in the past? Yes. Perfect example: Emoji.

REFERENCE: https://pagepipe.com/how-to-eliminate-deadweight-emojis-in-wordpress/

Autoptimize plugin to LiteSpeed servers include a button to disable Emoji. Why did WordPress add that cast-iron blunder?

They discovered a critical security vulnerability in WordPress core code. And then patched using emoji as a Trojan horse in WordPress 4.2. So embarrassing for WordPress. They never revealed what the security issue was.

So what did they add now? And why?

A major blunder: WebP by default merged into WordPress 6.1. You can read about it offsite here:

REFERENCE: https://wptavern.com/WebP-by-default-merged-into-core-for-wordpress-6-1

This is a sad day for page speed. All our tests show that WebP bloats the media library (uploads folder) on the server. And there is no speed benefit from WebP from actual testing. A web myth. Smaller files loaded in parallel do not always equate to fast pages. Incredible sales job by Google’s PR people.

That right. Google employees are serving full-time on the WordPress committee making the decision. Who claims to have invented WebP image format? Google. You can read about how that mistake happened here:

REFERENCE: https://pagepipe-ebooks.com/WebP-not-dont-use-WebP-image-format/

Get the free download at the bottom of that page link.

What is the worst repercussion of the mandated WebP image format? (Yes. Converting all uploaded JPEG images to the media library to WebP image format. Incredible).

What does that do?

Eventually, it bloats the site media library. Then backups can’t be restored using normal server resources. The restoration aborts – or site migration fails.

It’s a big danger we’ve found in our PagePipe speed work (site tuning)

https://speedhospital.org/wordpress-speed-tuning/

It isn’t that the media library won’t backup. It grows so huge it overruns server resources during the backup restoration.

Then your site is either throttled or taken offline by the host. This is a hidden liability most are unaware of. Creating WebP thumbnails accelerates this error condition.

You bloat the media library attempting to use WebP for speed improvements. All images are heavier than the original PNG and JPEG images. Imagify plugin WebP services are often used in WebP conversion. All old images are still on the server.

That’s right. Google lied about the benefits of WebP. You don’t like that word: lied. OK. A gross exaggeration because they weren’t used to telling the truth.

REFERENCE: https://pagepipe-ebooks.com/theme-me-duplicate-premium-speed-themes-with-free-themes-and-plugins/

There were 1,600 images shown in the media library at first. Now there are 20,800 more images than there were on the server. And not indicated anywhere in the media library.

Generating WebP along with the original JPEGs will use an extra 70 percent to store both file types.

There is no sign in the media library dashboard of bloat. The “uploads” folder reveals 14 more WebP thumbnails created for each image uploaded. The media library is now too fat to download without code corruption.

This is a recurring nightmare. Bad news for small sites with limited resources on shared and managed hosting. Clean-up is tedious – almost impossible.

REFERENCE: https://pagepipe.com/fixing-an-impossible-1-million-image-speed-killing-media-library/

The persons spearheading this decision for WebP incorporation into core are full-time employees. They’re Google’s paid “volunteers” working on the main WordPress core committee. Conflict of interest? Controlling the web through backdoor selling. Not good.

Google influencing (manipulating?) WordPress to make WebP the default format on WordPress is preposterous. People are blowing up their server “upload” folder with WebP retroactive conversions. All in the name of speed. They destroy their chances of successful migration and restoration.

Site death results.

Here’s how to resurrect your media library.

First, install this free plugin:

Disable WebP By Default plugin

REFERENCE: https://wordpress.org/plugins/disable-WebP-by-default/

This small plugin disables WebP creation on upload globally.

Many third-party services are offering to convert a media library completely to WebP. Marketing hype to differentiate. Have they not done any tests? There are destructive and expensive long-term consequences of this hidden liability.

Companies doing WebP bulk conversions are:

• ShortPixel
• EWWW Image Optimizer
• LiteSpeed Cache
• Smush plugin
• Images to WebP
• NitroPack
• and more.

Be smart. Don’t do it! Don’t be a lemming tumbling over the cliff. (Confirmed mythical lemming behavior). Don’t follow the herd.

Now here’s a smart way to purge all the WebP images from your library. It’s not for everyone. You have to know how to use the command line in a terminal program:

Delete all .WebP images using SSH.

If you have access to SSH, navigate to /wp-content/uploads and run the following command first

find . -name “*.WebP” -type f

It returns all files with WebP extension in your uploads folder including sub-directories. If the results look good, finally run this command to delete the files.

find . -name “*.WebP” -type f -delete

An alternative way is FTP. If you have only a few hundred web images, you can delete them manually using an FTP client like Filezilla.

Note: Don’t ever think of using FTP if you have thousands of images. FTP is too slow and takes hours/days to delete all images. Whereas SSH takes a few seconds to do the same.

So is there another way? One that uses free plugins? Yes.

Our next section addresses:

Efficient plugin strategies for optimizing images.