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:

<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:

<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:

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 page (target: under 500KB total for marketing pages)
• Number of image requests
• Are responsive images used?
• Are modern formats served?
• Is there layout shift from missing dimensions?

Tools: Lighthouse, WebPageTest, your CDN's analytics.

Step 3: Pick the pipeline

Three reasonable patterns:

Pattern A: Static, build-time

• Assets in repo or storage bucket
• Build process generates sizes and formats
• Served via CDN
• Good for: static sites, low asset churn, tight performance control

Pattern B: Image CDN with on-demand

• Source uploads to a bucket or service
• An image CDN (Cloudinary, imgix, Cloudflare Images, Bunny, etc.) processes on-demand via URL parameters
• Good for: mid-to-large sites, frequent asset changes, multiple variants

Pattern C: Headless CMS with built-in image API

• CMS holds source assets
• CMS provides image API for resizing, format conversion
• Good for: content-heavy sites, non-technical content uploaders, when CMS is already chosen

The patterns aren't mutually exclusive. Big sites often use Pattern A for design assets, Pattern B for content images.