---
title: Five image habits that keep WordPress fast
description: Five image habits we use on real WordPress sites to cut page weight, from resizing before upload to cleaning out an overgrown media library.
date: 2026-09-04
updated: 2026-09-05
tags: [friday roundup, wordpress, images, performance]
url: "https://drivenhost.com/blog/images-that-slow-sites"
author: DrivenHost
---

When a customer opens a ticket that says "my site got slow", the first thing we do is load a page and look at what it downloads. More often than not the answer is sitting right there in the media library: a hero photo straight off a phone camera, 4,000 pixels wide, three megabytes, displayed in a box 900 pixels across. No caching plugin fixes that. The browser still has to pull the whole file down before it can shrink it on screen. Here are five habits that make the biggest difference on the sites we look after, roughly in the order we apply them.

## Resize before the file ever reaches WordPress

This is unglamorous and it is still the single biggest win we see. A photo does not need to be wider than the widest place it will ever appear, which on most small-business themes is somewhere between 1,200 and 2,000 pixels. Resizing on your own machine before upload costs you ten seconds and saves the server from generating a stack of thumbnail sizes it will never serve. Squoosh (squoosh.app) runs in the browser and is enough for one-off images, and Preview on a Mac or IrfanView on Windows will batch a folder of them.

## Pick one optimizer and leave it alone

Compression plugins do useful work, and running two of them does not do twice as much. We have seen sites with ShortPixel and EWWW Image Optimizer both installed, both queuing the same attachments, both writing the same log tables, and the only visible result was a load spike every time someone bulk-uploaded a gallery. Choose one, run the initial bulk pass overnight rather than at noon on a Monday, and let new uploads get handled as they arrive. If you are on shared hosting and the bulk run keeps stalling, that is usually the plugin's API queue rather than the server, and it will pick up where it left off.

## Use WebP, but check the fallback actually works

WebP files land somewhere around a quarter to a third smaller than the JPEG equivalent at the same visible quality, which is real money on an image-heavy page. The part that generates tickets is delivery. Most optimizers can either rewrite the URLs in your content or hand the job to rules in .htaccess, and if those rules collide with a caching plugin or a CDN that caches one variant for everybody, some visitors get a broken image icon and you never see it in your own browser. After you switch it on, load the site in a private window, then in a second browser, then on your phone. Two minutes of checking beats a week of quiet breakage.

## Let lazy loading do its job, and keep it off the first thing people see

WordPress adds native lazy loading to images by default now, so most sites already have it without a plugin. It works well below the fold and badly at the top of the page, because deferring the one big image a visitor is waiting to see is exactly the wrong trade. Sliders and page builders are the usual culprits here, since they often load their own script before the image is even in the markup. If your Largest Contentful Paint number looks worse after a redesign, the hero image is the first place to look. We wrote about reading those numbers without the jargon in [our plain-language guide to Core Web Vitals](/blog/core-web-vitals-plain).

## Clean out the media library once a year

Media libraries grow quietly. Five years of uploads, a theme change or two, a plugin that generated its own image sizes, and suddenly the uploads folder is 14 GB and every backup takes an hour longer than it should. Once a year, take a full backup first, then look for attachments nothing links to and thumbnail sizes no active theme uses. Tools like Media Cleaner will find the orphans for you, though we would not trust any of them to delete without a restorable copy sitting somewhere else first. If your backup routine is not at that standard yet, [the backup post we keep pointing people to](/blog/backups-that-restore) covers what we mean.

None of this is exotic. It is the same five checks we run on nearly every slow site that comes across the desk, and on a typical small-business WordPress install it will do more for page weight than any settings screen. If you have gone through the list and pages are still crawling, that is worth a closer look at the account itself, and our [support team](/support) can pull the server-side numbers and tell you what the server is actually spending its time on.