Why do camera photos slow a page down?
A photo from a phone or a camera is made to be printed or zoomed into: thousands of pixels wide and several megabytes. A web page shows it in a box a few hundred, or at most a couple of thousand, pixels across, so the browser downloads every pixel and then throws most of them away. One oversized photo is often the heaviest thing on a page.
The fix is three steps, and their order matters: resize, compress, then add a placeholder.
How big should an image on a website be?
As wide as the largest box it fills, allowing for sharp screens. A photo shown 800 CSS pixels wide on a laptop is drawn with 1,600 device pixels on a screen with a device pixel ratio of 2, so exporting at twice the display width keeps it crisp there. Beyond that, extra pixels cost bytes and add nothing anyone can see.
Resize image has preset widths of 1280, 1920, 2560 and 3840 pixels. For a full-width photo, 1920 is usually enough and 2560 covers large high-density displays; an image in a column of text needs far less, and a thumbnail only a few hundred pixels.
It keeps the aspect ratio for you, and it reduces large images in halving steps rather than in one jump, which stops fine detail from turning to mush.
Which format and quality should web images use?
WebP, for nearly everything. Every current browser displays it, it keeps transparency, and Google's comparison found lossy WebP files 25 to 34 percent smaller than JPEGs of equal measured quality. In Compress image, set the format to WebP and start at quality 0.75, the tool's default; lower it until you can see a difference at full size, then step back up.
Use PNG only where exact pixels matter, such as a screenshot with small text or a logo with hard edges. Compare image formats encodes your own image every way and plots size against quality, which settles the question for that picture rather than in general.
If you would rather not choose at all, Optimize images for the web measures each image, picks a format and the lowest quality that still looks right, and lists every decision so you can check it.
Why resize before compressing?
Compressing first wastes the work. A lossy encoder spends its effort on pixels that the resize later throws away, and the artifacts it leaves behind are scaled down along with the picture instead of being avoided. Resizing first hands the encoder a smaller, cleaner image, so it reaches the same file size at a higher quality.
Worth knowingKeep the original. Each lossy save loses a little more, so export web copies from the full-size file rather than editing and re-saving a copy that has already been compressed.
What is a placeholder, and do you need one?
A placeholder is a stand-in shown while the real image downloads, so the page does not sit with a blank hole or jump when the picture arrives. The LQIP placeholder generator makes a tiny blurred version of each image as a base64 data URI, with its average color and a CSS gradient, small enough to put straight into your HTML or CSS.
Placeholders matter most for large images near the top of a page. Whatever you use, set each image's width and height attributes, so the browser reserves the right space before a single byte of the picture arrives.
The routine, step by step
- Resize every photo to the largest width it will be shown at, doubled for high-density screens if you want it sharp there. Resize image
- Compress to WebP, starting at quality 0.75 and checking the result at full size. Compress image
- Generate a placeholder for the large images near the top of the page. LQIP placeholder generator