Mejorar la velocidad de su web: entender y optimizar las Core Web Vitals

Para mejorar la velocidad de su web, mida primero con PageSpeed Insights dónde están los problemas y después actúe sobre los mayores frenos: imágenes demasiado grandes, falta de caché, fuentes y scripts que bloquean y una respuesta lenta del servidor. Google valora la experiencia de usuario con tres métricas, las Core Web Vitals. Este artículo explica qué significan, cómo medirlas correctamente y qué medidas aportan más, con indicaciones específicas para WordPress.

Las tres Core Web Vitals y sus umbrales

Los umbrales son de Google (web.dev, a octubre de 2026). Una página los cumple cuando al menos el 75 % de las visitas está en la zona verde, por separado en móvil y en ordenador. En marzo de 2024, el INP sustituyó a la métrica anterior FID (First Input Delay).

También conviene revisar el Time to First Byte (TTFB), es decir, el tiempo hasta la primera respuesta del servidor. Google considera bueno un valor de 0,8 segundos o menos. El TTFB no es una Core Web Vital, pero influye directamente en el LCP: lo que el servidor entrega tarde, el navegador no puede mostrarlo pronto.

Medir bien: datos de laboratorio y de campo

• PageSpeed Insights (pagespeed.web.dev) muestra arriba los datos de campo de usuarios reales de Chrome de los últimos 28 días, si hay suficientes, y debajo una prueba de laboratorio con Lighthouse y recomendaciones concretas.
• El informe «Core Web Vitals» de Google Search Console resume los datos de campo por grupos de páginas similares e indica qué URL tienen malos resultados. Tras una corrección, puede iniciar allí una validación.
• Las Chrome DevTools, con Lighthouse y la pestaña Rendimiento, sirven para hacer pruebas mientras trabaja en la web.

Para la valoración de Google cuentan los datos de campo, no la puntuación de la prueba de laboratorio. Las webs pequeñas a menudo tienen muy pocas visitas para generar datos de campo; entonces la prueba de laboratorio es la mejor referencia. Pruebe siempre también la vista móvil, que suele ser más lenta que la de ordenador.

Consejo: Mida varias páginas típicas, no solo la página de inicio: p. ej. una página de producto o servicio, un artículo del blog y el formulario de contacto. Después cambie una sola cosa cada vez y vuelva a medir.

Imágenes: la causa más frecuente de un LCP malo

En muchas páginas, el elemento LCP es una imagen grande, como una imagen de cabecera o un carrusel. Estas medidas son aquí las más eficaces:

• Servir las imágenes al tamaño realmente mostrado y ofrecer con srcset distintos tamaños para móvil y ordenador.
• Usar formatos modernos: WebP o AVIF suelen ser mucho más ligeros que JPEG o PNG con una calidad similar.
• No retrasar la carga de la imagen principal visible (sin lazy loading) y darle prioridad con fetchpriority="high"; las imágenes más abajo, en cambio, con lazy loading.
• Indicar el ancho y el alto de cada imagen para que el navegador reserve el espacio. Así se evitan desplazamientos y mejora el CLS.
• Prescindir de carruseles en la cabecera si basta con una sola imagen.

Caché y respuesta del servidor

Cada página que el servidor no tiene que montar antes llega más rápido a los visitantes. Hay tres niveles importantes:

• Caché de páginas: guarda las páginas HTML ya generadas. En servidores LiteSpeed, LSCache se encarga de ello directamente en el servidor web.
• Caché del navegador: con cabeceras de caché adecuadas, el navegador no vuelve a descargar imágenes, CSS y JavaScript en la siguiente visita.
• Caché de objetos, p. ej. Redis: acelera páginas dinámicas como el carrito o el área de socios, que no se pueden guardar en caché como página completa.

Si el TTFB sigue alto a pesar de la caché, la causa suele ser el servidor: una versión de PHP desactualizada, pocos recursos o una cuenta sobrecargada. En ese caso ayudan una versión de PHP actual o un hosting con recursos asignados.

Fuentes y scripts

Fuentes web

