Images

Last updated:

Practical patterns for purposeful images, alt text, sizing, formats, and delivery that stays fast and accessible.

01 — Foundation

Images shape the experience

Images affect performance, accessibility, layout stability, and trust — immediately.

Good images support understanding. Bad images create slow pages, layout shift, accessibility gaps, and decorative noise disguised as design.

This pattern defines practical expectations for accessible, performant, maintainable image usage — real delivery, not decorative asset chaos.

02 — Purpose

Every image should earn its place

If an image adds nothing meaningful, question whether it should exist — especially at 4MB.

  • explain, demonstrate, or build trust — not fill empty space
  • critical meaning should not live only inside imagery
  • important text belongs in real HTML, not baked into JPEGs

03 — Alt text

Alt text and decorative images

Describe purpose in context — not everything visible in the file.

Meaningful images

Avoid “image of” and “picture showing”. Describe what matters for the content around it.

Too vague

'Image of woman'

More useful

'Woman using a screen reader on a laptop'

Decorative images

Use an empty alt so assistive technology skips purely decorative media:

<img src="/images/divider.svg" alt="">

Functional images

When an image is a control, the accessible name should describe the action — “Search”, not “Magnifying glass”.

04 — Delivery

Sizing, formats, and responsive delivery

Export for how the image is shown — compression usually matters more than extra markup.

Default to one well-sized file with dimensions set in markup. Addpicture when mobile needs a different crop, orsrcset when smaller variants save meaningful bytes. With lazy loading, sizes="auto" can help in supporting browsers — it does not remove the need for srcset when you use width descriptors.

<img
    src="/images/product-800.webp"
    width="800"
    height="600"
    alt="Front view of the insulated water bottle"
    loading="lazy"
    decoding="async"
>

Choose formats intentionally

  • SVG for icons, logos, and simple vector graphics — optimise exports
  • WebP or AVIF for photos where support allows; PNG when transparency matters
  • compress aggressively — most users need pages that load, not raw hero files

05 — Loading

Lazy loading and priority

Load critical imagery first. Defer the rest deliberately.

  • lazy-load below-the-fold galleries and secondary media
  • do not lazy-load above-the-fold heroes users see immediately
  • use fetchpriority="high" sparingly for truly critical images
<img
    src="/images/hero.webp"
    width="1200"
    height="675"
    alt=""
    fetchpriority="high"
    decoding="async"
>

If everything is high priority, nothing is.

06 — UI

Icons, galleries, and captions

Support understanding — do not make users fight the interface or guess symbols.

  • pair icons with text labels for important actions
  • galleries and carousels: keyboard access, no autoplay chaos, visible controls
  • lightboxes: Escape, focus management, and no traps
  • captions when context matters — education, journalism, diagrams

07 — Performance

Performance and resilience

Image work usually starts at the asset layer — not after launch.

  • review dimensions, compression, duplicates, and delivery on every page
  • faster images help users on slow networks and older devices — performance is accessibility
  • content should still make sense if images fail to load

Anti-patterns to avoid

  • giant uncompressed hero files
  • missing alt text or novels of detail for decorative graphics
  • icon-only interfaces and carousels that autoplay forever

08 — Review

Before you approve

A short checklist for images in code review.

  • every image serves a purpose
  • alt text is appropriate; decorative images use alt=""
  • assets sized and compressed for how they display
  • width and height set; lazy loading used sensibly
  • responsive markup only when it genuinely helps
  • users would still understand the page without the images

When in doubt, ask: Does this improve understanding, or merely decorate the interface? If the answer is “decorate”, make sure the cost is justified.