Core Web Vitals y el alojamiento web: ¿qué es lo que realmente puedes controlar?

Los tres indicadores clave de rendimiento web y cómo influye el alojamiento en cada uno de ellos

Pintura con mayor contenido (LCP)

El LCP mide el tiempo que tarda en cargarse el elemento visible más grande de una página. En la mayoría de los sitios web, suele ser una imagen principal, un bloque de título grande o una miniatura de vídeo. Se considera bueno un tiempo inferior a 2,5 segundos. Se considera malo un tiempo superior a 4 segundos.

El alojamiento web es el factor clave para el LCP. El tiempo hasta el primer byte (TTFB) del servidor es el primer retraso en la cadena del LCP. Antes de que el navegador pueda empezar a cargar el contenido principal, tiene que recibir el primer byte del documento HTML del servidor. Una respuesta lenta del servidor implica un LCP lento, independientemente de lo optimizada que esté la página en el front-end.

En un NVMe bien configurado, el TTFB es inferior a 200 milisegundos. En un plan de alojamiento compartido con un servidor saturado, suele superar los 600 u 800 milisegundos. Esa diferencia por sí sola puede hacer que el LCP pase de «bueno» a «necesita mejorar», sin que haya ni una sola imagen de tamaño excesivo.

Interacción con Next Paint (INP)

El INP sustituyó al First Input Delay (FID) como indicador Core Web Vital en 2024. Mide la latencia de todas las interacciones de una página a lo largo de toda la sesión, no solo de la primera. El umbral considerado bueno es inferior a 200 milisegundos.

El INP depende principalmente de la ejecución de JavaScript y de la renderización del navegador, no del tiempo de respuesta del servidor. Los pesados marcos de trabajo de JavaScript del front-end, los complementos sobrecargados y el exceso de scripts de terceros son los principales factores que contribuyen a un INP deficiente. El alojamiento tiene un efecto indirecto: un servidor más rápido permite que la página termine de cargarse antes, lo que le da al navegador más tiempo para procesar el JavaScript antes de que el usuario empiece a interactuar.

Desplazamiento acumulativo del diseño (CLS)

El CLS mide cuánto se desplaza el contenido de forma inesperada durante la carga de la página. Una puntuación inferior a 0,1 es buena. El CLS depende casi por completo del front-end y no se ve afectado de forma significativa por la configuración del servidor. Las causas más habituales son las dimensiones de imagen sin definir, las fuentes que se cargan tarde y el contenido inyectado dinámicamente.

Tiempo hasta el primer byte: la contribución directa de tu servidor

El TTFB es la variable de alojamiento más fácil de controlar en el rendimiento de Core Web Vitals. Representa el tiempo que transcurre desde que un navegador envía una solicitud HTTP hasta que recibe el primer byte de la respuesta. Incluye el tiempo de resolución de DNS, el establecimiento de la conexión (TCP y TLS) y el tiempo de procesamiento del servidor.

El tiempo de procesamiento del servidor es algo en lo que tu infraestructura influye directamente. Una aplicación PHP que tiene que generar una página a partir de una consulta a la base de datos en cada solicitud tarda más en responder que una que sirve una versión HTML almacenada en caché. La infraestructura de alojamiento determina la rapidez con la que se sirve esa caché y la eficiencia con la que responde la base de datos cuando la caché no da con lo que busca.

Qué aporta realmente una buena infraestructura de alojamiento al LCP

La diferencia de rendimiento entre los distintos niveles de alojamiento no es solo teórica. Las pruebas independientes realizadas por GTmetrix en la infraestructura NVMe InMotion Hostingmuestran sistemáticamente un TTFB inferior a 200 milisegundos para WordPress en configuraciones VPS optimizadas, frente a los 600 a más de 1000 milisegundos que se registran en entornos de alojamiento compartido de menor nivel o mal configurados.

UltraStack de InMotion, disponible en los planes de VPS gestionado y WordPress , combina NGINX proxy inverso, PHP-FPM para la gestión de procesos, OPcache para el almacenamiento en caché de códigos de operación de PHP y Redis para el almacenamiento en caché de objetos. Cada componente resuelve un cuello de botella diferente en la cadena de respuesta del servidor.

NGINX proxy inverso: gestiona el servicio de archivos estáticos y la gestión de conexiones de forma más eficiente que Apache bajo carga simultánea. Los recursos estáticos (CSS, JS, imágenes) son servidos directamente por NGINX pasar por PHP.

PHP-FPM: gestiona un grupo de procesos de trabajo PHP persistentes. Elimina la sobrecarga que supone crear un nuevo proceso PHP para cada solicitud, que es precisamente lo que hace que Apache con mod_php se ralentice bajo carga.

