Corriger les bugs d’affichage et de chargement Elementor

by | WordPress

Si vous avez déjà vu une page Elementor “sans style”, un loader qui tourne indéfiniment, ou un éditeur qui affiche “Une erreur s’est produite”, vous êtes rarement face à “un bug Elementor” pur. Dans mon expérience, c’est presque toujours un mélange cache/optimisation, REST API bloquée, ou ressources CSS/JS empêchées de se charger.

Le problème

Les problèmes d’affichage et de chargement Elementor se manifestent surtout à deux endroits :

  • Front-end : la page se charge mais le design est cassé (pas de CSS), ou certains widgets ne s’affichent pas.
  • Admin (éditeur Elementor) : l’éditeur ne charge pas, reste bloqué, ou affiche une erreur liée à AJAX/REST.

Exemples de messages réels (vous verrez parfois l’un d’eux dans Elementor, la console, ou les logs PHP) :

"Une erreur s’est produite. Essayez de recharger la page."
"Le contenu de l’éditeur n’a pas pu être chargé."
"403 Forbidden (REST API)"
"Failed to load resource: net::ERR_BLOCKED_BY_CLIENT"
"Uncaught TypeError: Cannot read properties of undefined"
"Fatal error: Allowed memory size of ... bytes exhausted"

Ça arrive souvent :

  • après une mise à jour (WordPress 6.9.4, Elementor, thème, plugin de cache),
  • après activation d’un plugin d’optimisation (minification, defer JS, suppression CSS inutiles),
  • après migration (domaine, HTTPS, serveur),
  • sur un hébergement durci (WAF, ModSecurity, règles REST/AJAX strictes).

À qui s’adresse ce guide : blogueurs débutants (Divi 5, Elementor, Avada inclus), qui veulent une procédure fiable. À la fin, vous saurez :

  • identifier si le problème vient du cache, du chargement CSS/JS, de la REST API, d’un conflit plugin/thème ou du serveur,
  • corriger sans casser le site (et sans modifier le cœur de WordPress),
  • mettre en place des garde-fous pour éviter la récidive.

Résumé rapide

  • Si le design est cassé : vérifiez d’abord cache + optimisation, puis CSS print method et la présence des fichiers CSS/JS en réseau (devtools).
  • Si l’éditeur ne charge pas : testez la REST API et cherchez un 403/401/500 sur /wp-json/.
  • Faites un test “propre” : Health Check + thème par défaut + plugins désactivés (sans impacter vos visiteurs).
  • Activez WP_DEBUG et lisez wp-content/debug.log : une erreur PHP explique souvent le blocage.
  • Sur erreurs 500/mémoire : augmentez WP_MEMORY_LIMIT, vérifiez PHP 8.1+ et la limite mémoire côté serveur.
  • Après correction : videz tous les caches (plugin, serveur, CDN, navigateur) et régénérez les CSS/Assets Elementor.

Les symptômes

Voici les symptômes les plus fréquents, du plus courant au plus déroutant :

  • Page sans mise en forme (polices, marges, couleurs manquantes) : CSS Elementor non chargé ou supprimé par optimisation.
  • Widgets invisibles (carrousel, popups, formulaires) : JS bloqué, conflit avec minification/defer, ou erreur JS.
  • Éditeur Elementor bloqué sur “Chargement…” : requête REST/AJAX en erreur (403/500), ou fatal PHP.
  • Écran blanc (front ou admin) : erreur PHP fatale, mémoire épuisée, plugin incompatible.
  • Erreur 500 en ouvrant l’éditeur : limite mémoire/temps, WAF, ou plugin sécurité trop agressif.
  • Modifications non visibles : cache, CSS non régénérées, CDN, ou pages servies en HTML statique.
  • Ça marche en local mais pas en production : règles serveur (ModSecurity), permissions fichiers, ou configuration cache/CDN différente.
  • Liens et images cassés après migration : URLs en dur, mixed content, ou base URL incorrecte.

