vendredi 25 septembre 2026

À propos

Contact

Elementor

Un site Elementor avec un flash de contenu non stylé au chargement de la page

Un clignotement visuel gênant apparaissait à chaque chargement de page : le CSS généré par Elementor arrivait après le rendu initial du DOM. Symptôme, diagnostic et correctif d'un cas concret.

Par Clément Hadrot • 28 août 2025 • 4 min de lecture • Aucun commentaire
Un site Elementor avec un flash de contenu non stylé au chargement de la page

Sur un site institutionnel récemment optimisé côté performance par une autre agence, un client a signalé un détail visuel agaçant : à chaque chargement de page, un bref instant de texte non stylé, en police par défaut du navigateur, apparaissait avant que la mise en forme habituelle du site ne s’applique. Ce phénomène, connu sous le nom de flash of unstyled content, dure généralement moins d’une demi-seconde, mais reste parfaitement perceptible sur une connexion moyenne.

Symptôme

Le clignotement touchait systématiquement les pages construites avec Elementor, jamais les pages statiques du thème sans contenu Elementor. Il était plus marqué sur mobile, où la connexion réseau plus lente laissait davantage de temps au navigateur pour afficher le contenu avant l’arrivée complète du CSS. Aucune erreur console visible, aucun message d’erreur PHP : uniquement ce décalage temporel entre l’affichage du HTML et l’application des styles.

Diagnostic

L’inspection du chargement réseau de la page a révélé la cause : une optimisation de performance mise en place par l’agence précédente chargeait l’intégralité des feuilles de style, y compris celles générées dynamiquement par Elementor pour chaque page, via l’attribut media="print" basculé en media="all" par un petit script au chargement, une technique de chargement différé du CSS destinée à améliorer un score de performance mesuré par un outil d’audit automatisé.

Cette technique fonctionne bien pour du CSS statique de thème, mais elle entre en conflit avec la manière dont Elementor génère son propre CSS : les fichiers spécifiques à chaque page, produits dynamiquement par le moteur de style d’Elementor, se retrouvaient différés de la même façon que le CSS global, alors qu’ils contiennent l’essentiel de la mise en forme visuelle réelle de la page (couleurs, espacements, typographies propres au contenu).

L'essentiel à retenir : Le flash de contenu non stylé trahit un ordre de chargement CSS défaillant ; Un fichier CSS chargé en asynchrone sans précaution en est souvent la cause ; Le préchargement critique règle le problème sans renoncer à la performance

Correctif

La correction a consisté à exclure spécifiquement les fichiers CSS générés par Elementor (repérables par leur chemin sous /wp-content/uploads/elementor/css/) du mécanisme de différé, tout en conservant ce mécanisme pour les autres feuilles de style non critiques du thème, moins urgentes à afficher.

add_filter( 'style_loader_tag', function( $tag, $handle, $href ) {
    if ( strpos( $href, '/uploads/elementor/css/' ) !== false ) {
        return $tag; // pas de différé pour le CSS Elementor
    }
    if ( in_array( $handle, [ 'theme-fonts', 'theme-print' ], true ) ) {
        return str_replace( "media='all'", "media='print' onload=\"this.media='all'\"", $tag );
    }
    return $tag;
}, 10, 3 );

En complément, une balise de préchargement critique a été ajoutée pour le fichier CSS de la page en cours, généré par Elementor, afin que le navigateur commence à le télécharger dès la lecture de l’en-tête HTML, avant même de rencontrer sa référence normale dans le corps de page.

<link rel="preload" href="/wp-content/uploads/elementor/css/post-482.css" as="style">

Prévention

  • Toute technique de différé de CSS appliquée globalement sur un site Elementor doit exclure explicitement les fichiers générés dynamiquement par le plugin, propres à chaque page.
  • Vérifier après chaque optimisation de performance, via un audit visuel manuel en plus des scores automatisés, qu’aucun flash de contenu non stylé n’apparaît sur les gabarits de page principaux.
  • Tester spécifiquement sur une connexion réseau simulée plus lente (throttling), où ce type de décalage devient beaucoup plus visible qu’en connexion rapide de bureau.
  • Ne jamais optimiser uniquement pour un score d’outil d’audit sans vérification visuelle réelle du résultat obtenu sur le site.

Un score de performance parfait qui produit un clignotement visible à l’écran n’est pas une vraie optimisation, c’est un déplacement du problème d’une métrique vers l’expérience réelle du visiteur.

En résumé

Ce cas illustre un piège classique des optimisations de performance appliquées sans distinction sur un site Elementor : les fichiers CSS générés dynamiquement par le plugin, propres à chaque page, ne se traitent pas de la même façon que le CSS statique global du thème. Les exclure des mécanismes de différé, tout en les préchargeant intelligemment, élimine le flash de contenu non stylé sans sacrifier les gains de performance obtenus par ailleurs.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi