Web Codecs API: Procesamiento de video nativo en el navegador

El navegador ya no es un reproductor pasivo. Con Web Codecs API, puede codificar, decodificar y transformar video con aceleración por hardware, sin servidores ni WebAssembly intermedio. WordPress 7.1 acaba de validarlo como estándar de producción.

Esta semana, WordPress 7.1 incorporó procesamiento de medios del lado del cliente como funcionalidad base del core: compresión de imágenes, redimensionamiento, conversión de formato y generación de thumbnails directamente en el navegador del usuario, usando una combinación de WebAssembly y Web Codecs API.

No es una casualidad. Es la señal de que el procesamiento de video en el navegador ha cruzado el umbral de madurez para producción.

En este artículo contamos cómo migramos la generación de thumbnails de un portal de video médico — que procesaba cientos de videos educativos por semana — de un pipeline server-side a procesamiento 100% en el navegador del cliente. Las métricas, los patrones que funcionaron y el framework para decidir cuándo usar cada enfoque.

Qué es Web Codecs API (y por qué importa ahora)

Web Codecs API es una especificación W3C que expone los códecs de video y audio del navegador a JavaScript. A nivel práctico, te da cuatro interfaces principales:

• VideoDecoder: decodifica EncodedVideoChunk (datos comprimidos H.264, H.265, VP9, AV1) en VideoFrame (frames individuales en RGB/YUV).
• VideoEncoder: hace lo inverso — toma VideoFrame y produce EncodedVideoChunk.
• VideoFrame: representa un frame individual raw, accesible para lectura de píxeles, dibujo en canvas o transformación.
• ImageDecoder: decodifica imágenes fijas en secuencias de frames (útil para GIF animados o secuencias de thumbnails).

La diferencia crítica con los enfoques anteriores (subir el video a un servidor, usar ffmpeg.wasm, o depender de APIs propietarias) es que Web Codecs corre con aceleración por hardware — utiliza los decodificadores dedicados de la GPU, no emulación por software. Eso se traduce en latencias de milisegundos por frame en lugar de segundos.

En 2026, el soporte alcanzó near-baseline: Chrome 94+, Edge 94+, Firefox 130+, Safari 26.0+. Según datos de Can I Use, el 94% de los usuarios globales tienen un navegador compatible. Zoom Web, Loom y Adobe Premiere Web ya lo usan en producción.

El proyecto: portal de video médico con cientos de thumbnails por semana

Trabajamos con un cliente del sector salud que aloja una biblioteca de videos educativos para cirujanos. Cada semana suben entre 50 y 80 nuevos videos (grabaciones de procedimientos, conferencias, tutoriales), y cada video necesita:

1. Un thumbnail principal para la página de listado.
2. 3-5 thumbnails de escena para la línea de tiempo interactiva.
3. Un preview GIF animado para la vista de galería.

El pipeline original era server-side: el video se subía a un bucket S3, un worker Node.js lo descargaba, ejecutaba ffmpeg para extraer frames, generaba los thumbnails, y los subía de vuelta al CDN. El proceso completo tomaba entre 45 segundos y 2 minutos por video, dependiendo de la duración.

Cuando el cliente empezó a recibir videos directamente desde los quirófanos vía grabaciones móviles (formato HEVC, 4K), el pipeline server-side comenzó a colapsar: los workers se quedaban sin memoria, los tiempos de procesamiento se duplicaron, y el costo de instancias EC2 se disparó.

La migración a procesamiento en el navegador

Decidimos mover la generación de thumbnails al navegador del editor. En lugar de procesar el video en el servidor, el editor sube el video al navegador y nosotros:

1. Extraemos los frames clave usando VideoDecoder + un intervalo de tiempo configurable (cada 15 segundos para procedimientos largos, cada 5 segundos para tutoriales cortos).
2. Redimensionamos y encodeamos los frames extraídos como JPEG/WebP usando OffscreenCanvas y canvas.toBlob().
3. Subimos solo los thumbnails al servidor — el video original va directamente a S3, nunca toca un worker de procesamiento.

async function extractThumbnails(videoFile, intervalSeconds = 15) {
  const track = videoFile.stream().getVideoTracks()[0];
  const decoder = new VideoDecoder({
    output: async (frame) => {
      const canvas = new OffscreenCanvas(frame.displayWidth, frame.displayHeight);
      const ctx = canvas.getContext('2d');
      ctx.drawImage(frame, 0, 0);
      const blob = await canvas.convertToBlob({ type: 'image/webp', quality: 0.8 });
      // Upload thumbnail blob to CDN
      await uploadThumbnail(blob, frame.timestamp);
      frame.close();
    },
    error: (e) => console.error('Decode error:', e),
  });

  decoder.configure({ codec: 'avc1.64001f', codedWidth: 1920, codedHeight: 1080 });

  // Feed chunks from the file
  const reader = new FileReader();
  // ... read and feed EncodedVideoChunks at intervalSeconds intervals
}

