Alojamiento y rendimiento
Cómo aceleramos WordPress: LiteSpeed Enterprise, LSCache y Redis por sitio
La solicitud más rápida de WordPress es la que nunca se ejecuta; así es como nuestra infraestructura responde a la mayoría de las visitas desde la memoria caché antes de que se invoque PHP o MySQL, y lo que eso significa para Core Web Vitals.
La solicitud más rápida es la que nunca se ejecuta
Una solicitud estándar de WordPress es costosa. El servidor web transfiere el control a PHP, PHP inicia WordPress, ejecuta los complementos, consulta MySQL unas cuantas docenas de veces, ensambla el código HTML y solo entonces envía los bytes de vuelta. En un sitio con mucho tráfico, todo ese proceso ocurre para cada visitante, y es ahí a donde se va casi todo el tiempo hasta el primer byte.
Nuestra respuesta consiste en asegurarnos de que, en la mayoría de las visitas, nada de eso ocurra. En todos los sitios que alojamos (más de 100 000 sitios PBN además del hosting administrado de WordPress principal), la gran mayoría de las visualizaciones de páginas front-end se sirven como una página completa prerrenderizada directamente desde la caché, sin invocar PHP ni tocar la base de datos. El resto de esta publicación trata sobre cómo encajan las capas que hacen que eso sea posible y dónde se gana su lugar cada una.
El enfoque importante es que no son cachés que compiten entre los que debes elegir. La caché de página completa, la caché de objetos y el borde de la CDN capturan cada uno una clase diferente de petición, y el valor reside en cómo se transfieren las tareas entre ellos.
LiteSpeed Enterprise + LSCache: la capa de página completa
Cada sitio funciona con LiteSpeed Enterprise con LSCache a nivel de servidor. Cuando una respuesta del front-end es almacENABLE_CACHEble, el servidor web la marca con las cabeceras de control de caché y etiquetas de LiteSpeed, y LiteSpeed sirve la página completa directamente en la siguiente solicitud: sin proceso PHP generado ni consulta MySQL emitida. Esa es la mayor palanca individual para el TTFB de WordPress, porque elimina todo el arranque de la aplicación de la ruta crítica.
Como LSCache vive dentro del servidor web en lugar de en un plugin de PHP, comienza a funcionar antes en el ciclo de vida de la petición y almacena las páginas en un formato que el servidor puede servir instantáneamente. Un rastreador de caché mantiene las páginas populares activas, de modo que el primer visitante tras una purga no es quien asume el coste de regenerar la página. El resultado es un TTFB notablemente más bajo y constante que el de una caché basada únicamente en un plugin añadida a una pila genérica, donde la caché sigue estando detrás de PHP.
Nuestro propio complemento de caché de calidad de repositorio viene preinstalado y se actualiza automáticamente en cada sitio, conectando WordPress con LSCache correctamente desde el primer momento. En un origen que no sea LiteSpeed, simplemente no emite cabeceras de página completa y se aparta, mientras que la caché de objetos y las reglas de exclusión siguen haciendo su trabajo; de modo que un sitio migrado nunca se queda en un estado roto y semiconfigurado.
Manteniéndose rápido sin servir contenido obsoleto: ESI y purga automática inteligente
El almacenamiento en caché agresivo de páginas completas tiene dos modos de fallo clásicos: mostrar a un usuario conectado la página de otra persona, y mostrar a cualquiera una página que debería haber cambiado. Ambos se resuelven en la capa de caché en lugar de almacenando menos en caché.
ESI (Edge Side Includes) nos permite almacenar la página en caché a la vez que dejamos huecos para las partes que deben permanecer dinámicas. En una tienda de WooCommerce, las páginas de catálogo, producto y categoría se sirven mediante caché de página completa para lograr el TTFB más rápido posible, mientras que ESI procesa el fragmento del carrito, los totales del mini-carrito y el estado de la cuenta en cada solicitud. El carrito, el pago (checkout), mi cuenta y cualquier página de nonce o sesión se excluyen de forma predeterminada. Los compradores siempre ven su propia cesta y un proceso de pago operativo; además, todos siguen recibiendo la tienda desde la caché.
La frescura se gestiona mediante el borrado automático inteligente. Los ganchos de borrado se activan automáticamente cuando cambian el contenido, los productos, los precios o los pedidos, de modo que las páginas en caché relevantes se actualizan de inmediato en lugar de depender de un temporizador, y también puedes realizar un borrado bajo demanda desde el panel de control o desde el interior de WordPress. El borrado basado en etiquetas significa que editar una entrada borra dicha entrada y sus archivos, pero no toda la caché, por lo que una sola edición no reinicia en frío todo el sitio.
Caché de objetos Redis por sitio: para lo que no puede ser una página completa
No todas las solicitudes pueden ser una página estática completa. Las sesiones iniciadas, el panel de administración de WordPress, los carritos de WooCommerce, las búsquedas y los fragmentos dinámicos que deja ESI deben ejecutar PHP. Para esos casos, el objetivo cambia de «omitir la aplicación» a «omitir la base de datos».
Cada sitio cuenta con su propio objeto de caché Redis dedicado. WordPress almacena en caché los resultados de las lecturas repetidas de la base de datos —opciones, transitorios, consultas de publicaciones y términos, datos de productos y sesiones de WooCommerce— en la memoria, de modo que no se ejecute la misma consulta en MySQL en cada acceso. El efecto es más visible exactamente donde la caché de página completa no puede ayudar: paneles más rápidos, carritos más rápidos y una carga de la base de datos mucho menor bajo tráfico.
El caché de objetos es por sitio, no compartido, lo cual importa tanto para el rendimiento como para el aislamiento. Combinado con la limitación de velocidad de la base de datos por sitio, las consultas pesadas o mal redactadas de un sitio no pueden agotar la base de datos de sus vecinos. Puedes leer más sobre cómo encaja toda la configuración multicapa en nuestra página de funciones de caché, y sobre los límites entre inquilinos en la sección de aislamiento.
El borde y el transporte subyacente
La caché que se aloja en el origen todavía tiene que cruzar la red. Delante del servidor se sitúa el extremo de la CDN, por lo que los recursos estáticos y las páginas almacenables en caché se sirven desde un punto de presencia cercano al visitante, y el origen permanece tranquilo incluso bajo carga. En nuestra línea de alojamiento sin footprint-free, ese mismo extremo es un grupo de múltiples CDN repartido entre varios proveedores, que cumple un objetivo de footprint además de uno de rendimiento; en WordPress estándar es simplemente una capa rápida y de buen comportamiento que mantiene los orígenes inactivos.
Por debajo, no se escatima en lo fundamental. Los sitios funcionan con almacenamiento NVMe y HTTP/3, de modo que los bytes que el caché envía llegan a través de un transporte moderno y multiplexado, con almacenamiento rápido detrás de cada fallo de caché. Ninguna de estas capas es un complemento: LiteSpeed, LSCache, Redis por sitio, NVMe y HTTP/3 forman la base en todos los planes, no un nivel de ampliación de pago.
Qué mueve realmente los Core Web Vitals
Vale la pena ser preciso, porque a menudo se exagera la capacidad del hosting en lo que respecta a Core Web Vitals. El TTFB es la parte de la ecuación de la que es responsable el servidor, y la pila de caché superior es lo que logra reducirlo: una página completa en caché servida mediante HTTP/3 desde el borde (edge) alcanza el valor de TTFB más bajo posible. Dado que el TTFB es el factor determinante del Largest Contentful Paint, un origen rápido proporciona a todas las métricas posteriores una ventaja inicial que de otro modo no podrían tener.
Pero LCP, CLS y INP se deciden principalmente en el navegador, por la propia página: una imagen principal sin optimizar, CSS y JavaScript que bloquean el renderizado, un diseño que se desplaza al cargar las fuentes y los anuncios, y un trabajo pesado en el hilo principal por parte de los plugins. Ninguna cantidad de caché en el servidor soluciona una imagen principal de 2 MB o un tema que incluye megabytes de JavaScript. Un hosting honesto hace que la contribución del servidor sea prácticamente gratuita y consistente, y luego le corresponde al sitio mantener el front-end optimizado.
Esa división del trabajo es el modelo mental útil. Garantizamos que la solicitud llegue rápido al navegador y se mantenga rápida bajo tráfico; tú mantienes la carga útil pequeña y estable. Donde ambos se encuentran —el calentamiento de caché, la entrega perimetral y el mantenimiento de una base de datos receptiva para que las páginas dinámicas no se detengan— es exactamente donde nuestra pila está optimizada, y es lo que hace que el WordPress administrado en esta plataforma sea más rápido que el mismo sitio en un servidor genérico.
Preguntas frecuentes
¿Todavía necesito un plugin de caché como WP Rocket?
No. El almacenamiento en caché de páginas completas se gestiona a nivel de servidor web mediante LSCache de LiteSpeed, y nuestro propio complemento de caché —preinstalado y actualizado automáticamente— conecta WordPress correctamente a este, respaldado por una caché de objetos Redis por sitio. Instalar un segundo complemento de caché de páginas completas suele entrar en conflicto con la caché a nivel de servidor en lugar de ayudar, por lo que no es necesario ni se recomienda.
¿La caché romperá mi carrito de WooCommerce o mis páginas de inicio de sesión?
No. El carrito, el proceso de pago (checkout), mi cuenta y cualquier página con nonce o de sesión se excluyen de la caché por defecto, y ESI mantiene el fragmento del carrito y los totales activos en páginas que por lo demás están en caché. Los compradores siempre ven su propia cesta y un proceso de pago funcional mientras la tienda sigue cargándose desde la caché.
¿Cómo se mantiene la caché actualizada cuando publico o edito?
El borrado automático inteligente se activa en los ganchos de WordPress relevantes, por lo que publicar, editar contenido o cambiar un producto, precio o pedido borra solo las páginas afectadas y sus archivos —no toda la caché— y un rastreador las vuelve a precargar. También puedes borrar bajo demanda desde el panel de control o desde el interior de WordPress.
¿Puede el hosting por sí solo brindarme unos Core Web Vitals perfectos?
Te ofrece el mejor TTFB posible, que es la parte del servidor y una ventaja inicial para el Largest Contentful Paint. Pero el LCP, el CLS y el INP dependen en gran medida de la propia página: los tamaños de las imágenes, los recursos que bloquean el renderizado, la estabilidad del diseño y el JavaScript del hilo principal. Nuestra pila hace que la contribución del servidor sea rápida y coherente; mantener ligera la carga útil del front-end es lo que cierra el resto de la brecha.
Relacionados
Pruébalo gratis durante 14 días
Crea tus primeros sitios gratis durante 14 días, sin tarjeta. ¿Vas a mudar una red existente? Tu primera migración corre por nuestra cuenta.
Empieza gratis