Mantys CoreCome velocizzare un sito Divi e migliorare i suoi Core Web Vitals (passo dopo passo)
In sintesi: un sito Divi può essere veloce se si ottimizza nell'ordine giusto, prima le immagini, poi il CSS, poi il JavaScript, iniziando dalle leve che non possono rompere nulla prima di toccare quelle che possono.
Divi ha la reputazione di essere pesante. Include molto CSS e JavaScript per permettere al builder visuale di fare tutto, e di serie questo peso si riflette sui Core Web Vitals. La buona notizia: un sito Divi può essere veloce, e non è necessario stravolgerlo per arrivarci.
Il trucco è ottimizzare nell'ordine giusto, e iniziare dalle leve che non possono rompere nulla. Questo metodo safe-first è la spina dorsale di questa guida. Procederemo con Immagini, poi CSS, poi JavaScript, dal più sicuro al più delicato, e ogni passaggio si basa su una guida dedicata da approfondire.
Passo 1: Immagini (la leva più sicura)
Le immagini sono quasi sempre il peso maggiore di una pagina Divi, e Divi peggiora la situazione in un modo specifico: fa largo uso di molte immagini a piena larghezza e di molte immagini di sfondo CSS (sfondi di sezioni e moduli).
Le mosse sicure sono quelle consuete, e nessuna di esse può rompere nulla: comprimete le immagini, servitele come WebP o AVIF, e servitele alle dimensioni corrette invece di un file enorme rimpicciolito via CSS. Applicate il lazy-load alle immagini sotto la piega, ma mai a quella hero in alto (l'LCP), altrimenti la rallentate. E impostate width e height (o un aspect-ratio) in modo che il layout smetta di saltare (CLS).
Ecco l'insidia specifica di Divi. Gli sfondi di sezioni e moduli non hanno alcun srcset. La leva srcset/sizes semplicemente non può toccarli, quindi nessuno strumento può ridimensionarli al posto vostro. Dovete comprimere e dimensionare quelle immagini a monte, prima che vengano impostate come sfondi. Questo caso delle immagini senza srcset è trattato nella nostra guida su srcset e sizes.
E per le immagini normali, l'attributo sizes generato da Divi e WordPress è spesso sbagliato nel momento in cui un'immagine si trova in una colonna o in una griglia, il che riguarda la maggior parte di un layout Divi, quindi il browser scarica più del necessario. Perché questo accade, e come leggerlo negli strumenti per sviluppatori in trenta secondi, è l'argomento di quella stessa guida su srcset.
Passo 2: CSS
Divi ha un proprio pannello delle prestazioni (Theme Options → Performance). Attivate Dynamic CSS: invece di caricare l'intero foglio di stile di Divi, carica solo il CSS dei moduli effettivamente usati nella pagina. È un guadagno importante e sicuro. Dynamic Module Framework e Dynamic Icons funzionano allo stesso modo, caricando solo ciò che serve alla pagina.
Divi ha anche l'opzione Critical CSS. Se usate già uno strumento esterno di critical CSS, non eseguitele entrambe. Disattivate il Critical CSS di Divi e lasciate che se ne occupi un solo motore. Due motori che si contendono la stessa responsabilità è la ricetta per pagine incoerenti e difficili da debuggare. Chiamatela la regola d'oro: un motore per responsabilità.
È qui che si verifica il classico problema di Divi. Il Critical CSS e la rimozione del CSS inutilizzato mantengono solo ciò che è visibile in cima alla pagina al caricamento. Il vostro menu mobile, l'overlay di ricerca e il mega-menu sono nascosti in quel momento, quindi i loro stili vengono rimossi, e finiscono per apparire aperti o senza stile. La soluzione duratura è inserire quelle regole interattive in linea in un blocco non ottimizzabile dopo wp_head(), in modo che viaggino insieme al tema. Il metodo completo, e le insidie legate alle cache per-URL e mobile/desktop, sono nella guida al critical CSS.
Un'altra buona pratica per Divi: dopo una modifica importante, rigenerate il CSS statico di Divi. Una cache di Divi non aggiornata può servire un foglio di stile troncato, che sembra esattamente un'ottimizzazione rotta. Svuotate la cache e rigenerate, poi verificate il rendering reale.
Passo 3: JavaScript (e il menu Divi)
Divi carica jQuery, e sulla maggior parte dei siti è il menu a renderlo necessario. Rimandare il JavaScript è un grande vantaggio, ma è anche dove le cose si rompono se fatto con superficialità.
Il caso emblematico è il menu a hamburger che si apre solo al secondo clic. Divi ha persino un'impostazione dedicata, Defer jQuery And jQuery Migrate, e attivarla in modo ingenuo scatena esattamente quel bug: il primo tocco risveglia il caricamento dello script invece di aprire il menu.
La soluzione, mantenendo il menu Divi, consiste nell'escludere l'intera catena di dipendenze dal ritardo insieme: jQuery, jQuery Migrate e lo script del menu. Individuateli tramite un frammento URL univoco (non l'handle interno, che può essere rimosso), e mantenete un controllo sullo stato del documento in modo che lo script escluso tolleri un'esecuzione anticipata. Fatto questo, il menu torna a rispondere al primo tocco. Se non riuscite a gestire la catena, lasciate Defer jQuery disattivato piuttosto che pubblicare un menu a doppio tocco. La procedura passo passo è nella guida al menu a hamburger.
Una volta gestito il menu, rimandare o ritardare il resto (slider, lightbox e così via) va benissimo e fornisce la maggior parte del guadagno sul JavaScript.
Passo 4: L'ordine e il metodo
Mettete insieme tutto con il metodo safe-first. Per prima cosa, attivate tutti i guadagni sicuri: compressione e dimensioni delle immagini, lazy-load fuori schermo (mai per l'LCP), minificazione, compressione lato server, cache del browser, font-display. Non possono rompere nulla, quindi non serve testarli uno per uno.
Poi misurate i vostri Core Web Vitals per vedere cosa resta. Solo allora affrontate le leve da testare, critical CSS e rimando del JavaScript, una alla volta, verificando mobile E desktop e i vostri flussi chiave (menu, ricerca, carrello) dopo ogni modifica. La spiegazione completa è nella guida pilastro sulle ottimizzazioni sicure.
Con Mantys Core
Mantys Core può essere l'intero strato delle prestazioni, cache inclusa, oppure funzionare insieme alla configurazione che avete già. Su un sito Divi in particolare, si allinea con ciascuno dei passaggi visti sopra:
gestisce Critical CSS e used-CSS pagina per pagina, e rispetta i blocchi non ottimizzabili, così i menu e gli overlay nascosti al caricamento mantengono i loro stili;
misura la larghezza reale visualizzata di ogni immagine, riscrive
sizes, e genera WebP, includendo il ridimensionamento corretto che l'output nativo di Divi non coglie;ritarda il JavaScript con eccezioni dichiarate tramite frammento URL e un controllo sullo stato del documento, così il menu Divi continua a rispondere al primo tocco;
e separa mobile e desktop così non dovete indovinare quale cache serve cosa.
La regola d'oro, un motore per responsabilità, applicata per voi: disattivate le opzioni corrispondenti di Divi, e Mantys si occupa di quei compiti in modo pulito, senza due motori che si contendono lo stesso lavoro.
In sintesi
- Divi può essere veloce; ottimizzate nell'ordine, Immagini poi CSS poi JavaScript, e iniziate da ciò che non può rompersi.
- Immagini: comprimere, WebP, dimensioni corrette, lazy-load fuori schermo (mai per l'hero); le immagini di sfondo di Divi non hanno srcset, quindi dimensionatele a monte.
- CSS: attivate Dynamic CSS; mantenete un solo motore di critical CSS, non due; proteggete i menu e gli overlay nascosti al caricamento; rigenerate il CSS statico di Divi dopo le modifiche importanti.
- JavaScript: per mantenere il menu Divi con il ritardo JS attivo, escludete l'intera catena jQuery tramite frammento URL con un controllo sullo stato, oppure lasciate Defer jQuery disattivato.
- Metodo: prima tutti i guadagni sicuri, misurate i Core Web Vitals, poi le leve rischiose una alla volta, testando mobile e desktop.