Web Images: Formats, Performance, and Delivery
Last reviewed:
Fast web images come from a complete delivery system: an appropriate source, sensible dimensions, efficient encoding, responsive selection, correct loading priority, caching, accessibility, and visual review. Changing the extension solves only one part.
Choose format by asset type
| Asset | Strong candidates | Why |
|---|---|---|
| Photograph | JPEG, WebP, AVIF | Efficient photographic encoding with different support and workflow tradeoffs |
| Screenshot or UI capture | PNG, lossless WebP | Protects text and hard edges |
| Logo or icon | SVG when trusted and appropriate; PNG fallback | Scalability or dependable raster alpha |
| Transparent product cutout | PNG, WebP, AVIF | Alpha support; test edge quality and application support |
| Animation | GIF, animated WebP, animated AVIF where supported | Frame support varies across formats and pipelines |
Use Best Image Format for Websites for a shorter decision guide and AVIF vs WebP for a focused comparison.
Serve appropriate dimensions
A 4000-pixel-wide photo displayed at 400 pixels can waste transfer and decoding work. Responsive images let a browser choose among prepared width candidates based on layout and device conditions. The srcset attribute describes candidates, while sizes describes the expected rendered width.
Do not create dozens of variants without evidence. Each variant adds storage, generation, cache, markup, and maintenance complexity. The web.dev image performance guide emphasizes both fewer transferred bytes and appropriately sized images.
Compression and visible quality
A format comparison is meaningless without real encoder output. Test difficult photographs, gradients, small text, transparency, and fine edges. Compare at final size and 100% view. Select the smallest candidate that passes the visual and compatibility requirements—not an arbitrary quality number.
Loading priority matters
The image most likely to become Largest Contentful Paint should be discoverable promptly and should not be lazily loaded merely because other images are. Below-the-fold images often benefit from lazy loading. Width and height attributes or an aspect ratio help reserve space and reduce layout shift.
Format savings cannot compensate for a hero image discovered late through script or CSS, an oversized source, or an unnecessary carousel of heavy assets.
Responsive and fallback delivery
The picture element can offer sources by format or media condition, with an img fallback. Use it when the variants provide real value. Keep alternate text on the img element and describe the image according to its purpose.
The MDN image format guide documents common web-format capabilities and fallback considerations. Compatibility changes, so review current browser and application requirements.
Intrinsic size, layout size, and source size
Intrinsic dimensions belong to the image file. Layout dimensions are the CSS size on the page. Source selection determines which file the browser downloads. A responsive setup works when these layers agree: the browser understands the expected layout width and has sensible candidates from which to choose.
Supplying width and height attributes can establish an aspect ratio before the image loads, reducing layout movement. CSS can still make the image responsive. Avoid distorting the aspect ratio or relying on a huge source for every viewport.
The LCP image deserves special treatment
The primary hero or content image can become Largest Contentful Paint. It should be discoverable in initial HTML when practical, have an appropriate priority, and avoid lazy loading. A small but late-discovered image can still produce a slow LCP.
Do not preload every image. Excessive high-priority requests compete with styles, fonts, scripts, and the genuinely important asset. Measure the real page and confirm which element becomes LCP.
Lazy loading and below-the-fold content
Native lazy loading can defer images that are not initially visible. It reduces early network work when used selectively. Images near the fold may need careful thresholds because a user can reach them quickly. Placeholder choices should not add more bytes or layout instability than they save.
Caching and content updates
Versioned image URLs can use long-lived caching because a changed asset receives a new URL. HTML should reference the current version. Reusing the same URL for different bytes can leave users with stale imagery, while disabling caching wastes repeat-visit performance.
Choose a naming and deployment strategy that works with the site’s cache and CDN rather than adding random query strings without understanding the cache key.
Accessibility is part of delivery quality
Informative images need text alternatives that communicate their purpose. Decorative images should not create noise for assistive technology. Images of text should be avoided when real text can provide better scaling, translation, search, selection, and contrast.
Format optimization cannot compensate for a missing alternative, unreadable embedded text, or animation that ignores reduced-motion needs.
Art direction versus resolution switching
Resolution switching serves the same composition at different dimensions or densities. Art direction provides a different crop or composition for a layout. The picture element can support both, but every variant adds editorial and technical maintenance. Use art direction when the subject would otherwise be unclear, not merely because the feature exists.
How to evaluate format savings honestly
- Use the same source and final dimensions.
- Document encoder and settings.
- Test a representative corpus, not one image.
- Compare visible output under target viewing conditions.
- Include fallback and markup complexity in the implementation decision.
- Measure page behavior, not only individual file bytes.
This approach avoids universal percentage claims that cannot be reproduced across content sets.
A production web-image workflow
- Start from a strong master.
- Classify the asset: photo, graphic, screenshot, logo, icon, or animation.
- Define layout widths and device needs.
- Choose candidate formats supported by the audience and pipeline.
- Create only useful dimension variants.
- Encode and visually compare representative assets.
- Implement responsive markup and an appropriate fallback.
- Set intrinsic dimensions or aspect ratio.
- Assign loading priority based on page position and importance.
- Measure in the actual page, not a file-size table alone.
Using ForgeConvert in the workflow
ForgeConvert can produce supported format derivatives such as JPG to WebP, JPG to AVIF, PNG to WebP, or SVG to PNG. It currently does not resize images, generate responsive variants, edit content, or guarantee a smaller file. Prepare dimensions separately and verify outputs in the target browser.
Web image performance checklist
- Correct content-appropriate format.
- Appropriate intrinsic dimensions.
- Responsive candidates only where useful.
- Visible quality reviewed on representative assets.
- Alpha and animation verified.
- Hero/LCP image discovered early.
- Below-fold images loaded appropriately.
- Width and height or aspect ratio supplied.
- Long-lived caching for versioned assets.
- Descriptive alt text when the image conveys meaning.
Frequently asked questions
Should every website use AVIF?
No. AVIF can be efficient, but encoding cost, support, workflow complexity, visual results, and fallback strategy matter. Test it against WebP and JPEG for the actual asset set.
Is SVG always best for logos?
SVG is excellent for suitable trusted vector artwork, but a raster logo cannot be made truly vector by changing its extension. Some destinations also require PNG or ICO.
Does lazy loading improve every image?
No. Lazy-loading the primary above-the-fold image can delay it. Use loading behavior according to the image’s role.
Will a smaller file always load faster?
Transfer size matters, but discovery timing, connection, caching, decoding, dimensions, and request count also contribute.