The most common speed problem, and the cheapest
If a small business website is slow, the first thing to check is the images, because it is the first thing to be wrong. Photos uploaded straight from a phone are three to five thousand pixels wide and several megabytes each. They are then shown at a few hundred pixels wide inside a page. The browser downloads the whole multi-megabyte file to display a thumbnail, and a page with ten of them is thirty or forty megabytes.
On office Wi-Fi it feels fine. On a phone on mobile data, it is the site that never finishes loading.
The good news is that this is fixable across the entire site in an afternoon, without touching the design, and it is often the single largest speed improvement available.
How to confirm it is the images
Open the site in a desktop browser, open the developer tools, go to the Network tab, reload the page, and sort by size. If the largest items are image files and any of them is over a few hundred kilobytes, you have found it. A hero photo should be under two hundred kilobytes; a gallery thumbnail under fifty.
Alternatively run the page through any online speed test and look for "properly size images" and "serve images in next-gen formats" near the top of the recommendations.
What "compressing the site" involves
Three separate things, usually done together.
Resize. Each image is reduced to the largest size it will ever be displayed at. A photo shown at 800 pixels wide does not need to be 4000. Most platforms can generate multiple sizes and serve the right one for the screen, so a phone gets a small version and a desktop a larger one.
Compress. The file is re-encoded at a quality setting that is visually indistinguishable on a screen but much smaller on disk. Photographs tolerate this well; a quality setting around 75 to 82 out of 100 is the usual sweet spot.
Convert. Modern formats, WebP and AVIF, are a quarter to a half the size of a JPEG at the same visual quality, and every current browser supports WebP. Converting the library and serving the modern format with a JPEG fallback is standard.
Doing it across an existing library
You do not re-upload three hundred photos by hand.
On WordPress, an image optimisation plugin processes the entire existing media library in bulk: resizing, compressing and converting every file and its generated sizes, and then doing the same automatically for every future upload. Some run on your server; some send images to a service and return them. Both work; the service-based ones are faster on shared hosting. Run it on a backup or staging copy first, because it rewrites files.
On other platforms the equivalent is a build step or a service in front of the site that resizes and converts on the fly. Next.js, for example, does it automatically when images go through its image component.
Then the theme is checked to make sure it is asking for the right sizes rather than the original, and images below the fold are set to load lazily so the first screen is not waiting on the gallery at the bottom.
Stopping it happening again
The compression run fixes what is there. Preventing recurrence is a setting and a habit:
- The platform resizes and converts on upload, automatically, so the next phone photo is handled the moment it lands.
- A maximum upload dimension is set, so a 6000-pixel original is scaled to 2400 on arrival.
- Whoever adds photos knows the one rule: upload the photo; let the site handle the size. No pre-processing needed.
On a care plan, a monthly check of the largest files in the library catches anything that slipped through.
What to expect afterwards
On the inherited sites we fix, image work alone usually takes a page from five or six seconds on a phone to two or three. Combined with a caching layer and a plugin cleanup, under two seconds is the normal result. The design does not change. The photos look the same. The site simply stops asking the visitor's phone to download a poster to show a postcard.
Where this fits
Image compression is the first item in the fix half of our diagnosis and fix, because it has the best ratio of result to effort on almost every site. It is also part of why every site we build loads in under two seconds from launch: the images never get a chance to be the problem.