Código simplificado — la implementación completa maneja demuxing con MP4Box.js y control de concurrencia.

Resultados

• Tiempo de generación de thumbnails: de 45-120 segundos server-side a 1.2-3.5 segundos en el navegador del editor (con conexión de fibra).
• Costo de infraestructura: el procesamiento pasó de correr en instancias EC2 c5.4xlarge a cero — solo pagamos el storage de S3 y la entrega por CloudFront.
• Experiencia del editor: los thumbnails aparecen inmediatamente después de la subida, sin pantallas de carga ni colas de procesamiento.

Framework de decisión: Web Codecs vs ffmpeg.wasm vs servidor

En la práctica, no existe una bala de plata. Cada enfoque tiene su lugar. Después de varios proyectos de procesamiento de video en el navegador, este es el framework que usamos para decidir:

Si el 80% de tus videos llegan en H.264 o HEVC (que es el caso de la mayoría de sitios en 2026), Web Codecs cubre todo lo que necesitas para thumbnails y previews sin tocar un servidor.

Por qué esto importa para Core Web Vitals

Procesar video en el servidor tiene un costo oculto: el LCP. Cuando el thumbnail se genera server-side, el navegador del visitante tiene que esperar a que el servidor procese, almacene y entregue la imagen. En sitios con cientos de videos, esa espera puede sumar segundos al LCP de las páginas de listado.

Con thumbnails generados en el navegador del editor, el proceso es:

1. Editor sube video → navegador extrae thumbnail → thumbnail sube a CDN.
2. Visitante carga página → thumbnail ya está en CDN → LCP se resuelve en una sola petición.

La diferencia es un LCP que pasa de 3.8s (mediana móvil 2026 según HTTP Archive) a <1.5s para páginas de video.

Y cuando combinamos esto con carga diferida de video nativa con <video loading="lazy"> — como cubrimos en nuestro playbook de embedding de video — el impacto en Core Web Vitals es inmediato.

Web Codecs + Astro: el patrón que funciona

En los proyectos que construimos con Astro, el patrón es consistente:

1. Static generation para las páginas de listado (los thumbnails ya están en el CDN como imágenes estáticas).
2. Componente VideoProcessor en el panel del editor (cliente, con client:load) que usa Web Codecs para generar thumbnails y previews en el momento de la subida.
3. Imágenes WebP para los thumbnails (WebP ofrece 25-30% mejor compresión que JPEG con calidad equivalente, ideal para fotogramas de video).

Este patrón funciona particularmente bien con Server Islands de Astro, donde el contenido del video se renderiza de forma diferida sin bloquear el resto de la página.

También es una arquitectura que recomendamos cuando evaluamos headless CMS vs WordPress para sitios con contenido multimedia pesado: el procesamiento en el navegador elimina la dependencia de pipelines server-side que suelen ser el cuello de botella en ambas plataformas.

Lo que no hace Web Codecs (y cuándo necesitas alternativas)

No todo es color de rosa. Web Codecs tiene limitaciones importantes:

No es un demuxer. La API trabaja con EncodedVideoChunk, pero no sabe leer containers MP4, WebM o MOV. Necesitas una librería de demuxing aparte (MP4Box.js, mux.js) para extraer los chunks del archivo.

Soporte de codecs limitado. Cada navegador decide qué codecs expone. En Safari, HEVC funciona perfecto; en Firefox, AV1 tiene mejor soporte. Necesitas detectar capabilities con VideoDecoder.isConfigSupported() antes de configurar.

Sin fallback automático. Si el usuario usa un navegador antiguo (KaiOS, Safari < 16.4), Web Codecs no está disponible. La solución es detectar soporte con 'VideoDecoder' in window y caer a ffmpeg.wasm o servidor.

El garbage collector es tu enemigo. Los VideoFrame deben cerrarse explícitamente con .close(). Si acumulas frames abiertos, la memoria del navegador se dispara. Es el error más común en implementaciones nuevas.

Conclusiones

Web Codecs API ya no es una tecnología experimental. Con near-baseline en todos los navegadores principales, validación de productos como WordPress 7.1, y casos de uso reales que demuestran reducciones de costos de infraestructura del 100% para generación de thumbnails, es momento de considerarlo como opción por defecto para procesamiento de video en el cliente.

Si tu sitio maneja videos generados por usuarios o contenido educativo con thumbnails automáticos, la pregunta ya no es "¿deberíamos procesar en el navegador?" sino "¿qué partes de nuestro pipeline deberían migrar primero?".

Nosotros empezamos por los thumbnails y nunca miramos atrás. El servidor no tenía por qué estar en medio de esa operación.