¿Qué es un bloque de contenido?

¿Qué es un bloque de contenido?

Un bloque de contenido es una unidad reutilizable y estructurada de contenido en un sistema de gestión de contenidos (CMS) o en un constructor de páginas: un hero, una tabla de precios, un FAQ, una galería o una llamada a la acción. Cada bloque tiene campos definidos y una única forma coherente de mostrarse. Quien edita construye la página apilando bloques en lugar de dar formato a un gran campo de texto libre, de modo que el contenido y la presentación quedan separados.

Cómo funcionan los bloques de contenido

Un bloque suele tener tres partes:

• Esquema: los campos y las reglas, por ejemplo un hero con titular obligatorio, texto de botón y enlace.
• Formulario de edición: los campos que rellena el editor, generados a partir del esquema.
• Renderizado: la plantilla o el componente del front-end que convierte los datos del bloque en HTML.

Una página es entonces una lista ordenada de instancias de bloque. En Sanity, por ejemplo, un constructor de páginas es un array de tipos de objeto, y cada elemento guardado lleva su tipo en _type y un _key único (documentación de Sanity). El editor de bloques de WordPress se basa en la misma idea: las preguntas frecuentes de Gutenberg describen escribir y diseñar entradas y páginas con bloques, que se guardan en el contenido de la entrada (documentación de WordPress).

Ejemplo

Un equipo de marketing necesita una página de aterrizaje. Añade un bloque hero, un bloque de características en tres columnas, un bloque de testimonios y un bloque de FAQ, y rellena los campos. El desarrollador construyó cada bloque una sola vez. Cuando el equipo crea una segunda página de aterrizaje, reutiliza los mismos cuatro bloques y el diseño, los niveles de encabezado y los espacios coinciden sin código nuevo.

Por qué los bloques superan a un único campo de texto

• Coherencia. Dos editores no pueden dar estilos distintos a la misma sección.
• Reutilización. Un bloque puede aparecer en muchas páginas, y una instancia compartida se edita una sola vez.
• HTML más limpio. Los campos sustituyen al HTML pegado que arrastra estilos sueltos.
• SEO y accesibilidad más fáciles. Los niveles de encabezado y los campos de texto alternativo se pueden exigir en el esquema.
• Contenido estructurado. El CMS puede responder preguntas como qué páginas usan una tabla de precios.

Errores comunes

• Demasiados tipos de bloque. Empieza con los pocos que de verdad uses y añade más cuando surja una necesidad real.
• Esquemas demasiado grandes. Un hero con treinta campos opcionales abruma a quien edita. Divídelo en variantes.
• Sin límites de diseño. Si cada bloque permite cambiar colores y espacios, vuelves a tener páginas incoherentes.
• Varios H1 en una página. Cinco bloques hero pueden significar cinco H1. Fija el nivel de encabezado en el esquema.
• Olvidar la localización. Cada campo de texto necesita un valor por idioma.
• Cambiar un esquema sin migrar. Si renombras un campo, las instancias de bloque existentes dejan de ser válidas hasta que las migres.
• Ignorar el peso. Cada tipo de bloque que renderiza tu front-end añade HTML, scripts e imágenes. Carga de forma diferida los bloques pesados que quedan fuera de la pantalla inicial.

Bloques de contenido y rendimiento web

Los bloques hacen que las páginas sean fáciles de montar, y por eso también fáciles de sobrecargar. Muchos bloques en una página pueden sumar más scripts y peticiones, y eso se nota en las Core Web Vitals. También importa cómo se construye la página: consulta generación de sitios estáticos y renderizado en el servidor. El contenido que pasa por borrador, revisión y publicación necesita además un proceso claro: ciclo de vida del contenido.

Prueba el resultado en lugar de adivinar. El test de velocidad web de LoadFocus muestra cómo rinde una página con muchos bloques, y la monitorización de velocidad de página la sigue después de cada cambio de contenido. Si tu CMS expone una API REST o GraphQL, una prueba de carga de API muestra si aguanta un pico de tráfico. Las guías del blog sobre monitorizar las Core Web Vitals y mejorar la puntuación de rendimiento de WordPress cubren los siguientes pasos.

Preguntas frecuentes: bloques de contenido

¿Cuál es la diferencia entre un bloque de contenido y un componente?

Las palabras suelen usarse como sinónimos. En rigor, el bloque es el lado del CMS (esquema, formulario de edición y contenido) y el componente es el código del front-end que lo renderiza. En muchas configuraciones van emparejados uno a uno.

¿Son lo mismo los bloques de contenido y un constructor de páginas?

No. Los bloques son las unidades de contenido. Un constructor de páginas es la interfaz de edición que permite organizarlos.

¿Ayudan los bloques de contenido al SEO?

Pueden ayudar, porque los niveles de encabezado, el texto alternativo y los datos estructurados se pueden imponer en el esquema. También pueden perjudicar, por ejemplo cuando varios bloques generan cada uno un H1 o cuando bloques pesados ralentizan la página.

¿Necesito un CMS headless para usar bloques?

No. Los CMS tradicionales como WordPress también usan bloques. Un CMS headless guarda los bloques como datos y permite que varios front-ends los rendericen, lo que encaja con la publicación multicanal.

¿Cuántos tipos de bloque debería tener un sitio?

Los mínimos que cubran tus páginas reales. Un tipo de bloque nuevo se justifica cuando el mismo patrón aparece en varias páginas y ningún bloque existente encaja.