Quand c’est possible, ouvrez les outils développeur du navigateur (Chrome/Firefox) :

  • onglet Console : erreurs JavaScript (souvent la vraie cause de “ça ne charge pas”),
  • onglet Réseau : fichiers CSS/JS en 404/403, ou requêtes wp-json en échec.

Pourquoi ça arrive

Explication simple (débutant)

Elementor fonctionne en chargeant des fichiers CSS (le style) et JavaScript (les interactions). Si un plugin “optimise” trop (minifie, combine, diffère, supprime), ou si le serveur bloque certaines requêtes, Elementor n’arrive plus à :

  • appliquer les styles,
  • exécuter les scripts nécessaires,
  • communiquer avec WordPress via la REST API (l’API JSON de WordPress).

Explication technique (intermédiaire/pro)

Les pannes Elementor se regroupent souvent en 5 familles :

  • Ressources statiques : CSS/JS en 404/403, mauvais en-têtes cache, blocage par CDN/WAF, concaténation cassée.
  • REST API / admin-ajax : endpoints /wp-json/ bloqués, authentification, cookies, règles sécurité.
  • Erreurs PHP : fatal lors du rendu (front) ou de la génération CSS (admin), souvent dans un plugin tiers ou un snippet.
  • Conflits thème/plugins : double chargement de jQuery, scripts reportés, hooks (actions/filtres) mal utilisés.
  • Cache & invalidation : page cache, cache objet, CDN, navigateur, et cache CSS Elementor non synchronisés.

Causes probables (du plus fréquent au plus rare) :

  1. Plugin de cache/optimisation qui diffère ou combine les scripts Elementor.
  2. Cache non purgé après mise à jour (CDN inclus).
  3. REST API bloquée par un plugin sécurité, un WAF, ou des règles serveur.
  4. Erreur PHP fatale (souvent un snippet copié/collé au mauvais endroit).
  5. Limite mémoire/temps trop faible.
  6. Permissions fichiers/dossiers incorrectes sur wp-content/uploads ou wp-content.

Prérequis avant de commencer

Sauvegardez avant de modifier quoi que ce soit (fichiers + base de données). Ne testez pas des snippets au hasard sur le site de production.

  • WordPress : 6.9.4 (votre contexte) ou plus récent.
  • PHP : 8.1 minimum recommandé (8.2/8.3 souvent plus confortable). Référence : PHP Supported Versions (php.net).
  • Outils :
  • Accès : idéalement FTP/SFTP + panneau d’hébergement (logs) + accès admin.

Activez le debug WordPress (temporairement) pour capturer les erreurs PHP. Documentation officielle : Debugging in WordPress.

Ajoutez dans wp-config.php (au-dessus de “That’s all”) :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // Écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // Évite d'afficher les erreurs aux visiteurs
@ini_set( 'display_errors', 0 ); // Renforce le masquage côté PHP

Si votre site utilise Divi 5 ou Avada : les mêmes causes existent (cache, optimisation, JS différé). La différence, c’est que les symptômes peuvent apparaître dans leur builder aussi. La méthode de diagnostic reste la même.

Solution 1 : CSS/JS Elementor non chargés (enqueue, cache, optimisation)

Quand vous voyez une page “toute cassée”, je commence presque toujours par l’onglet Réseau du navigateur : cherchez des 404 (fichier manquant) ou 403 (bloqué) sur des fichiers CSS/JS, et des erreurs de type “Mixed Content”.

Diagnostic rapide

  • Ouvrez la page cassée en navigation privée.
  • DevTools → Réseau → filtrez sur css puis js.
  • Repérez :
    • 404 sur des fichiers dans /wp-content/uploads/ (souvent CSS générées),
    • 403 (WAF, règles serveur, plugin sécurité),
    • fichiers servis mais vides ou minifiés cassés.

Cause fréquente : plugin d’optimisation qui “casse” Elementor