• Alojar las fuentes en su propio servidor en lugar de cargarlas desde servidores externos. Así ahorra conexiones y protege mejor los datos de sus visitantes.
• Cargar solo los estilos necesarios, p. ej. normal y negrita, en formato WOFF2.
• Con font-display: swap, el navegador muestra el texto de inmediato con una fuente de reserva.
• Precargar la fuente más importante con rel="preload".

JavaScript y servicios de terceros

El INP se resiente sobre todo con mucho JavaScript que bloquea el navegador. Los culpables típicos son widgets de chat, scripts de seguimiento y publicidad, banners de cookies con muchos servicios integrados, contenidos incrustados de redes sociales y maquetadores visuales pesados.

• Eliminar los scripts innecesarios en lugar de limitarse a optimizarlos.
• Cargar los scripts con defer o async para que no bloqueen la construcción de la página.
• Cargar vídeos y mapas solo tras un clic: primero una imagen de vista previa, después el contenido incrustado.
• Minimizar y combinar CSS y JavaScript, pero probar la web después de cada cambio.

Evitar desplazamientos del diseño (CLS)

Pocas cosas molestan tanto como un botón que se mueve justo cuando se pulsa porque algo más arriba todavía se está cargando. El CLS mide precisamente estos desplazamientos. Las causas más frecuentes y cómo evitarlas:

• Imágenes, vídeos e iframes sin dimensiones: indique ancho y alto o una proporción fija (aspect-ratio).
• Elementos que se cargan después, como banners de cookies, barras de avisos o espacios publicitarios: muéstrelos superpuestos al contenido o reserve el espacio de antemano.
• Fuentes web que cambian el ancho del texto al sustituir a la fuente de reserva: elija una fuente de reserva con proporciones similares.
• Contenidos insertados con JavaScript por encima de la zona visible: insértelos solo después de una acción del visitante.

CDN: cuándo merece la pena

Una red de distribución de contenidos (CDN) almacena archivos estáticos en servidores de muchos países y los entrega desde la ubicación más cercana. Es más útil cuando sus visitantes están repartidos por varios continentes. Si su web se dirige sobre todo a clientes en Suiza y Liechtenstein, la caché, las imágenes optimizadas y una respuesta rápida del servidor suelen aportar más. Aun así, una CDN puede tener sentido, por ejemplo con muchas imágenes grandes o descargas.

WordPress: los ajustes más importantes

• Usar un plugin de caché adecuado al servidor web. En LiteSpeed es LiteSpeed Cache, que además puede optimizar CSS y JavaScript, gestionar el lazy loading y convertir imágenes a WebP o AVIF mediante el servicio QUIC.cloud.
• WordPress admite WebP desde la versión 5.8 y AVIF desde la versión 6.5. Desde la versión 6.3, WordPress añade automáticamente fetchpriority="high" a la imagen que probablemente será el elemento LCP.
• Usar un tema de bloques ligero en lugar de un maquetador visual pesado.
• Revisar los plugins con regularidad y eliminar todo lo que no se use.
• Limpiar la base de datos: revisiones antiguas, comentarios de spam y transients caducados, con una copia de seguridad previa.
• Usar una versión de PHP actual; WordPress recomienda actualmente PHP 8.3 o superior.

Consejo: Encontrará más consejos prácticos en nuestro artículo «Acelerar WordPress: 8 medidas que realmente marcan la diferencia».

Siga este orden

1. Registrar el estado actual en móvil y ordenador con PageSpeed Insights y Search Console.
2. Identificar el elemento LCP (PageSpeed Insights lo indica) y optimizarlo de forma específica; normalmente es la imagen principal.
3. Activar la caché de páginas y comprobar el TTFB.
4. Convertir las imágenes a WebP o AVIF e indicar ancho y alto.
5. Alojar las fuentes usted mismo y reducir los scripts de terceros.
6. Volver a medir después de cada cambio y revisar los datos de campo al cabo de unas semanas.

En los planes WordPress de HostOn, LiteSpeed Cache viene preconfigurado y las webs funcionan en servidores LiteSpeed con almacenamiento NVMe. La caché de páginas y la respuesta del servidor quedan así cubiertas; las imágenes, las fuentes y los scripts siguen siendo tarea de la propia web.