Bygger på:Konstant och kontextuellt↗ Foundation

Images — Format, Ratios, Sizes & Handling — Aleris Baseline

Status

Design system foundation. Covers image format strategy, standard aspect ratios, responsive sizing, compression, and delivery. Ready for implementation.


Format Strategy

The Stack: AVIF → WebP → JPEG

AVIF is the primary format. WebP is the fallback. JPEG is the legacy safety net. Serve all three via the <picture> element and let the browser choose the best it supports.

<picture>
  <source srcset="image.avif" type="image/avif" />
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="..." width="800" height="450" loading="lazy" decoding="async" />
</picture>

Why this order: AVIF produces files ~50% smaller than JPEG and ~20-30% smaller than WebP at comparable quality. WebP decodes faster in the browser. As of March 2026, WebP has ~97% global browser coverage, AVIF ~93%. The gap is mostly legacy Android and older Safari. For Aleris's audience (Scandinavian, recent devices), AVIF coverage is effectively universal.

Format by Content Type

Content Primary Notes
Photography (patients, staff, clinics) AVIF Best compression for complex images with gradients and skin tones
UI elements, icons, logos SVG Vector, infinitely scalable, tiny file size
Screenshots, diagrams WebP or AVIF Either works; WebP if encoding speed matters
Illustrations with flat colour WebP AVIF's compression advantage is smaller for low-entropy images
Animated content MP4/WebM video Not animated GIF, not animated WebP. Video is dramatically smaller

When to Use PNG

Rarely. PNG is lossless and large. Use it only when pixel-perfect reproduction is legally or clinically required (e.g., a medical image where lossy compression could be argued to alter diagnostic information). For everything else, AVIF/WebP with high quality settings (90%+) is visually lossless at a fraction of the file size.


Aspect Ratios

Standard Ratios

Four ratios cover all Aleris needs:

16:9 — Hero images, banners, video thumbnails. The widest standard ratio. Creates a cinematic, horizontal emphasis. Use for communicative surfaces where the image leads the layout.

3:2 — Article images, staff portraits (landscape), general content images. More height than 16:9, better balanced in cards and list layouts. The most versatile ratio.

1:1 — Profile photos, avatars, thumbnails in lists and grids. Simplest to crop, most flexible in layouts. Use for any context where the image is small and functional rather than editorial.

4:3 — Documentation images, clinical photography (where more vertical space is needed), legacy content. An alternative to 3:2 when the subject needs more height.

The Rule

All images in the same view share aspect ratio. A card grid where every card has a different image proportion looks broken regardless of individual image quality. The aspect ratio is set by the component, not by the image content.

In CSS:

.image-container {
  aspect-ratio: 3 / 2;
  overflow: hidden;
}

.image-container img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

object-fit: cover ensures the image fills the container without distortion, cropping from centre. For portraits or images where the subject position matters, object-position can adjust the focal point.


Responsive Sizing

srcset Series

Generate these sizes per image use case:

Content images (articles, cards, guides): 400w, 800w, 1200w, 1600w

Hero/banner images: 640w, 1024w, 1440w, 1920w

Thumbnails/avatars: 64w, 128w, 256w

sizes Attribute

Tell the browser how wide the image will render at each breakpoint so it can choose the right file:

<img
  srcset="image-400.avif 400w, image-800.avif 800w, image-1200.avif 1200w"
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 600px"
  src="image-800.jpg"
  alt="..."
  width="800"
  height="533"
  loading="lazy"
  decoding="async"
/>

Preventing Layout Shift

Always include width and height attributes on <img> elements. The browser uses these to calculate aspect ratio and reserve space before the image loads, preventing Cumulative Layout Shift (CLS).

If the rendered size differs from the intrinsic size (it usually does in responsive layouts), the width and height values communicate the ratio, not the exact pixel dimensions. An 800×533 image that renders at 400×267 still needs width="800" height="533" — the browser infers the 3:2 ratio.


Loading Strategy

Lazy Loading

loading="lazy" on every image except the first visible image in the viewport (the Largest Contentful Paint candidate). That image gets:

<img src="hero.avif" loading="eager" fetchpriority="high" decoding="async" ... />

This tells the browser: load this image first, it's the most important visual on the page.

Decoding

decoding="async" on all images. Allows the browser to decode the image off the main thread, preventing rendering blocks.


Compression

Quality Settings

Format Lossy quality Notes
AVIF 75–80 Below 70, artefacts become visible on gradients and skin tones
WebP 80–85 Slightly less efficient than AVIF; needs higher quality to match
JPEG (fallback) 80–85 Standard web quality

These are starting points. Photographic content (patients, clinical environments) may need 80-85 for AVIF to preserve subtlety. Graphic content (illustrations, diagrams) can go lower.

Automation

Manual compression and format conversion does not scale. Use an image CDN or build-pipeline tool that automatically:

  • Serves the best format based on browser Accept headers
  • Generates srcset variants at standard breakpoints
  • Applies quality settings per format
  • Strips unnecessary metadata (EXIF, GPS — privacy-relevant for any image taken at a clinic)

Options: Vercel Image Optimization (if deploying on Vercel), Cloudflare Images, imgix, or a build-time solution like Sharp in a Next.js pipeline.

EXIF and Metadata: Privacy Consideration

Patient and staff photos taken at clinics may contain GPS coordinates, camera info, and timestamps in EXIF metadata. This metadata must be stripped before serving images publicly. Automated image pipelines should strip all EXIF by default. If metadata is needed for internal use (photo management, audit), store it separately from the served image file.


Image Tokens

/* Aspect ratios — used with aspect-ratio CSS property */
--image-ratio-hero: 16 / 9;
--image-ratio-content: 3 / 2;
--image-ratio-square: 1 / 1;
--image-ratio-document: 4 / 3;

/* Border radius on images */
--image-radius-default: var(--radius-m);    /* 8px — softened corners */
--image-radius-avatar: var(--radius-full);  /* Circular for profile images */
--image-radius-none: 0;                     /* Full-bleed images */

Design Decision Record

Decision: AVIF as primary format with WebP fallback, served via <picture>. Why: AVIF offers the best compression for photographic content, which dominates Aleris imagery (clinic environments, staff portraits, patient-facing content). WebP fallback covers the ~4% of browsers without AVIF support. This progressive enhancement approach ensures every user gets the best their browser supports.

Decision: Four standard aspect ratios (16:9, 3:2, 1:1, 4:3), enforced by component, not by image content. Why: Consistent aspect ratios within a view create visual coherence. The component defines the ratio; the image fills it via object-fit: cover. This eliminates the need for content editors to manually crop every image to specific dimensions.

Decision: EXIF metadata stripped by default on all served images. Why: Images taken at Aleris clinics may contain GPS coordinates that identify care locations. Patient and staff privacy requires that this metadata never reaches the browser. Strip automatically in the image pipeline, store separately if needed for internal purposes.

Decision: Automated image delivery via CDN or build pipeline, not manual conversion. Why: Manual format conversion and size generation does not scale across Aleris's multi-country, multi-product surface. Automation ensures consistency and prevents human error (wrong format, missing srcset variant, oversized file).


Open Questions

  • Should Aleris invest in a shared image CDN across all properties (aleris.se, aleris.no, aleris.dk, product apps), or handle image optimization per property?
  • Do clinical/medical images have different quality requirements than marketing/editorial images? (Hypothesis: yes — clinical images may need higher quality or even lossless for diagnostic integrity.)
  • How does the CMS (Optimizely) handle image variants? Can it be configured to output AVIF/WebP, or does a separate pipeline need to sit between CMS and delivery?