{"id":82575,"date":"2026-03-27T10:23:59","date_gmt":"2026-03-27T09:23:59","guid":{"rendered":"https:\/\/kinsta.com\/es\/?p=82575&preview=true&preview_id=82575"},"modified":"2026-03-31T14:09:41","modified_gmt":"2026-03-31T12:09:41","slug":"temas-de-bloques-alojamiento-wordpress","status":"publish","type":"post","link":"https:\/\/kinsta.com\/es\/blog\/temas-de-bloques-alojamiento-wordpress\/","title":{"rendered":"C\u00f3mo los temas modernos basados en bloques est\u00e1n cambiando el alojamiento para WordPress"},"content":{"rendered":"

El alojamiento administrado para WordPress est\u00e1 dise\u00f1ado para que WordPress funcione bien. Ofrece un entorno optimizado para el comportamiento de WordPress bajo carga, su gesti\u00f3n de la cach\u00e9<\/a> y la ejecuci\u00f3n de PHP.<\/p>\n

Los temas de bloques<\/a> no cambian los fundamentos del alojamiento, pero s\u00ed cambian d\u00f3nde aparecen los cuellos de botella en el rendimiento. Aqu\u00ed es donde el papel del proveedor de alojamiento se hace m\u00e1s evidente. La infraestructura por s\u00ed sola no basta para que un sitio sea r\u00e1pido; una infraestructura mal configurada se nota mucho en los flujos de trabajo modernos de WordPress, sobre todo cuando hay bloques din\u00e1micos, el Editor del sitio<\/a>, vistas previas y sesiones de usuario conectadas.<\/p>\n

Para entender por qu\u00e9, conviene analizar qu\u00e9 ocurre realmente durante una solicitud de p\u00e1gina y c\u00f3mo las decisiones de alojamiento afectan a la experiencia del usuario cuando se utiliza una arquitectura basada en bloques.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

\u00bfQu\u00e9 pasa cuando se solicita una p\u00e1gina de WordPress?<\/h2>\n

Veamos una solicitud sencilla que devuelve una respuesta 200 OK<\/a>.<\/p>\n

1. El navegador env\u00eda la solicitud<\/h3>\n

Un usuario introduce una URL o hace clic en un enlace. Si la direcci\u00f3n IP del servidor a\u00fan no est\u00e1 almacenada en cach\u00e9, el navegador realiza una consulta DNS<\/a>. A continuaci\u00f3n, abre una conexi\u00f3n TCP y negocia una sesi\u00f3n TLS<\/a> segura.<\/p>\n

Antes de que WordPress entre en acci\u00f3n, la solicitud pasa por el servidor web y cualquier capa configurada, como cortafuegos o proxies inversos.<\/p>\n

2. Comprobaci\u00f3n de la cach\u00e9<\/h3>\n

El servidor comprueba si existe una versi\u00f3n v\u00e1lida en cach\u00e9 de la p\u00e1gina solicitada.<\/p>\n

Si hay una cach\u00e9 HTML de p\u00e1gina completa<\/a> disponible y v\u00e1lida, WordPress no se ejecuta. La respuesta almacenada en cach\u00e9 se devuelve inmediatamente.<\/p>\n

Si no hay ninguna entrada en la cach\u00e9, o si se omite el almacenamiento en cach\u00e9 de forma intencionada para usuarios registrados, vistas previas o endpoint espec\u00edficos, la solicitud se reenv\u00eda a WordPress.<\/p>\n

3. WordPress se inicia<\/h3>\n

WordPress carga sus archivos principales, los plugins activos y el tema activo. Inicializa los hooks y se prepara para resolver la solicitud.<\/p>\n

En esta fase, WordPress a\u00fan no genera ning\u00fan resultado. Determina qu\u00e9 contenido se est\u00e1 solicitando.<\/p>\n

4. Resoluci\u00f3n de la consulta principal<\/h3>\n

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\u00e1gina, un archivo, un resultado de b\u00fasqueda u otro tipo de contenido.<\/p>\n

Solo despu\u00e9s de esto comienza la selecci\u00f3n de la plantilla.<\/p>\n

5. Resoluci\u00f3n de la plantilla<\/h3>\n

Aqu\u00ed es donde los temas de bloques y los cl\u00e1sicos empiezan a diferir estructuralmente.<\/p>\n

Temas cl\u00e1sicos<\/h4>\n

WordPress eval\u00faa la jerarqu\u00eda de plantillas y selecciona el archivo de plantilla PHP adecuado, como single.php, page.php o archive.php. Ese archivo contiene c\u00f3digo PHP que genera HTML directamente.<\/p>\n

Temas de bloques<\/h4>\n

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.<\/p>\n

A continuaci\u00f3n, la plantilla seleccionada se procesa a trav\u00e9s del sistema de renderizado de bloques.<\/p>\n

6. Montaje del dise\u00f1o<\/h3>\n

Temas cl\u00e1sicos<\/h4>\n

El dise\u00f1o se crea mediante plantillas PHP. Estas plantillas combinan c\u00f3digo de marcado, l\u00f3gica y llamadas a funciones para generar c\u00f3digo HTML.<\/p>\n

Temas de bloques<\/h4>\n

El dise\u00f1o se crea a partir de plantillas de bloques, partes de plantillas y contenido de las entradas. El c\u00f3digo de los bloques se analiza y cada bloque se convierte a HTML antes de generar el resultado final.<\/p>\n

7. Estructura del contenido<\/h3>\n

Temas cl\u00e1sicos<\/h4>\n

El contenido de las entradas se almacena principalmente en formato HTML en la base de datos. Durante la visualizaci\u00f3n, WordPress aplica filtros, shortcodes y otros procesos antes de renderizarlo.<\/p>\n

Temas de bloques<\/h4>\n

El contenido de los bloques se almacena como HTML con metadatos de bloque incrustados, por ejemplo:<\/p>\n

<!-- wp:image {\"id\":123} -->\n\n<img src=\"logo.png\">\n\n<!-- \/wp:image --><\/code><\/pre>\n
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\u00f3n y la tipograf\u00eda, antes de generar el HTML final.<\/p>\n
8. Representaci\u00f3n din\u00e1mica<\/h3>\n
La generaci\u00f3n din\u00e1mica est\u00e1 presente tanto en los temas cl\u00e1sicos como en los de bloques. Muchos temas cl\u00e1sicos se basan en consultas personalizadas, widgets o shortcodes que generan contenido en tiempo de ejecuci\u00f3n.<\/p>\n
En las arquitecturas basadas en bloques, el comportamiento din\u00e1mico se formaliza a trav\u00e9s de bloques din\u00e1micos. Por ejemplo, un bloque de bucle de consulta genera su marcado durante la solicitud utilizando PHP en lugar de almacenar HTML est\u00e1tico en la base de datos.<\/p>\n
Cuando se omite el almacenamiento en cach\u00e9 de p\u00e1gina completa, este flujo de trabajo de renderizaci\u00f3n se produce en cada solicitud.<\/p>\n
9. Estilo<\/h3>\n
En los temas cl\u00e1sicos, el estilo suele proporcionarse a trav\u00e9s de archivos CSS est\u00e1ticos<\/a> que el tema pone en cola.<\/p>\n
En los temas de bloques, los estilos globales definidos en theme.json<\/code> y los metadatos de los bloques permiten a WordPress generar autom\u00e1ticamente un CSS coherente. Esto reduce la necesidad de grandes hojas de estilo creadas a mano y centraliza la configuraci\u00f3n del dise\u00f1o.<\/p>\n
10. Resultado final<\/h3>\n
Una vez procesadas las plantillas, el contenido, los bloques y los estilos, WordPress genera la respuesta HTML final.<\/p>\n
El servidor env\u00eda este paquete de datos (o payload) al navegador. Si est\u00e1 configurado, la respuesta puede almacenarse en cach\u00e9 para futuras solicitudes.<\/p>\n
D\u00f3nde desplazan la carga los temas de bloques<\/h2>\n
El ciclo de vida de las solicitudes que acabas de ver se aplica tanto a los temas cl\u00e1sicos como a los de bloques<\/a>. WordPress sigue resolviendo consultas, seleccionando plantillas, ejecutando PHP y devolviendo HTML.<\/p>\n
Lo que cambia con los temas de bloques no es la base, sino d\u00f3nde se realiza el trabajo y cu\u00e1ndo no se puede omitir.<\/p>\n
En primer lugar, las plantillas<\/a> pueden almacenarse en la base de datos. Cuando un usuario edita una plantilla en el Editor del sitio, WordPress guarda esa versi\u00f3n y le da prioridad frente al archivo del directorio del tema. Esto aporta flexibilidad, pero tambi\u00e9n significa que los despliegues y la invalidaci\u00f3n de la cach\u00e9 deben tener en cuenta las plantillas almacenadas en la base de datos.<\/p>\n
En segundo lugar, los bloques din\u00e1micos<\/a> hacen que el renderizado en tiempo de ejecuci\u00f3n sea m\u00e1s visible. Los temas cl\u00e1sicos pueden generar contenido din\u00e1mico mediante consultas personalizadas, widgets o shortcodes. Los temas de bloques formalizan este patr\u00f3n a trav\u00e9s de bloques din\u00e1micos, como el bloque Query Loop. Cuando se omite la cach\u00e9 de p\u00e1gina completa, estos bloques ejecutan c\u00f3digo PHP durante la solicitud.<\/p>\n
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\u00e9. Estas rutas dependen directamente de la ejecuci\u00f3n de PHP, el rendimiento de la base de datos y el almacenamiento en cach\u00e9 de objetos.<\/p>\n
Por \u00faltimo, los estilos globales definidos en theme.json<\/code><\/a> centralizan las decisiones de dise\u00f1o. Cuando cambian los estilos o la estructura de las plantillas, la coordinaci\u00f3n de la cach\u00e9 cobra mayor importancia para garantizar que tanto los visitantes como los editores vean inmediatamente los cambios.<\/p>\n
Ninguno de estos cambios requiere un tipo de alojamiento diferente. Sin embargo, s\u00ed que hacen m\u00e1s evidentes ciertas deficiencias de la infraestructura, sobre todo en situaciones en las que no se utiliza la cach\u00e9 y se ha iniciado sesi\u00f3n.<\/p>\n
Teniendo esto en cuenta, el siguiente paso es ver qu\u00e9 debe gestionar un entorno de alojamiento bien configurado en una configuraci\u00f3n basada en bloques.<\/p>\n
Consideraciones de alojamiento para sitios basados en bloques<\/h2>\n
Los temas basados en bloques no introducen nuevos requisitos de alojamiento. Hacen que sea m\u00e1s importante que los ya existentes funcionen correctamente.<\/p>\n
Un entorno bien configurado debe tener en cuenta tanto las rutas con cach\u00e9 como las que no la tienen, especialmente para los editores y los usuarios que han iniciado sesi\u00f3n.<\/p>\n
Almacenamiento en cach\u00e9 coordinado entre capas<\/h3>\n
La cach\u00e9 de p\u00e1gina completa<\/a> sigue siendo la capa de rendimiento m\u00e1s eficaz para el tr\u00e1fico an\u00f3nimo. Las p\u00e1ginas p\u00fablicas deben almacenarse en cach\u00e9 de forma intensiva, mientras que las vistas previas, las sesiones con usuario registrado y los endpoints espec\u00edficos se omiten autom\u00e1ticamente.<\/p>\n
El almacenamiento en cach\u00e9 de objetos<\/a> tambi\u00e9n desempe\u00f1a un papel importante. Al almacenar en memoria los resultados de consultas repetidas y las estructuras de datos calculadas, una cach\u00e9 de objetos reduce la carga de la base de datos y mejora la capacidad de respuesta tanto del frontend como del backend.<\/p>\n
Hay que coordinar la invalidaci\u00f3n de la cach\u00e9. Cuando se actualizan contenidos, plantillas o estilos globales, las p\u00e1ginas relacionadas deben actualizarse r\u00e1pidamente. Una mala coordinaci\u00f3n de la cach\u00e9 puede provocar dise\u00f1os desactualizados, estilos incoherentes o un comportamiento confuso en las vistas previas.<\/p>\n
Una CDN complementa esta configuraci\u00f3n almacenando en cach\u00e9 activos est\u00e1ticos como im\u00e1genes, fuentes y scripts m\u00e1s cerca de los visitantes.<\/p>\n
La cach\u00e9<\/a> no se reduce a una sola capa. Se trata de c\u00f3mo interact\u00faan estas capas entre s\u00ed.<\/p>\n
Capacidad de PHP y rendimiento en tiempo de ejecuci\u00f3n<\/h3>\n
Cuando se omite la cach\u00e9 de p\u00e1gina completa, WordPress ejecuta PHP para resolver consultas, generar plantillas y procesar bloques din\u00e1micos.<\/p>\n
Por eso es importante planificar la capacidad de PHP. El entorno debe proporcionar suficientes hilos PHP<\/a> para gestionar la concurrencia prevista sin que se acumulen colas. Los l\u00edmites de memoria<\/a> deben configurarse para evitar el intercambio de memoria bajo carga.<\/p>\n
OPcache debe estar activado y configurado correctamente para que no haya que recompilar el c\u00f3digo byte de PHP una y otra vez. Durante los despliegues, OPcache debe actualizarse para que el c\u00f3digo actualizado se ejecute de inmediato.<\/p>\n
Estas pr\u00e1cticas 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\u00e1s evidentes cuando el renderizado es din\u00e1mico.<\/p>\n
Almacenamiento en cach\u00e9 de la base de datos y de objetos<\/h3>\n
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\u00e9.<\/p>\n
Una cach\u00e9 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.<\/p>\n
Observabilidad y monitorizaci\u00f3n<\/h3>\n
A medida que la actividad se va desplazando hacia las rutas de ejecuci\u00f3n, la visibilidad cobra mayor importancia. Los administradores y los propietarios de los sitios web deber\u00edan supervisar:<\/p>\n