Accelera Divi 5 con codice personalizzato

by | WordPress

Se le tue pagine Divi 5 impiegano dai 3 agli 8 secondi a caricarsi, nonostante il server non sia sovraccarico, il problema spesso deriva da una combinazione esplosiva di fattori: risorse caricate ovunque, richieste ripetute e JavaScript di terze parti che blocca il rendering.

Il problema

Il “bug” non è un errore unico, ma uno schema che vedo spesso sui siti Divi 5 (WordPress (6.9.4, PHP 8.1+): Il front-end diventa lento dopo l'aggiunta di moduli, script di marketing o dopo un aggiornamento di un tema/plugin. Anche il Visual Builder lato amministratore può risultare lento, ma questo articolo si concentra principalmente sulle prestazioni del front-end.

Quando si abilita il debug, è possibile che nei log vengano visualizzati segnali di questo tipo (esempi realistici):

PHP Warning:  Undefined array key "et_pb_pagebuilder" in /wp-content/themes/Divi/includes/builder/frontend-builder/helpers.php on line 123

PHP Notice:  Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the my-plugin domain was triggered too early. 
This is usually an indicator for some code in the plugin or theme running too early. in /wp-includes/functions.php on line 6121

E sul lato browser (console), i sintomi tipici sono:

[Violation] 'requestAnimationFrame' handler took 120ms
[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event
Uncaught ReferenceError: jQuery is not defined

Dove appare:

  • Front-end : pagina che “sfarfalla”, LCP elevato, Time To Interactive troppo lungo, scorrimento a scatti.
  • Admin : compilazione lenta, salvataggi lenti, anteprima lunga (spesso collegati alla stessa causa: troppi elementi e chiamate AJAX).
  • Cron / AJAX : a volte le chiamate ripetute (heartbeat, endpoint REST, admin-ajax) aumentano il carico.

A chi è destinata questa guida? A chi sa come aggiungere codice (tramite tema figlio o "mu-plugin"), sa leggere Query Monitor e desidera ottimizzare le prestazioni. compatibili WordPress 6.9.4+ sans Analisi approfondita di Divi 5, Elementor o Avada. Al termine, saprai come isolare il collo di bottiglia (risorse, database, JavaScript), applicare 3 correzioni di codice "prima/dopo" e verificare i risultati ottenuti.

Riassunto veloce

  • Inizia misurando : Prima di modificare il codice, utilizza Query Monitor e DevTools (LCP, TBT).
  • Divi 5 sta diventando lento soprattutto quando si caricano CSS/JS ovunque (anche su pagine che non ne hanno bisogno).
  • seconda causa più comune : query ripetitive al database (opzioni/caricamento automatico, meta query, shortcode che ricalcolano).
  • Terza causa : script di terze parti (chat, analisi, test A/B) che bloccano il thread principale.
  • 3 correzioni : interrogazioni condizionali, transienti + invalidazione, differimento/ritardo mirato (senza modificare gli script del builder).

Sintomi

  • Pagina lenta solo su determinati URL (ad esempio, la homepage ultra-modulare di Divi), mentre gli articoli semplici vanno bene.
  • LCP > 3s sui dispositivi mobili, anche con la cache di pagina abilitata.
  • Alto TBT (Tempo di blocco totale): la pagina "risponde" lentamente, lo scorrimento si blocca, i clic vengono ignorati.
  • Numero di richieste molto elevato (200+), spesso a causa di script, font e moduli di terze parti.
  • L'HTML viene caricato rapidamente ma il rendering è lento. Il server funziona correttamente, ma il browser impiega troppo tempo a eseguire codice JavaScript.
  • Errori dopo l'aggiunta di frammenti : schermata bianca (fatale) o pagine interrotte dopo un "differimento" eccessivamente aggressivo.
  • Conflitto tra cache e minimizzazione : CSS non applicato, JS "jQuery non è definito", i moduli Divi non sono più animati.

Tabella diagnostica rapida

sintomo Probabile causa Verifica Soluzione
TTFB OK (< 300ms) ma LCP/TBT scadente Livello JS + troppi asset Strumenti per sviluppatori > Prestazioni / Lighthouse Soluzione 1 + Soluzione 3
TTFB elevato (> 800 ms) anche con la cache Cache configurata in modo errato / pagine non memorizzate nella cache / richieste pesanti Cache delle intestazioni + Monitoraggio delle query (query) Soluzione 2 + verifica della cache del server
Le pagine sono lente solo quando sono connesse Barra di amministrazione, generatore, script “logged-in” Test in modalità Incognito + connessione Query condizionali + disabilitazione dei moduli amministrativi non necessari
Divi Builder lento, fronte accettabile Plugin di amministrazione complessi, Heartbeat, endpoint Monitoraggio query (AJAX), Rete Limita Heartbeat, pulisci i plugin di amministrazione
Dopo “defer JS”, ​​le animazioni si sono interrotte Rimanda l'esecuzione degli script jQuery/Divi Console: "jQuery non è definito" Soluzione 3 (lista di esclusione)

Perché succede

In parole semplici: Divi 5 funziona bene quando carica solo ciò che la pagina necessita. Ma non appena si aggiungono moduli, effetti, font, script di terze parti e plugin "tutto in uno", se ne paga il prezzo in termini di CSS/JS e di elaborazione lato browser.

Versione tecnica: predominano tre colli di bottiglia.

  • Risorse globali : il tuo tema/figlio o i tuoi plugin hanno messo in coda i file su toutes le pagine tramite wp_enqueue_scripts, a volte incondizionatamente. Anche se Divi 5 ottimizza il proprio flusso di lavoro, le tue aggiunte ignorano queste ottimizzazioni.
  • Query e calcoli ripetuti codici brevi, filtri the_content e moduli che realizzano WP_Query o get_posts() ad ogni accesso. Su un sito ad alto traffico, la cache della pagina maschera parzialmente... finché non si hanno pagine non memorizzate nella cache (carrello, area riservata) o molte varianti (cookie, geolocalizzazione, test A/B).
  • Blocco JavaScript Script di tracciamento, chat, mappe di calore, cursori, ecc., aggiungono carico al thread principale. Il browser ritarda il rendering e il punteggio Core Web Vitals crolla.

Cause elencate dalla più frequente alla più rara (nella sezione 5):

  1. Inserimento globale (CSS/JS) nel tema figlio o in un plugin per snippet.
  2. Minificazione/concatenazione eccessivamente aggressiva (cache dei plugin) che riordina le dipendenze (jQuery in ritardo, script inline prima della libreria).
  3. Query ripetute al database + opzioni di caricamento automatico sovradimensionate.
  4. Script di terze parti aggiunti "manualmente" in Divi (modulo codice) o tramite plugin per intestazione/piè di pagina.
  5. Incompatibilità tra PHP e memoria (siti che utilizzano ancora PHP 8.0 o con memory_limit troppo basso): un problema raro, ma reale.

Prerequisiti prima di iniziare

  • Sauvegarde Completamento (file + database). Se ti trovi in ​​ambiente di produzione, esegui una clonazione/staging.
  • versioni : WordPress 6.9.4, PHP 8.1+ (idealmente 8.2/8.3 se il tuo provider di hosting lo offre), Divi 5 aggiornato.
  • strumenti :

Abilitare un ambiente di debug utilizzabile (possibilmente in ambiente di staging):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Évitez d'afficher les notices en front
define( 'SCRIPT_DEBUG', false ); // Laissez à false en prod; true uniquement pour diagnostiquer

Documenti ufficiali utili: Debug di WordPress.

Soluzione 1: Eliminare i file CSS/JS caricati inutilmente (query condizionali)

Ho riscontrato spesso questo problema sui siti Divi, dove il tema figlio carica i file "site.css" e "site.js" ovunque, e dove questi file includono librerie pesanti (swiper, gsap, fancybox) utilizzate in sole due pagine.

Diagnosi

  • Strumenti per sviluppatori > Rete: identifica i file CSS/JS "personalizzati" caricati su una pagina che non ne ha bisogno (ad esempio, un semplice articolo).
  • Query Monitor > Script/Stili: identifica gli handle (nomi) e l'origine (tema figlio, plugin).

Prima (rotto): coda globale

Esempio tipico in functions.php dal tema figlio (o da un plugin per snippet):

<?php
add_action( 'wp_enqueue_scripts', function () {
	// Mauvaise pratique : chargé sur toutes les pages, même quand inutile
	wp_enqueue_style(
		'child-site',
		get_stylesheet_directory_uri() . '/assets/site.css',
		array(),
		'1.0.0'
	);

	wp_enqueue_script(
		'child-site',
		get_stylesheet_directory_uri() . '/assets/site.js',
		array( 'jquery' ),
		'1.0.0',
		true
	);
}, 10 );

Dopo (corretto): carica solo quando necessario

Obiettivo: caricare le risorse solo sulle pagine in cui sono necessarie. In Divi, spesso le pagine sono identificabili tramite ID, slug, template o la presenza di uno shortcode/modulo.

<?php
/**
 * Plugin conseillé : placez ce code dans un mu-plugin pour éviter les pertes lors d'une mise à jour.
 * Fichier : wp-content/mu-plugins/divi-perf-enqueues.php
 */
add_action( 'wp_enqueue_scripts', function () {
	// Ne jamais casser l'admin
	if ( is_admin() ) {
		return;
	}

	$should_load = false;

	// 1) Exemple : ne charger que sur la page "Accueil" (à adapter)
	if ( is_front_page() ) {
		$should_load = true;
	}

	// 2) Exemple : ne charger que sur un template spécifique
	if ( is_page_template( 'templates/landing.php' ) ) {
		$should_load = true;
	}

	// 3) Exemple : ne charger que sur une page précise (ID)
	if ( is_page( 123 ) ) {
		$should_load = true;
	}

	if ( ! $should_load ) {
		return;
	}

	// Versionnez avec filemtime() pour éviter les caches fantômes après déploiement
	$css_path = get_stylesheet_directory() . '/assets/site.css';
	$js_path  = get_stylesheet_directory() . '/assets/site.js';

	wp_enqueue_style(
		'child-site',
		get_stylesheet_directory_uri() . '/assets/site.css',
		array(),
		file_exists( $css_path ) ? (string) filemtime( $css_path ) : null
	);

	wp_enqueue_script(
		'child-site',
		get_stylesheet_directory_uri() . '/assets/site.js',
		array(),
		file_exists( $js_path ) ? (string) filemtime( $js_path ) : null,
		true
	);
}, 20 );

Perché accelera effettivamente?

  • Meno byte Scaricabile, soprattutto su dispositivi mobili.
  • Meno CSS da analizzare (il browser impiega del tempo a ricalcolare gli stili).
  • Meno codice JavaScript da eseguire, pertanto TBT è in calo.

Spiegazione blocco per blocco

  • is_admin() : evita di compromettere l'editor/il generatore.
  • $should_load : centralizza la logica. Ho visto troppi siti con 10 if dispersi, impossibili da mantenere.
  • filemtime() : evita la trappola del "Ho risolto il problema, ma la cache sta ancora servendo la vecchia versione".
  • Eliminazione della dipendenza jquery Se non ti serve: jQuery è spesso presente su Divi, ma non richiederlo inutilmente.

Alternativa utile: chiudere un plugin su determinate pagine

Molti rallentamenti derivano da plugin che vengono caricati ovunque (moduli, slider, mappe). È possibile scaricarli correttamente se si conoscono i relativi handle.

<?php
add_action( 'wp_enqueue_scripts', function () {
	// Exemple : sur les articles, enlever un script inutile (handle à adapter)
	if ( is_single() ) {
		wp_dequeue_script( 'some-plugin-frontend' );
		wp_dequeue_style( 'some-plugin-frontend' );
	}
}, 100 ); // Priorité haute pour passer après les enqueues du plugin

Riferimento ufficiale: wp_dequeue_script ().

Soluzione 2: Evitare richieste ripetitive (transienti + cache degli oggetti)

In Divi 5, le pagine "di marketing" spesso contengono moduli dinamici (articoli in evidenza, prodotti, testimonianze). Il problema: uno shortcode o un modulo personalizzato esegue una query sul database ogni volta che viene visualizzato, a volte più volte per pagina.

Diagnosi

  • Monitoraggio query > Query: identifica le query ripetute (stessa SELECT, stessa meta_key).
  • Controlla anche “Chiamante”: vedrai subito se proviene da un codice breve in the_content o un aggancio globale.

Prima (rotto): shortcode che effettua richieste ad ogni hit

Esempio concreto: uno shortcode per gli "ultimi articoli" inserito in un modulo Code Divi.

<?php
add_shortcode( 'latest_posts_cards', function ( $atts ) {
	$atts = shortcode_atts(
		array(
			'count' => 6,
		),
		$atts,
		'latest_posts_cards'
	);

	$q = new WP_Query(
		array(
			'post_type'      => 'post',
			'posts_per_page' => (int) $atts['count'],
			'no_found_rows'  => true,
		)
	);

	if ( ! $q->have_posts() ) {
		return '';
	}

	ob_start();
	echo '<div class="cards">';
	while ( $q->have_posts() ) {
		$q->the_post();
		echo '<a class="card" href="' . esc_url( get_permalink() ) . '">' . esc_html( get_the_title() ) . '</a>';
	}
	echo '</div>';
	wp_reset_postdata();

	return (string) ob_get_clean();
} );

Problemi:

  • Ogni visualizzazione = una query (o più se si aggiungono metadati/termini).
  • Se lo shortcode si estende su più pagine, il carico aumenta vertiginosamente.
  • Se ti trovi su una pagina non nascosta (pagina membro, carrello acquisti), paghi a ogni visita.

Dopo (corretto): transitorio + invalidazione corretta

Il codice HTML finale viene memorizzato nella cache e invalidato quando un articolo viene pubblicato o aggiornato. È semplice, robusto e compatibile con WordPress 6.9.4.

<?php
/**
 * Cache HTML d'un shortcode avec transient.
 * Compatible PHP 8.1+.
 */

function bpcab_latest_posts_cards_render( int $count ): string {
	$q = new WP_Query(
		array(
			'post_type'              => 'post',
			'posts_per_page'         => $count,
			'no_found_rows'          => true,
			'ignore_sticky_posts'    => true,
			'update_post_meta_cache' => false,
			'update_post_term_cache' => false,
		)
	);

	if ( ! $q->have_posts() ) {
		return '';
	}

	ob_start();
	echo '<div class="cards">';
	while ( $q->have_posts() ) {
		$q->the_post();
		echo '<a class="card" href="' . esc_url( get_permalink() ) . '">' . esc_html( get_the_title() ) . '</a>';
	}
	echo '</div>';
	wp_reset_postdata();

	return (string) ob_get_clean();
}

add_shortcode( 'latest_posts_cards', function ( $atts ) {
	$atts = shortcode_atts(
		array(
			'count' => 6,
		),
		$atts,
		'latest_posts_cards'
	);

	$count = max( 1, min( 20, (int) $atts['count'] ) );

	// Clé de cache dépendante du paramètre
	$cache_key = 'bpcab_latest_posts_cards_' . $count;

	$cached = get_transient( $cache_key );
	if ( is_string( $cached ) && $cached !== '' ) {
		return $cached;
	}

	$html = bpcab_latest_posts_cards_render( $count );

	// TTL raisonnable : 15 minutes (à adapter)
	set_transient( $cache_key, $html, 15 * MINUTE_IN_SECONDS );

	return $html;
} );

/**
 * Invalidation : quand un post est publié/mis à jour/supprimé.
 * On supprime plusieurs variantes (count 1..20) pour rester simple.
 */
function bpcab_latest_posts_cards_purge_cache(): void {
	for ( $i = 1; $i <= 20; $i++ ) {
		delete_transient( 'bpcab_latest_posts_cards_' . $i );
	}
}

add_action( 'save_post_post', function ( $post_id, $post, $update ) {
	// Évitez les autosaves/révisions
	if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) ) {
		return;
	}
	bpcab_latest_posts_cards_purge_cache();
}, 10, 3 );

add_action( 'deleted_post', function ( $post_id ) {
	if ( get_post_type( $post_id ) === 'post' ) {
		bpcab_latest_posts_cards_purge_cache();
	}
}, 10, 1 );

Perché questo risolve il problema?

  • Stai rimuovendo le richieste nella maggior parte dei casi (soprattutto con la cache degli oggetti Redis/Memcached).
  • Eviti il ​​ricalcolo HTML in the_content, che è un punto caldo su Divi (molti filtri).
  • È possibile limitare le cache meta/terms tramite update_post_meta_cache et update_post_term_cache quando non ne hai bisogno.

Valutazioni di prestazioni e compatibilità

  • I dati temporanei vengono memorizzati nel database senza cache degli oggetti e in memoria utilizzando Redis/Memcached. Entrambe le soluzioni sono valide, ma il miglioramento delle prestazioni è significativamente maggiore con una cache degli oggetti persistente.
  • Documento ufficiale: API Transienti.
  • Evitate di impostare un TTL di "1 giorno" senza invalidazione: visualizzerete contenuti obsoleti e finirete per "svuotare tutte le cache" in preda al panico.

Soluzione 3: Ritardare l'esecuzione di JavaScript di terze parti (defer/delay) senza compromettere Divi 5

Lo scenario classico: abiliti un'opzione "JS Delay" in un plugin di caching e Divi (o un modulo) si blocca. Quindi disabiliti l'opzione e perdi un enorme vantaggio. L'approccio corretto è fare riferimento solo al terzoe a escludere script critici (jQuery, script del tema/builder, script inline dipendenti).

