Facebook discussions go on and on about various “automatic” ways to optimize graphics. They assume oversized graphics are the only possible reason for web slowness.

Will automated image optimization solutions do a better job than a human? We mean better than optimizing each graphic by hand in a photo manipulation program. Machines can’t determine human quality perception. They can take a bad image – and make it much worse. Foolishness.

We’ve done our homework on image page weight (file sizes) and how it affects speed. Images may be 60 percent of page weight – but they aren’t 60 percent of page slow down. There isn’t as big of interdependence between speed and weight as site owners think. Only 10 percent of speed is image waste. The fastest sites on the web have no images. These generally load in under 600 milliseconds. Serious.

But that’s Spartan or Stoic discipline. Speed overkill. The site owner has 100-millisecond Time To First Byte (TTFB rare quality). And 100 milliseconds of SSL handshaking (best case). And then milliseconds to cram in the actual page assets. Done. Less than 1 percent of websites are 1-second fast. How do they look? Boring.

The average page load time on the Internet is 8 seconds. Can you believe that? It’s proven 10 seconds is the end of human tolerance. Backbutton: Click! Gone.

Images load in parallel now on browsers. Fast. They are often no worry at all. Bigger worries are assets that request information from remote servers. You’ll achieve more effective optimization removing Google Fonts than tweaking images. Remove Google Fonts with a free no-setting plugin.

Or even better, a fast theme that uses a mobile system font stack in the CSS style code.

Removing fonts is a nicety for speed but not always essential. Image optimization isn’t a greater consideration than Google Font slow downs. We’re talking 100 to 300 millisecond gains is all. 300 milliseconds is still 15 percent of a 2-second performance budget. You don’t ignore that. But in some cases, we do.

The big exception for image failure is when total geniuses build websites. Pseudo-intellectuals think a 24-bit PNG is WAY better than a lossy JPG. Huge PNG images are then placed on every page as featured images. Horrific misjudgement.

We’ve seen pages drop from 12-second loads to 4-seconds. How? By converting the media library non-transparent PNGs into JPEGs. Is 4 seconds good enough speed? Not ever. But it’s better than average page load time.

Image resizing and compression plugins cost money based on usage. They don’t tell you that in the plugin description. Compressed images on a remote server return back to storage in your media library. The services aren’t free. The meter is running above a set quantity threshold. The exception is Imsanity plugin. (No typo on that odd name). Imsanity stops insanely huge image uploads like from digital cameras.

But Imsanity is still a dull person’s plugin. It’s for apathetic loafers who won’t optimize at all. We recommend using Imsanity as a safeguard against client foolishness. It’s not needed on our sites because we hand-optimize (like you do – right). But it’s our favorite plugin to prevent client sites from blowing up.

Most optimization plugins connect to a third-party server floating out in web cyberspace. Some need an API or account permission request. These remote server calls retard website speed whenever there’s activity.

If you keep images pretty small (dimensions or file size or both), all images load at the same time. Boom. 50 milliseconds. Larger images are a problem. Like full-screen desktop Retina size. Those need examination. They aren’t broken into smaller data packets causing delays. Small stuff is inconsequential for load time.

What things help image speed most? Proper image sizing. First. And second compression settings. But squeezing images to where they’re unrecognizable won’t payback benefits. There’s no reason today not to keep the quality compression setting high – 70 and up.

WordPress optimizes images already to a Photoshop quality of 50. That’s right. WordPress rebuilds and compresses images in the media library. That feature improves on-the-fly swapping when screen sizes are smaller. This is for built-in speed.

Do you need more compression than that? No. But it doesn’t compress original images. Just thumbs and medium sizes. Nor does it resize originals.

Some themes – like Twenty-seventeen default theme – have built-in lazy-load for featured images (2000x1200px or bigger). 3,000 pixels square is the recommended starting size for Retina-ready images. That’s according to Retina 2X plugin instructions. It’s a good plugin if you must deliver Retina images. But that’s a huge and heavy image.

Lazy loading images improves perceived load time. But the same amount of data still goes through the pipe. This extra weight is detrimental for mobile speed. Why? Because of data consumption cost. Lazy loading doesn’t remove any extra data weight, it only delays it.

Lazy load does unpleasant things on occasions. Like loading a logo last that appears at the top of the page. This delayed load may cause Flash of Unstyled Text (FLOUT). That makes a page look broken for a second. This is not good UX. So on some sites, we don’t use lazy load. Or we may choose to disable it on key pages with a plugin like Plugin Logic for selective plugin activation. This is Plugin Surgery.

“So … if I’m optimizing in Photoshop, and then use a plugin will that optimize it even better?”

Pain is a great teacher. Try that trick. It won’t work.

If you compress images in Photoshop or Gimp, you don’t need further compression.

OTHER READING

• https://pagepipe.com/the-fastest-alternatives-to-heavy-jpeg-images-for-page-speed/
• https://pagepipe.com/wordpress-undoes-your-manual-image-optimization-efforts-making-image-files-larger/
• https://pagepipe.com/mobile-image-optimization/
• https://pagepipe.com/the-fastest-alternatives-to-heavy-jpeg-images-for-page-speed/