Alojamiento y rendimiento
Cómo hacemos que WordPress sea rápido: LiteSpeed Enterprise, LSCache y Redis por sitio
La solicitud de WordPress más rápida es la que nunca se ejecuta: descubra cómo nuestro stack responde a la mayoría de las visitas desde la caché antes de que se invoquen PHP o MySQL, y lo que esto 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 la tarea a PHP, PHP inicia WordPress, ejecuta los plugins, consulta MySQL unas cuantas docenas de veces, ensambla el HTML y solo entonces devuelve los bytes. En un sitio concurrido, todo este proceso ocurre para cada visitante, y es ahí donde se consume casi todo su tiempo hasta el primer byte.
Nuestra respuesta es asegurarnos de que, para la mayoría de las visitas, nada de esto ocurra en absoluto. En todos los sitios que alojamos —más de 100.000 sitios PBN más WordPress administrado estándar—, la gran mayoría de las páginas vistas de la interfaz pública se sirven como una página completa prerrenderizada directamente desde la caché, sin invocar PHP ni interactuar con la base de datos. El resto de esta publicación trata sobre cómo encajan las capas que hacen esto posible y dónde se gana su lugar cada una de ellas.
El enfoque clave es que estas no son cachés que compiten entre sí para que usted elija una. La caché de página completa, la caché de objetos y el borde de la CDN capturan cada uno un tipo diferente de solicitud, y el verdadero valor radica en cómo se complementan y transfieren el control entre sí.
LiteSpeed Enterprise + LSCache: la capa de página completa
Cada sitio se ejecuta en LiteSpeed Enterprise con LSCache a nivel de servidor. Cuando una respuesta de front-end se puede almacenar en caché, el servidor web la estampa con encabezados LiteSpeed cache-control y de etiquetas, y LiteSpeed sirve la página completa directamente en la siguiente petición — no se genera ningún proceso de PHP ni se emite ninguna consulta de MySQL. Esa es la mayor palanca individual para el TTFB de WordPress, porque elimina por completo el arranque de la aplicación de la ruta crítica.
Debido a que LSCache reside dentro del servidor web en lugar de en un plugin de PHP, comienza a operar antes en el ciclo de vida de la solicitud y almacena las páginas en un formato que el servidor puede purgar al instante. Un rastreador de caché mantiene listas las páginas más populares, por lo que el primer visitante tras una purga no asume la carga de regenerar la página. El resultado es un TTFB notablemente menor y más constante que el de una caché basada únicamente en plugins acoplada a una infraestructura genérica, donde la caché aún se encuentra detrás de PHP.
Nuestro propio plugin de caché de nivel de repositorio se entrega preinstalado y con actualización automática en cada sitio, conectando WordPress con LSCache de forma correcta desde el primer momento. En un servidor de origen que no sea LiteSpeed, simplemente no emite encabezados de página completa y se aparta del camino, mientras que la caché de objetos y las reglas de exclusión siguen haciendo su trabajo; de este modo, un sitio migrado nunca queda en un estado roto a medio configurar.
Mantener la rapidez 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: servir a un usuario conectado la página de otra persona y servir a cualquiera una página que debería haber cambiado. Ambos se resuelven en la capa de almacenamiento en caché en lugar de almacenar menos en caché.
ESI (Edge Side Includes) nos permite almacenar la página en caché mientras deja espacios dinámicos para las partes que deben permanecer activas. En una tienda de WooCommerce, las páginas de catálogo, productos y categorías se sirven mediante una 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 minicarrito y el estado de la cuenta por cada solicitud. El carrito, la pantalla de pago, mi cuenta y cualquier página con nonce o de sesión quedan excluidos de forma predeterminada. Los compradores siempre ven su propia cesta y un proceso de pago funcional; al mismo tiempo, todos continúan recibiendo el escaparate desde la caché.
La actualización se gestiona mediante un purgado automático inteligente. Los ganchos de purgado se activan automáticamente cuando cambian el contenido, los productos, los precios o los pedidos, de modo que las páginas en caché pertinentes se actualizan de inmediato en lugar de depender de un temporizador, y usted también puede purgar a petición desde el panel de control o desde el interior de WordPress. El purgado basado en etiquetas implica que editar una entrada solo borra dicha entrada y sus archivos —no toda la caché—, por lo que una sola edición no provoca un arranque en frío de 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 completa estática. Las sesiones con inicio de sesión, la administración de WordPress, los carritos de WooCommerce, las búsquedas y los fragmentos dinámicos que ESI mantiene activos deben ejecutar PHP. Para ellos, el objetivo pasa de 'omitir la aplicación' a 'omitir la base de datos'.
Cada sitio obtiene su propia caché de objetos Redis dedicada. WordPress almacena en memoria los resultados de las lecturas repetidas de la base de datos (opciones, datos transitorios, búsquedas de entradas y términos, así como datos de productos y sesiones de WooCommerce), de modo que no se ejecuta la misma consulta en MySQL con cada visita. El efecto es más visible exactamente donde la caché de página completa no puede ayudar: paneles de administración más rápidos, carritos más rápidos y una carga de base de datos mucho menor bajo tráfico elevado.
La caché de objetos es independiente para cada sitio y no compartida, lo cual es fundamental tanto para el rendimiento como para el aislamiento. Al combinarse con la limitación de la base de datos por sitio, las consultas pesadas o mal optimizadas de un sitio no pueden agotar los recursos de la base de datos para los demás. Puede obtener más información sobre cómo interactúa toda esta configuración multicapa en nuestra página de funciones de caché, y sobre los límites entre clientes en la sección de aislamiento.
El edge y el transporte subyacente
La caché que reside en el servidor de origen todavía tiene que atravesar la red. Delante del servidor se encuentra el perímetro de la CDN, de modo 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 desahogado incluso bajo carga. Para nuestra línea de alojamiento libre de huellas (footprint-free), ese mismo perímetro es un conjunto multi-CDN distribuido entre varios proveedores, lo que cumple un objetivo respecto a la huella SEO además de uno de rendimiento; en el WordPress convencional, se trata simplemente de una capa rápida y eficiente que mantiene los orígenes inactivos.
En el fondo, no se escatima en lo fundamental. Los sitios funcionan con almacenamiento NVMe con HTTP/3, por lo que los bytes que envía la caché llegan a través de un transporte moderno y multiplexado, con un almacenamiento rápido detrás de cada fallo de caché (cache miss). Ninguna de estas capas es un complemento: LiteSpeed, LSCache, Redis por sitio, NVMe y HTTP/3 son la base de cada plan, no un nivel de venta adicional.
Qué influye realmente en Core Web Vitals
Vale la pena ser precisos, ya que a menudo se exagera el impacto del alojamiento en los Core Web Vitals. El TTFB es la parte de la ecuación que corresponde al servidor, y la pila de almacenamiento en caché mencionada arriba es lo que lo reduce: una página completa en caché servida a través de HTTP/3 desde el extremo es prácticamente lo más bajo que puede llegar a ser el TTFB. Dado que el TTFB es el punto de partida del Largest Contentful Paint, un origen rápido proporciona a cada métrica posterior una ventaja inicial que de otro modo no podría obtener.
Sin embargo, LCP, CLS e INP se definen principalmente en el navegador, por la propia página: una imagen principal sin optimizar, CSS y JavaScript que bloquean la renderización, un diseño que se desplaza a medida que se cargan fuentes y anuncios, y una sobrecarga en el hilo principal provocada por los complementos. Ninguna cantidad de caché en el servidor soluciona una imagen principal de 2 MB o un tema que carga megabytes de JavaScript. Un alojamiento web transparente hace que la contribución del servidor sea prácticamente imperceptible y constante; a partir de ahí, depende del sitio web mantener la interfaz ligera.
Esa división del trabajo es el modelo mental adecuado. Nosotros garantizamos que la solicitud llegue con rapidez al navegador y se mantenga rápida bajo condiciones de tráfico; usted mantiene el volumen de datos reducido y estable. El punto de convergencia entre ambos —el calentamiento de la caché, la entrega perimetral y la preservación de la capacidad de respuesta de la base de datos para evitar demoras en las páginas dinámicas— es precisamente donde nuestra infraestructura está optimizada, y es lo que hace que el WordPress gestionado en esta plataforma sea más veloz que ese mismo sitio en un alojamiento genérico.
Preguntas frecuentes
¿Todavía necesito un plugin de caché como WP Rocket?
No. El almacenamiento en caché de página completa se gestiona en el servidor web mediante LSCache de LiteSpeed, y nuestro propio plugin de caché —preinstalado y actualizado automáticamente— conecta WordPress con él correctamente, respaldado por una caché de objetos Redis para cada sitio. Añadir un segundo plugin de caché de página completa suele entrar en conflicto con la caché a nivel de servidor en lugar de ayudar, por lo que no es necesario ni se recomienda.
¿Afectará el almacenamiento en caché a mi carrito de WooCommerce o a las páginas para usuarios que han iniciado sesión?
No. El carrito, el pago, my-account y cualquier página de nonce o de sesión están excluidos de la caché de forma predeterminada, y ESI mantiene el fragmento del carrito y los totales actualizados en páginas que de otro modo estarían en caché. Los compradores siempre ven su propia cesta y un proceso de pago funcional mientras la tienda se sigue cargando desde la caché.
¿Cómo se mantiene actualizada la caché cuando publico o edito?
La purga automática inteligente se activa en los hooks de WordPress pertinentes, por lo que publicar, editar contenido o cambiar un producto, precio o pedido solo borra las páginas afectadas y sus archivos, no toda la caché, y un rastreador las vuelve a precargar. También puede purgar a petición desde el panel de control o desde el interior de WordPress.
¿Puede el alojamiento por sí solo proporcionarme unos Core Web Vitals perfectos?
Esto le proporciona el mejor TTFB posible, que es la contribución del servidor y una ventaja inicial para Largest Contentful Paint. Sin embargo, LCP, CLS e INP se definen en gran medida por la propia página: el tamaño de las imágenes, los recursos que bloquean el renderizado, la estabilidad del diseño y el código JavaScript del hilo principal. Nuestra infraestructura hace que la aportación del servidor sea rápida y constante; mantener reducida la carga del front-end es lo que cierra la brecha restante.
Relacionado
Pruébelo gratis durante 14 días
Ponga en marcha sus primeros sitios gratis durante 14 días — sin tarjeta. ¿Va a trasladar una red existente? Las migraciones son gratuitas y sin límite.
Empiece gratis