Diagnosi

  • Strumenti per sviluppatori > Prestazioni: identifica le attività che richiedono molto tempo e il codice JavaScript che le blocca.
  • Strumenti per sviluppatori > Rete: identifica i domini di terze parti (ad esempio connect.facebook.net, www.googletagmanager.com, gatto, ecc).

Prima (rotto): differimento globale su tutti gli script

Un frammento pericoloso che vedo ancora circolare (spesso copiato da un vecchio tutorial):

<?php
add_filter( 'script_loader_tag', function ( $tag ) {
	// Mauvaise pratique : defer sur absolument tout
	return str_replace( '<script ', '<script defer ', $tag );
} );

Risultati tipici: Uncaught ReferenceError: jQuery is not definedModuli Divi che non si inizializzano, slider bloccati.

Dopo (corretto): differimento mirato + elenco di esclusione

Noi applichiamo defer Escludiamo solo gli script non critici ed escludiamo esplicitamente gli handle sensibili. Il punto chiave: non indoviniamo gli handle interni di Divi (possono cambiare). Piuttosto, escludiamo in base alle dipendenze e alle "famiglie" (jQuery + script contrassegnati come critici) e limitiamo l'esclusione ai componenti di terze parti che controlli (i tuoi script + alcuni plugin).

<?php
/**
 * Defer ciblé des scripts front.
 * Objectif : réduire le JS bloquant sans casser Divi 5.
 *
 * Placez ce code en mu-plugin et testez sur staging.
 */
