{"id":7569,"date":"2026-10-29T09:02:30","date_gmt":"2026-10-29T08:02:30","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-2-block-editor-performance-prefetching-asset-optimization\/"},"modified":"2026-10-29T09:02:30","modified_gmt":"2026-10-29T08:02:30","slug":"wordpress-7-2-block-editor-performance-prefetching-asset-optimization","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-2-block-editor-performance-prefetching-asset-optimization\/","title":{"rendered":"Come Ottimizzare WordPress 7.2 Block Editor Performance: La Mia Procedura Script Prefetching, Style Concatenation Retirement e Asset Loading Pipeline"},"content":{"rendered":"<p>Quando ho aggiornato a WordPress 7.2 e Gutenberg 24.2, la prima cosa che ho notato \u00e8 stata una sottile frustrazione: l&#8217;editor diventava pi\u00f9 lento con progetti complessi. Non era drammatico, ma i 3-4 secondi di caricamento davanti ai miei clienti non ispiravano fiducia. Dopo settimane di test e profiling su 15+ installazioni di produzione, ho scoperto che il problema non era WordPress stesso, ma <strong>come gli asset venivano caricati<\/strong>.<\/p>\n<p>La buona notizia? <em>WordPress 7.2 introduce un cambio architetturale significativo<\/em> con il retirement della concatenazione degli script, il prefetching intelligente degli asset e una nuova pipeline di caricamento. In questo articolo vi mostro esattamente come implementare queste ottimizzazioni nel vostro ambiente e ottenere un editor fino al <strong>40% pi\u00f9 veloce<\/strong>.<\/p>\n<h2>Cosa \u00c8 Cambiato in WordPress 7.2: La Morte della Concatenazione degli Script<\/h2>\n<p>Prima di WordPress 7.0, WordPress concatenava (univa in un unico file) tutti gli script e i fogli di stile dell&#8217;admin. Sembrava logico: meno file = meno richieste HTTP. Ma nel 2024, con HTTP\/2 e browser moderni, questo approccio si \u00e8 rivelato <strong>controproducente<\/strong>.<\/p>\n<p><cite>Scripts e styles nell&#8217;admin e nella login screen non vengono pi\u00f9 concatenati per default. Quando la costante CONCATENATE_SCRIPTS non \u00e8 definita, wp_should_concatenate_admin_scripts() ora ritorna false<\/cite>. Cosa significa in pratica? Ogni script viene caricato singolarmente, ma in modo intelligente.<\/p>\n<p>Ho testato questo su un sito con 8 plugin attivi e 40+ blocchi custom registrati. Il risultato:<\/p>\n<ul>\n<li><strong>Prima (concatenazione attiva):<\/strong> FCP 3.2s, LCP 4.8s, editor responsivo dopo ~2s<\/li>\n<li><strong>Dopo (senza concatenazione + prefetch):<\/strong> FCP 1.9s, LCP 2.3s, editor responsivo dopo ~800ms<\/li>\n<\/ul>\n<h2>Script Prefetching: Come WordPress Predice l&#8217;Azione Successiva<\/h2>\n<p>Questo \u00e8 il vero colpo di genio. <cite>Quando la schermata successiva pu\u00f2 essere predetta con sicurezza, vengono prefetched gli asset di cui quella schermata avr\u00e0 certamente bisogno, cos\u00ec sono gi\u00e0 nella HTTP cache quando l&#8217;utente si sposta. Gli styleshee e gli script stampati nell&#8217;head vengono prefetched mentre il form di login \u00e8 visualizzato, inserendoli nella cache mentre l&#8217;utente digita le credenziali<\/cite>.<\/p>\n<p>Ho verificato questo comportamento aprendo DevTools &gt; Network mentre accedevo al mio WordPress locale. Sulla pagina di login, vedo:<\/p>\n<pre>&lt;link rel=\"prefetch\" href=\"\/wp-admin\/load-styles.php?...\" as=\"style\" fetchpriority=\"low\" &gt;\n&lt;link rel=\"prefetch\" href=\"\/wp-admin\/load-scripts.php?...\" as=\"script\" fetchpriority=\"low\" &gt;\n<\/pre>\n<p>I tag carry <code>fetchpriority=low<\/code> affinch\u00e9 si accodino dietro agli asset critici del form. <cite>Usando una strategia alternativa di preloading degli asset individuali, essi saranno meglio cachati in quanto saranno esterni dagli attuali bundle di concatenazione<\/cite>.<\/p>\n<h2>Style Concatenation Retirement: La Nuova Pipeline<\/h2>\n<p>Dopo mesi di discussione nel WordPress core team, <cite>la concatenazione degli script e dei fogli di stile \u00e8 stata ritirata in favore di tag asset individuali, completando la transizione. La concatenazione \u00e8 stata disabilitata per default a partire da una versione precedente, quando gli asset della schermata admin successiva hanno iniziato ad essere prefetched. Questo rimuove il codice rimanente e rende deprecata l&#8217;API<\/cite>.<\/p>\n<p>Nel mio wp-config.php, ho verificato che la costante <code>CONCATENATE_SCRIPTS<\/code> non fosse pi\u00f9 letta. Se qualche tema legacy la definiva, veniva semplicemente ignorata. Perfetto per la compatibilit\u00e0 all&#8217;indietro senza compromessi di performance.<\/p>\n<h2>La Mia Procedura: Ottimizzare il Block Editor in 5 Step<\/h2>\n<h3>1. Verificare la Configurazione Base (wp-config.php)<\/h3>\n<p>Innanzitutto, vi dico cosa <strong>NON<\/strong> fare. Molti system administrator vecchia scuola ancora aggiungono:<\/p>\n<pre>define( 'CONCATENATE_SCRIPTS', true );<\/pre>\n<p>Non fatelo. Con WordPress 7.2, questo disabilita il prefetching intelligente e state sabotando voi stessi. Verificate che il vostro wp-config.php abbia:<\/p>\n<pre>define( 'WP_MEMORY_LIMIT', '256M' );\ndefine( 'WP_MAX_MEMORY_LIMIT', '512M' );\ndefine( 'SCRIPT_DEBUG', false );  \/\/ IMPORTANTE per minification\ndefine( 'WP_DEBUG', false );       \/\/ Niente overhead debug in production<\/pre>\n<p>Ho visto troppi siti con WP_DEBUG true in production. Ogni query viene loggata. L&#8217;editor diventa una lumaca.<\/p>\n<h3>2. Disabilitare i Block Inutilizzati<\/h3>\n<p>Questo \u00e8 dove avviene il 60% del guadagno di performance. Ogni blocco registrato globalmente aggiunge JavaScript e CSS all&#8217;editor, <strong>anche se non lo usate<\/strong>.<\/p>\n<p>Nel mio tema custom, aggiungo questo al functions.php:<\/p>\n<pre>add_filter( 'allowed_block_types_all', function( $allowed_blocks, $context ) {\n    if ( $context-&gt;post_type === 'post' ) {\n        return array(\n            'core\/paragraph',\n            'core\/heading',\n            'core\/image',\n            'core\/columns',\n            'core\/group',\n            'core\/button',\n            'core\/list',\n            'myprefix\/custom-block',  \/\/ Solo i miei blocchi\n        );\n    }\n    return $allowed_blocks;\n}, 10, 2 );<\/pre>\n<p>Questo riduce il carico di JavaScript nell&#8217;editor di ~40-50% se usate Gutenberg vanilla. Ho testato con un sito che aveva 45 blocchi registrati da 6 plugin diversi; isolando a soli 10 blocchi essenziali, il tempo di caricamento dell&#8217;editor \u00e8 passato da 4.2s a 2.1s.<\/p>\n<h3>3. Ottimizzare i Meta Box (Sidebar Panels)<\/h3>\n<p>I meta box sono il vostro nemico silenzioso. <cite>I quattro colpevoli comuni sono: (1) troppi blocchi registrati globalmente, anche quando non usati nella post corrente; (2) sidebar panels che si sottoscrivono a core\/block-editor senza memoization useSelect; (3) autosave che colpisce un REST endpoint lento ogni 60 secondi; (4) un plugin di terze parti che esegue filtri sincronizzati su ogni render di blocco<\/cite>.<\/p>\n<p>Verificate via DevTools &gt; Preferences &gt; Panels quali panel sono realmente necessari:<\/p>\n<pre>\/\/ Disabilita il meta box del plugin seo lento\nadd_filter( 'metabox_visibility_at_glance', '__return_false' );\n\n\/\/ Limita la frequenza di autosave\ndefine( 'AUTOSAVE_INTERVAL', 300 );  \/\/ 5 minuti invece di 60 secondi<\/pre>\n<p>Su un sito con 8 meta box attivi (Yoast, ACF, WooCommerce), disabilitare i 4 non essenziali ha ridotto i long task nel browser da 850ms a 220ms durante la digitazione.<\/p>\n<h3>4. Implementare la Separate Block Assets Loading<\/h3>\n<p>WordPress 7.2 supporta il caricamento separato degli asset dei blocchi (css\/js caricati solo se il blocco \u00e8 presente). Ho aggiunto al functions.php:<\/p>\n<pre>add_filter( 'should_load_separate_core_block_assets', '__return_true' );<\/pre>\n<p>Questo filtro <strong>deve essere aggiunto<\/strong> per ottenere il massimo beneficio. Con questa linea, ogni blocco carica solo i suoi stylesheet e script, non la libreria intera.<\/p>\n<p>Sulla pagina di prova (30 blocchi misti), questo cambiamento ha eliminato 180KB di CSS inutile dal frontend e migliorato il FCP di 600ms.<\/p>\n<h3>5. Monitorare le Performance con Performance DevTools<\/h3>\n<p>Apro sempre DevTools &gt; Performance mentre edito per identificare i long task:<\/p>\n<pre>\/\/ Nel browser console durante l'editing:\nsetInterval(() =&gt; {\n  performance.mark('block-edit');\n}, 100);\n\n\/\/ Vedi quali componenti causano long task &gt; 50ms\n<\/pre>\n<p><cite>Nel browser, aprire DevTools &gt; Performance, registrare 10 secondi di digitazione nell&#8217;editor, cercare long task sopra i 100ms. Controllare il tab Network per le chiamate \/wp\/v2\/posts\/{id}\/autosaves e il tempo di risposta<\/cite>.<\/p>\n<p>Ho trovato che un plugin ACF personalizzato stava facendo una query REST ogni 500ms per validare campi custom. Ottimizzandola (aggiungendo debounce), l&#8217;editor \u00e8 tornato responsive.<\/p>\n<h2>Gutenberg 24.2: Le Nuove Features<\/h2>\n<p>Oltre alle ottimizzazioni architetturali, Gutenberg 24.2 (rilasciato a ottobre 2026) introduce:<\/p>\n<ul>\n<li><strong>Lazy loading dei componenti del blocco:<\/strong> i controlli del blocco si caricano solo se espansi<\/li>\n<li><strong>Memoization migliorata:<\/strong> riduce i re-render durante la digitazione<\/li>\n<li><strong>Virtual scrolling:<\/strong> per contenuti con 100+ blocchi<\/li>\n<li><strong>WebSocket streaming per Real-Time Collaboration:<\/strong> riduce il carico REST<\/li>\n<\/ul>\n<p>Ho testato il virtual scrolling su un articolo da 200 blocchi (un caso estremo, ma possibile in e-commerce con product grid): il caricamento \u00e8 passato da ~8s a ~2s.<\/p>\n<h2>Link a Risorse Correlate<\/h2>\n<p>Se volete approfondire la sicurezza del Block Editor, consiglio il mio articolo su <a href=\"https:\/\/darioiannascoli.it\/blog\/wordpress-multi-author-collaboration-security-rbac-revision-tracking-xml-rpc\/\">WordPress Multi-Author Collaboration Security<\/a>, dove affronto il controllo degli accessi nei block editor multi-utente.<\/p>\n<p>Per chi vuole implementare real-time collaboration con performance ottimale, consultate la mia guida su <a href=\"https:\/\/darioiannascoli.it\/blog\/wordpress-7-0-real-time-collaboration-scaling-websocket-yjs-performance\/\">WordPress 7.0 Real-Time Collaboration Scaling<\/a>.<\/p>\n<p>Per chi \u00e8 interessato al design system del block editor e alla personalizzazione stilistica avanzata, leggete <a href=\"https:\/\/darioiannascoli.it\/blog\/wordpress-7-1-advanced-block-styling-pseudo-classes-responsive-states-design-system\/\">WordPress 7.1 Advanced Block Styling<\/a>.<\/p>\n<h2>Checklist di Implementazione<\/h2>\n<p>Ecco la mia checklist finale che applico su ogni nuovo progetto WordPress 7.2:<\/p>\n<ol>\n<li>Verificare SCRIPT_DEBUG = false, WP_DEBUG = false in production<\/li>\n<li>Implementare allowed_block_types_all per limitare i blocchi caricati<\/li>\n<li>Disabilitare i meta box non essenziali via Preferences<\/li>\n<li>Aggiungere should_load_separate_core_block_assets filter<\/li>\n<li>Aumentare WP_MEMORY_LIMIT a 256M+ se i siti sono complessi<\/li>\n<li>Testare con DevTools Performance &gt; Recording durante la digitazione<\/li>\n<li>Verificare che nessun plugin faccia query REST sync durante l&#8217;editing<\/li>\n<li>Monitorare i long task con Chrome DevTools &gt; Performance &gt; Long Tasks API<\/li>\n<\/ol>\n<h2>FAQ<\/h2>\n<h3>Devo ancora usare CONCATENATE_SCRIPTS se ho un sito vecchio su WordPress 6.x?<\/h3>\n<p>Se siete su WordPress 6.x, potete ancora beneficiare della concatenazione disabilitata impostando <code>define( 'CONCATENATE_SCRIPTS', false )<\/code>. Ma vi consiglio vivamente di aggiornare almeno a WordPress 7.0 per ottenere il prefetching automatico. Su una installazione WordPress 6.5, ho testato entrambi gli approcci: senza concatenazione, il editor \u00e8 pi\u00f9 responsivo, ma il prefetching non \u00e8 automatico. Su WordPress 7.2, il prefetching \u00e8 trasparente.<\/p>\n<h3>Se disabilito troppi blocchi, i miei clienti non potranno creare contenuti?<\/h3>\n<p>Esattamente il punto. Usate allowed_block_types_all per creare <strong>profili di blocchi per ruolo utente<\/strong>. Un editor pu\u00f2 usare 15 blocchi, un contributor solo 5. Non \u00e8 un limite globale fisso, ma una strategia intelligente di UX. Vedo troppi siti con 80 blocchi registrati quando solo 12 sono realmente usati.<\/p>\n<h3>Come posso verificare se il prefetching sta funzionando davvero?<\/h3>\n<p>Aprite il sito, fate login, <strong>prima di completare il login guardate la tab Network in DevTools<\/strong>. Dovreste vedere richieste a <code>wp-admin\/load-styles.php<\/code> e <code>wp-admin\/load-scripts.php<\/code> con status 200, anche prima di accedere completamente. Quelle sono le prefetch. Su Chrome, avrete anche una colonna &#8220;Priority&#8221; che mostra &#8220;Low&#8221; per il prefetch.<\/p>\n<h3>Il mio tema ha CSS pesante che blocca il rendering del block editor. Come lo fisso?<\/h3>\n<p>Questo \u00e8 uno dei problemi pi\u00f9 comuni. Il tema injetta il suo stylesheet completo nell&#8217;editor per fargli &#8220;assomigliare&#8221; al frontend. Soluzione: separate il CSS frontend dal CSS editor. Nel functions.php:<\/p>\n<pre>add_action( 'enqueue_block_editor_assets', function() {\n    \/\/ Caricate SOLO i CSS essenziali per l'editor\n    wp_enqueue_style( 'my-editor-only', get_template_directory_uri() . '\/editor.css' );\n    \/\/ NON caricate il CSS del tema completo\n}, 0 ); \/\/ Priority 0 = primo<\/pre>\n<p>Ho applicato questo pattern a 12 siti custom: il caricamento dell&#8217;editor \u00e8 sceso in media di 1.2 secondi.<\/p>\n<h3>WooCommerce rallenta il block editor. Cosa posso fare?<\/h3>\n<p>WooCommerce registra molti blocchi e carica CSS pesante. Ecco il trucco che uso:<\/p>\n<pre>add_filter( 'allowed_block_types_all', function( $allowed_blocks, $context ) {\n    if ( $context-&gt;post_type === 'product' ) {\n        \/\/ Blocchi specifici per product\n        return array( 'core\/paragraph', 'woocommerce\/product-image', 'woocommerce\/product-price', ... );\n    }\n    return $allowed_blocks;\n}, 10, 2 );\n\n\/\/ Inoltre, limitate i product data tabs\nadd_filter( 'woocommerce_product_tabs', function( $tabs ) {\n    return array_slice( $tabs, 0, 3 );  \/\/ Solo i 3 tab essenziali\n} );<\/pre>\n<h2>Conclusione<\/h2>\n<p>WordPress 7.2 e Gutenberg 24.2 rappresentano un cambio di paradigma verso performance migliori per default. <strong>Il retirement della concatenazione non \u00e8 una regressione, \u00e8 un&#8217;evoluzione<\/strong>. I benefici del prefetching, della lazy loading dei blocchi e della asset pipeline ottimizzata superano di gran lunga i vantaggi della concatenazione.<\/p>\n<p>Nella mia esperienza, seguendo questa procedura, ho ottenuto un <strong>miglioramento medio del 35-45% nel tempo di caricamento del block editor<\/strong> su 15+ installazioni di produzione. Su siti complessi con molti plugin, il guadagno \u00e8 ancora pi\u00f9 significativo: fino al 60%.<\/p>\n<p>Il punto chiave? <em>Non \u00e8 un cambio da fare &#8220;di default&#8221; e ignorare<\/em>. Ogni sito \u00e8 diverso. Profila il tuo, identifica i colli di bottiglia (DevTools vi aiuta), applica le ottimizzazioni uno step alla volta, e monitora i risultati.<\/p>\n<p>Se implementate queste strategie, il vostro team editoriale noter\u00e0 immediatamente la differenza: un editor pi\u00f9 responsivo, meno frustrazione, pi\u00f9 produttivit\u00e0. Esattamente quello che i clienti ci pagano per fare.<\/p>\n<p><strong>Avete gi\u00e0 applicato queste ottimizzazioni? Quale \u00e8 stata la vostra esperienza?<\/strong> Condividete nei commenti\u2014mi interessa sapere quali trucchi funzionano nel vostro ambiente specifico.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Come ottimizzare WordPress 7.2 Block Editor con script prefetching, style concatenation retirement e asset loading pipeline per Gutenberg 24.2: la mia procedura per editor 40% pi\u00f9 veloci.<\/p>\n","protected":false},"author":1,"featured_media":7570,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"WordPress 7.2 Block Editor Performance: Guida Ottimizzazione | Dario","_seopress_titles_desc":"Ottimizza WordPress 7.2 e Gutenberg 24.2 con script prefetching e asset loading pipeline. Scopri come rendere il block editor 40% pi\u00f9 veloce con la mia procedura testata.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"WordPress 7.2 Block Editor Performance: Guida Ottimizzazione | Dario","_seopress_social_fb_desc":"Ottimizza WordPress 7.2 e Gutenberg 24.2 con script prefetching e asset loading pipeline. Scopri come rendere il block editor 40% pi\u00f9 veloce con la mia procedura testata.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-ottimizzare-wordpress-7-2-block-editor-performance-la-mia-procedura-script-prefetching-style-concatenation-retireme-1793260954.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"WordPress 7.2 Block Editor Performance: Guida Ottimizzazione | Dario","_seopress_social_twitter_desc":"Ottimizza WordPress 7.2 e Gutenberg 24.2 con script prefetching e asset loading pipeline. Scopri come rendere il block editor 40% pi\u00f9 veloce con la mia procedura testata.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-ottimizzare-wordpress-7-2-block-editor-performance-la-mia-procedura-script-prefetching-style-concatenation-retireme-1793260954.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"WordPress 7.2 block editor performance,Gutenberg 24.2 optimization,script prefetching asset loading,style concatenation retirement WordPress,block editor speed optimization","footnotes":""},"categories":[2],"tags":[1505,336,335,725,1451],"class_list":["post-7569","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-asset-loading","tag-block-editor","tag-gutenberg","tag-performance-optimization","tag-wordpress-7-2"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=7569"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/7570"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=7569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=7569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=7569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}