El alojamiento administrado para WordPress está diseñado para que WordPress funcione bien. Ofrece un entorno optimizado para el comportamiento de WordPress bajo carga, su gestión de la caché y la ejecución de PHP.
Los temas de bloques no cambian los fundamentos del alojamiento, pero sí cambian dónde aparecen los cuellos de botella en el rendimiento. Aquí es donde el papel del proveedor de alojamiento se hace más evidente. La infraestructura por sí sola no basta para que un sitio sea rápido; una infraestructura mal configurada se nota mucho en los flujos de trabajo modernos de WordPress, sobre todo cuando hay bloques dinámicos, el Editor del sitio, vistas previas y sesiones de usuario conectadas.
Para entender por qué, conviene analizar qué ocurre realmente durante una solicitud de página y cómo las decisiones de alojamiento afectan a la experiencia del usuario cuando se utiliza una arquitectura basada en bloques.
¿Qué pasa cuando se solicita una página de WordPress?
Veamos una solicitud sencilla que devuelve una respuesta 200 OK.
1. El navegador envía la solicitud
Un usuario introduce una URL o hace clic en un enlace. Si la dirección IP del servidor aún no está almacenada en caché, el navegador realiza una consulta DNS. A continuación, abre una conexión TCP y negocia una sesión TLS segura.
Antes de que WordPress entre en acción, la solicitud pasa por el servidor web y cualquier capa configurada, como cortafuegos o proxies inversos.
2. Comprobación de la caché
El servidor comprueba si existe una versión válida en caché de la página solicitada.
Si hay una caché HTML de página completa disponible y válida, WordPress no se ejecuta. La respuesta almacenada en caché se devuelve inmediatamente.
Si no hay ninguna entrada en la caché, o si se omite el almacenamiento en caché de forma intencionada para usuarios registrados, vistas previas o endpoint específicos, la solicitud se reenvía a WordPress.
3. WordPress se inicia
WordPress carga sus archivos principales, los plugins activos y el tema activo. Inicializa los hooks y se prepara para resolver la solicitud.
En esta fase, WordPress aún no genera ningún resultado. Determina qué contenido se está solicitando.
4. Resolución de la consulta principal
Usando reglas de reescritura y variables de consulta, WordPress crea y ejecuta la consulta principal a la base de datos. Determina si la solicitud es para una entrada individual, una página, un archivo, un resultado de búsqueda u otro tipo de contenido.
Solo después de esto comienza la selección de la plantilla.
5. Resolución de la plantilla
Aquí es donde los temas de bloques y los clásicos empiezan a diferir estructuralmente.
Temas clásicos
WordPress evalúa la jerarquía de plantillas y selecciona el archivo de plantilla PHP adecuado, como single.php, page.php o archive.php. Ese archivo contiene código PHP que genera HTML directamente.
Temas de bloques
WordPress comprueba si existe una plantilla de bloque personalizada en la base de datos. Si existe, tiene prioridad. Si no, WordPress recurre al archivo de plantilla de bloque incluido en el tema, como single.html o index.html.
A continuación, la plantilla seleccionada se procesa a través del sistema de renderizado de bloques.
6. Montaje del diseño
Temas clásicos
El diseño se crea mediante plantillas PHP. Estas plantillas combinan código de marcado, lógica y llamadas a funciones para generar código HTML.
Temas de bloques
El diseño se crea a partir de plantillas de bloques, partes de plantillas y contenido de las entradas. El código de los bloques se analiza y cada bloque se convierte a HTML antes de generar el resultado final.
7. Estructura del contenido
Temas clásicos
El contenido de las entradas se almacena principalmente en formato HTML en la base de datos. Durante la visualización, WordPress aplica filtros, shortcodes y otros procesos antes de renderizarlo.
Temas de bloques
El contenido de los bloques se almacena como HTML con metadatos de bloque incrustados, por ejemplo:
<!-- wp:image {"id":123} -->
<img src="logo.png">
<!-- /wp:image -->Cuando WordPress procesa este contenido, analiza la estructura del bloque, interpreta los atributos y el anidamiento, y aplica atributos y estilos a nivel de bloque, como el espaciado, la alineación y la tipografía, antes de generar el HTML final.
8. Representación dinámica
La generación dinámica está presente tanto en los temas clásicos como en los de bloques. Muchos temas clásicos se basan en consultas personalizadas, widgets o shortcodes que generan contenido en tiempo de ejecución.
En las arquitecturas basadas en bloques, el comportamiento dinámico se formaliza a través de bloques dinámicos. Por ejemplo, un bloque de bucle de consulta genera su marcado durante la solicitud utilizando PHP en lugar de almacenar HTML estático en la base de datos.
Cuando se omite el almacenamiento en caché de página completa, este flujo de trabajo de renderización se produce en cada solicitud.
9. Estilo
En los temas clásicos, el estilo suele proporcionarse a través de archivos CSS estáticos que el tema pone en cola.
En los temas de bloques, los estilos globales definidos en theme.json y los metadatos de los bloques permiten a WordPress generar automáticamente un CSS coherente. Esto reduce la necesidad de grandes hojas de estilo creadas a mano y centraliza la configuración del diseño.
10. Resultado final
Una vez procesadas las plantillas, el contenido, los bloques y los estilos, WordPress genera la respuesta HTML final.
El servidor envía este paquete de datos (o payload) al navegador. Si está configurado, la respuesta puede almacenarse en caché para futuras solicitudes.
Dónde desplazan la carga los temas de bloques
El ciclo de vida de las solicitudes que acabas de ver se aplica tanto a los temas clásicos como a los de bloques. WordPress sigue resolviendo consultas, seleccionando plantillas, ejecutando PHP y devolviendo HTML.
Lo que cambia con los temas de bloques no es la base, sino dónde se realiza el trabajo y cuándo no se puede omitir.
En primer lugar, las plantillas pueden almacenarse en la base de datos. Cuando un usuario edita una plantilla en el Editor del sitio, WordPress guarda esa versión y le da prioridad frente al archivo del directorio del tema. Esto aporta flexibilidad, pero también significa que los despliegues y la invalidación de la caché deben tener en cuenta las plantillas almacenadas en la base de datos.
En segundo lugar, los bloques dinámicos hacen que el renderizado en tiempo de ejecución sea más visible. Los temas clásicos pueden generar contenido dinámico mediante consultas personalizadas, widgets o shortcodes. Los temas de bloques formalizan este patrón a través de bloques dinámicos, como el bloque Query Loop. Cuando se omite la caché de página completa, estos bloques ejecutan código PHP durante la solicitud.
En tercer lugar, los flujos de trabajo del editor dependen en gran medida de los endpoints REST. Guardar plantillas, actualizar estilos globales, previsualizar cambios e interactuar con patrones generan solicitudes sin almacenar en caché. Estas rutas dependen directamente de la ejecución de PHP, el rendimiento de la base de datos y el almacenamiento en caché de objetos.
Por último, los estilos globales definidos en theme.json centralizan las decisiones de diseño. Cuando cambian los estilos o la estructura de las plantillas, la coordinación de la caché cobra mayor importancia para garantizar que tanto los visitantes como los editores vean inmediatamente los cambios.
Ninguno de estos cambios requiere un tipo de alojamiento diferente. Sin embargo, sí que hacen más evidentes ciertas deficiencias de la infraestructura, sobre todo en situaciones en las que no se utiliza la caché y se ha iniciado sesión.
Teniendo esto en cuenta, el siguiente paso es ver qué debe gestionar un entorno de alojamiento bien configurado en una configuración basada en bloques.
Consideraciones de alojamiento para sitios basados en bloques
Los temas basados en bloques no introducen nuevos requisitos de alojamiento. Hacen que sea más importante que los ya existentes funcionen correctamente.
Un entorno bien configurado debe tener en cuenta tanto las rutas con caché como las que no la tienen, especialmente para los editores y los usuarios que han iniciado sesión.
Almacenamiento en caché coordinado entre capas
La caché de página completa sigue siendo la capa de rendimiento más eficaz para el tráfico anónimo. Las páginas públicas deben almacenarse en caché de forma intensiva, mientras que las vistas previas, las sesiones con usuario registrado y los endpoints específicos se omiten automáticamente.
El almacenamiento en caché de objetos también desempeña un papel importante. Al almacenar en memoria los resultados de consultas repetidas y las estructuras de datos calculadas, una caché de objetos reduce la carga de la base de datos y mejora la capacidad de respuesta tanto del frontend como del backend.
Hay que coordinar la invalidación de la caché. Cuando se actualizan contenidos, plantillas o estilos globales, las páginas relacionadas deben actualizarse rápidamente. Una mala coordinación de la caché puede provocar diseños desactualizados, estilos incoherentes o un comportamiento confuso en las vistas previas.
Una CDN complementa esta configuración almacenando en caché activos estáticos como imágenes, fuentes y scripts más cerca de los visitantes.
La caché no se reduce a una sola capa. Se trata de cómo interactúan estas capas entre sí.
Capacidad de PHP y rendimiento en tiempo de ejecución
Cuando se omite la caché de página completa, WordPress ejecuta PHP para resolver consultas, generar plantillas y procesar bloques dinámicos.
Por eso es importante planificar la capacidad de PHP. El entorno debe proporcionar suficientes hilos PHP para gestionar la concurrencia prevista sin que se acumulen colas. Los límites de memoria deben configurarse para evitar el intercambio de memoria bajo carga.
OPcache debe estar activado y configurado correctamente para que no haya que recompilar el código byte de PHP una y otra vez. Durante los despliegues, OPcache debe actualizarse para que el código actualizado se ejecute de inmediato.
Estas prácticas se aplican a todos los sitios de WordPress, pero los flujos de trabajo basados en bloques pueden hacer que los problemas de rendimiento sean más evidentes cuando el renderizado es dinámico.
Almacenamiento en caché de la base de datos y de objetos
Las plantillas de bloques personalizadas en el Editor del sitio se almacenan en la base de datos. El contenido de los bloques incluye metadatos estructurados que WordPress analiza antes de mostrarlos. Aunque este procesamiento es eficiente, sigue dependiendo de la capacidad de respuesta de la base de datos cuando se omite el almacenamiento en caché.
Una caché de objetos persistente reduce las consultas repetidas y ayuda a estabilizar el rendimiento tanto para los visitantes del frontend como para los editores que trabajan en el panel de control.
Observabilidad y monitorización
A medida que la actividad se va desplazando hacia las rutas de ejecución, la visibilidad cobra mayor importancia. Los administradores y los propietarios de los sitios web deberían supervisar:
- Índices de aciertos de caché
- Utilización de los workers PHP y longitud de la cola
- El rendimiento de las consultas a la base de datos
- Tiempos de respuesta de la API REST
- Tiempo hasta el primer byte para las solicitudes con caché y sin caché
Los temas de bloques no requieren una infraestructura especializada. Lo que sí hacen es facilitar la detección de configuraciones de infraestructura poco óptimas.
Gestiona WordPress con los estándares actuales
Los temas de bloques no cambian los requisitos que WordPress exige al alojamiento. Simplemente dejan más claro cuándo no se cumplen esos requisitos.
Cuando las plantillas se almacenan en la base de datos, los bloques dinámicos se renderizan en tiempo de ejecución y los editores dependen de solicitudes REST sin almacenar en caché, la infraestructura deja de ser invisible. En este punto, solo hay dos opciones: o bien el flujo de trabajo es soportado sin problemas, o bien se interpone en el camino.
Ahí es donde el alojamiento administrado para WordPress marca la diferencia.
En Kinsta, todo el stack está diseñado específicamente para adaptarse al funcionamiento actual de WordPress, desde la caché coordinada y la caché de objetos persistentes hasta el rendimiento optimizado de PHP y la distribución global a través de una CDN sobre una potente infraestructura en la nube. El objetivo es garantizar que tanto los visitantes como los editores disfruten de un rendimiento constante, incluso cuando la visualización se realiza de forma dinámica.
El WordPress basado en bloques no es más pesado. Es más transparente. Y cuando los cimientos son sólidos, esa transparencia juega a tu favor.
Bud Kraus has been working with WordPress as an in-class and online instructor, site developer, and content creator since 2009. He has produced instructional videos and written many articles for WordPress businesses.
