Page builder vs codice custom in WordPress: quando Elementor costa più di quanto risparmi

La domanda arriva ogni volta: conviene usare un page builder come Elementor o scrivere codice custom? La risposta onesta è che dipende — ma il 'dipende' ha una direzione prevalente che quasi nessuno ammette. I page builder sono comodi per chi non scrive codice, e per siti dove la performance non è critica. Ma su siti dove i Core Web Vitals contano — e oggi contano per tutti — il page builder ha un costo che si paga in LCP, INP, e CLS. Non è un costo immediato, è un costo che si accumula con ogni pagina costruita.

Il problema non è che Elementor sia male scritto — è che il suo modello di output è strutturalmente pesante. Ogni sezione genera un wrapper div, ogni colonna genera un altro wrapper, ogni elemento genera il suo wrapper. Una sezione con tre colonne e sei elementi genera 20-30 livelli di DOM. Il CSS è inline per ogni elemento (perché il builder non sa dove finirà il componente), e il JavaScript carica la libreria del builder su ogni pagina anche dove non serve. Su una landing page, questo peso è tollerabile. Su un sito di cento pagine, è un treno di CSS e JS che si trascina dietro ogni visita.

Il costo misurabile di un page builder

Non è un'opinione — è un dato. Una pagina costruita con Elementor pesa in media il 40-60% più di una pagina equivalente costruita con codice custom. Il DOM ha 2-3 volte più elementi. Il CSS inline aggiunge 50-100KB per pagina. Il JavaScript del builder aggiunge 200-300KB. Misurarlo è semplice:

# Confronta il peso di una pagina Elementor vs una pagina custom
curl -s https://www.example.com/pagina-elementor/ | wc -c
curl -s https://www.example.com/pagina-custom/ | wc -c

# Confronta il numero di elementi DOM
# (richiede un browser headless o un tool come Lighthouse)
# Lighthouse: 'DOM Size' metric
# Elementor tipico: 1500-2500 elementi
# Codice custom tipico: 400-800 elementi

# Confronta il CSS caricato
curl -s https://www.example.com/pagina-elementor/ | grep -c '<style'
# Elementor: 10-20 blocchi <style> inline
curl -s https://www.example.com/pagina-custom/ | grep -c '<style'
# Custom: 0-2 blocchi <style> (tutto in file esterni)

Quando il page builder è la scelta giusta

Non è tutto codice custom. I page builder hanno un caso d'uso legittimo: siti dove il team di marketing deve modificare le pagine senza uno sviluppatore, e dove la performance non è il fattore critico. Un sito vetrina di cinque pagine per un'azienda locale, dove il titolare vuole cambiare i testi e le immagini senza chiamare l'agenzia — Elementor è la scelta giusta. Il costo in performance è tollerabile, e il beneficio in autonomia è reale.

Il problema è quando il page builder viene usato su siti dove non dovrebbe: e-commerce con checkout, portali editoriali ad alto traffico, siti dove i Core Web Vitals sono già al limite. Lì, il costo del page builder non è tollerabile — è il fattore che ti fa fallire i Core Web Vitals che con codice custom passeresti. La regola: se il sito ha più di 500 visite al giorno e la performance conta, valuta il codice custom. Se ha 50 visite al giorno e l'autonomia del team conta più della performance, il page builder va bene.

Il compromesso: page builder per il marketing, codice per le performance

La soluzione che vediamo funzionare meglio è il compromesso: usare il page builder per le pagine di marketing (landing page, about, servizi) dove il team ha bisogno di autonomia, e codice custom per le pagone critiche per le performance (home page, checkout, blog, pagine ad alto traffico). Questo richiede un tema che supporti entrambi — un tema custom con template PHP per le pagone critiche e Elementor abilitato per le altre:

// Disabilita Elementor sulle pagine critiche per le performance
add_filter( 'elementor/frontend/should_render', function( $should_render, $post_id ) {
    // Pagine dove Elementor NON deve caricare (codice custom)
    $custom_template_pages = array(
        get_option( 'page_on_front' ),          // home page
        wc_get_page_id( 'checkout' ),            // checkout
        wc_get_page_id( 'cart' ),                // carrello
        get_option( 'page_for_posts' ),          // blog
    );

    if ( in_array( $post_id, array_filter( $custom_template_pages ) ) ) {
        return false; // usa il template PHP del tema, non Elementor
    }

    return $should_render;
}, 10, 2 );

// Disabilita il CSS inline di Elementor sulle pagine dove è attivo
// (richiede Elementor Pro per il CSS custom per pagina)
add_filter( 'elementor/frontend/should_print_css_files', function( $should, $post_id ) {
    // Le pagine custom non caricano mai il CSS di Elementor
    $custom_template_pages = array(
        get_option( 'page_on_front' ),
        wc_get_page_id( 'checkout' ),
    );

    if ( in_array( $post_id, array_filter( $custom_template_pages ) ) ) {
        return false;
    }

    return $should;
}, 10, 2 );

La migrazione: quando passare dal builder al codice

Se hai un sito costruito interamente con Elementor e i Core Web Vitals sono rossi, la migrazione parziale è la via più pragmatica. Non devi rifare tutto — inizia dalle pagine ad alto traffico (home, blog, checkout) e migra quelle al codice custom. Le pagine a basso traffico possono restare su Elementor. Il risultato è un sito che passa i Core Web Vitals sulle pagine che contano, mantenendo l'autonomia del team sulle pagine dove non serve massima performance. Non è il massimo — ma è il compromesso che funziona nella maggior parte dei casi reali.

Il page builder non è il nemico — è uno strumento con un costo. Usarlo senza sapere il costo è l'errore. Saperlo e decidere consapevolmente è la scelta professionale. La differenza tra un sito che passa i Core Web Vitals e uno che non li passa, spesso, non è il page builder in sé — è la consapevolezza di quando usarlo e quando no.