Gyorsítsd fel a Divi 5-öt egyéni kóddal

Ha a Divi 5 oldalaid 3-8 másodperc alatt jelennek meg, annak ellenére, hogy a szervered nincs túlterhelve, a probléma gyakran robbanásveszélyes keverékből fakad: mindenhol betöltött elemek, ismétlődő kérések és harmadik féltől származó JavaScript blokkolja a megjelenítést.

a probléma

A „hiba” nem egyedi hiba, hanem egy minta, amit gyakran látok a Divi 5 oldalakon (WordPress (6.9.4, PHP 8.1+): A front-end lelassul modulok, marketing szkriptek hozzáadása vagy téma/bővítmény frissítése után. Adminisztrációs oldalon a Visual Builder is lassú lehet, de ez a bejegyzés elsősorban a front-end teljesítményére összpontosít.

Amikor engedélyezi a hibakeresést, a naplókban az alábbi jeleket találhatja (valós példák):

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

És a böngésző (konzol) oldalán a tipikus tünetek:

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

Ahol megjelenik:

Front-end : „villogó” oldal, magas LCP, túl hosszú az interakcióig eltelt idő, szaggatott görgetés.
admin lassú builder, lassú mentések, hosszú előnézet (gyakran ugyanarra az okra vezethető vissza: túl sok elem és AJAX hívások).
Cron / AJAX : néha az ismételt hívások (heartbeat, REST végpontok, admin-ajax) növelik a terhelést.

Kinek szól ez az útmutató? Tudod, hogyan kell kódot hozzáadni (gyermektéma vagy „mu-plugin”), ismered a Query Monitort, és optimalizálni szeretnéd a tartalmaidat. Összeegyeztethető WordPress 6.9.4 + sans Divi 5, Elementor vagy Avada feltörése. A végére tudni fogod, hogyan izoláld a szűk keresztmetszetet (eszközök, adatbázis, JS), hogyan alkalmazz 3 „előtte/utána” kódjavítást, és hogyan validáld az eredményeket.

Gyors összefoglaló

Kezdje a méréssel Lekérdezésfigyelő + fejlesztői eszközök (LCP, TBT) használata a kód megkezdése előtt.
Lassul az 5. osztály főleg, ha mindenhová betöltöd a CSS/JS-t (még olyan oldalakra is, ahol nincs rá szükség).
Második leggyakoribb ok ismétlődő adatbázis-lekérdezések (opciók/automatikus betöltés, meta lekérdezések, újraszámoló rövidkódok).
Harmadik ok : harmadik féltől származó szkriptek (chat, analitika, A/B tesztelés), amelyek blokkolják a fő szálat.
3 javítás feltételes lekérdezések, tranziensek + érvénytelenítés, célzott késleltetés/halasztás (a builder szkriptek érintése nélkül).

Tünetek

Az oldal csak bizonyos URL-eken lassú (pl. ultramoduláris Divi honlap), míg az egyszerű cikkek is megfelelőek.
LCP > 3 másodperc mobilon, még akkor is, ha engedélyezve van az oldal gyorsítótára.
Magas TBT (Teljes blokkolási idő): az oldal lassan „reagál”, a görgetés elakad, a kattintásokat figyelmen kívül hagyja.
Kérelmek száma nagyon magas (200+), gyakran harmadik féltől származó szkriptek + betűtípusok + modulok miatt.
A HTML gyorsan kézbesült, de lassan jelenik meg : a szerver rendben van, de a böngésző JS-ben tölti az idejét.
Hibák kódrészletek hozzáadása után fehér képernyő (végzetes) vagy törött oldalak egy túlságosan agresszív "elhalasztás" után.
Gyorsítótár/minifikációs ütközés CSS nincs alkalmazva, JS „jQuery nincs definiálva”, a Divi modulok már nem animálnak.

Gyors diagnosztikai táblázat

tünet	Valószínű ok	igazolás	Megoldás
TTFB OK (< 300 ms), de LCP/TBT gyenge	JS szint + túl sok elem	DevEszközök > Teljesítmény / Világítótorony	1. megoldás + 3. megoldás
Magas TTFB (> 800ms) még gyorsítótárral is	A gyorsítótár rosszul van konfigurálva / az oldalak nincsenek gyorsítótárazva / nagy mennyiségű kérés érkezik	Fejlécek gyorsítótára + Lekérdezésfigyelő (lekérdezések)	2. megoldás + a szerver gyorsítótárának ellenőrzése
Az oldalak csak csatlakozáskor lassúak	Adminisztrációs sáv, szerkesztő, „bejelentkezett” szkriptek	Inkognitó + csatlakoztatott teszt	Feltételes lekérdezések + felesleges adminisztrációs modulok letiltása
Lassú Divi Builder, elfogadható előlap	Nehéz adminisztrációs bővítmények, Heartbeat, végpontok	Lekérdezésfigyelő (AJAX), Hálózat	Korlátozd a szívverést, tisztítsd meg az adminisztrációs bővítményeket
A „JS elhalasztása” után az animációk elromlottak.	jQuery/Divi szkriptek elhalasztása	Konzol: „A jQuery nincs definiálva”	3. megoldás (kizárási lista)

Miért történik ez?

Egyszerűen fogalmazva: a Divi 5 akkor teljesít jól, ha csak azt tölti be, amire az oldalnak szüksége van. De amint rétegezed a modulokat, effekteket, betűtípusokat, harmadik féltől származó szkripteket és az „all-in-one” bővítményeket, meg kell fizetni az árát CSS/JS és böngészőoldali feldolgozás tekintetében.

Technikai változat: három szűk keresztmetszet dominál.

Globális eszközök : a témád/gyermeked vagy a bővítményeid sorba rendezett fájljai itt: összes az oldalakon keresztül wp_enqueue_scripts, néha feltétel nélkül. Annak ellenére, hogy a Divi 5 optimalizálja a saját folyamatát, a kiegészítéseid megkerülik ezeket az optimalizálásokat.
Ismétlődő lekérdezések és számítások rövidkódok, szűrők the_content és modulok, amelyek elkészítik WP_Query vagy get_posts() minden találattal. Egy nagy forgalmú oldalon az oldal gyorsítótára részben maszkolja... amíg nincsenek gyorsítótárazatlan oldalak (bevásárlókosár, tagoknak fenntartott terület) vagy sok variációja (sütik, geolokáció, A/B tesztelés).
JavaScript blokkolás A követőszkriptek, a chat, a hőtérképek, a slaiderek stb. plusz munkát adnak a fő szálhoz. A böngésző késlelteti a renderelést, és a Core Web Vitals pontszám zuhan.

Az okok a leggyakoribbtól a legritkábbig felsorolva (az 5. csoportban):

Globális sorba állítás (CSS/JS) a gyermektémában vagy egy kódrészlet bővítményben.
Túl agresszív minifikáció/concat (bővítmény gyorsítótár), amely átrendezi a függőségeket (a jQuery lemarad, a függvénykönyvtár elé beágyazott szkriptek).
Ismétlődő adatbázis-lekérdezések + túlméretezett automatikus betöltési lehetőségek.
Harmadik féltől származó szkriptek „manuálisan” hozzáadva a Divi-ben (kódmodul) vagy fejléc/lábléc bővítményen keresztül.
PHP/memória inkompatibilitás (az oldalak még PHP 8.0-t használnak, vagy a memória_limit túl alacsony), ritka, de valós.

Előfeltételek a kezdés előtt

védelme Kész (fájlok + adatbázis). Ha éles környezetben dolgozol, végezz klónozást/bemelegítést.
változatok WordPress 6.9.4, PHP 8.1+ (ideális esetben 8.2/8.3, ha a tárhelyszolgáltatód kínálja), naprakész Divi 5.
Tools :
- Lekérdezés figyelő kérésekhez, hookokhoz, HTTP API-hoz és PHP hibákhoz.
- Állapotfelmérés és hibaelhárítás hogy elszigeteljék a konfliktust a nyilvános helyszín megzavarása nélkül.
- Hozzáférés wp-config.php a hibakeresés megfelelő engedélyezéséhez.

Használható hibakeresési környezet engedélyezése (lehetőleg előzetesen):

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

Hasznos hivatalos dokumentumok: WordPress hibakeresése.

1. megoldás: Törölje a feleslegesen betöltött CSS/JS-t (feltételes lekérdezések)

Gyakran találkoztam ezzel a problémával Divi oldalakon, ahol a gyermektéma mindenhová betölti a „site.css” és a „site.js” fájlokat, és ahol ezek a fájlok két oldalon használt nehéz függvénykönyvtárakat (swiper, gsap, fancybox) tartalmaznak.

Diagnosztikai

DevTools > Network: azonosítsa az „egyéni” CSS/JS fájlokat, amelyek olyan oldalakon töltődnek be, amelyeknek nincs rájuk szükségük (pl. egy egyszerű cikk).
Lekérdezésfigyelő > Szkriptek/Stílusok: azonosítsa a handle-öket (neveket) és az eredetet (gyermektéma, bővítmény).

Előtte (hibás): globális sorba helyezés

Tipikus példa a functions.php a gyermek témából (vagy egy kódrészlet bővítményből):

<?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 );

