Optimize web images by choosing an appropriate format, generating useful size variants and letting the browser request the right variant for its layout. Reserve the image's space before it loads, delay images that are genuinely offscreen and load the likely LCP image promptly. Compression is one part of the job: an unnecessarily large variant or a delayed request can waste the benefit of a better encoder.
Start with the image the browser actually downloads
Before changing export settings, inspect a representative page in the browser's Network panel. Reload it at a mobile viewport and again at a desktop viewport. Record the requested image URL, transfer size, displayed dimensions, intrinsic dimensions and request start time. A small thumbnail can be serving the original upload even when the CMS has generated suitable alternatives.
Find the image that contributes to Largest Contentful Paint on each layout. It might be a hero photograph on one viewport and a product image on another. The LCP optimization guide explains how to separate discovery delay, transfer time and rendering delay. That distinction prevents you from treating every slow image as a compression problem.
Keep originals outside the delivery workflow so you can regenerate variants without repeatedly compressing an already compressed file. Use one representative sample from each content type: photography, screenshots, illustrations, transparent assets and images with text. A preset that looks acceptable on a landscape can visibly damage a product label or a detailed diagram.
Check whether an image is editorial content or decoration. Meaningful images need alternative text that communicates their purpose; decorative images can use an empty alternative. Performance changes must preserve that distinction. Avoid replacing a semantic image with a CSS background merely to make an audit look different. Background delivery can be appropriate for decoration, but it changes discovery and accessibility considerations. Also check linked images: the accessible name should explain the destination when the image is the link's only content. These checks belong in the same template review as size and loading behavior.
Establish the baseline before applying a sitewide conversion. Save screenshots for visual comparison and note which image requests occur before the main content appears. This is an inspection procedure, not a benchmark: no universal percentage saving follows from switching extensions.
Match the format to the content
Choose by visual content and delivery requirements rather than assuming one format always wins. AVIF and WebP are useful modern options, but their result depends on the image, encoder, settings and supported browser population. JPEG and PNG remain appropriate in some workflows, and SVG solves a different problem from raster compression.
Use this table as a starting decision, then compare actual outputs.
| Format | Useful starting point | What to inspect |
|---|---|---|
| AVIF | Photographs and complex raster images where lossy compression is acceptable | Fine detail, gradients, encoding time and target browser support |
| WebP | Photographs, illustrations and assets requiring lossy or lossless options | Edges, transparency and whether it beats the alternatives at acceptable quality |
| JPEG | Photographic delivery and compatibility fallback | Blocking, ringing and visible damage after repeated encoding |
| PNG | Lossless raster content, some screenshots and transparency workflows | Whether a smaller lossless or visually acceptable modern variant exists |
| SVG | Icons, logos and geometric illustrations authored as vectors | Path complexity, embedded raster data and safe handling of uploaded files |
A photograph saved inside an SVG wrapper does not become a compact vector image. Likewise, converting a huge screenshot to a lossless format does not solve oversizing. Inspect the asset itself before deciding that its extension is the main problem.
Quality numbers are encoder-specific. A value of 70 in one encoder is not an objective equivalent of 70 in another, and there is no setting that guarantees invisible loss for every image. Compare at the intended display size and at higher density. Look closely at hair, text, edges, flat gradients and small product details. Choose a defensible visual threshold before optimizing for the smallest byte count.
Remove unnecessary metadata from public derivatives when appropriate, while preserving required attribution and color handling. Keep the original color-managed source. Verify the delivered image in target browsers after processing, because an export that looks correct in an editor may not match your production pipeline.
Let srcset describe the available widths
An image's CSS width is not necessarily the number of physical pixels required for a sharp result. Device pixel ratio matters. A browser displaying a 600 CSS-pixel image on a higher-density screen may reasonably select a wider asset. Do not impose a rule that intrinsic width must never exceed displayed CSS width.
With width descriptors, srcset tells the browser which files exist and the actual pixel width of each. sizes describes the image's expected display width under the relevant media conditions. The browser combines that information with device and browsing conditions to choose a candidate. It retains the final decision; the markup is not a command to download a particular file at every breakpoint.
This example matches a content area with 16-pixel side margins below 992 pixels and a maximum image width of 960 pixels above that point. The referenced variants must exist and have the declared widths.
<style>
.article-image {
display: block;
width: min(100%, 960px);
height: auto;
}
.article-content {
width: calc(100% - 32px);
max-width: 960px;
margin-inline: auto;
}
</style>
<div class="article-content">
<img class="article-image"
src="/images/coast-960.webp"
srcset="/images/coast-480.webp 480w,
/images/coast-960.webp 960w,
/images/coast-1920.webp 1920w"
sizes="(max-width: 991px) calc(100vw - 32px), 960px"
width="1920" height="1080"
alt="Rocky coastline beside a calm blue sea">
</div>The exact breakpoint in the sizes attribute follows the container geometry: at 992 pixels of viewport width, subtracting 32 pixels leaves 960 pixels. Keep the CSS and the declared sizes aligned when the design changes. An inaccurate sizes="100vw" on a narrow card can make the browser choose a larger file than necessary.
Inspect currentSrc in the browser to see which candidate was chosen. Test after a fresh navigation because browsers may reuse a larger cached candidate rather than fetch a smaller one after resizing. Compare at realistic device pixel ratios, not just by dragging a desktop window.
Use picture for format choices and art direction
The picture element adds explicit source selection rules. It is useful for offering formats and for art direction, where a mobile crop changes composition rather than simply reducing pixel dimensions. The required img remains the element carrying alternative text and providing a fallback source.
This example offers two modern encodings and a JPEG fallback for the same composition. All variants have the same aspect ratio.
<picture>
<source type="image/avif"
srcset="/images/garden-800.avif 800w,
/images/garden-1600.avif 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<source type="image/webp"
srcset="/images/garden-800.webp 800w,
/images/garden-1600.webp 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<img src="/images/garden-800.jpg"
srcset="/images/garden-800.jpg 800w,
/images/garden-1600.jpg 1600w"
sizes="(max-width: 800px) 100vw, 800px"
width="1600" height="1000"
style="display:block;width:min(100%,800px);height:auto"
alt="Raised garden beds arranged along a stone path">
</picture>The browser evaluates the sources in order and uses the first matching supported option. Do not include a format solely to lengthen the markup; the operational cost of generating, storing and invalidating variants should be justified by your actual assets and audience.
For art direction, add a media condition to a source and supply the appropriate crop. If the crop changes aspect ratio, reserve the matching ratio at that breakpoint using suitable source dimensions or CSS. A desktop ratio applied to a portrait mobile crop can still create movement or unwanted empty space. Review the subject's position at every crop, especially when text or a product detail must remain visible.
Reserve space and keep the LCP request early
Explicit width and height attributes allow the browser to derive an aspect ratio before the image is available. Responsive CSS can still scale the image. The attributes are not a requirement to display it at those physical dimensions; they give layout useful information before decoding finishes.
Missing dimensions can let content below the image move when it arrives. The layout shift guide covers that failure in more detail. Also inspect containers, carousels and placeholders: a correctly sized img can still shift if its parent changes height after JavaScript initializes.
Use loading="lazy" for images sufficiently below the initial viewport. Browser-native lazy loading schedules requests according to browser heuristics, so it is not an exact “download only when visible” switch. The browser may fetch an image before it enters the viewport to avoid showing an empty space during scrolling.
This below-the-fold example reserves its space and permits asynchronous decoding.
<img src="/images/workshop-960.webp"
width="960" height="640"
loading="lazy" decoding="async"
style="max-width:100%;height:auto"
alt="Hand tools organized on a workshop wall">Do not lazy-load the likely LCP image. Keep its real URL discoverable in the initial HTML where possible, rather than placing it only in a JavaScript data attribute. fetchpriority="high" can signal that an important image deserves earlier scheduling, but it does not repair a resource that the browser cannot discover yet.
This hero example requests eager loading and raises fetch priority.
<img src="/images/hero-1600.webp"
srcset="/images/hero-800.webp 800w,
/images/hero-1600.webp 1600w"
sizes="100vw"
width="1600" height="900"
loading="eager" fetchpriority="high"
style="display:block;width:100%;height:auto"
alt="Sunlight falling across a quiet mountain valley">decoding="async" is a hint about how decoding is coordinated with other presentation work, not a compression setting or a guarantee of faster LCP. Choose it with the visual context in mind and verify the trace. Avoid declaring every image high priority: competing requests still share bandwidth and processing resources.
Check the generated HTML
A CMS, theme and optimization plugin can each alter loading attributes. Inspect the final response and the selected image request, not only the template you edited.
Make the image pipeline repeatable
An image CDN can generate resized, cropped or re-encoded derivatives and deliver them through distributed caches. Its transformations are useful only when templates request appropriate variants. Serving the original upload through a geographically closer endpoint does not automatically fix a responsive sizing error.
Define a small, deliberate family of widths that matches recurring layouts. Avoid generating every possible integer width: excessive variants complicate caching, processing and storage. Include format and transformation parameters in the delivery system's cache identity, and verify that a format-negotiated response is cached correctly for different supported clients.
Keep fallback behavior clear if a transformation fails. Test new uploads, existing images, transparent files, unusual aspect ratios and protected media. Do not send private originals to a public transformation URL simply because the public image workflow uses one. Use the provider's documented controls for origin restrictions and signed URLs where relevant.
CMS automation has two responsibilities: generating files and generating accurate markup. Check both. A media library may create several widths while a custom template still outputs a single original URL. Conversely, a template may reference variants that were not regenerated after a setting change. The result can be a hidden fallback, a broken image or an oversized response.
For WordPress, review the Core Web Vitals platform guide before adding another image plugin. For Shopify, follow the storefront speed guide and verify theme-generated image tags. Use one coherent transformation strategy so that two systems do not repeatedly recompress the same derivative.
Audit existing pages in a deliberate order
Make the review reproducible for the next editor or developer. Record the template, viewport, device pixel ratio, image URL and processing settings next to the visual comparison. Include an example with a long caption and one without a caption, because surrounding layout can change the image slot. Assign responsibility for the source upload, derivative generation and template output so a later failure has an identifiable owner. When a design changes the slot width, update that record and review the generated markup again. Keep the approved original and derivative pair as a visual reference for future preset changes. This turns a one-off cleanup into a workflow that can detect regressions without relying on someone remembering how the page used to look.
Start with a representative high-traffic template and its LCP image. Fix a missing real source, accidental lazy loading or inaccurate sizing before spending time adjusting marginal compression differences. Then examine repeated thumbnails and offscreen galleries, where a template-level change may affect many pages.
Compare the original and proposed derivative in the image savings calculator, using actual file sizes rather than a guessed saving percentage. That calculation describes bytes, not a guaranteed time improvement. Network conditions, caching, decoding and contention determine how those bytes affect a visit.
Check the page at narrow and wide viewports, with an empty cache and a repeat visit. Scroll to the bottom so lazy-loaded images are included in visual inspection. Verify alternative text, correct crops, preserved transparency and stable layout. If the new image is smaller but arrives later, revisit request discovery and priority.
Keep the workflow in the site's page speed optimization maintenance process: preserve originals, generate derivatives, emit accurate markup and test the selected resources after template changes. The next useful deliverable is a verified image pipeline for one template, with visual quality and request behavior documented well enough to repeat across the site.
