Make more of your photos

Photos for faster websites: prepare the right files

Match photos to page layouts, compare exports and verify delivered images instead of relying on a compression score.

Compress photos

A website can display a small photograph while downloading a much larger source. Changing the visible width in a page editor does not necessarily change the image file transferred to the visitor. To improve image performance, look at both the delivery file and the page that uses it. A compact export helps only if the website actually serves it in the right place and at an appropriate size.

Begin with a simple inventory. Identify the main image near the top, repeated cards, article illustrations and any full-size gallery views. Ask what each picture contributes. Removing a redundant decorative photo can be more useful than carefully compressing it. Keep images that explain something, establish context or support the page’s purpose, then prepare them for their actual placement rather than treating every camera original as a ready-made web asset.

Separate source dimensions from display size

A photograph has pixel dimensions, while a layout assigns it a displayed space. Those are related but not identical. A visitor with a dense screen may benefit from more source pixels than the layout’s apparent width suggests, but sending an enormous original to every device is not a good default. Prepare candidates that fit the intended views and check the result on the devices that matter to your audience.

For a deliberately hypothetical example, a card displayed at 400 CSS pixels wide might be tested with 400-pixel and 800-pixel source candidates. These are illustrative planning dimensions, not a universal prescription or a measured speed improvement. The appropriate choice depends on the actual layout and display density. Compare clarity and transferred bytes rather than automatically multiplying every image by the same factor and assuming the result is optimal.

Let the page choose a useful version

Responsive image markup can offer source candidates instead of sending the same file everywhere. The MDN responsive images guide explains how HTML can describe those alternatives. Your site builder may generate them automatically. Check its output before manually preparing a large set of duplicates. The important question is which version the browser actually requests, not how many alternatives exist in the media library.

Composition also needs attention. A wide desktop banner can leave a face tiny or cut off important context in a narrow mobile frame. Preparing a different crop is a visual decision, separate from reducing bytes. Inspect each intended layout with the real image. Do not solve a composition problem merely by sending more pixels; extra resolution cannot move a subject back into a crop that excludes it.

Choose an export by comparing content

Test a few accepted formats with a representative source. Compare the visible result at the intended display size and inspect difficult areas such as foliage, hair, fine lettering or smooth gradients. Modern formats can be useful, but a smaller file with distracting artefacts is not necessarily the right choice. If a format needs an alternative in your delivery setup, include that in the implementation plan rather than assuming the editor preview proves compatibility.

Keep a clear distinction between photography and graphics. A screenshot full of text has different needs from a landscape, and a transparent logo has different needs from both. Use suitable assets for each purpose. Avoid converting every image in the library to the same photographic preset just for consistency. The web.dev images course provides further background on making these decisions within a complete website workflow.

Treat loading behaviour as part of the page

Compressing a file does not decide when it loads. Images immediately important to the first view need different treatment from a long gallery below the article. Ask your site builder how it handles loading rather than applying one setting to everything. Delaying the main image can make the page feel incomplete even when its file is small. Loading every gallery original immediately can waste transfer on pictures the visitor never reaches.

Reserve the image’s place in the layout so that surrounding content does not jump when it appears. This is a page implementation concern, not a quality-slider setting. Check image proportions and dimensions in the rendered page. A file can be well optimised while the page still moves around because its container has no stable space. Fix the layout cause rather than repeatedly recompressing the same photograph without changing the behaviour.

Verify the delivered files

After publishing through your normal process, inspect a representative mobile and desktop page. Confirm the downloaded image dimensions, format and byte size using browser network tools or the equivalent reports in your site system. Check with a fresh load so that a cached old image does not hide a mistake. The media library’s file size is not proof of what a content delivery service sends after its own transformations.

Keep performance claims tied to measurements. If you have not measured loading before and after a change, describe the file reduction rather than inventing a speed gain. Even a real transfer saving does not translate into an identical improvement for every visitor: connection, caching, page structure and other resources affect the result. Record the conditions of any comparison so a later editor can understand what it actually established.

Keep a maintainable image workflow

Store originals separately from delivery copies and use filenames that describe content without unnecessary personal information. Write alternative text that communicates an informative image’s purpose; a filename or keyword list is not a substitute. Consider captions where they help explain a technical detail. Accessibility and clarity remain important even when your immediate task is reducing the number of bytes on the page.

Before finishing, open the page at its intended sizes and follow the relevant user journey. Check crop, colour, readable detail and layout stability. Keep the chosen export approach documented so future uploads do not silently reintroduce oversized files. A useful performance workflow produces images that are quick enough for their role, clear enough for their message and straightforward for the next person maintaining the website to reproduce.

A measured example

Our own test illustration combines colors, edges and fine noise. It is not a camera photo. The size of your own photo depends on its content.

Original illustration with gradients and edges
Before: 1200 × 800 px · 312 KB (312324 bytes)
Smaller illustration for detail comparison
After: 800 × 533 px · 45 KB (45336 bytes)

JPEG, quality 90 → 65, measured with the documented sharp example generator: 85% smaller. Measurements and method