Utána (javítva): csak szükség esetén töltse be

Cél: az elemek betöltése csak azokon az oldalakon, ahol szükség van rájuk. A Diviben gyakran vannak olyan oldalak, amelyek azonosíthatók azonosító, slug, sablon vagy rövidkód/modul megléte alapján.

<?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 );

Miért gyorsul fel valójában?

Kevesebb bájt Letölthető, különösen mobilon.
Kevesebb CSS elemzése (a böngésző időt tölt a stílusok újraszámításával).
Kevesebb JS futtatása, ezért a TBT csökkent.

Blokkról blokkra történő magyarázat

is_admin() : elkerüli a szerkesztő/szerkesztő összeomlását.
$should_load : központosítja a logikát. Túl sok olyan oldalt láttam már, ahol 10 if szétszórt, fenntarthatatlan.
filemtime() : elkerüli a „javítottam, de a gyorsítótár a régi verziót szolgálja ki” csapdát.
Függőség eltávolítása jquery Ha nincs rá szükséged: a jQuery gyakran megtalálható a Divi-n, de ne használd feleslegesen.

Hasznos alternatíva: bővítmény eltávolítása bizonyos oldalakról

Sok lassulás oka olyan bővítményekből adódik, amelyek mindenhol betöltődnek (űrlapok, csúszkák, térképek). Ezeket gond nélkül eltávolíthatod, ha ismered a kezelőfelületeket.

