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
| Métrica | Qué indica | Objetivo |
|---|---|---|
| TTFB | Cuánto tarda el servidor en responder | < 0,8 s |
| LCP | Cuándo se ve el elemento principal | ≤ 2,5 s |
| INP | Rapidez de respuesta a clics y toques | ≤ 200 ms |
| CLS | Saltos de diseño mientras carga | ≤ 0,1 |
| Peso total | Bytes descargados | Cuanto menos, mejor; muchas páginas pueden quedar por debajo de 1–2 MB |
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
widthyheightpara 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
defero 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: swappara 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
- Medir portada, ficha de producto y artículo en móvil; anotar LCP, TTFB y peso.
- Optimizar imágenes (redimensionar, comprimir, WebP/AVIF,
width/height). - Activar caché de página y compresión.
- Revisar y recortar scripts de terceros.
- Ajustar fuentes y CSS.
- Si el TTFB sigue alto, mejorar hosting o añadir CDN.
- 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.