J’ai souvent croisé ce bug sur des sites où un plugin active :

  • “Defer/Delay JavaScript”,
  • “Combine JS/CSS”,
  • “Remove unused CSS” agressif,
  • optimisations Cloudflare (Rocket Loader, etc.).

Commencez par désactiver temporairement ces options (pas forcément le plugin complet), puis :

  • Elementor → Outils → Régénérer CSS & Données (le libellé exact varie selon la version),
  • purgez le cache du plugin, du serveur, du CDN, puis du navigateur.

Quand un snippet “déqueue” des scripts par erreur

Un classique : un snippet copié/collé pour “optimiser” qui retire des scripts CSS/JS partout, y compris sur les pages Elementor.

Où se trouve ce code ? Souvent dans :

  • functions.php du thème (ou thème enfant),
  • un plugin de snippets,
  • un plugin custom.

Code AVANT (cassé) : il retire trop large (exemple volontairement réaliste).

<?php
// functions.php (thème enfant) — EXEMPLE CASSÉ : retire des ressources trop tôt et trop large.
add_action( 'wp_enqueue_scripts', function () {
	// Suppression agressive : casse souvent Elementor, WooCommerce, etc.
	wp_dequeue_style( 'elementor-frontend' );
	wp_dequeue_script( 'elementor-frontend' );

	// Erreur fréquente : retirer jQuery sur un site qui en dépend encore.
	wp_deregister_script( 'jquery' );
}, 20 );

Pourquoi ça casse : Elementor a besoin de ses handles (elementor-frontend, etc.) pour afficher correctement. Retirer jQuery peut aussi casser des widgets tiers. Le hook action wp_enqueue_scripts (une “action” = un point d’accroche où WordPress exécute votre code) est le bon endroit pour gérer les assets, mais il faut cibler précisément.

Code APRÈS (corrigé) : on limite l’optimisation aux pages qui ne sont pas gérées par Elementor, et on évite de toucher à jQuery sans audit.

Où coller ce code : dans functions.php du thème enfant (recommandé), ou mieux dans un petit plugin custom (plus stable). Sauvegardez avant de modifier.

<?php
/**
 * Empêche la suppression des assets Elementor sur les pages construites avec Elementor.
 * Compatible WordPress 6.9.4+ / PHP 8.1+.
 */
add_action( 'wp_enqueue_scripts', function () {

	// Si Elementor n'est pas actif, on ne fait rien.
	if ( ! did_action( 'elementor/loaded' ) ) {
		return;
	}

	// Si la page courante est construite avec Elementor, ne touchez pas aux assets Elementor.
	if ( is_singular() ) {
		$post_id = get_queried_object_id();

		if ( $post_id && class_exists( 'ElementorPlugin' ) ) {
			// Méthode robuste : vérifier si Elementor a des données pour ce post.
			$document = ElementorPlugin::$instance->documents->get( $post_id );

			if ( $document && $document->is_built_with_elementor() ) {
				return; // On sort : aucune désinscription ici.
			}
		}
	}

	// À partir d'ici, vous êtes sur une page "non-Elementor".
	// Si vous voulez optimiser, faites-le progressivement et testez.
	// Exemple : NE PAS dérégister jQuery sans vérifier tous les scripts du site.

}, 20 );

Explication bloc par bloc

  • did_action( 'elementor/loaded' ) : vérifie qu’Elementor a bien été chargé.
  • is_singular() : cible articles/pages (pas archives).
  • ElementorPlugin::$instance->documents->get() : récupère le “document” Elementor associé.
  • is_built_with_elementor() : confirme que la page est réellement construite avec Elementor.

Tableau de diagnostic (affichage cassé)