<?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

Hivatalos hivatkozás: wp_dequeue_script ().

2. megoldás: Kerülje az ismétlődő kéréseket (tranziensek + objektumgyorsítótár)

A Divi 5-ben a „marketing” oldalak gyakran tartalmaznak dinamikus modulokat (kiemelt cikkek, termékek, ajánlások). A buktató: egy rövidkód vagy egyéni modul minden alkalommal adatbázis-lekérdezést hajt végre, amikor megjelenik, néha oldalonként többször is.

Diagnosztikai

Lekérdezésfigyelő > Lekérdezések: ismétlődő lekérdezések azonosítása (ugyanaz a SELECT, ugyanaz a meta_key).
Nézd meg a „Hívó” funkciót is: gyorsan láthatod, hogy rövid kódról érkezik-e. the_content vagy egy globális horog.

Előtte (hibás): rövid kód, amely minden találatkor lekérdezi

Realisztikus példa: egy „legfrissebb cikkek” rövidkód beillesztve egy Code Divi modulba.

<?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();
} );

Problémák:

Minden megjelenítés = egy lekérdezés (vagy több, ha metaadatokat/kifejezéseket adsz hozzá).
Ha a rövidkód több oldalra terjed ki, a betöltés felrobban.
Ha nem rejtett oldalon vagy (tag, bevásárlókosár), akkor minden látogatáskor fizetsz érte.

Utána (javítva): átmeneti + megfelelő érvénytelenítés

A végleges HTML gyorsítótárba kerül, és érvénytelenné válik, amikor egy cikket közzétesznek/frissítenek. Egyszerű, robusztus és kompatibilis a WordPress 6.9.4-es verziójával.

<?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 );

Miért oldja meg ez a problémát?

