Web Image Optimization: Eight Practical Steps for Speed and SEO

Why image bytes can affect LCP

Largest Contentful Paint (LCP) measures when the largest visible content element is rendered. On many pages, that element is a hero, product, or article image. Its bytes must be downloaded and decoded before it appears. A slow image can therefore delay LCP and make the page feel incomplete, especially on mobile connections.

Compression helps, but file format, pixel dimensions, loading priority, and how clearly the image is described all matter. These eight steps form a practical pre-publish review.

1. Pick a format that matches the image

A photo saved as PNG can be much larger than a suitable JPEG or WebP. A transparent icon saved as JPEG can lose its transparency and gain fuzzy colored edges. Format choice comes before tuning an encoder.

Start with WebP for a web photo when your workflow supports it, retain JPEG where compatibility matters, and choose PNG or SVG for graphics that need precise edges. Use Convert on the image tool when you intend to change format; Compress preserves the current one.

2. Compress enough, but measure the visual result

Saving a JPEG at quality 95 may barely change its size. A setting around 75–85 is a useful test for many web photos, but a fixed value cannot account for texture, noise, source quality, or display size. JPEG and WebP use quality controls; palette PNG and GIF use color count. Compare actual bytes and critical visual details after each change.

For a batch, test several representative images first. One setting that suits a clean studio background may damage a dense forest scene.

3. Export at the displayed dimensions

CSS can show a 3000-pixel-wide image at 800 pixels, but it cannot save the download of the larger file. Determine the image's maximum rendered width. Export at about 1.5–2 times that width for high-density displays when useful, instead of delivering the full camera original to every visitor.

Resize before compressing. A smaller image often retains better visible quality per byte than a huge image saved at a very low quality.

4. Supply responsive image candidates

Mobile and desktop layouts may need different widths. srcset lists candidate resources, while sizes tells the browser how wide the image will appear under each layout. Without an accurate sizes value, a browser may choose an unnecessarily large candidate. A picture element can also serve WebP with a JPEG fallback where needed.

Test the actual network request at narrow and wide viewports. Merely adding srcset is not enough if the declared layout widths are wrong.

5. Prioritize visible images and defer the rest

Do not lazy-load a likely LCP image. Let the browser request it early, and consider an appropriate high-priority hint when it is genuinely the most important image. Images below the fold can use native lazy loading. Give every image explicit dimensions or a stable aspect ratio to prevent layout jumps while it loads.

6. Use descriptive filenames

DSC_04821.jpg tells a reader or search engine little. A short descriptive name such as red-running-shoes-side.jpg identifies the subject and makes the URL more understandable. Use ordinary words, avoid keyword lists, and do not make filenames unreasonably long.

7. Write alt text for people first

Alt text substitutes for an image when it is unavailable and is announced by screen readers. Describe the relevant content, not a string of search terms. A decorative image can have empty alt text. A product image can identify the product, color, and angle; an image-only link should explain the link's purpose.

Good alt text and nearby captions also give search engines context, but accessibility is the primary writing test: would someone understand what information the image contributed without seeing it?

8. Review EXIF and other metadata

Camera files can contain device details, timestamps, embedded previews, and GPS coordinates. These bytes are often irrelevant to a web page, and location can be sensitive. Verify that the published file has the intended metadata state and orientation. If tobeimage returns the original file because recompression would make it larger, the original metadata remains; do not assume every download has been stripped.

Pre-publish checklist

• The format suits the content and the receiving browser or platform.
• Quality or palette settings have been tested against visible details.
• Pixel dimensions match the actual layout, not the camera original.
• srcset and sizes deliver an appropriate file to mobile and desktop.
• The first-screen image is requested promptly; later images can load lazily.
• Every image has dimensions or a stable aspect ratio.
• Filenames and alt text explain the subject without keyword stuffing.
• Unneeded EXIF/GPS data is absent from the actual published file.
• The total first-screen image weight is acceptable, not just each file individually.

Compression reduces bytes per image, but overall speed also depends on image count, timing, and delivery. Use the complete format and compression tutorial for the controls or the target-size guide when a single image has a strict byte budget.