Symptôme Cause probable Vérification Solution
Page sans CSS Cache/optimisation supprime ou retarde CSS DevTools → Réseau → CSS en 404/200 mais vide Désactiver “Remove unused CSS”, régénérer CSS Elementor, purger caches
Widgets interactifs KO Defer/delay JS casse l’ordre d’exécution Console → erreurs TypeError / undefined Exclure scripts Elementor du defer/delay
CSS en 404 dans /uploads/ Permissions/écriture uploads Tester écriture, logs serveur Corriger permissions, régénérer CSS
Différences connecté/déconnecté Cache page sert une version obsolète Test navigation privée, entêtes cache Purger cache page + CDN + navigateur

Solution 2 : l’éditeur Elementor ne charge pas (REST API, permissions, conflits)

Quand l’éditeur ne charge pas, cherchez d’abord une requête en échec vers /wp-json/. Elementor dépend énormément de la REST API (API JSON de WordPress). Si elle est bloquée, l’éditeur tombe.

Étape 1 : tester la REST API

Ouvrez dans votre navigateur (remplacez le domaine) :

  • https://exemple.com/wp-json/

Vous devez obtenir une réponse JSON (ou une page listant les routes). Si vous voyez :

  • 403 : blocage sécurité/WAF,
  • 401 : auth/cookies,
  • 500 : erreur PHP,
  • une redirection bizarre vers login : cookies/proxy.

Référence REST API : WordPress REST API Handbook.

Étape 2 : isoler un conflit sans casser le site (Health Check)

Installez Health Check & Troubleshooting, puis :

  1. Outils → Santé du site → Mode dépannage (visible uniquement pour vous).
  2. Désactivez tous les plugins dans ce mode.
  3. Réactivez Elementor (et Elementor Pro si présent).
  4. Testez l’éditeur.
  5. Réactivez vos plugins un par un jusqu’à reproduire la panne.

J’ai très souvent trouvé le coupable dans :

  • plugins de sécurité (blocage REST),
  • plugins d’optimisation (minification/defer dans l’admin),
  • plugins “snippets” avec un code qui fatal en admin.

Cause fréquente : un snippet bloque REST (mauvais hook ou mauvaise condition)

Exemple réaliste : quelqu’un veut “désactiver la REST API” et colle un snippet global. Résultat : Elementor ne peut plus charger l’éditeur.

Code AVANT (cassé) :

<?php
// EXEMPLE CASSÉ : bloque toute la REST API, y compris pour l'admin et Elementor.
add_filter( 'rest_authentication_errors', function( $result ) {
	return new WP_Error(
		'rest_disabled',
		'REST API désactivée',
		array( 'status' => 403 )
	);
} );

Pourquoi ça casse : Elementor utilise la REST API pour charger/sauvegarder des données. Bloquer globalement rest_authentication_errors revient à “couper le réseau” de l’éditeur.

Code APRÈS (corrigé) : on limite le blocage aux visiteurs non connectés, et on laisse l’admin/éditeur fonctionner. Collez ce code dans un plugin custom (recommandé) ou le thème enfant. Sauvegardez avant.

<?php
/**
 * Restreint la REST API côté public sans casser l'admin ni Elementor.
 * À utiliser uniquement si vous avez une vraie raison sécurité.
 */
add_filter( 'rest_authentication_errors', function( $result ) {

	// Si une autre auth a déjà échoué, on respecte le résultat.
	if ( ! empty( $result ) ) {
		return $result;
	}

	// Autoriser les utilisateurs connectés (éditeur Elementor inclus).
	if ( is_user_logged_in() ) {
		return $result;
	}

	// Autoriser certaines routes publiques si nécessaire (exemple : oEmbed).
	$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? (string) $_SERVER['REQUEST_URI'] : '';
	if ( str_contains( $request_uri, '/wp-json/oembed/' ) ) {
		return $result;
	}

	// Bloquer le reste côté public.
	return new WP_Error(
		'rest_disabled_public',
		'REST API restreinte aux utilisateurs connectés.',
		array( 'status' => 403 )
	);
} );

Explication

  • Filtre rest_authentication_errors : un “filtre” modifie une valeur (ici, l’autorisation REST).
  • is_user_logged_in() : vous évitez de casser l’éditeur pour les admins/éditeurs.
  • On garde une exception oembed (optionnel), car certains embeds publics en dépendent.

