--- name: Images — Format, Ratios, Sizes & Handling type: reference status: anchor depends_on: [aleris-tokens.css, foundation/constant-contextual] propagates_to: [aleris-tokens.css, aleris-design-system-open-questions.md, index.html] open_questions: [OQ-21, OQ-22, OQ-23] last_verified: 2026-03-21 --- # 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 `` element and let the browser choose the best it supports. ```html ... ``` 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: ```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: ```html ... ``` ### Preventing Layout Shift Always include `width` and `height` attributes on `` 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: ```html ``` 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 ```css /* 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 ``. **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?