If I had to pick a single optimization for a slow site, I'd pick images without hesitation. On most sites I review, images account for 60 to 80 percent of a page's total weight, and they're almost always badly prepared: exported at four thousand pixels wide to be displayed at three hundred, in outdated formats, uncompressed, and all loading at once even though the visitor never scrolls to the footer. The good news is that fixing it requires no coding and usually cuts page weight in half or better.
Mistake number one: uploading the image exactly as it came out
A photo from a modern phone easily runs four thousand pixels wide and weighs several megabytes. If you upload it as is and your design shows it in an eight-hundred-pixel box, you're forcing every visitor to download five times more information than their screen can display. It's like mailing a full-scale blueprint so someone can look at it from across the room.
The practical rule is simple: resize to twice the display size, and no more. Twice, not exactly the size, because high-density screens render double the actual pixels. An image occupying eight hundred pixels in the layout should be uploaded at sixteen hundred. A logo shown at one hundred and ten pixels needs no more than two hundred and fifty-six. That change alone typically cuts weight by ninety percent.
Formats: which one for what
- WebP is today's default choice for almost everything. It weighs 25 to 35 percent less than an equivalent-quality JPG, supports transparency like PNG, and every current browser understands it. If you can only keep one format, keep this one.
- JPG is still valid for photographs if you need compatibility with very old software, but on the web there's no longer a technical reason to prefer it.
- PNG only makes sense for graphics with few colors and hard edges, or when you need lossless perfect transparency. Using it for photographs is the most expensive mistake out there: a PNG of a photo can weigh ten times more than its WebP equivalent.
- SVG is the outright winner for logos, icons and any vector graphic. It weighs almost nothing, looks perfect at any size and never pixelates.
- AVIF compresses even better than WebP, but takes longer to generate and isn't always worth the extra complexity. As a future plan, yes; as today's priority, no.
Compression: how hard you can squeeze without it showing
When you save an image, you pick a quality level. Intuition says use the maximum, and intuition is wrong. The visual difference between quality one hundred and quality eighty is practically imperceptible on a screen, but the weight difference is enormous, on the order of half.
My reference values: for photographs without transparency, quality eighty; for images with transparency, eighty-eight; for screenshots containing text, a bit higher, because text is the first thing to get muddy under compression. And always, always look at the result on screen before calling it done. A percentage is just a number; your eye is the judge.
Lazy loading: don't download what nobody is looking at
A page with twenty images downloads all twenty the moment it opens, even though the visitor only sees the first two. Lazy loading changes that: images outside the viewport are downloaded only as the visitor approaches them.
These days it's as simple as adding one standard attribute to the image tag, and modern browsers handle it without any script. But there's an important exception many people miss: the hero image, the one visible the instant the page opens, must not be lazy-loaded. On the contrary, it should be marked as high priority so it starts downloading before anything else. Deferring the hero image makes the metric Google measures worse, not better.
Two details worth a lot that cost nothing
The first is declaring each image's width and height in the markup. Without them, the browser doesn't know how much space to reserve and the content jumps when the image finishes loading. That is exactly the visual stability metric Google penalizes, and it's fixed with two attributes.
The second is alt text. It serves accessibility, which would be reason enough, but it's also one of the few signals search engines have for understanding what an image shows. Describe what's visible in natural language, without stuffing keywords: "rack of servers in a data center" is useful, "cheap hosting fast hosting hosting argentina" is counterproductive.
How I do it in practice
- Resize to twice the display size.
- Convert to WebP at quality eighty (eighty-eight if it has transparency).
- Give it a descriptive filename, lowercase with hyphens, no accents or spaces.
- Write the alt text.
- Add width, height and lazy loading, except on the hero image.
- Check it looks right in the browser and measure the page before and after.
One server detail that matters: filenames should be lowercase. Windows doesn't distinguish uppercase from lowercase, but Linux does, so an image that looks perfect on your computer can appear broken once uploaded. It's one of the most frustrating errors precisely because it works locally.
How many versions of each image you actually need
One question that comes up constantly is whether it's worth generating several sizes of the same image. The short answer is yes, and most content systems already do it automatically, but they usually do it badly: they generate eight or ten sizes nobody uses, filling your disk with megabytes of dead files. It's worth reviewing which sizes your design really uses and disabling the rest.
As a rule of thumb, three versions cover almost every case: a small one for thumbnails and listings, a medium one for content within an article, and a large one for hero images or lightbox views. If your layout is responsive, letting the browser pick between those three based on screen width means a phone downloads a fraction of what a desktop does, without you doing anything else.
The counterintuitive part is that adding versions reduces total transferred weight even though it increases stored weight. Disk space is cheap and plentiful; your visitor's mobile connection is neither. When in doubt, optimize for what travels over the network, not for what sits on the server.
The hosting's role
Optimizing images reduces how much has to be sent; hosting determines how fast it gets sent. The two factors multiply. What you want on the server side is properly configured browser caching so returning visitors don't re-download what they already have, compression enabled, SSD storage to serve files quickly, and enough bandwidth not to choke during a traffic spike.
That's why I work with BanaHosting: pure SSD on Dell servers with RAID-10, LiteSpeed with LSCache which handles static content very well, unlimited bandwidth, and between 50 and 150 GB of storage depending on the plan, which is plenty for a well-optimized image library. It starts at $4.95 a month, with free migration of up to 3 sites and a 30-day money-back guarantee so you can test it risk-free.