WebP, Cache-Control y lazy load: las 3 optimizaciones que más impactan el SEO técnico

Cuando auditamos una web y vemos que el score de velocidad está entre 45 y 65 sobre 100, las causas son casi siempre las mismas. Antes de tocar una línea de código o cambiar de hosting, comprobamos tres cosas: si las imágenes están en WebP, si hay Cache-Control configurado, y si las imágenes fuera del viewport están con lazy load. En el 70% de los casos, corregir estas tres cosas sube el score entre 8 y 15 puntos.

No son cambios mágicos ni complejos. Son correcciones técnicas básicas que la mayoría de webs no tienen aplicadas porque nadie se ha sentado a hacerlas.

1. WebP: menos peso, misma (o mejor) calidad

WebP es un formato de imagen desarrollado por Google que ofrece compresión superior a PNG y JPEG manteniendo una calidad visual prácticamente idéntica para el ojo humano. La diferencia de tamaño es significativa:

Ese es el caso real de AC Clima Málaga, donde la imagen hero pasó de 2,3 MB a 192 KB después de la conversión. Para el usuario en móvil con conexión 4G normal, eso supone la diferencia entre una página que carga en 1,2 segundos y una que carga en 4,5 segundos.

Cómo implementarlo correctamente

La implementación correcta usa el elemento <picture> con un fallback en PNG o JPEG para navegadores que no soporten WebP (aunque actualmente representa menos del 2% del tráfico):

Los atributos width y height son obligatorios — sin ellos el navegador no puede reservar el espacio antes de cargar la imagen, lo que causa el Cumulative Layout Shift (CLS), una de las Core Web Vitals que Google penaliza.

2. Cache-Control: que el navegador recuerde lo que ya descargó

Sin Cache-Control, cada vez que un usuario visita una página su navegador descarga todos los recursos desde cero: HTML, CSS, imágenes, fuentes. Con Cache-Control configurado correctamente, en las visitas siguientes el navegador carga los recursos que no han cambiado desde su caché local — lo que puede reducir el tiempo de carga de una segunda visita en un 80%.

Para webs desplegadas en Cloudflare Pages, la configuración se hace con un archivo _headers en la raíz del proyecto:

La lógica es: para el HTML principal (max-age=3600, 1 hora) el caché es corto porque el contenido puede cambiar. Para los assets estáticos como imágenes, CSS y JS (max-age=31536000, 1 año), el caché es largo porque si cambia el archivo se cambia también el nombre del archivo. El parámetro stale-while-revalidate hace que mientras se actualiza en background el usuario siga viendo la versión cacheada sin esperar.

3. Lazy load: no cargar lo que el usuario no ve

El lazy load hace que las imágenes que están fuera del viewport (la parte visible de la pantalla) no se carguen hasta que el usuario se aproxima a ellas con el scroll. En una página con 10 imágenes, sin lazy load el navegador intenta descargar las 10 a la vez al cargar la página. Con lazy load, carga solo las 2-3 del viewport inicial y aplaza el resto.

La implementación nativa (sin JavaScript) es un solo atributo:

El impacto combinado de las tres optimizaciones

Aplicadas juntas en una web que partía de 58/100 en PageSpeed Insights móvil, obtuvimos los siguientes resultados tras implementar las tres:

• LCP (Largest Contentful Paint): de 4,8s a 1,9s — gracias a WebP y fetchpriority en el hero.
• CLS (Cumulative Layout Shift): de 0,18 a 0,02 — gracias a width y height explícitos en todas las imágenes.
• FCP (First Contentful Paint): de 2,1s a 0,8s — gracias a Cache-Control y reducción de peso total.
• Score total: de 58 a 82 en móvil, de 71 a 93 en desktop.

Tiempo de implementación: 45 minutos. No hubo cambios de hosting, ni refactorización de código, ni librerías nuevas. Solo estas tres correcciones.