Image Optimization

As web pages started carrying more photographs, the weight of a page shifted from text to images. The trouble is that the person who makes an image and the person who ships it are usually two different people. A designer exports a master file 4,000 pixels on its long edge so it can also be used in print, that file goes up on the site untouched, and the browser then draws it into a slot 300 pixels wide. The browser downloads all 4,000 pixels first and shrinks them afterward. Most of the time spent downloading is thrown away.

None of this shows up in the office. On a company wired network a 2 MB photo appears instantly. On a phone riding a mobile connection through a subway tunnel, the same page is a white screen for eight seconds. That's why the complaint often arrives from the people buying ads rather than from engineering — the clicks were definitely paid for, but only half of them register as visits.

Work on web performance starts with measurement, and once you measure, images are frequently named as the heaviest single piece. Largest Contentful Paint (LCP) records how long it takes for the biggest block on screen to render, and that block is often the photo sitting at the top of the page. Image optimization is the technique aimed at exactly that spot.

Find the heavy files, resize them to the dimensions they're displayed at, switch formats, and then make the whole thing run without a person involved.

1. Find out what's heavy. Open the network tab in your browser's developer tools and sort by transfer size — the top ten entries tell you immediately how much of the page is images. If a 3 MB page is carrying 2.4 MB in four photos, nothing else on the list is worth touching.
2. Resize to the displayed dimensions. An image that lands in a 300-pixel-wide slot needs to be 600 pixels at most. The doubling is there so it doesn't look soft on high-density screens; 4,000 pixels is not used by any display anywhere.
3. Pick a format. Exporting the same photo as WebP instead of JPEG cuts roughly 30 percent of the file size with no visible difference, and AVIF cuts more. Logos and icons — drawings made of lines and flat areas — belong in SVG rather than a photo format.
4. Lower the quality setting. Most tools take a value between 0 and 100, and moving a photo saved at 100 down to somewhere between 75 and 80 cuts the file roughly in half while being hard to tell apart by eye.
5. Defer the rest. Images below the first screen can wait until scrolling reaches them, which is what lazy loading does. Write the width and height into the markup first, though, or a photo arriving late will shove the sentence someone was reading down the page. Cumulative Layout Shift (CLS), which measures how much the page jumps around, gets worse from exactly this mistake.
6. Take it out of human hands. Have the build step or a dedicated image server accept the uploaded original and generate the sizes and formats automatically.

Reach for this first on any screen where images make up more than half the page weight — landing pages, product listings, case study pages, anything where the photography is the point.

There are screens where it changes nothing, and they're easy to spot. An admin panel or a settings page built out of text and tables feels the same no matter how much you shrink its images. On those, the bigger share of the work belongs to compression, which makes the transmitted data smaller, and caching, which stores a result once and hands the same one back on the next request.

A slow first response from the server is the other limit. Time to First Byte (TTFB) measures how long it takes for the first byte to come back after a request goes out, and if that number is 1.5 seconds, no amount of image work removes those 1.5 seconds. When the numbers refuse to move after an image pass, look there.

Dropping the quality setting needs agreement. There's a point where the texture of a product shot or a brand color starts to shift, and where that line sits differs by team. If an engineer lowers the value with only file size in mind, a designer finds it later and reverts it. Settle on a baseline for format and quality once, together, and apply it automatically from then on.

"The thing blowing up LCP is the hero image. The original is 2.4 megabytes."

One photo at the top of the first screen is eating most of the load time, so start there.

"Converting this to WebP and resizing it should get us half the way on its own."

Two easy steps — format conversion and resizing — land close enough to the target.

"Let's put image optimization in the build. If we do it by hand it'll be back to normal next month."

An argument for automating it rather than treating it as a one-off cleanup.

This came up at Pagedeck when the new pricing page went live. Noa uploaded eight screenshots straight from the originals and the page came to 6 MB. Ravi noticed on the first day of the ad campaign that visits were running unusually low against clicks and asked about it, and Theo, measuring on a simulated mobile connection, found the first screen took nine seconds.

All Theo did was resize to 1,600 pixels, convert to WebP, and defer the bottom four images. The page went from 6 MB to 900 KB and the first screen came in around two seconds. What the team decided in that meeting was to run the same work automatically at upload time, because a pipeline rather than someone's memory is what keeps the next page from repeating it.

The most common misreading is that this is a technique for degrading quality. Cutting file size sounds like giving something up, so the assumption is natural. In practice most of the savings come from parts the user can never see. Going from 4,000 pixels to 600 changes nothing about what renders in a 300-pixel slot, and changing format just stores the same picture more efficiently. Leave the misunderstanding in place and uploading originals hardens into policy, while mobile users keep downloading pixels that will never be used.

Treating it as a one-time cleanup is the other one. After a performance sprint clears out the images, the numbers jump and it feels finished. But images keep arriving every week — feature banners, blog illustrations, customer logos — and each one goes in at full size. Without automation in place, measuring again three months later shows the page back where it started.