Una foto de 4 MB en un hueco de 300 px.
Es el problema más común y el que más se nota en el móvil. También es el más barato de arreglar: no hace falta rediseñar nada, solo dejar de enviar imágenes que nadie necesita.
Abre la pestaña de red, ordena por tamaño y mira la imagen más grande. Si mide 3000 px y se muestra a 600, sobra el 80 %. Redimensiona, sirve WebP o AVIF y deja el lazy load para todo menos para la imagen principal.
El error de origen
La foto se sube tal como salió de la cámara. WordPress genera varias miniaturas, pero el tema o el maquetador pueden seguir usando la original. Esa original acaba en la portada, en una tarjeta de 400 px de ancho, y el navegador la descarga entera para reducirla después.
El resultado: la web pesa 8 MB, tarda en enseñar el producto y el visitante culpa a «la conexión» o al hosting. En realidad está descargando fotos que no se van a ver a ese tamaño en ninguna pantalla.
Cómo saber cuánto sobra
En las herramientas del navegador, pestaña de red, recarga con la caché desactivada y ordena por tamaño. Haz clic en la imagen más grande y compara dos datos: el tamaño real del archivo y el tamaño al que se muestra.
Si se muestra a 600 × 400 y el archivo es de 3000 × 2000, estás enviando 25 veces más píxeles de los necesarios. Ahí no hay debate: sobra.
| Original de cámara | 3000 px · JPEG · 4,2 MB |
|---|---|
| Redimensionada | 1200 px · JPEG · 260 KB |
| Redimensionada y WebP | 1200 px · WebP · 140 KB |
| Con AVIF | 1200 px · AVIF · 95 KB |
La diferencia entre la primera y la última no se ve en un móvil a plena luz. Se ve en el tiempo de carga, sobre todo con mala cobertura.
Las cuatro decisiones que importan
- Tamaño. Sube la imagen al tamaño máximo al que se va a ver, no al que salió de la cámara. Si el hueco es de 800 px, una imagen de 1600 px cubre pantallas de alta densidad.
- Formato. WebP es el estándar hoy y funciona en todos los navegadores actuales. AVIF comprime mejor, pero tarda más en generarse. JPEG sigue valiendo para fotos; PNG solo para gráficos con transparencia.
- Respuesta. `srcset` y `sizes` permiten servir una versión distinta según el ancho de pantalla. WordPress ya genera los tamaños; el tema tiene que usarlos bien.
- Carga. `loading="lazy"` en todo lo que está por debajo del pliegue. En la imagen principal, no: retrasarla empeora el LCP. Ahí conviene `fetchpriority="high"`.
El lazy load mal puesto
Poner `loading="lazy"` a todas las imágenes es una moda que sale cara. La imagen grande de la cabecera es la que el navegador debería cargar primero; si la marcas como perezosa, la retrasa hasta que el layout está listo y el LCP empeora.
La regla es sencilla: perezoso para lo que no se ve al entrar; prioritario para la imagen que define la primera pantalla. En una ficha de producto, esa es la foto principal. En la portada, la del hero.
Lo que no hay que hacer
Comprimir a lo bruto con calidad 30 para que pese poco. Se nota, sobre todo en fotografía de producto y en caras. Un buen equilibrio suele estar entre 75 y 82 de calidad en WebP, y se ajusta según la imagen.
Tampoco sirve convertir a WebP una imagen que ya está mal recortada o desenfocada. El peso es la mitad del problema; la otra mitad es que la foto se vea bien en el tamaño en que se usa.
¿Cuánto pesan de más las fotos de tu web?
La auditoría te dice cuánto se descarga, qué imágenes son las más pesadas y si se están sirviendo a un tamaño que no hace falta.
Auditar mi web