Cas particulier : l’éditeur charge, mais impossible de sauvegarder

Si l’éditeur s’ouvre mais la sauvegarde échoue (erreur 403/nonce), cherchez :

  • un plugin sécurité qui bloque admin-ajax.php ou REST,
  • un cache qui met en cache des pages admin (ça ne devrait jamais arriver),
  • un proxy/CDN qui modifie cookies/en-têtes.

Documentation AJAX admin (utile pour comprendre les appels) : AJAX in Plugins.

Solution 3 : erreurs 500 / mémoire / PHP (diagnostic serveur + WP-CLI)

Si vous voyez une erreur 500, un écran blanc, ou “Allowed memory size exhausted”, arrêtez de “tweaker Elementor” : c’est un problème d’exécution PHP ou de serveur.

Étape 1 : lire les logs (vraiment)

  • wp-content/debug.log (si WP_DEBUG_LOG activé).
  • Logs PHP/Apache/Nginx via votre hébergeur.

Un message typique :

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)

Étape 2 : augmenter la mémoire WordPress (côté WP)

Où modifier : wp-config.php. Sauvegardez avant. Ne modifiez jamais les fichiers du cœur WordPress.

Code AVANT (souvent absent) : rien n’est défini, WordPress prend une valeur par défaut.

Code APRÈS :

define( 'WP_MEMORY_LIMIT', '256M' );      // Front-end
define( 'WP_MAX_MEMORY_LIMIT', '512M' );  // Admin (éditeur, imports, etc.)

Si votre hébergeur limite PHP à 128M, cette ligne ne suffira pas : il faudra augmenter memory_limit côté PHP (panneau d’hébergement, php.ini, ou support).

Référence : wp-config.php (developer.wordpress.org).

Étape 3 : vérifier la version PHP et les extensions

Elementor et ses add-ons réagissent mal aux environnements “à moitié à jour”. Visez PHP 8.1+ (idéalement 8.2/8.3 si votre stack le permet) et des extensions standard (mbstring, intl selon besoin).

Référence PHP : memory_limit (php.net).

Étape 4 : WP-CLI pour diagnostiquer plus vite (avancé, mais très efficace)

Si vous avez WP-CLI, vous pouvez vérifier rapidement l’état du site.

# Vérifier la version WordPress
wp core version

# Vérifier les plugins et repérer ceux récemment mis à jour
wp plugin list --status=active

# Vider certains caches (selon plugins, commandes variables)
wp cache flush

WP-CLI : WP-CLI Commands.

Cas “rare mais réel” : règles serveur qui bloquent wp-json ou certains paramètres

Sur des hébergements avec ModSecurity, j’ai déjà vu des règles bloquer des requêtes REST parce que certains champs contenaient du HTML (normal pour un builder). Symptôme : 403 uniquement sur certaines pages/widgets.

  • Vérifiez dans les logs WAF/ModSecurity si une règle est déclenchée.
  • Demandez à l’hébergeur une exception ciblée sur les endpoints concernés (pas une désactivation globale).

Vérifications après correction

Après chaque correction, faites des tests simples et reproductibles :

  1. Test front-end : la page s’affiche correctement en navigation privée.
  2. Test éditeur : Elementor s’ouvre, vous pouvez déplacer un widget, sauvegarder, recharger.
  3. Test réseau : plus de 404/403 sur CSS/JS Elementor, plus d’erreurs sur /wp-json/.
  4. Test console : pas d’erreurs JS bloquantes (les warnings mineurs existent, mais pas de TypeError en boucle).
  5. Test cache : purgez cache plugin + serveur + CDN, puis recharge “hard refresh” (Ctrl+F5).

Si vos modifications ne se voient pas : dans Elementor, régénérez les CSS/Assets (menu Outils), puis videz les caches. C’est la combinaison qui résout le plus de “ça ne change rien”.

