EL PIPELINE DE IMÁGENES

Las imágenes son el elemento LCP en aproximadamente el 70 % de las páginas de marketing. La gestión adecuada de las imágenes es, en mi opinión, el factor que más influye en el rendimiento. Los equipos que lo hacen bien alcanzan los Core Web Vitals sin esfuerzo; los que lo hacen mal luchan contra los Core Web Vitals sin descanso.

La clave está en la organización: elegir el formato, ajustar el tamaño al subir el archivo, optimizar la codificación, establecer unas dimensiones concretas y precargar la imagen LCP. Cada una de estas medidas supone una inversión técnica única que se amortiza en todas las páginas de todos los sitios web.

Genero imágenes principales mediante FAL flux-pro/v1.1-ultra y Recraft v3. Ambos generan archivos JPEG de 1200 por 675 píxeles con la máxima calidad de codificación, que suelen ocupar entre 600 KB y 1,5 MB por imagen. Subir los archivos sin procesar a Supabase Storage supone que cada página envía aproximadamente 1 MB solo en la imagen principal.

FAL cuesta aproximadamente 4 céntimos por imagen destacada, lo cual es insignificante en comparación con la fotografía manual o la adquisición de licencias de imágenes de archivo.

Antes de cualquier subida, la imagen pasa por el proceso sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer(). Esto genera un archivo WebP un 90 % más pequeño que el JPEG original sin pérdida perceptible de calidad. Una imagen principal de 900 KB pasa a tener un tamaño de 80 KB.

En 53 imágenes de héroe en gautamkhorana.com, el ahorro total fue aproximadamente 50MB en todo el sitio. El mismo pipeline aplicado a sitios de clientes en Seahawk entregó consistentemente ganancias similares. El código son diez líneas; el impacto es duradero.

Establece `cacheControl: 31536000` en la subida al almacenamiento para que la CDN almacene el archivo en caché durante un año. El formato WebP ofrece a los navegadores modernos lo que necesitan; los navegadores más antiguos recurren al formato JPEG a través del elemento `picture`.

Utiliza un patrón de URL estable (slug-hero.webp) para que el proceso de invalidación de la caché sea claro. Cuando se actualice una imagen destacada, el slug debería cambiar (slug-hero-v2.webp) y la base de datos actualizaría la URL de forma atómica.

Todas las imágenes principales deben tener atributos de ancho y alto explícitos en el código HTML. Sin ellos, el diseño se desplaza mientras se carga la imagen y aumenta el CLS. Los componentes de imagen de Astro y Next.js se encargan de esto automáticamente; las etiquetas `img` sin formato requieren que se especifiquen manualmente.

La imagen principal situada «por encima del pliegue» debe precargarse mediante el enlace `rel="preload" as="image"` en el encabezado del documento. Suele suponer un ahorro de entre 100 y 400 milisegundos en la métrica LCP. Se trata del cambio de una sola línea con mayor impacto que se puede aplicar en la mayoría de los sitios web de marketing.

Aplica la carga diferida a todas las imágenes que se encuentren por debajo de la línea de desplazamiento utilizando «loading="lazy"». Los navegadores ya gestionan esto de forma nativa; no hace falta ninguna biblioteca de JavaScript.

He extraído este proceso a scripts/lib/optimize-image.mjs, que toma un búfer, realiza el cambio de tamaño y la codificación a WebP, y devuelve el búfer optimizado. Se utiliza en el proceso de la imagen principal del autoblog, en los scripts de recodificación masiva y en la utilidad de subida manual.

El hecho de que haya un único helper significa que el proceso está centralizado. Los nuevos scripts que necesitan subir imágenes llaman al mismo helper, aplican la misma compresión y generan archivos del mismo tamaño. El proceso no depende de que un único ingeniero se acuerde de ejecutar «sharp».