media-asset-management

# Media Asset Management

Design how images, video, and downloadable files get stored, processed, organized, and served. Stack-agnostic. The principles apply whether you're running a custom pipeline or using a hosted service.

---

## When to use

- Designing or redesigning the image and media pipeline
- Choosing a media CDN or image service
- Setting up responsive image delivery
- Planning a digital asset management (DAM) system
- Auditing media performance issues
- Picking video hosting and embedding strategy
- Setting up workflows for designers and writers to upload assets
- Migrating media from one platform to another

## When NOT to use

- Performance optimization beyond media (use `performance-optimization`)
- Brand identity or photography direction (use `brand-identity`, `art-direction`)
- Content production strategy (use `content-strategy`)
- Single-image optimization (covered in `performance-optimization`)

---

## Required inputs

- Current media inventory: where assets live, in what formats
- Volume: how many assets, how much storage, how much traffic
- Sources: who creates and uploads media (designers, writers, automated tools)
- Platforms: where media is consumed (web, email, app, partners)
- Performance baseline: current image sizes, load times
- Budget reality: hosted services have monthly costs

---

## The framework: 4 stages

The media pipeline has four stages. Each has its own decisions.

### Stage 1: Source

Where assets enter the system.

**Sources:**
- Designers (Figma exports, Photoshop, Illustrator)
- Photographers (RAW or JPEG from camera)
- Stock photo libraries
- AI-generated images
- User-generated content (uploads)
- Automated systems (e.g., screenshots, generated thumbnails)

**At source, decide:**
- File formats accepted (RAW, TIFF, PSD, AI vs delivered formats)
- Naming conventions
- Required metadata (alt text, captions, credits, rights)
- Maximum source resolution (high enough to derive any size; not so high it's wasteful)
- Where source files live (separate from delivered assets)

**Anti-pattern:** sources and delivered assets in the same place. Hard to find masters. Hard to regenerate. Hard to audit usage.

### Stage 2: Process

Transforming source files into delivery formats.

**Processing decisions:**
- Resize to standard sizes (e.g., a fixed set of widths: 320, 640, 960, 1280, 1920, 2560)
- Compress (lossy or lossless, with quality targets)
- Convert formats (JPEG, WebP, AVIF for raster; SVG for vector)
- Generate thumbnails and previews
- Strip metadata (EXIF, GPS) unless intentionally retained
- Color profile management (sRGB for web)

**Process options:**
- **Build-time:** Static assets processed during deploy. Predictable, fast at runtime, hard to vary.
- **On-demand:** A service generates the right format/size when requested. Flexible, requires a processing layer.
- **Hybrid:** Static processed sizes plus on-demand for edge cases.

For sites with many image variants and ongoing change, on-demand wins. For tightly controlled marketing sites, build-time can be simpler.

### Stage 3: Deliver

Getting assets to users efficiently.

**Delivery decisions:**
- CDN: required for any non-trivial volume. Edge caching, global distribution.
- Format negotiation: serve AVIF to browsers that support it, WebP otherwise, JPEG as fallback. Use the `<picture>` element or content negotiation.
- Responsive images: `srcset` and `sizes` attributes so browsers pick the right size for the viewport.
- Lazy loading: `loading="lazy"` for below-the-fold images.
- Async decoding: `decoding="async"` for non-critical images.
- Width and height attributes: always set, prevents layout shift.

**Modern HTML pattern:**

```html
<img 
  src="/image-1280.jpg" 
  srcset="/image-640.jpg 640w, /image-960.jpg 960w, /image-1280.jpg 1280w, /image-1920.jpg 1920w" 
  sizes="(max-width: 768px) 100vw, 50vw"
  width="1280"
  height="720"
  loading="lazy"
  decoding="async"
  alt="Descriptive alt text">
```

Or for format negotiation:

```html
<picture>
  <source type="image/avif" srcset="/image.avif">
  <source type="image/webp" srcset="/image.webp">
  <img src="/image.jpg" alt="Descriptive alt text" width="1280" height="720">
</picture>
```

### Stage 4: Manage

Keeping the system organized and useful over time.

**Management decisions:**
- Asset library or DAM (digital asset management): centralized place for the team to find assets
- Tagging and search
- Version control (designers updating an asset, old version still in use)
- Rights and licensing tracking
- Audit and cleanup (what's not used anymore?)
- Permissions (who can upload, edit, delete)

A simple shared folder works at low scale. A real DAM is necessary above a few thousand assets or with multiple teams.

---

## Format reference

For typical web use:

| Format | Use for | Avoid for |
|---|---|---|
| AVIF | Photographs, complex images. Best compression. | Browser support edge cases (rare in 2026, ubiquitous now) |
| WebP | Photographs, illustrations. Good compression. Wide support. | Print, archival |
| JPEG | Photographs (fallback). Universal support. | Sharp-edged graphics, transparent backgrounds |
| PNG | Sharp-edged graphics, transparent backgrounds, screenshots. Lossless. | Photographs (file size) |
| SVG | Logos, icons, simple illustrations. Scalable. | Photographs, complex art |
| GIF | Effectively obsolete. Use video formats for animation. | Anything modern |
| MP4 (H.264) | Video, universal support. | Static content |
| WebM (VP9 / AV1) | Video, better compression. | Older browsers |

For most sites: serve AVIF/WebP for modern browsers, JPEG/PNG fallback. SVG for vector. MP4 for video.

---

## Workflow

### Step 1: Inventory

What assets exist? Where? In what state?

- Image count and total storage
- Average sizes (KB) per format
- Image-related performance metrics
- Number of pages with broken or missing images
- Source files vs delivered files

### Step 2: Audit performance

For a sample of pages:
- Image weight per