add_filter( 'script_loader_tag', function ( $tag, $handle, $src ) {

	if ( is_admin() ) {
		return $tag;
	}

	// 1) Exclusions strictes : ne touchez pas à jQuery ni aux scripts "core"
	$excluded_handles = array(
		'jquery',
		'jquery-core',
		'jquery-migrate',
	);

	if ( in_array( $handle, $excluded_handles, true ) ) {
		return $tag;
	}

	// 2) Exclure les scripts chargés dans l'en-tête (souvent critiques)
	// Si un script n'est pas en footer, on évite d'y toucher par défaut.
	// (On ne peut pas toujours détecter "in_footer" ici de façon fiable selon les plugins.)
	// Stratégie : n'appliquer defer qu'à une allowlist.
	$allowed_handles = array(
		'child-site',              // Votre JS custom
		'contact-form-7',          // Exemple : à adapter
		'wpforms',                 // Exemple : à adapter
		'gtm4wp',                  // Exemple : à adapter
	);

	if ( ! in_array( $handle, $allowed_handles, true ) ) {
		return $tag;
	}

	// 3) N'ajoutez pas defer si déjà présent
	if ( str_contains( $tag, ' defer' ) ) {
		return $tag;
	}

	// Ajout de defer
	return str_replace( '<script ', '<script defer ', $tag );

}, 10, 3 );

