Gutenberg e blocchi: le novità dell'editor che cambiano il modo di costruire le pagine

L'editor a blocchi ha diviso la community WordPress per anni, ma oggi la questione è meno ideologica e più pratica: Gutenberg è l'editor predefinito, evolve costantemente, e chi costruisce siti deve sapere cosa fa e cosa non fa. Le novità recenti non sono rivoluzionarie — sono miglioramenti incrementali che, sommati, cambiano l'esperienza di editing.

Il trend generale è chiaro: API più pulite per gli sviluppatori di blocchi, migliore performance di rendering nell'editor, e una riduzione progressiva del divario tra quello che si vede in editing e quello che si vede in frontend. Per chi costruisce siti professionali, questo significa meno hack CSS per allineare l'editor al frontend.

Blocchi custom vs page builder: quando l'uno vale l'altro

La domanda che ci sentiamo fare più spesso è: conviene costruire blocchi custom o usare un page builder? La risposta dipende dal progetto, ma c'è un principio guida: i blocchi custom producono HTML pulito e leggero, i page builder producono HTML ricco di wrapper e classi di utility. Su un sito vetrina la differenza è impercettibile; su un sito ad alto traffico o con Core Web Vitals stretti, il peso del DOM del page builder si paga in LCP e INP.

Un blocco custom ben fatto è un componente React isolato, con i suoi stili scoped, che produce esattamente il markup che serve — niente di più. Il costo è lo sviluppo iniziale; il beneficio è la manutenibilità nel tempo, perché il blocco non dipende da un plugin terzo che può cambiare API o sparire.

// Registrazione minimale di un blocco Gutenberg custom
// con @wordpress/blocks — senza page builder, senza dipendenze pesanti

import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps, RichText } from '@wordpress/block-editor';

registerBlockType( 'wpplanet/cta-box', {
  title: 'Box CTA',
  category: 'wpplanet',
  attributes: {
    title: { type: 'string', default: '' },
    text:  { type: 'string', default: '' },
  },
  edit: ( { attributes, setAttributes } ) => (
    <div { ...useBlockProps( { className: 'wpplanet-cta' } ) }>
      <RichText
        tagName='h3'
        value={ attributes.title }
        onChange={ ( v ) => setAttributes( { title: v } ) }
        placeholder='Titolo della CTA'
      />
      <RichText
        tagName='p'
        value={ attributes.text }
        onChange={ ( v ) => setAttributes( { text: v } ) }
        placeholder='Testo descrittivo'
      />
    </div>
  ),
  save: ( { attributes } ) => (
    <div { ...useBlockProps.save( { className: 'wpplanet-cta' } ) }>
      <h3>{ attributes.title }</h3>
      <p>{ attributes.text }</p>
    </div>
  ),
} );

L'ibrido realistico

Nella pratica, l'approccio più sano è spesso ibrido: usare i blocchi del core per i contenuti standard (testo, immagini, colonne), costruire blocchi custom per i componenti ripetuti del brand (CTA, testimonial, card servizi), e lasciare il page builder solo dove serve libertà di layout al cliente finale — pagine landing che il marketing vuole comporre da solo. La regola è: più il componente è ripetuto e strutturato, più conviene un blocco custom; più è unico e libero, più il page builder ha senso.

Le novità dell'editor non rendono i page builder obsoleti, ma li spostano verso il loro uso corretto: composizione libera, non sostituto di uno sviluppo strutturato. Quando un sito ha bisogno di componenti che si ripetono su decine di pagine, il blocco custom è la scelta che paga nel tempo — in performance, in manutenibilità, e in indipendenza da fornitori terzi.