Why are photos usually the heaviest thing on a page?
A photo is a grid of pixels, and each pixel needs a few bytes of colour information even after compression. Text, CSS and even most scripts are tiny next to that. On the bird club page the HTML is under 1 KB and the stylesheet is 10 KB, while the heron photo is 1,150 KB. That one file is more than 98 percent of everything the phone downloads.
The Waterfall view makes the cost visible. The heron's bar starts early and runs for almost six seconds on the pretend 4G connection, which moves about 200 KB each second. The largest paint lands at about 6.8 seconds, because the photo is the biggest thing on the first screen and nothing can paint it until the last byte arrives.
Two settings decide how heavy a photo file is: how many pixels it has, and how hard the encoder squeezes them. Pixels matter most, so start there.
How many pixels does an image actually need?
Work it out from the space the image fills on screen. On this phone the page column is 360 CSS pixels wide minus 16 pixels of margin on each side, so the heron shows at about 328 CSS pixels across.
Modern phones have screens with two or three real pixels for every CSS pixel. This is the device pixel ratio, and the simulated phone uses 2. To look sharp, the image needs about 328 × 2 = 656 real pixels across. The 720 pixel copy covers that with a little to spare.
The original has 2,400 pixels across and 1,600 down, which is 3.84 million pixels. The 720 by 480 copy has about 0.35 million. The phone was downloading eleven times more pixels than it could show, then throwing them away while scaling the picture down.
column width: 360 - 16 - 16 = 328 CSS px
2x screen: 328 x 2 = 656 real px
next size up: heron-720.jpg (720 x 480)
Is a 3x phone a reason to send even more pixels?
Some phones have a ratio of 3, and on those a 720 pixel image is slightly under the ideal 984. In practice the difference is very hard to see at arm's length, while the file for 3x would be roughly twice as heavy. Many teams cap phone images at about 2x for that reason.
The opposite mistake is common too. The 360 pixel copy is only 26 KB, and on an old 1x screen it would be fine. On a 2x screen every image pixel is stretched over four screen pixels, and fine feathers turn soft. The task check rejects it for that reason: lighter is better only once the image is sharp enough.
When one page has to serve both phones and wide desktop screens, a single file can't be right for both. The responsive images lesson shows srcset and sizes, which let each device pick its own size from a list.
What does the quality setting change?
JPEG, WebP and AVIF are lossy formats. When you export, the quality setting (usually 0 to 100) tells the encoder how much fine detail it may throw away. Lower numbers give smaller files and, eventually, visible blockiness and smeared edges.
The relationship is far from straight. On the heron, quality 95 gives 210 KB and quality 80 gives 78 KB at the same 720 pixels. Going from 80 to 95 nearly triples the file, and on a phone screen the two look the same. Going from 80 down to 50 would save less and start to show, especially in smooth areas like water and sky.
For photos, a quality between about 70 and 85 is a sensible starting point. Check by eye at the size the image will be shown, on a real phone if you can, and lower it until you start to see damage, then step back up a little.
Where do these settings come from in a real workflow?
Most image editors have an export or save-for-web dialog with a width field and a quality slider. Set the width first, then the quality, and watch the file size the dialog reports. Command-line tools and build steps can do the same thing for a whole folder at once, which is how larger sites keep every upload in check.
Watch for exports that copy extra data along with the picture. Camera files often carry location, camera model and a full colour profile. Stripping that metadata saves a few kilobytes and, for location data, protects the person who took the photo.
Keep the original somewhere safe. You will want it again when a design changes or a new format comes along, and re-exporting from a large original always looks better than shrinking an already shrunk copy.
How do width and height fit in once the file changes?
The width and height attributes should describe the file's real pixels, or at least its shape. When you switch from the 2,400 by 1,600 original to the 720 by 480 copy, update both numbers. The shape is the same 3:2 here, so the layout would survive if you forgot, but a mismatch is confusing to read and breaks as soon as the shape differs.
The CSS rule img{max-width:100%;height:auto} then scales the image to the column. The attributes give the browser the ratio before any bytes arrive, so it keeps the right space and nothing jumps. A later lesson covers that in detail.
<img src="/img/heron-720.jpg"
alt="A grey heron standing in shallow water"
width="720" height="480">How do you check image weight on a real site?
In Chrome DevTools, open the Network panel, filter to Img and reload. The Size column shows what each image cost to download. Hover an image in the Elements panel and DevTools shows two sizes: the rendered size in CSS pixels and the intrinsic size of the file. A file several times wider than twice its rendered size is a clear target.
Lighthouse reports the same thing under an audit about properly sizing images, and lists how many kilobytes each one could save. PageSpeed Insights runs Lighthouse for you and adds real visitor data from the Chrome UX Report when the site has enough traffic. This simulator's Vitals view raises an oversized warning when an image is more than one and a half times wider than the phone needs at 2x.
What do AI tools get wrong about image weight?
Code written by AI assistants usually points at whatever image file it was given and never asks how big it is. Ask for a gallery page and you get <img> tags for full camera files with a CSS width on them, which looks right on a laptop and costs a phone several megabytes.
AI speed advice also tends to jump straight to formats or lazy loading. Both help, and both have their own lessons, but neither fixes a 2,400 pixel file shown at 328 pixels. Check the pixel size and the quality setting first. They usually give the biggest saving of anything on the page, and they work in every browser.
Field notes
- Photos are usually the heaviest files on a page.
- Work out the pixels needed from the display width times the screen's pixel ratio.
- A quality around 80 is often much smaller than 95 with little visible change.
- Update
widthandheightto match the new file's real pixels.
Easy to get wrong
CSS only changes how big the image is drawn. The phone still downloads every pixel of the original. Resize the file itself.
The top of the quality scale costs a lot of bytes for detail nobody can see on a phone. The egret file shrank from 330 KB to 74 KB with no visible change.
A 360 pixel image stretched over 656 screen pixels looks soft. Size for the space times the device pixel ratio, then stop.
Questions people ask
Should I use PNG for photos?
No. PNG is lossless, so a photo saved as PNG is often five to ten times larger than a good JPEG. Keep PNG for screenshots, diagrams and graphics with flat colour or sharp text, and use JPEG, WebP or AVIF for photos.
What about logos and icons?
Use SVG where you can. It is drawn from shapes, stays sharp at any size and is usually a few kilobytes. Make sure the server compresses it, which the compression lesson covers.
Does the simulator model quality settings?
Only through the file sizes in each lesson. It doesn't look at the pixels, so it can't tell you when quality is too low. Your eyes, on a real phone, are the check for that.
Is there a target size for a hero photo?
For a full-width phone photo, under about 100 KB in JPEG is a reasonable aim, and less in WebP or AVIF. Treat that as a starting point and let your own waterfall and largest paint time decide.