Opzione “Ritardo” (più aggressiva): solo per script di terze parti identificati.

Quando il vero problema deriva da un copione terze parti (chat/mappa di calore), defer Non sempre è sufficiente. È possibile ritardare il caricamento dopo l'interazione. È più rischioso (in termini di esperienza utente e tracciamento), ma efficace.

Esempio minimalista: uno script di terze parti viene iniettato solo dopo il primo scorrimento/clic. Lo faccio principalmente per i widget di chat.

<?php
/**
 * Injecte un loader JS "delay" en footer.
 * Ajustez la liste de scripts tiers selon vos besoins.
 */
add_action( 'wp_footer', function () {

	if ( is_admin() ) {
		return;
	}

	?>
<script>
(function() {
	"use strict";

	var loaded = false;

	function loadThirdParty() {
		if (loaded) return;
		loaded = true;

		// Exemple : charger un script tiers (URL à adapter)
		var s = document.createElement("script");
		s.src = "https://example-cdn.invalid/chat-widget.js";
		s.async = true;
		document.head.appendChild(s);
	}

	// Déclencheurs : interaction utilisateur
	window.addEventListener("scroll", loadThirdParty, { passive: true, once: true });
	window.addEventListener("click", loadThirdParty, { passive: true, once: true });
	window.addEventListener("keydown", loadThirdParty, { passive: true, once: true });

	// Fallback : charge au bout de 8s si aucune interaction
	window.setTimeout(loadThirdParty, 8000);
})();
</script>
	<?php
}, 100 );