A legtöbb találatnál eltávolítod a kéréseket (különösen a Redis/Memcached objektum gyorsítótárazással).
Elkerülöd a HTML újraszámítását a következőben: the_content, ami a Divi egyik népszerű pontja (sok szűrővel).
A meta/kifejezések gyorsítótárainak korlátozása a következőképpen történik: update_post_meta_cache et update_post_term_cache amikor nincs rá szükséged.

Teljesítmény- és kompatibilitási értékelések

A tranzienseket az adatbázisban objektumgyorsítótár nélkül, a memóriában pedig Redis/Memcached használatával tárolja a rendszer. Mindkettő rendben van, de a teljesítménynövekedés jelentősen jobb egy perzisztens objektumgyorsítótárral.
Hivatalos dokumentum: API tranziensek.
Kerüld az „1 napos” TTL beállítását érvénytelenítés nélkül: elavult tartalmat fogsz látni, és pánikszerűen „törölni fogod az összes gyorsítótárat”.

3. megoldás: Késleltesse a harmadik féltől származó JavaScriptet (defer/delay) a Divi 5 megsértése nélkül

A klasszikus forgatókönyv: engedélyezed a „JS Delay” opciót egy gyorsítótárazó bővítményben, és a Divi (vagy egy modul) nem működik. Aztán letiltod az opciót, és hatalmas nyereséget veszítesz. A helyes megközelítés a következő: csak a harmadikat említsd, és a kizárni kritikus szkriptek (jQuery, téma/készítő szkriptek, függő inline szkriptek).

Diagnosztikai

DevTools > Teljesítmény: hosszú feladatok és a blokkoló JS azonosítása.
DevTools > Hálózat: harmadik féltől származó domainek azonosítása (pl. connect.facebook.net, www.googletagmanager.com, macska, stb.).

Előtte (hibás): globális halasztás minden szkripten

Veszélyes részlet, amit még mindig látok keringeni (gyakran egy régi oktatóanyagból másolva):

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

Tipikus eredmények: Uncaught ReferenceError: jQuery is not definedDivi modulok inicializálása sikertelen, lefagyott csúszkák.

Utána (javítva): célzott elhalasztás + kizárási lista

Jelentkezünk defer Csak a nem kritikus szkripteket zárjuk ki, és kifejezetten kizárjuk az érzékeny handle-eket. A lényeg: nem találgatunk a belső Divi handle-ekre (ezek változhatnak). Ehelyett függőségek és "családok" (jQuery + kritikusként megjelölt szkriptek) szerint zárunk ki, és az Ön által ellenőrzött harmadik félre (az Ön szkriptjei + néhány bővítmény) korlátozzuk a kizárást.

<?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 );

„Késleltetés” opció (agresszívabb): csak azonosított harmadik féltől származó szkriptekhez

Amikor a valódi probléma egy olyan dologból ered, forgatókönyv harmadik fél (csevegés/hőtérkép), defer Ez nem mindig elég. Késleltetheted a betöltésüket az interakció után. Kockázatosabb (UX, követés), de hatékony.

Minimalista példa: egy harmadik féltől származó szkriptet csak az első görgetés/kattintás után injektálok. Főleg chat widgeteknél használom ezt.

<?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 );

kockázatok Ha túl sokáig vársz, elveszítheted az „oldalmegtekintés” elemzési eseményeket. Teszteld az eszközöddel (GA4, Matomo, Pixel), és dokumentáld a választásodat.

A szkriptek betöltésével kapcsolatos hivatalos dokumentáció: wp_enqueue_script () és szűrő szkriptbetöltő_címke.

Javítás utáni ellenőrzések

Mérés előtt/után :
- Világítótorony (mobil): LCP, TBT, CLS.
- DevTools > Hálózat: kérések száma, átvitt teljes súly.
- Lekérdezésfigyelő: adatbázis-lekérdezések száma, teljes idő, lassú lekérdezések.
Divi 5 funkcionális tesztek :
- Menük, horgonyok, csúszkák, harmonikák, űrlapok.
- Dinamikus modulokkal rendelkező oldalak (blog, bolt, ajánlások).
Csatlakoztatott és leválasztott állapotok tesztelése A Divi és néhány bővítmény gyorsabban töltődik be, ha be vagy jelentkezve.
Gyorsítótár Töröld a bővítmény gyorsítótárát + a szerver gyorsítótárát (ha van ilyen) + a böngésző gyorsítótárát. Láttam már embereket, akik egy regressziót "érvényesítettek", mert egy régi, gyorsítótárazott erőforrást teszteltek.

