Optimización images para AMP vs PWA es una comparativa técnica sobre cómo servir imágenes según la plataforma. Compara amp-img con estrategias de service worker, formatos AVIF/WebP y delivery por CDN. Elige AMP para indexación rápida con AMP Cache; elige PWA para control offline y delivery adaptativo.
Comparativa rápida de Optimización images para AMP vs PWA
En el contexto de Optimización images para AMP vs PWA, esta tabla resume compromisos clave. Incluye impacto en LCP, control de formatos, costes y complejidad de implementación.
| Criterio |
AMP |
PWA |
Cuándo elegir |
| Control de markup |
Markup obligatorio *amp-img* y restricciones JS |
Control completo con HTML picture y service worker |
Elige AMP si no puedes gestionar SW; PWA si necesitas control |
| Impacto en LCP |
Preload y prioridad automática si markup correcto |
Precaching y estrategias de fetch mejoran LCP con buen control |
Elige AMP para contenidos indexables; PWA para experiencias ricas |
| Formatos soportados |
WebP/AVIF via CDN o srcset, con limitaciones si no hay rewriting |
Entrega adaptativa con Content Negotiation y srcset/picture |
Elige PWA si necesitas AVIF nativo y fallback automatizado |
| Coste y operativa |
Menos infra, pero dependencia de AMP Cache si se usa |
Mayor complejidad y posible coste CDN por egress |
Elige AMP para despliegues simples; PWA si puedes gestionar CDN |
En la práctica, AMP reduce la fricción de despliegue. PWA ofrece mayor control sobre Core Web Vitals cuando se gestiona correctamente.
Optimización images para AMP cuándo elegirlo
En el contexto de AMP, amp-img se refiere al componente oficial del proyecto AMP. Obliga a declarar width y height o layout, lo que cambia la forma en que el navegador prioriza la carga para el LCP.
Los atributos obligatorios permiten al navegador asignar espacio y evitar CLS. Para mejorar LCP en AMP, usa y asegúrate de que el componente incluye width/height o layout="responsive" para reservar espacio. No existe un atributo llamado «amp-runtime» que priorice imágenes: AMP prioriza recursos según el markup correcto y el uso de preload y el orden del DOM. Ejemplo mínimo de hero con preload:
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp">
<amp-img src="/wp-content/uploads/hero.webp" width="1200" height="675" layout="responsive" alt="Hero"></amp-img>
Para srcset en AMP se usa srcset igual que en HTML. No se puede ejecutar JS propio que manipule la prioridad, por eso hay que asegurar que la plantilla genera el markup correcto.
Prioriza el hero con preload y atributos width height. No confíes solo en lazy-loading para el LCP.
Patrones de caching de imágenes en PWA
En una PWA no basta con un ejemplo genérico de caches.open(...): conviene aplicar patrones distintos según la criticidad de la imagen. Para el hero (LCP), precachea la versión optimizada con Workbox: workbox.precaching.precacheAndRoute([{url:'/img/hero.avif', revision:'v1'}]) para garantizar carga inmediata en visitas recurrentes. Para imágenes de la UI, usa CacheFirst con expiración y límite de entradas; para catálogo grande, usa StaleWhileRevalidate para no bloquear la interfaz. Ejemplo Workbox runtime: js
workbox.routing.registerRoute(
({request}) => request.destination === 'image',
new workbox.strategies.CacheFirst({
cacheName: 'images-cache',
plugins: [
new workbox.expiration.ExpirationPlugin({maxEntries: 200, maxAgeSeconds: 30*24*60*60}),
new workbox.cacheableResponse.CacheableResponsePlugin({statuses:[0,200]})
]
})
); Verifica siempre response.ok antes de cache.put para evitar almacenar respuestas fallidas/404 u opacas, y usa cabeceras Cache-Control en origen para coordinar caducidad entre CDN y SW. Estas prácticas reducen el riesgo de crecimiento descontrolado de la caché y mejoran LCP al priorizar solo lo crítico.
Optimización images para PWA cuándo elegirlo
En el contexto de PWA, la plataforma se refiere al uso de service worker y manifest para controlar la caché. El service worker permite estrategias como cache first o stale-while-revalidate para imágenes.
El precaching de imágenes críticas mejora el LCP si se hace selectivamente. Evita el precache masivo. Ejemplo simple de fetch strategy en service worker:
self.addEventListener('fetch', event => {
if (event.request.destination === 'image') {
event.respondWith((async () => {
const cache = await caches.open('img-v1');
const cached = await cache.match(event.request);
if (cached) return cached;
try {
const networkResp = await fetch(event.request);
// Solo cachear respuestas válidas y no opacas sin control
if (networkResp && (networkResp.status === 200 || networkResp.type === 'opaque')) {
// Clonar antes de guardar
await cache.put(event.request, networkResp.clone());
}
return networkResp;
} catch (err) {
return cached || Response.error();
}
})());
}
});
Combina esta lógica con una política de expiración (p. ej. Workbox ExpirationPlugin) para limitar entradas y tiempo de vida, y evita precachear el catálogo completo.
Para LCP el hero puede precachearse con Workbox o un precache manual. No conviene precachear todas las imágenes de catálogo. Eso puede bloquear ancho de banda y empeorar LCP.
En PWA se recomienda el uso de picture con AVIF/WebP y fallback. Ejemplo de picture para producción:
<picture>
<source type="image/avif" srcset="/img/hero.avif 1200w">
<source type="image/webp" srcset="/img/hero.webp 1200w">
<img src="/img/hero.jpg" alt="Hero" width="1200" height="675" loading="eager">
</picture>
Excepción: no usar precache para imágenes de alta resolución que no sean críticas. PWA puede empeorar LCP si precachea todo el catálogo.
Dato accionable: automatizar conversión a WebP/AVIF en el pipeline de build reduce hasta 30 a 50 por ciento en peso de imagen según pruebas 2021-2023.
Delivery adaptativo
Content negotiation o CDN rewriting
Precaching
Precarga solo hero y assets críticos
Formato
AVIF > WebP > JPEG, con fallback
Amp-img: limitaciones y buenas prácticas concretas
amp-img exige declarar width y height o usar layout="responsive" para proporcionar la relación de aspecto y evitar CLS; si no se declara correctamente el runtime de AMP no puede priorizar ni reservar espacio. Usa el slot placeholder para mostrar un SVG o un blurred placeholder mientras carga: ```html
``` En AMP, srcset funciona pero debes incluir el atributo sizes para que el runtime elija correctamente la resolución; por ejemplo sizes="(max-width: 600px) 100vw, 1200px". AMP limita el uso de JS personalizado; por tanto, no puedes manipular dinámicamente la prioridad de carga desde client-side. Lo que sí puedes controlar es el orden del markup, el preload del recurso crítico y el uso correcto de amp-img con atributos obligatorios. Finalmente, si necesitas fallback para formatos modernos, combina srcset con una URL de fallback o usa CDN rewriting compatible con AMP Cache para servir WebP/AVIF.
Infografía rápida de entrega adaptativa
1. Detectar formato soportado
3. Servir AVIF/WebP con fallback
Tip: usar srcset y sizes para imágenes responsivas y content negotiation.
Cómo elegir según tu situación
En el contexto de tomar una decisión, estas reglas prácticas ayudan a evaluar prioridades. Prioriza LCP, control y coste.
- Si la prioridad es indexación rápida y despliegue sencillo elegir AMP.
- Si el objetivo es control offline, fallback y formatos modernos elegir PWA.
- Si no puedes tocar la plantilla o el hosting es restrictivo, ninguna de las dos opciones será viable.
Una regla rápida: si el 60% de tráfico es móvil, valorar cache y formatos modernos.
Lo que nadie te cuenta
En el contexto de optimizar en producción, hay costes y límites no obvios. El CDN y el rewriting suelen traer facturación por egress inesperada.
Un CDN con egress en Europa puede costar entre €0.01 y €0.12 por GB en 2026 según el proveedor. Eso impacta cuando se sirve AVIF o WebP a gran escala.
Según el HTTP Archive Web Almanac 2023, las imágenes representan aproximadamente el 44 por ciento del peso medio de una página web. Según StatCounter 2024, el tráfico móvil supera el 55 por ciento del tráfico global.
Advertencia: convertir sin fallback puede romper la navegación en navegadores antiguos. Comprobar outputs y headers es obligatorio.
Automatización de WebP/AVIF y generación de srcset en el pipeline
Conviene integrar conversión y generación de múltiples tamaños en el pipeline CI para no depender de procesos manuales. Un patrón sencillo con sharp (Node) produce variantes y nombres cacheables: js
const sharp = require('sharp');
const sizes = [320,640,1200];
for (const w of sizes) {
await sharp('hero.jpg').resize(w).toFile(`dist/hero-${w}.avif`);
await sharp('hero.jpg').resize(w).webp().toFile(`dist/hero-${w}.webp`);
} Al subir a CDN, publica los archivos generados y crea el srcset automáticamente: <source type="image/avif" srcset="/hero-320.avif 320w, /hero-640.avif 640w, /hero-1200.avif 1200w">. Para fallback automático en el borde, activa Content Negotiation o URL rewriting en el CDN (Cloudflare Image Resizing, Fastly Image Optimizer, o reglas de Netlify/Edge) y conserva una copia JPEG/HTML fallback para navegadores sin soporte. Automatizar en el build reduce errores, permite hashing de archivos, y facilita invalidaciones coherentes en el CDN.
Checklist LCP para imágenes en AMP y PWA
- Preload del hero en HTML o via server hints.
- Atributos width y height o layout responsive en amp-img.
- Picture + srcset con AVIF/WebP y fallback JPEG.
- Precaching selectivo en service worker solo para hero y assets críticos.
- Reescritura en CDN para content negotiation.
Metodología de benchmark reproducible
En el contexto de medir impacto, usar Lighthouse y WebPageTest con set de URLs consistente. Correr pruebas desde 3 ubicaciones y promediar 9 runs.
- Configuración recomendada: dispositivo móvil Moto G4, red 3G lenta y CPU slowdown 4x.
- Métricas clave: LCP, CLS y Time to First Byte.
Caso práctico anónimo: un WooCommerce redujo LCP de 4.2s a 1.9s en 7 días tras pasar a PWA con precache y WebP en CDN.
Preguntas frecuentes
¿Qué es Optimización images para AMP vs PWA?
Optimización images para AMP vs PWA se refiere a decidir cómo servir imágenes según la plataforma. Incluye markup de amp-img, uso de picture con srcset, y estrategias de service worker para PWA. Sirve para mejorar LCP, reducir CLS y bajar peso de página. La elección depende de control, indexación y posibilidad de gestionar CDN y service worker.
¿Qué es la versión PWA?
PWA es una web que usa manifest y service worker para comportarse como app. Permite offline parcial, precaching y estrategias de fetch. Mejora experiencia en clientes recurrentes al reducir latencia y llamadas repetidas. Requiere gestión de caché y lógica para evitar servir assets obsoletos. PWA es ideal cuando se necesita control de entrega y experiencia progresiva.
¿Qué es AMP?
AMP es un framework que limita JavaScript y obliga a componentes como amp-img. Su objetivo es páginas rápidamente indexables y cacheables por AMP Cache. Reduce complejidad del front y acelera despliegues. Tiene limitaciones para personalización y requiere adaptar plantillas. AMP ayuda si la prioridad es indexación y carga inicial rápida.
¿Cómo optimizar imágenes para AMP?
Optimizar imágenes para AMP exige generar amp-img con width y height o layout responsive. Preloadear la imagen hero desde HTML para mejorar LCP. Generar srcset desde el servidor y asegurar rewriting del CDN para WebP/AVIF. No usar lazy-loading en el hero. Revisar output del plugin que genere AMP para confirmar los atributos obligatorios.
¿Cómo optimizar imágenes para PWA?
Optimizar imágenes en PWA implica usar picture/srcset, content negotiation y precache selectivo. El service worker debe aplicar estrategias según criticidad. No precachear todo el catálogo. Automatizar conversión a WebP/AVIF en el build y hacer fallback. Testear con Lighthouse y WebPageTest para validar LCP después de cambios.
WebP reduce peso respecto a JPEG entre 25 y 35 por ciento en pruebas de la industria. AVIF ofrece ahorros adicionales, típicamente entre 30 y 50 por ciento respecto a WebP según tests 2021-2023. Elegir AVIF cuando el soporte y CDN ofrecen rewriting y fallback sencillo. Mantener JPEG como último recurso para compatibilidad.
¿Cómo afecta la optimización de imágenes al LCP?
La optimización de imágenes afecta LCP directamente por peso y prioridad de carga. Preload del hero y formatos modernos reducen tiempo de renderizado. Sin preload, lazy-loading puede empeorar LCP. Una estrategia combinada de preload, formatos adaptativos y cache control suele reducir LCP en porcentajes relevantes. Medir antes y después con Lighthouse y WebPageTest.
Referencias:
HTTP Archive Web Almanac
AMP Project