rischi Potresti perdere gli eventi di analisi "visualizzazione di pagina" se aspetti troppo. Esegui un test con il tuo strumento (GA4, Matomo, Pixel) e documenta la tua scelta.

Documentazione ufficiale sul caricamento degli script: wp_enqueue_script () e filtro script_loader_tag.

Controlli post-correzione

  • Misurazione prima/dopo :
    • Faro (mobile): LCP, TBT, CLS.
    • Strumenti per sviluppatori > Rete: numero di richieste, peso totale trasferito.
    • Monitoraggio delle query: numero di query al database, tempo totale, query lente.
  • Divi 5 Test Funzionali :
    • Menu, ancore, cursori, fisarmoniche, moduli.
    • Pagine con moduli dinamici (blog, negozio, testimonianze).
  • Prova connesso vs. scollegato Divi e alcuni plugin si caricano più velocemente quando si è effettuato l'accesso.
  • Cache Svuota la cache dei plugin, la cache del server (se presente) e la cache del browser. Ho visto persone "confermare" una regressione perché stavano testando una vecchia risorsa memorizzata nella cache.

Se ciò non funziona ancora

  1. Isolare un conflitto Con Controllo integrità (modalità Risoluzione dei problemi): disattiva tutti i plugin tranne Divi/Divi Builder, quindi riattivali uno alla volta.
  2. Verifica la presenza di errori PHP in wp-content/debug.logUn'eccessiva quantità di notifiche può rallentare le cose (soprattutto se il file di registro si trova su un disco lento).
  3. Controllo della memoria PHP Se ti avvicini al limite, potresti riscontrare problemi di swapping/GC. Controlla WP_MEMORY_LIMIT e il limite da parte del fornitore di hosting.
  4. Visualizza le opzioni di caricamento automatico : quando autoload Diventa enorme; ogni query carica troppi dati. Query Monitor può essere d'aiuto, altrimenti è necessaria un'ispezione del database (avanzata).
  5. Disabilita temporaneamente la minimizzazione/concatenazione (Plugin Cache): Se il sito torna stabile, il problema è l'ordine degli script. Riattivalo, escludendo i file di Divi/jQuery.
  6. Console del browser Un singolo errore JavaScript può impedire l'inizializzazione dei moduli (il che fa apparire il sito come "lento" quando si tratta di uno script che esegue un ciclo).
  7. Test senza CDN (temporaneamente): una CDN configurata in modo errato può causare latenza e mancate corrispondenze nella cache.
  8. Riscritture Se riscontri errori 404 sugli asset, rigenera i permalink (riscrivi) e controlla le regole del server.

Comandi WP-CLI utili (se si dispone dell'accesso)

# Vérifier l'environnement
wp core version
wp php version
wp plugin list --status=active
wp theme list

# Vider certains caches (selon votre stack)
wp cache flush

# Repérer des options autoload (avancé, à manipuler avec prudence)
wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_bytes FROM wp_options WHERE autoload='yes';"

WP-CLI: documentazione ufficiale.

Errori e trappole comuni

sintomo Probabile causa Soluzione consigliata
Schermata bianca dopo l'aggiunta del frammento Codice copiato nel posto sbagliato / punto e virgola mancante Prova in ambiente di test, attiva WP_DEBUG_LOGcorreggere la sintassi
jQuery is not defined La funzione Defer è stata applicata a jQuery o l'ordine degli script è stato interrotto dalla minimizzazione. Escludere jquery/jquery-coredisabilita concat, ritesta
Il frammento di codice “non funziona” La pagina della cache/CDN serve la vecchia versione Versione con filemtime()svuota la cache dei plugin + CDN
Ottimizzazione OK in locale, lenta in produzione Script di terze parti, latenza di rete, cache degli oggetti mancante Profilo in produzione (senza impatto), abilitare Redis/Memcached se possibile
Hook non eseguiti Snippet inserito in un plugin disabilitato / conflitto con un plugin per snippet Preferisci uno mu-pluginverificare l'ordine di carico
CSS/JS non caricati cattivo get_stylesheet_directory_uri() vs get_template_directory_uri() Per i temi per bambini, utilizzare get_stylesheet_*
Regressione su Elementor/Avada Rimuovi dalla coda un handle condiviso o troppo globale Applica le condizioni per pagina/modello, evita le regole "valide per tutto il sito".

Errori che vedo spesso (e che costano caro)

  • Copia un frammento di testo “rimanda tutto” Trovato su un forum: prima o poi si rompe.
  • Inserisci il codice nel file sbagliato (Es. functions.php (del tema principale Divi). Tutto si romperà nel prossimo aggiornamento.
  • Dimenticare la priorità : per wp_dequeue_script, spesso è richiesta un'alta priorità (ad esempio 100).
  • Confondere azione e filtro : script_loader_tag Si tratta di un filtro, non di un'azione.
  • Test direttamente in produzione senza possibilità di rollback. Su un sito Divi, un errore JavaScript può avere un impatto su tutte le pagine.

Variante / alternativa

Metodo senza codice (plugin)

  • Un plugin di caching/prestazioni che gestisce le esclusioni tramite handle (minificazione, ritardo JS) può essere sufficiente se ci si prende il tempo di configurare le esclusioni di Divi. L'insidia è l'"ottimizzazione con un clic": su Divi, spesso non funziona.
  • Per quanto riguarda il database, una cache di oggetti persistente (Redis/Memcached) offre un vantaggio netto sulle pagine non memorizzate nella cache.

Metodo più avanzato (sviluppatori)

  • Profilo PHP (APM): Sentry, New Relic, Datadog. Potrai subito capire se la lentezza è dovuta al database, all'API HTTP o alla CPU.
  • Sostituisci alcuni shortcode mediante blocchi o modelli statici, quando il contenuto non deve essere ricalcolato a ogni accesso.
  • Suddivisione del codice JS personalizzato : un bundle per tipo di pagina, caricato in modo condizionale (Soluzione 1), piuttosto che un site.js monolitico.

Evita questo problema in futuro

  • Adotta una regola semplice Niente CSS/JS "globali" personalizzati senza giustificazione. Caricali per pagina/modello o per funzionalità.
  • Nascondi ciò che è costoso Gli shortcode e le query devono avere una strategia di caching (transitorio + invalidazione).
  • Evita le dipendenze invisibili Se il tuo codice JavaScript dipende da jQuery, dichiaralo esplicitamente. Se possibile, passa a JavaScript puro per ridurre i vincoli di ordine.
  • Monitorare gli script di terze parti Ogni widget "gratuito" contribuisce ad aumentare i costi. Ho visto pagine con 12 tag di marketing; nessuna ottimizzazione di WordPress può compensare una spesa del genere.
  • Tenere un registro interno delle modifiche Quando si abilita "delay JS", prestare attenzione alle esclusioni, altrimenti si rischia di perdere ore al prossimo incidente.

Riferimenti utili a WordPress:

Risorse

Domande frequenti

Divi 5 è necessariamente più lento di un tema a blocchi?

No. Su pagine semplici, Divi 5 può essere perfettamente adeguato. La differenza si nota soprattutto su pagine altamente modulari e con un elevato numero di script di terze parti. Il fattore determinante è ciò che si carica ed esegue su ciascuna pagina.

Dove inserire il codice: tema figlio, plugin, mu-plugin?

Per le ottimizzazioni dell'"infrastruttura" (accodamenti, differimento, cache), consiglio un mu-pluginIn questo modo si evitano perdite di dati durante un aggiornamento di Divi o un cambio di tema.

È compatibile con Elementor o Avada?

Sì, se si rispettano le condizioni per pagina/modello e un elenco di handle consentiti. Il pericolo è il frammento "defer all" o il wp_dequeue_* troppo globale, il che può rimuovere risorse necessarie a un altro sviluppatore.

Perché Query Monitor mostra un numero inferiore di query, ma la pagina rimane lenta?

Probabilmente il collo di bottiglia si trova sul lato browser (JS/CSS) o sul lato rete (script di terze parti). Verifica il TBT, le attività di lunga durata e il peso totale trasferito.

La cache di pagina non è sufficiente?

La memorizzazione nella cache delle pagine è utile soprattutto per migliorare il TTFB (Time To First Byte). Se il LCP/TBT (Last Contentful Page) è scarso, spesso è dovuto a CSS/JS eccessivamente prolissi o caricati in modo errato. Da qui l'importanza delle query condizionali e del differimento mirato.

Devo abilitare OPcache?

Sì, se il tuo provider di hosting lo consente. OPcache riduce significativamente l'utilizzo della CPU da parte di PHP. Riferimento: PHP OP Cache.

Come si fa a sapere quali handle escludere dal differimento?

Inizia escludendo jquery, jquery-coreQuindi aggiungi gli script che si interrompono durante l'esecuzione. Usa Query Monitor (scheda Script) per visualizzare i riferimenti esatti.

Il transitorio causerà problemi con i contenuti obsoleti?

Non se si invalida correttamente durante gli aggiornamenti (ad esempio save_postSenza invalidazione, sì, si finirà per avere contenuti incoerenti.

L'utilizzo di "delay JS" è dannoso per la SEO?

Dipende da cosa stai ritardando. Ritardare una chat in genere non ha un impatto sulla SEO. Ritardare uno script che inserisce contenuti visibili può causare problemi. Mantieni gli script critici immediati e ritarda quelli di terze parti non essenziali.

Riscontro rallentamenti solo quando sono connesso a Internet, è normale?

Spesso sì: barra di amministrazione, script di modifica, plugin che caricano risorse "autenticate". Testa sempre in modalità di navigazione privata per misurare l'esperienza dell'utente.

articoli correlati

Invia un commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati dei tuoi commenti.