Si ça ne marche toujours pas

Procédure de dépannage que j’applique quand le problème résiste :

1) Reproduire et capturer

  • Notez l’URL exacte, le navigateur, connecté/déconnecté.
  • Capturez :
    • une capture écran de la console,
    • les requêtes en échec dans Réseau (URL + code HTTP),
    • les 30 dernières lignes de debug.log.

2) Tester sans conflit (Health Check)

  • Mode dépannage → thème par défaut → seulement Elementor actif.
  • Si ça marche : conflit confirmé, réactivez un par un.
  • Si ça ne marche pas : regardez serveur/REST/permissions.

3) Vérifier les caches dans le bon ordre

  1. Cache du plugin (WP Rocket / LiteSpeed Cache / etc.).
  2. Cache serveur (Varnish, LiteSpeed, Nginx microcache).
  3. CDN (Cloudflare).
  4. Navigateur (hard refresh + vider cache).

4) Vérifier les permaliens et règles de réécriture

Un symptôme vicieux : des endpoints REST en 404 après migration. Allez dans Réglages → Permaliens → Enregistrer (sans changer). Ça force la régénération des règles.

Référence : flush_rewrite_rules() (à ne pas appeler sur chaque chargement de page).

5) Vérifier les permissions fichiers

  • Les CSS générées et certains fichiers sont dans wp-content/uploads.
  • Si WordPress ne peut pas écrire, Elementor ne peut pas régénérer correctement.

6) Vérifier la sécurité (nonces, cookies, WAF)

Si vous voyez des 403 sur des requêtes de sauvegarde :

  • désactivez temporairement le plugin sécurité en mode dépannage,
  • vérifiez les règles Cloudflare/WAF,
  • vérifiez que votre site est bien en HTTPS partout (pas de mixed content).

Pièges et erreurs courantes

Symptôme Cause probable Solution recommandée
CSS/JS manquants Cache/optimisation (combine/defer/remove unused) Désactiver options agressives, exclure Elementor, régénérer CSS, purger caches
Éditeur bloqué “Chargement…” REST API bloquée (403/500) Tester /wp-json/, désactiver plugin sécurité, vérifier WAF
Erreur 500 en ouvrant l’éditeur Mémoire/timeout PHP Augmenter WP_MEMORY_LIMIT, memory_limit serveur, vérifier logs
“Rien ne change” après modification Cache navigateur/CDN + CSS non régénérées Régénérer CSS Elementor + purger tous les caches + navigation privée
Erreur après ajout d’un snippet Code collé au mauvais endroit, point-virgule manquant Retirer le snippet via FTP, corriger syntaxe, utiliser un plugin custom
Fonction appelée trop tôt Hook inadapté / priorité incorrecte Déplacer sur le bon hook (wp_enqueue_scripts, init, etc.)
Widgets tiers qui cassent Add-on Elementor incompatible avec WP/PHP Mettre à jour, désactiver l’add-on, vérifier compatibilité PHP 8.1+

Erreurs que je vois tout le temps chez les débutants :

  • Copier du code dans Apparence → Éditeur de fichiers sur le site en production, sans sauvegarde.
  • Oublier un ; et provoquer un fatal (puis écran blanc).
  • Utiliser un ancien tutoriel qui recommande de désactiver jQuery ou la REST API “pour la sécurité”. En 2026, ça casse plus de choses que ça n’en protège.
  • Vider uniquement le cache du plugin, mais oublier le CDN et le navigateur.

Variante / alternative

Méthode sans code (recommandée pour débutants)

  • Utilisez Health Check pour isoler un conflit sans impacter les visiteurs.
  • Dans votre plugin de cache/optimisation :
    • désactivez “Delay JS” pour l’admin,
    • excluez les scripts Elementor de la minification/defer,
    • désactivez temporairement “Remove unused CSS” pour valider le diagnostic.
  • Dans Elementor → Outils : régénérez CSS/Assets.

