Headless WordPress: quando vale la pena staccare il frontend (e quando è sovrainvestimento puro)

Headless WordPress è uno di quegli argomenti che genera più entusiasmo che pragmatismo. La premessa è allettante: usi WordPress come backend per gestire contenuti, e un frontend separato (React, Next.js, un'app) consuma i dati via REST API. Risultato: un frontend velocissimo, un backend che conosci, e la libertà di costruire l'esperienza che vuoi. Sembra il meglio di entrambi i mondi. Spesso è il peggio di entrambi — con un costo aggiuntivo.

Il punto che nessuno sottolinea abbastanza è che headless raddoppia la complessità. Hai due codebase da mantenere, due team (o due competenze), due punti di failure, due deploy da coordinare. Il backend WordPress non sparisce: continua a esistere, va aggiornato, va protetto, va monitorato. Ci si aggiunge un frontend che va costruito, testato, e mantenuto nel tempo. Per un sito vetrina di 8 pagine, è sovrainvestimento puro. Per un editoriale con milioni di visite al mese, può essere la scelta giusta.

Quando headless ha senso davvero

I casi in cui headless vale la pena sono rari ma chiari. Il primo è l'editoriale ad alto traffico: un portale con milioni di visite al mese dove ogni millisecondo di TTFB conta, dove il frontend deve essere iper-ottimizzato, e dove il team di sviluppo ha le competenze per mantenere un'app React in produzione. Il secondo è il multi-canale: lo stesso contenuto che deve apparire su un sito web, un'app mobile, un display digitale, un newsletter — un'unica fonte di verità (WordPress) consumata da più frontend diversi.

Il terzo caso è l'integrazione profonda: quando il sito non è solo contenuto ma un'applicazione con logica complessa — area utente, dashboard, interazioni real-time — dove WordPress come CMS non basta e serve un frontend con stato. Il quarto, più raro, è la performance estrema su dispositivi specifici: un frontend costruito su misura per un target di dispositivi che un tema WordPress non può ottimizzare allo stesso livello.

In tutti questi casi il denominatore comune è lo stesso: il volume o la complessità giustificano il costo di mantenere due codebase. Se il tuo sito ha 500 visite al giorno e 10 pagine, headless è sovrainvestimento — stai pagando il costo di un'architettura enterprise per un problema che un tema ben fatto risolve meglio.

Il costo reale (che nessuno calcola prima)

Il costo di headless non è solo lo sviluppo iniziale — che è già più alto di un tema WordPress. È il costo di mantenimento nel tempo. Un tema WordPress si aggiorna dal backend, i plugin si aggiornano con un click, e il team di marketing può gestire contenuti senza toccare il codice. Un frontend headless richiede un deploy ogni volta che cambi qualcosa di strutturale, un processo di build, e qualcuno che sa farlo.

Poi c'è il costo nascosto delle API. WordPress REST API è completa ma non è pensata per essere l'unica interfaccia: ogni endpoint che aggiungi va documentato, testato, e mantenuto. Le performance delle API sotto carico sono un capitolo a parte — un endpoint che restituisce 50 post con immagini e meta può pesare 200KB di JSON, e se il frontend lo chiama per ogni pagina, il risparmio di tempo rispetto a un HTML renderizzato si mangia. Ecco un esempio di endpoint REST personalizzato:

// Endpoint REST personalizzato per articoli ottimizzati
add_action( 'rest_api_init', function () {
    register_rest_route( 'wp-planet/v1', '/articles', array(
        'methods'             => 'GET',
        'callback'            => 'get_optimized_articles',
        'permission_callback'  => '__return_true',
        'args'                => array(
            'page'     => array( 'default' => 1 ),
            'per_page' => array( 'default' => 12, 'maximum' => 50 ),
        ),
    ) );
} );

function get_optimized_articles( WP_REST_Request $request ) {
    $per_page = min( (int) $request['per_page'], 50 );
    $page     = max( (int) $request['page'], 1 );

    $query = new WP_Query( array(
        'post_type'           => 'post',
        'post_status'         => 'publish',
        'posts_per_page'      => $per_page,
        'paged'               => $page,
        'ignore_sticky_posts' => true,
        'no_found_rows'       => false,
    ) );

    $items = array();
    foreach ( $query->posts as $post ) {
        $items[] = array(
            'id'        => $post->ID,
            'title'     => get_the_title( $post ),
            'slug'      => $post->post_name,
            'excerpt'   => get_the_excerpt( $post ),
            'date'      => get_the_date( 'c', $post ),
            'cover_url' => get_the_post_thumbnail_url( $post, 'large' ),
        );
    }

    return new WP_REST_Response( array(
        'items'       => $items,
        'total'       => $query->found_posts,
        'total_pages' => $query->max_num_pages,
    ), 200 );
}

Quando headless è la scelta sbagliata

Siti vetrina, PMI, blog aziendale, piccoli e-commerce: in tutti questi casi headless è quasi sempre la scelta sbagliata. Il costo di mantenimento supera il beneficio di performance, il team di marketing non può più gestire i contenuti autonomamente, e ogni cambio richiede un intervento tecnico. Un tema WordPress ben costruito, con caching e ottimizzazione, raggiunge performance più che sufficienti per la maggior parte dei siti — senza raddoppiare la complessità.

Il segnale più chiaro che headless è la scelta sbagliata è quando lo proponi per ragioni di moda invece che per necessità. 'Vogliamo essere moderni' non è un requisito tecnico. 'Il nostro TTFB è di 1.200ms e perdiamo il 15% delle conversioni' è un requisito tecnico — e la soluzione potrebbe essere un hosting migliore e un caching avanzato, non un frontend separato.

La domanda che ti fa capire se ti serve

Prima di scegliere headless, fatti questa domanda: il mio problema è il frontend o il backend? Se il problema è che il tema è lento, i plugin sono troppi, e il database è gonfio — quello è un problema di WordPress, e headless non lo risolve (lo sposta). Se il problema è che ti serve un'esperienza che WordPress non può dare — un'app, un multi-canale, un'interazione real-time — allora headless potrebbe essere la risposta.

La differenza tra un'architettura che serve e una che si sceglie per moda è il costo. Un tema WordPress ottimizzato costa una frazione di un frontend headless, sia in sviluppo che in mantenimento. Se il tuo sito non ha il volume o la complessità che giustificano il costo, stai pagando una Ferrari per andare a fare la spesa. Un frontend ben costruito su WordPress, con le ottimizzazioni giuste, può essere veloce, sicuro e gestibile — senza raddoppiare il lavoro.