Ha ez még mindig nem működik

Izoláljon egy konfliktust Állapotellenőrzéssel (Hibaelhárítási mód): tiltsa le az összes bővítményt a Divi/Divi Builder kivételével, majd aktiválja újra őket egyenként.
PHP hibák ellenőrzése -ban wp-content/debug.logAz értesítések özöne lelassíthatja a dolgokat (különösen, ha a napló egy lassú lemezen van).
PHP memória vezérlése Ha közel kerülsz a határértékhez, felcserélődést/GC-t fogsz tapasztalni. Ellenőrizd. WP_MEMORY_LIMIT és a tárhelyszolgáltató oldalán lévő korlát.
Automatikus betöltési beállítások megtekintése : mikor autoload Óriásivá válik; minden lekérdezés túl sok adatot tölt be. A Lekérdezésfigyelő segíthet, egyébként az adatbázis-ellenőrzés (haladó).
A minifikáció/összefűzés ideiglenes letiltása (Gyorsítótár bővítmény): Ha az oldal ismét stabillá válik, a probléma a szkriptek sorrendjében van. Aktiváld újra, a Divi/jQuery kezelők kivételével.
Böngésző konzol egyetlen JS hiba is megakadályozhatja a modulok inicializálását (ami „lassú webhelynek” tűnik, ha egy ciklusos szkriptről van szó).
CDN nélküli tesztelés (átmenetileg): a rosszul konfigurált CDN késleltetést és gyorsítótár-kihagyásokat okozhat.
Átírások Ha 404-es hibákat tapasztalsz az elemeken, generáld újra a permalinkeket (írd át), és ellenőrizd a szerverszabályokat.

Hasznos WP-CLI parancsok (ha van hozzáférésed)

# 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: hivatalos dokumentáció.

Gyakori buktatók és hibák

tünet	Valószínű ok	Ajánlott megoldás
Fehér képernyő a kódrészlet hozzáadása után	Rossz helyre másolta a kódot / hiányzik a pontosvessző	Tesztelés a stagingen, aktiválás `WP_DEBUG_LOG`javítsa ki a szintaxist
`jQuery is not defined`	A jQuery-re alkalmazott halasztás vagy a minifikáció által meghiúsult parancssorrend	Kizárás `jquery`/`jquery-core`concat letiltása, újratesztelés
A kódrészlet „nem működik”	A gyorsítótár oldal/CDN a régi verziót szolgálja ki	Verzió a következővel: `filemtime()`bővítmény gyorsítótárának törlése + CDN
Optimalizálás helyileg rendben, éles környezetben lassú	Harmadik féltől származó szkriptek, hálózati késleltetés, hiányzó objektumgyorsítótár	Profil éles környezetben (hatás nélkül), lehetőség szerint Redis/Memcached engedélyezése
A hookok nem futnak le	Kódrészlet letiltott bővítménybe került / ütközik egy kódrészlet bővítménnyel	Inkább egyet `mu-plugin`ellenőrizze a berakodási sorrendet
CSS/JS nincs betöltve	rossz `get_stylesheet_directory_uri()` vs `get_template_directory_uri()`	Gyermektémákhoz használja `get_stylesheet_*`
Regresszió Elementor/Avada alapú függvényeken	Megosztott vagy túlságosan globális azonosító sorból való eltávolítása	Alkalmazzon feltételeket oldalanként/sablononként, kerülje az „oldalszintű” szabályokat

Gyakran látott (és költséges) hibák