Méthode plus avancée (développeurs)

Si vous devez garder une optimisation agressive, la voie propre est d’exclure précisément les handles/scripts Elementor dans votre outil, plutôt que de déqueue en PHP “au hasard”. Query Monitor vous aide à lister les scripts/styles chargés sur une page et à voir qui les enfile.

Query Monitor : plugin officiel. Hooks WordPress : Hooks (actions & filtres).

Éviter ce problème à l’avenir

  • Faites les mises à jour en environnement de test (staging) puis déployez.
  • Évitez les snippets “magiques” qui promettent +100 PageSpeed en supprimant jQuery/REST. Testez, mesurez, et gardez un rollback.
  • Centralisez vos personnalisations dans un petit plugin custom (plus stable qu’un functions.php de thème).
    • Avantage : si vous changez de thème (Avada → Hello Elementor, etc.), vous ne perdez pas vos correctifs.
  • Surveillez les erreurs : gardez un logging (au moins temporaire) et consultez les logs serveur après une mise à jour.
  • Ne cachez jamais l’admin avec un cache page/CDN.
  • Documentez vos exclusions dans le plugin de cache (quels scripts Elementor sont exclus et pourquoi).

Si vous utilisez Elementor avec Divi 5 ou Avada sur le même site (oui, ça arrive après une refonte partielle), soyez encore plus strict : évitez de combiner/minifier “globalement” sans exclusions, car vous multipliez les dépendances JS.

Ressources

Questions fréquentes

Pourquoi Elementor affiche une page sans style après une mise à jour ?

Le plus fréquent : un cache (plugin/serveur/CDN) sert une version obsolète, ou une optimisation a supprimé/différé des CSS. Régénérez les CSS Elementor puis purgez tous les caches, y compris le navigateur.

Comment savoir si c’est la REST API qui bloque l’éditeur ?

Testez /wp-json/ et regardez l’onglet Réseau : si vous voyez du 403/401/500 sur des requêtes REST, vous avez la cause. Ensuite, isolez plugin sécurité/WAF via Health Check.

Est-ce que je peux désactiver jQuery pour améliorer les performances ?

Évitez sur un site avec Elementor et des widgets tiers : vous risquez de casser des fonctionnalités. Si vous voulez réduire JS, passez plutôt par des exclusions ciblées et la suppression de widgets/add-ons inutiles.

Je vois “Allowed memory size exhausted”, que faire ?

Augmentez WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT dans wp-config.php, puis vérifiez la limite memory_limit côté PHP chez l’hébergeur. Ensuite, identifiez le plugin qui consomme via logs/Query Monitor.

Pourquoi ça marche quand je suis connecté, mais pas pour les visiteurs ?

C’est typique d’un cache page/CDN qui sert une version différente aux visiteurs. Testez en navigation privée, purgez CDN, et vérifiez que votre plugin de cache n’a pas mis en cache une page avant régénération des CSS.

Le mode dépannage Health Check est-il dangereux ?

Non : il ne change l’état des plugins/thème que pour votre session. Les visiteurs continuent de voir le site normal. C’est l’outil le plus sûr pour isoler un conflit.

Faut-il désactiver la REST API pour la sécurité ?

Dans la majorité des cas, non. Ça casse des fonctionnalités (Elementor inclus). Si vous devez restreindre, faites-le finement (par rôles, routes spécifiques) et testez l’éditeur.

Après migration, Elementor ne charge plus correctement : quoi vérifier en premier ?

HTTPS partout (pas de mixed content), permaliens (ré-enregistrer), cache/CDN, et les URLs dans la base si des liens sont restés en dur. Ensuite, testez /wp-json/.

Elementor, Divi 5 et Avada : les mêmes problèmes existent ?

Oui. Les builders modernes dépendent tous d’assets CSS/JS et d’appels AJAX/REST. Les plugins d’optimisation et de sécurité sont les causes numéro 1 des pannes de chargement, quel que soit le builder.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *