Durante años, la forma estándar de construir un WordPress «profesional» pasaba por elegir un theme potente —uno de los que promete mil opciones, paneles de control interminables y compatibilidad con todo— e instalar encima un maquetador visual. El resultado solía ser funcional. Y solía ser lento.
El problema no era el maquetador en sí. El problema es lo que ese modelo implica estructuralmente: capas de abstracción sobre capas de abstracción, JavaScript cargado para funcionalidades que a lo mejor ni usas en esa página, estilos duplicados entre el tema, el constructor y los plugins. Todo eso tiene un coste que se mide en milisegundos y que Google lleva tiempo señalando con su framework de Core Web Vitals.
En CLOSE llevamos un tiempo moviéndonos en otra dirección. No como una tendencia que seguir, sino porque los datos lo justifican.
Contents
El cambio real que trae Full Site Editing
Full Site Editing (FSE) no es simplemente «editar visualmente desde el admin de WordPress». Es un cambio en la arquitectura de cómo se construye y se entrega un sitio. La diferencia técnica de fondo es que el editor de bloques —Gutenberg— pasa a controlar no solo el contenido de las páginas, sino también la cabecera, el pie, las plantillas, los archivos de categorías, las páginas de producto. Todo el frontend del sitio vive ahora dentro del mismo sistema.
Lo que esto permite, desde un punto de vista de rendimiento, es significativo. Un block theme bien construido sirve CSS como hojas de estilos separadas por bloque, cargando solo los estilos que realmente se necesitan en cada página. No hay un styles.css monolítico de 300KB. No hay JavaScript de maquetador parseando el DOM antes de que el usuario vea nada. El HTML que llega al navegador es más limpio, más predecible, más fácil de cachear.
Eso tiene un impacto directo en las métricas que más importan ahora mismo: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint). Sitios que en su versión anterior con tema + page builder marcaban «needs improvement» en estas métricas, tras una migración a block theme bien ejecutada suelen entrar en verde sin necesidad de trucos adicionales.
Por qué los themes de antes eran un problema estructural
Hay que entender qué vendían los themes de la generación anterior. Vendían opciones. Cuantas más opciones, mejor theme. Fuentes, colores, layouts, animaciones, sidebars opcionales, headers alternativos, megamenús, sliders integrados. Todo eso se cargaba siempre, tanto si lo usabas como si no.
El resultado es que el navegador recibía un payload enorme para renderizar una página que en realidad solo necesitaba una fracción de ese código. Y encima, ese código llegaba en un orden que bloqueaba el renderizado: scripts en el <head>, CSS crítico mezclado con decorativo, fuentes personalizadas sin estrategia de carga.
Los block themes invierten esa lógica. Partes desde cero —o desde una base mínima— y añades solo lo que necesitas. El theme.json define el sistema de diseño: tipografías, colores, espaciados, tamaños de contenido. No hay panel de opciones. No hay configuración guardada en la base de datos que haya que interpretar en tiempo de ejecución. Es declarativo, estático, cacheable.
Lo que cambia en el proceso de desarrollo
Trabajar con block themes y FSE no es solo un cambio de herramienta. Cambia el proceso completo.
El diseño ahora tiene que hablar el idioma de los bloques desde el principio. Un diseñador que entrega mockups sin contemplar la rejilla nativa de WordPress, los espaciados del tema o cómo se comportan los patrones de bloque reutilizables, está creando trabajo extra en desarrollo. La alineación entre diseño y sistema tiene que existir antes de escribir una línea de código.
En cuanto al desarrollo, la curva de aprendizaje es real. FSE requiere entender theme.json a fondo —no solo para configurar colores, sino para controlar spacing.blockGap, los fluid sizing de tipografía, los permisos de edición por bloque para el cliente. También implica dominar los templates, template parts y patterns como sistema, no como archivos sueltos. Y requiere saber cuándo usar CSS custom properties globales definidas por el tema versus estilos en línea generados por el editor, que tienen un impacto diferente en la cascade.
Lo que se gana a cambio es un sitio más fácil de mantener a largo plazo. Cuando el cliente necesita cambiar un color corporativo, se modifica en theme.json y se propaga automáticamente. Cuando hay que actualizar WordPress core, no hay un constructador visual con su propio sistema de actualización y sus breaking changes. El sitio es más robusto frente al tiempo.
Cuándo tiene sentido y cuándo no
FSE y los block themes son la elección correcta para la mayoría de proyectos web que construimos hoy. Pero no para todos.
Tiene todo el sentido en sitios corporativos, landings de servicios, blogs, portafolios y webs informativas. También en tiendas WooCommerce cuando el diseño no requiere funcionalidades muy específicas del constructor. Y especialmente en proyectos donde la velocidad de carga tiene impacto directo en conversión —ecommerce, captación de leads, reservas online.
Donde puede no ser la elección óptima es en proyectos que ya están construidos sobre constructores con mucha personalización acumulada, donde el coste de migración no se justifica en el corto plazo. O en casos donde el cliente tiene un equipo interno acostumbrado a un flujo de edición muy específico del constructor anterior y no hay tiempo ni presupuesto para la transición.
La decisión hay que tomarla proyecto a proyecto, pero la dirección por defecto ha cambiado. Ya no es «¿usamos un constructor?» sino «¿tenemos razones específicas para no usar blocks nativos?».
El rendimiento no es un añadido
Esto es quizás lo más importante de este cambio de paradigma. Con los modelos anteriores, el rendimiento era algo que se trabajaba al final: se pasaba el sitio por un auditor de velocidad, se identificaban los problemas y se intentaban resolver con plugins de caché, compresión de imágenes y diferimiento de scripts. El resultado era parchear sobre una arquitectura que no estaba pensada para ser rápida.
Con block themes bien construidos, el rendimiento es una consecuencia natural de las decisiones de arquitectura. Los estilos están bien organizados. El JavaScript es mínimo. Las fuentes se cargan con estrategia. Las imágenes se sirven en el formato adecuado desde el bloque de imagen nativo. No hay que convencer al sitio de que sea rápido porque está construido para serlo.
Eso no significa que sea automático ni que no requiera trabajo. Requiere criterio en cada decisión de desarrollo, desde cómo se definen los patrones hasta cómo se configura el hosting. Pero el punto de partida es radicalmente mejor.
Si estás valorando cómo mejorar el rendimiento de tu web o si un proyecto nuevo debería construirse con esta arquitectura, podemos hacer una revisión técnica sin compromiso. Escríbenos en close.technology/contacto.