Másoljon egy részletet a „mindent elhalaszt” szövegből. Egy fórumon találtam: előbb-utóbb elromlik.
Helyezze a kódot rossz fájlba (Pl. functions.php (a Divi szülőtémáról). A következő frissítésben minden hibás lesz.
A prioritás elfelejtése : A wp_dequeue_script, gyakran magas prioritás szükséges (pl. 100).
Zavarba ejtő művelet és szűrő : script_loader_tag egy szűrő, nem egy művelet.
Közvetlen tesztelés éles környezetben visszagörgetés nélkül. Egy Divi oldalon egy JS hiba az összes oldalt érintheti.

Változat / alternatíva

Kódmentes módszer (bővítmények)

Egy gyorsítótárazási/teljesítménynövelő bővítmény, amely a kizárásokat handle-ökön (minimifikáció, JS késleltetés) keresztül kezeli, elegendő lehet, ha időt szánsz a Divi kizárásainak konfigurálására. A buktató az „egykattintásos optimalizálás”: a Divi-n gyakran elromlik.
Az adatbázis esetében az állandó objektumgyorsítótár (Redis/Memcached) nettó nyereséget biztosít a nem gyorsítótárazott oldalakon.

Fejlettebb módszer (fejlesztők)

PHP profilkészítő (APM): Sentry, New Relic, Datadog. Azonnal látni fogja, hogy a lassúság oka az adatbázis, a HTTP API vagy a CPU.
Cseréljen ki néhány rövidkódot statikus blokkok vagy minták segítségével, amikor a tartalmat nem kell minden találatkor újraszámolni.
Egyéni JS szeletelése : oldaltípusonként egy köteg, feltételesen betöltve (1. megoldás), ahelyett, hogy egy site.js monolitikus.

Kerülje el ezt a problémát a jövőben

Fogadj el egy egyszerű szabályt Nincs egyéni "globális" CSS/JS indoklás nélkül. Betöltés oldal/sablon vagy funkció szerint.
Rejtsd el, ami drága A rövidkódoknak és lekérdezéseknek gyorsítótárazási stratégiával kell rendelkezniük (átmeneti + érvénytelenítés).
Kerüld a láthatatlan függőségeket Ha a JavaScripted jQuery-től függ, akkor explicit módon deklaráld. Ha lehetséges, térj át normál JavaScriptre a sorrendi korlátok csökkentése érdekében.
Harmadik féltől származó szkriptek figyelése Minden egyes „ingyenes” widget növeli a költségeket. Láttam már olyan oldalakat, amelyeken 12 marketingcímke volt; ezt semmilyen WordPress optimalizálás nem tudja kompenzálni.
Vezessen belső változásnaplót : amikor engedélyezi a „JS késleltetését”, jegyezze fel a kizárásokat, különben órákat veszít a következő incidensnél.

Hasznos WordPress hivatkozások:

Ajánlott gyakorlatok a sorba helyezéshez: Beleértve a CSS-t és a JavaScriptet
Tranziensek API: tranziensek
Hooks szkriptek: szkriptbetöltő_címke

erőforrás

Gyakran Ismételt Kérdések

Feltétlenül lassabb a Divi 5, mint egy blokktéma?

Nem. Egyszerű oldalakon a Divi 5 tökéletesen megfelelő lehet. A különbség főként a nagyon moduláris oldalakon és a harmadik féltől származó szkriptek számánál észrevehető. Az igazi tényező az, hogy mit töltesz be és futtatsz az egyes oldalakon.

Hová helyezzem a kódot: gyermektéma, bővítmény, mu-plugin?

„Infrastruktúra” optimalizáláshoz (sorba állítás, elhalasztás, gyorsítótár) a következőt ajánlom: mu-pluginElkerülöd a veszteségeket Divi frissítés vagy témaváltás során.

Kompatibilis az Elementorral vagy az Avadával?

Igen, ha oldalanként/sablononkénti feltételeket és engedélyezőlistát használsz. A veszélyt az „összes elhalasztása” kódrészlet vagy a wp_dequeue_* túl globális, ami eltávolíthatja egy másik építő által igényelt eszközöket.

Miért jelenít meg a Lekérdezésfigyelő kevesebb lekérdezést, mégis lassú marad az oldal?

Mivel a szűk keresztmetszet valószínűleg a böngésző oldalán (JS/CSS) vagy a hálózati oldalon (harmadik féltől származó szkriptek) van. Ellenőrizd a TBT-t, a hosszú feladatokat és az átvitt teljes súlyt.

Nem elég az oldal gyorsítótára?

Az oldalak gyorsítótárazása elsősorban a TTFB-vel segít. Ha az LCP/TBT gyenge, az gyakran a túlzottan bőbeszédű vagy rosszul betöltött CSS/JS miatt van. Ezért fontosak a feltételes lekérdezések és a célzott késleltetés.

Engedélyezzem az OPcache-t?

Igen, ha a tárhelyszolgáltatód engedélyezi. Az OPcache jelentősen csökkenti a PHP CPU-használatát. Referencia: PHP OPcache.

Honnan tudod, hogy mely handle-eket kell kizárni a halasztásból?

Kezdje a kizárással jquery, jquery-coreEzután add hozzá a menet közben megszakadó szkripteket. A pontos leírók megtekintéséhez használd a Lekérdezésfigyelőt (Szkriptek fül).

Az átmeneti állapot problémákat okozhat az elavult tartalommal?

Nem, ha a frissítések során megfelelően érvényteleníted (pl. save_postÉrvénytelenítés nélkül igen, következetlen tartalommal fogsz rendelkezni.

Rossz a „delay JS” a SEO szempontjából?

Attól függ, hogy mit halogatsz. Egy chat késleltetése általában nincs hatással a keresőoptimalizálásra (SEO). Egy látható tartalmat beszúró szkript késleltetése problémákat okozhat. A kritikus szkripteket tartsd azonnalinak, és a nem létfontosságú harmadik fél által küldötteket halaszd el.

Csak akkor tapasztalok lassulást, amikor csatlakozom az internethez, ez normális?

Gyakran igen: adminisztrációs sáv, szerkesztőszkriptek, „bejelentkezett” elemeket betöltő bővítmények. Mindig privát böngészési módban tesztelj a látogatói élmény felmérése érdekében.

Gyorsítsd fel a Divi 5-öt egyéni kóddal

a probléma

Gyors összefoglaló

Tünetek

Gyors diagnosztikai táblázat

Miért történik ez?

Előfeltételek a kezdés előtt

1. megoldás: Törölje a feleslegesen betöltött CSS/JS-t (feltételes lekérdezések)

Diagnosztikai

Előtte (hibás): globális sorba helyezés

Utána (javítva): csak szükség esetén töltse be

Miért gyorsul fel valójában?

Blokkról blokkra történő magyarázat

Hasznos alternatíva: bővítmény eltávolítása bizonyos oldalakról

2. megoldás: Kerülje az ismétlődő kéréseket (tranziensek + objektumgyorsítótár)

Diagnosztikai

Előtte (hibás): rövid kód, amely minden találatkor lekérdezi

Utána (javítva): átmeneti + megfelelő érvénytelenítés

Miért oldja meg ez a problémát?

Teljesítmény- és kompatibilitási értékelések

3. megoldás: Késleltesse a harmadik féltől származó JavaScriptet (defer/delay) a Divi 5 megsértése nélkül

Diagnosztikai

Előtte (hibás): globális halasztás minden szkripten

Utána (javítva): célzott elhalasztás + kizárási lista

„Késleltetés” opció (agresszívabb): csak azonosított harmadik féltől származó szkriptekhez

Javítás utáni ellenőrzések

Ha ez még mindig nem működik

Hasznos WP-CLI parancsok (ha van hozzáférésed)

Gyakori buktatók és hibák

Gyakran látott (és költséges) hibák

Változat / alternatíva

Kódmentes módszer (bővítmények)

Fejlettebb módszer (fejlesztők)

Kerülje el ezt a problémát a jövőben

erőforrás

Gyakran Ismételt Kérdések

Feltétlenül lassabb a Divi 5, mint egy blokktéma?

Hová helyezzem a kódot: gyermektéma, bővítmény, mu-plugin?

Kompatibilis az Elementorral vagy az Avadával?

Miért jelenít meg a Lekérdezésfigyelő kevesebb lekérdezést, mégis lassú marad az oldal?

Nem elég az oldal gyorsítótára?

Engedélyezzem az OPcache-t?

Honnan tudod, hogy mely handle-eket kell kizárni a halasztásból?

Az átmeneti állapot problémákat okozhat az elavult tartalommal?

Rossz a „delay JS” a SEO szempontjából?

Csak akkor tapasztalok lassulást, amikor csatlakozom az internethez, ez normális?

Kapcsolódó cikkek

Hozzászólás beküldése Mégsem válaszát