OPcache: almacena en memoria el código byte de los scripts PHP precompilados. Los archivos WordPress se compilan una sola vez y se sirven desde la memoria en las solicitudes posteriores, lo que reduce considerablemente el tiempo de ejecución de PHP.

Caché de objetos de Redis: almacena en memoria los resultados de consultas a la base de datos que consumen muchos recursos. Una página que requeriría 20 consultas a la base de datos en un WordPress sin caché se puede servir desde Redis con una sola lectura de memoria.

La ubicación del servidor y su efecto en los Core Web Vitals

La distancia física entre tu servidor y tus usuarios aumenta la latencia. Cada 160 km de ruta de red añaden aproximadamente 1 milisegundo al tiempo de ida y vuelta. Para los usuarios de tu mercado principal, esto es insignificante. Para los usuarios que se encuentran al otro lado del mundo, se suma al TTFB y se convierte en un factor importante que influye en el LCP.

InMotion cuenta con centros de datos en Los Ángeles (California) y Ámsterdam (Países Bajos). Para las empresas cuyo público se encuentra principalmente en EE. UU. o Europa, estas ubicaciones cubren la mayor parte de la base de usuarios con conexiones de baja latencia. En el caso de un público global, la integración de la red de distribución de contenido (CDN) redirige el contenido estático a través de nodos periféricos más cercanos a los usuarios, lo que reduce la carga del servidor de origen y mejora el rendimiento percibido, independientemente de la ubicación del servidor de origen.

Las métricas que no puedes solucionar solo con el alojamiento web

Hay dos situaciones que provocan unos Core Web Vitals deficientes y que ninguna mejora en el alojamiento puede solucionar.

Lo primero es el exceso de código en el front-end. Una página que carga 40 scripts de terceros, una imagen principal sin optimizar de 8 MB y un tema que ejecuta 200 KB de JavaScript sin dividir obtendrá una puntuación baja en LCP e INP, independientemente de la velocidad del servidor. Una vez que el TTFB está por debajo de los 200 ms, el tiempo restante de LCP corresponde casi en su totalidad al tiempo de descarga y renderización. Eso requiere optimización de imágenes, auditoría de scripts y trabajo en el rendimiento del front-end.

La segunda es una implementación deficiente del almacenamiento en caché. Un entorno de alojamiento gestionado con NVMe y NGINX mostrando páginas lentas si la aplicación no implementa correctamente el almacenamiento en caché del lado del servidor. WordPress que no tienen un plugin de almacenamiento en caché adecuado configurado para funcionar con la pila del servidor generan ejecuciones de PHP de página completa en cada solicitud, lo que anula las ventajas del rápido hardware subyacente.

Relacionado: Core Web Vitals: la nueva señal de posicionamiento de Google, donde se explican en detalle las herramientas de medición y los métodos de diagnóstico.

Una lista de verificación práctica para agencias que gestionan sitios web de clientes

Para las agencias que se encargan de las puntuaciones de Core Web Vitals en nombre de sus clientes, es importante ocuparse de la capa de alojamiento e infraestructura antes de empezar con la optimización del front-end. Un servidor rápido con un almacenamiento en caché adecuado proporciona al front-end la base que necesita.

• Comprueba que el TTFB sea inferior a 200 ms con GTmetrix o PageSpeed Insights. Si supera los 400 ms, lo primero que debes revisar es el entorno de alojamiento.
• Asegúrate de que el almacenamiento en caché del lado del servidor esté activo. En el caso de WordPress, W3 Total Cache WP Super Cache, configurados para la pila de servidores específica, evitan la ejecución innecesaria de PHP.
• Asegúrate de que NGINX LiteSpeed sirvan los recursos estáticos directamente, sin intervención de PHP. Esto depende de la configuración, así que vale la pena que lo compruebes con tu proveedor de alojamiento.
• Comprueba si el almacenamiento en caché de objetos de Redis o Memcached está activo y configurado para la WordPress .
• Comprueba la versión de PHP. PHP 8.x ofrece mejoras significativas en el rendimiento con respecto a la versión 7.x y debería ser la opción predeterminada para cualquier WordPress en producción.

Relacionado: Comparativa de los proveedores de alojamiento web más rápidos, con pruebas de rendimiento y detalles sobre la infraestructura relevantes para el rendimiento del LCP.

El alojamiento VPS de InMotion, NVMe, ofrece de forma constante un TTFB inferior a 200 ms con UltraStack activado. Descubre cómo nuestra infraestructura influye en tus puntuaciones de Core Web Vitals: inmotionhosting.com/vps-hosting.