When a blog post loads slowly, the text is rarely the problem. Words are tiny. Images are not. A single unresized photograph from a modern phone can outweigh the entire rest of the page — the text, the styling, the layout — several times over. Put five or six of those in a post and visitors on a mobile connection may wait long enough to leave before the first picture appears. The frustrating part is that the fix is usually simple, and it does not require redesigning the site or learning a new skill.
This post follows one fictional slow post from measurement to fix. The numbers are illustrative, but the pattern is one you can check on your own site in a few minutes: find the post, look at the size of its images, and compare that with what the layout actually displays.
Measuring the problem first
Daniel runs a small gardening blog at example.org. One of his most-read posts, about growing tomatoes in containers, feels sluggish on his phone, and readers have mentioned it. Before changing anything, he measures. The post contains eight photographs, each uploaded straight from his camera at around 4000 pixels wide, and each weighing between 3 and 5 MB. Together the images total roughly 30 MB. The layout displays them at most 800 pixels wide.
That gap is the whole story. The browser downloads 4000 pixels of detail and displays 800. The other 3200 pixels are wasted bandwidth, and on a slower connection they translate directly into waiting. Daniel also notices that the images are all JPEGs, which is the right format for photographs, but at the camera's highest quality setting, far beyond what a screen can show. Measuring first matters because it tells him the fix is about size, not about the theme, the hosting, or the writing.
He opens the post in Image Optimizer's workflow in his mind as a checklist: resize to the display width, compress to a sensible quality, and re-upload. He does not need new software or a new host. He needs smaller versions of the same pictures.
Resize before you compress
The single biggest saving comes from resizing, and it should come first. Shrinking an image from 4000 pixels wide to 800 pixels wide removes most of its pixels, and with them most of its bytes. Compression then works on a much smaller file, so the two steps multiply rather than add.
Daniel resizes all eight photographs to 900 pixels wide — slightly above the 800-pixel display width, so they still look sharp on higher-density screens — and the total drops from about 30 MB to roughly 3 MB before he touches quality at all. That one step accounts for most of the improvement, and it is the step most often skipped, because uploading the original feels faster in the moment. It is not faster for the reader.
A useful habit is to decide your site's widest image width once, write it down, and resize every image to it before uploading. For many blogs that number is between 800 and 1200 pixels. Anything wider is detail nobody's screen will show in the layout.
Then compress with your eyes open
With the images resized, Daniel compresses them at a quality setting around 80. The total falls again, to roughly 1.5 MB for all eight photographs. He checks each one at display size, looking for blocky patches in skies and soft gradients, which are the first places over-compression shows. None of the eight looks worse at normal viewing size, and the page now loads in a fraction of the time it took before.
The lesson is to judge compression at the size readers will see, not zoomed in. A setting that looks slightly soft at 200 percent zoom can look perfect at 800 pixels wide, and chasing pixel-perfect quality at full zoom is how files stay large for no visible benefit. Conversely, if a photograph has large areas of smooth sky or water, be more cautious: those areas reveal compression first, and a slightly higher quality setting is worth the extra kilobytes there.
For a fuller guide to formats and settings, see how to optimize images for the web. Framing images well before compression matters too, but size and quality settings are where most of the loading time is won or lost.
Worked example: before and after, side by side
Here is Daniel's post, summarised as a before-and-after table in words. Before: eight photographs, 4000 pixels wide, camera quality, totalling about 30 MB. The post took many seconds to become readable on a mobile connection, and images arrived one by one, pushing text around as they loaded. After: the same eight photographs, 900 pixels wide, compressed at quality 80, totalling about 1.5 MB — roughly a twentieth of the original weight.
The visible difference to a reader is nil at display size. The photographs are the same pictures, the same colours, the same composition. The experiential difference is large: the page becomes readable quickly, pictures appear promptly, and the layout stops jumping as each image arrives. Daniel also keeps the originals in a folder on his computer, so if he ever redesigns the site with a wider layout, he can export fresh copies at the new width instead of stretching the small ones.
Nothing else about the post changed. Same words, same theme, same host. Images were the bottleneck, and images were the fix.
Honest limitations
Optimisation cannot fix every slow page. If the hosting is slow, the theme loads heavy scripts, or the page embeds several videos, smaller images will help but will not solve the whole problem. Image compression also has a floor: pushing quality too low will visibly damage photographs, especially ones with fine detail or smooth gradients, and a damaged image is worse than a slightly larger one. Finally, resizing is a one-way decision for the exported copy — a 900-pixel image cannot be enlarged later without losing sharpness — so always keep the original file somewhere safe before you resize.
FAQs
How do I know if images are slowing my page down?
Check the size of the images on the page against the size they are displayed at. If the files are several megabytes, or far wider than their display width, they are very likely the main cause. A browser's developer tools can show each image's transferred size.
Is resizing or compressing more important?
Resizing, usually. An oversized image wastes far more bytes than a slightly high quality setting. Do resizing first, then compress the resized copy and judge the result at display size.
Will smaller images look worse?
Not if you resize to the display width and compress moderately. An image shown at 800 pixels wide does not need 4000 pixels of data. Visible loss appears when quality is pushed very low, or when a small image is stretched larger than its pixel size.
Should I convert everything to WebP for speed?
WebP often gives a smaller file than JPEG at similar quality, which helps speed. But check that your site platform and any tools in your chain support it first. A JPEG at the right size and quality is still a large improvement over an untouched original.
If your post also includes scanned pages, Scan to PDF can bind photographed pages into a clean PDF, and PDF to JPG can turn document pages back into images for a post.
human review pending client designation