Cómo acelerar una web: qué medir y qué cambiar primero

La velocidad de carga es una de esas cosas que nadie nota cuando está bien y todo el mundo nota cuando está mal. Una web lenta tiene más rebote, menos ventas y, a través de las Core Web Vitals, puede verse perjudicada en Google. Optimizar no exige rehacer el sitio: en la mayoría de webs de pymes, tiendas WooCommerce o páginas corporativas, imágenes, caché y scripts de terceros explican la mayor parte del problema. Esta guía te enseña a medir, a priorizar y a aplicar las mejoras con mayor retorno.

Primero, mide

Sin una medición inicial no sabrás si lo que cambias sirve. Usa dos tipos de datos:

• Datos de laboratorio: una prueba simulada (Lighthouse, PageSpeed Insights, nuestro test de velocidad web). Es reproducible y te dice qué recursos pesan.
• Datos de campo: lo que experimentan usuarios reales en Chrome (informe CrUX, que aparece en PageSpeed Insights y en Search Console si tu web tiene tráfico suficiente).

Mide siempre en móvil, que es como Google evalúa y como entra la mayoría de visitas, y prueba varias páginas: la portada, una ficha de producto y un artículo del blog suelen tener problemas distintos.

Qué métricas mirar

LCP, INP y CLS son las Core Web Vitals; las explicamos en detalle en la guía de Core Web Vitals.

1. Imágenes: la mejora más rápida

En la mayoría de webs las imágenes son más de la mitad del peso. Lo habitual es encontrar fotos de 4000 px y 5 MB subidas directamente desde el móvil.

• Redimensiona a la anchura máxima a la que se muestran (por ejemplo, 1600 px para una imagen a ancho completo, 800 px para una tarjeta).
• Comprime: con el compresor de imágenes una foto JPEG suele bajar mucho de peso sin pérdida visible.
• Usa formatos modernos: WebP o AVIF pesan bastante menos que JPEG con la misma calidad. Puedes convertir a WebP en el navegador.
• Lazy loading en las imágenes que están por debajo del primer pantallazo (loading="lazy"), pero nunca en la imagen principal (la que suele ser el LCP).
• Indica width y height para que el navegador reserve el hueco y no haya saltos (CLS).

Todo esto lo desarrollamos en la guía de optimización de imágenes.

2. Caché y compresión

• Caché de página: en WordPress, un plugin de caché (o la caché del hosting) sirve HTML ya generado en lugar de ejecutar PHP y consultas a la base de datos en cada visita. Suele bajar el TTFB de forma drástica.
• Caché del navegador: los archivos estáticos con nombre versionado (CSS, JS, fuentes, imágenes) pueden llevar Cache-Control: public, max-age=31536000, immutable.
• Compresión: activa Brotli o, como mínimo, gzip para HTML, CSS, JS y SVG.

#Nginx: caché larga para estáticos
location ~* \.(css|js|woff2|webp|avif|jpg|png|svg)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

3. JavaScript y scripts de terceros

El JavaScript no solo se descarga: hay que ejecutarlo, y eso bloquea el hilo principal del móvil (y empeora el INP).

• Haz inventario: chat en vivo, píxeles de publicidad, mapas, widgets de reseñas, A/B testing… Quita lo que no uses.
• Carga los scripts no críticos con defer o después de la interacción (por ejemplo, el chat al hacer clic en el icono).
• Sustituye los vídeos de YouTube incrustados por una miniatura que cargue el reproductor al pulsar.
• En WordPress, evita page builders y plugins que cargan sus scripts en todas las páginas aunque solo se usen en una.

4. CSS y fuentes

• Elimina el CSS no utilizado y evita varias hojas de estilo de distintos plugins.
• Usa como mucho dos familias tipográficas y solo los pesos que necesites, en formato WOFF2.
• Aloja las fuentes en tu propio dominio y añade font-display: swap para que el texto se vea aunque la fuente no haya llegado.
• Precarga solo la fuente principal: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter.woff2" crossorigin>.

5. Hosting, HTTP/2-3 y CDN

Si el TTFB supera el segundo incluso con caché, el problema es el servidor:

• Hosting compartido saturado: valora un plan con más recursos, una versión de PHP actual y caché de objetos.
• Ubicación: si tus clientes están en México, un servidor en Europa añade latencia en cada petición. Elige un centro de datos cercano o usa una CDN.
• Protocolo: HTTP/2 y HTTP/3 permiten descargar muchos recursos en paralelo. Casi todas las CDN los activan por defecto.
• Redirecciones: cada salto (http → https → www) añade un viaje de ida y vuelta. Lo ideal es como mucho uno.

Orden recomendado de trabajo

1. Medir portada, ficha de producto y artículo en móvil; anotar LCP, TTFB y peso.
2. Optimizar imágenes (redimensionar, comprimir, WebP/AVIF, width/height).
3. Activar caché de página y compresión.
4. Revisar y recortar scripts de terceros.
5. Ajustar fuentes y CSS.
6. Si el TTFB sigue alto, mejorar hosting o añadir CDN.
7. Volver a medir y vigilar los datos de campo durante 28 días.

Errores frecuentes

• Obsesionarse con llegar a 100 en PageSpeed en lugar de mejorar los datos reales de usuarios.
• Instalar tres plugins de optimización que hacen lo mismo y se pisan.
• Aplicar lazy loading a la imagen principal, lo que retrasa el LCP.
• Minificar y combinar archivos a ciegas y romper el JavaScript de la tienda.
• Probar solo con la caché del navegador llena o desde la fibra de la oficina.

Lista de comprobación

• Imágenes con el tamaño adecuado, comprimidas y en WebP o AVIF.
• Imagen principal sin lazy loading y con prioridad (fetchpriority="high").
• Caché de página, caché de navegador y Brotli/gzip activos.
• Scripts de terceros auditados y diferidos.
• Fuentes en WOFF2, alojadas localmente, con font-display: swap.
• TTFB por debajo de 0,8 s y una sola redirección como máximo.
• Mediciones periódicas en móvil.