33. Performance : un site rapide

Un site que l’on attend est un site que l’on quitte. Ce chapitre explique d’où vient le temps de chargement, ce qui pèse vraiment dans une page Elementor, quels réglages activer, et comment mesurer sans se laisser obséder par un score. Il ouvre la dernière partie du support, celle où l’on rend le site livrable.

33.1 — Pourquoi la vitesse compte

Le visiteur d’un site d’artisan n’est pas assis devant un grand écran relié à la fibre. Il est dans sa cuisine, sur son téléphone, avec une couverture 4G moyenne, et il compare trois menuisiers avant de dîner. Chaque seconde d’attente augmente la part de ceux qui referment la page avant même de l’avoir vue. La vitesse n’est donc pas un sujet de technicien : c’est le premier test que subit votre site, avant la qualité de vos photos et avant votre argumentaire.

Google a formalisé cette exigence avec trois mesures qu’il appelle les Core Web Vitals (« signaux web essentiels ») et dont il tient compte dans son classement. Elles méritent d’être connues, parce que tous les outils de mesure les affichent.

Ces trois chiffres racontent une histoire simple : le visiteur veut voir vite (LCP), que ça réponde (INP) et que rien ne bouge sous son doigt (CLS). Tout ce chapitre consiste à servir ces trois attentes.

33.2 — Ce qui pèse vraiment dans une page

Avant de toucher au moindre réglage, il faut savoir où passe le temps. Sur un site vitrine construit avec Elementor et le thème Hello, la réponse est presque toujours la même, et elle tient en six postes, par ordre d’importance.

Les images : le premier levier

Une photo sortie d’un téléphone récent pèse 3 à 6 Mo et mesure 4 000 pixels de large. Affichée dans un bandeau qui n’en montre jamais plus de 1 900, elle fait télécharger au visiteur trois fois plus de données que nécessaire. Sur la plupart des pages vitrines, les images représentent à elles seules plus de la moitié du poids total. C’est donc là que se gagne l’essentiel : préparer chaque image à la bonne dimension (1 600 à 2 000 px de large pour un bandeau, 800 à 1 200 px pour une carte), au format WebP quand c’est possible, et sous 200 à 300 Ko. Le chapitre 14 détaille la méthode ; ce chapitre vous invite simplement à la vérifier image par image.

Les polices

Chaque famille de police et chaque graisse (normal, gras, italique…) est un fichier à télécharger. Deux familles et quatre graisses suffisent à un site vitrine ; au-delà, le texte tarde à s’afficher et la page « saute » quand la vraie police remplace la police provisoire. Chargez-les depuis votre propre site plutôt que depuis les serveurs de Google (ce qui règle en même temps la question du RGPD, voir chapitre 35) et réglez le comportement d’affichage sur swap, qui montre le texte immédiatement avec une police de substitution.

Les extensions et widgets inutiles

Chaque extension active ajoute son propre code à toutes les pages, qu’elle serve ou non. Un site vitrine a rarement besoin de plus d’une dizaine d’extensions. De même, un widget déposé « pour voir » puis oublié, un carrousel avec quinze diapositives ou un compteur animé sur une page qui n’en a pas l’usage sont autant de scripts chargés pour rien.

Les animations, les vidéos d’arrière-plan et les cartes

Une animation d’entrée n’est pas lourde en soi, mais elle retarde l’affichage du contenu qu’elle anime — c’est mauvais pour le LCP quand elle porte sur le bandeau. Une vidéo d’arrière-plan pèse plusieurs mégaoctets et se charge dès l’ouverture de la page ; Elementor propose d’ailleurs de ne pas la lire sur mobile, et il est sage de s’en tenir à une image sur téléphone. Enfin, le widget Google Maps charge des scripts de Google à chaque visite : une image de plan cliquable vers l’itinéraire fait le même service pour un coût nul (voir chapitre 16).

33.3 — Les réglages Elementor qui comptent

Elementor regroupe ses réglages de performance dans l’administration WordPress, pas dans l’éditeur. Ils se règlent une fois pour toutes, à la fin de la construction ou dès l’installation. Voici le parcours complet.

1. Ouvrez les réglages. Dans l’administration WordPress, allez dans Elementor › Éditeur › Réglages et cliquez sur l’onglet Performance.
2. Méthode d’impression CSS (CSS Print Method). Choisissez Fichier externe (External File). Elementor écrit alors les styles de chaque page dans un fichier séparé que le navigateur met en cache, au lieu de les répéter dans le code de la page à chaque visite. L’autre option, l’intégration interne (Internal Embedding), ne sert qu’à diagnostiquer un problème de style.
3. Chargement optimisé des images (Optimized Image Loading). Activez-le. Elementor demande au navigateur de charger en priorité la première image visible et de différer les autres jusqu’à ce que le visiteur fasse défiler la page : c’est le chargement paresseux (lazy loading), que WordPress applique déjà à ses propres images.
4. Chargement optimisé de Gutenberg (Optimized Gutenberg Loading). Activez-le. Sur une page construite avec Elementor, les styles de l’éditeur de blocs de WordPress ne servent à rien ; ce réglage évite de les charger.
5. Passez à l’onglet Avancé. Vous y trouvez Google Fonts, qui autorise ou interdit le chargement des polices depuis les serveurs de Google, et Chargement de Google Fonts (Google Fonts Load), qui règle le comportement d’affichage : choisissez Swap. Si vous hébergez vos polices localement (Polices personnalisées d’Elementor Pro dans Elementor › Éditeur › Éléments personnalisés, ou une extension de chargement local citée à titre d’exemple au chapitre 13), désactivez Google Fonts.
6. Laissez Font Awesome 4 désactivé. Le réglage Load Font Awesome 4 Support (prise en charge de l’ancienne bibliothèque d’icônes) n’a d’intérêt que pour un site très ancien : il charge une bibliothèque supplémentaire pour rien.
7. Enregistrez, puis videz le cache du site s’il y en a un (voir plus bas) et ouvrez une page en navigation privée pour vérifier que tout s’affiche.

33.4 — Cache, hébergement et PHP

Quand un visiteur demande une page, WordPress interroge sa base de données, assemble le contenu, applique le thème et Elementor, puis envoie le résultat. Ce travail se répète à chaque visite, alors que la page ne change pas d’un visiteur à l’autre. Un cache conserve la page assemblée et la sert directement aux visiteurs suivants ; c’est le deuxième levier après les images, et il se règle en dehors d’Elementor.

Deux voies sont possibles. La plupart des hébergeurs français courants proposent leur propre cache, activé depuis l’espace client ou par une extension maison ; c’est la solution la plus simple, et souvent la plus efficace, parce qu’elle agit avant même WordPress. À défaut, une extension de cache (WP Rocket est un exemple payant courant ; il en existe de gratuites) fait le même travail depuis WordPress. Dans les deux cas, retenez la règle : après chaque modification importante, on vide le cache, sinon les visiteurs voient l’ancienne version pendant des heures.

Le CDN (Content Delivery Network, réseau de serveurs répartis qui rapproche les fichiers du visiteur) est facultatif pour un artisan dont la clientèle est à cinquante kilomètres du serveur. Il devient utile pour un site qui vise plusieurs pays.

Reste la version de PHP, le langage qui fait tourner WordPress. Elementor exige au minimum PHP 7.4 et recommande PHP 8.3 ou plus récent, avec 512 Mo de mémoire (768 Mo pour de meilleures performances). Le changement se fait dans l’espace client de l’hébergeur, en quelques clics ; une version récente de PHP est plus rapide et mieux sécurisée. Vérifiez la version en place dans Elementor › Éditeur › Système, la page d’informations système.

33.5 — Mesurer sans courir après le 100/100

Trois outils gratuits permettent de mesurer un site sans rien installer. PageSpeed Insights, proposé par Google, analyse l’adresse que vous lui donnez et affiche, pour mobile et pour ordinateur, un score sur 100 accompagné des trois Core Web Vitals et d’une liste de recommandations. WebPageTest montre le chargement seconde par seconde sous forme de pellicule, ce qui aide à comprendre ce qui apparaît en premier. GTmetrix présente le poids total de la page et la liste des fichiers téléchargés, du plus lourd au plus léger : c’est le plus parlant pour repérer une image oubliée.

Comment lire un rapport

Regardez d’abord le résultat mobile, toujours moins bon que celui sur ordinateur et toujours plus proche de ce que vivent vos visiteurs. Distinguez ensuite les données de terrain, mesurées sur de vrais visiteurs quand le site en a assez, des données de laboratoire, simulées sur une connexion volontairement lente. Les premières comptent pour Google ; les secondes servent à diagnostiquer. Enfin, lisez la liste des recommandations comme une liste de pistes, pas comme une liste d’ordres : « Diffusez des images de nouvelle génération » veut dire « convertissez en WebP », « Éliminez les ressources qui bloquent le rendu » désigne le plus souvent des polices ou une extension de trop.

Un site vitrine à 85 sur mobile, qui s’affiche en deux secondes et dont le formulaire fonctionne, vaut mieux qu’un 100 obtenu en supprimant les photos.

Le score n’est pas une note d’examen. Un site avec de vraies photos de chantier atteint rarement 100, et cela n’a aucune importance : ce qui compte, c’est que les trois Core Web Vitals soient dans le vert et que le score mobile ne s’effondre pas sous 60. Au-delà, chaque point supplémentaire coûte plus qu’il ne rapporte.

Optimiser les images après coup

Si les images sont déjà en ligne sans avoir été préparées, deux options existent. La première est l’outil Image Optimizer d’Elementor, accessible dans le menu Elementor › Image Optimization de l’administration : il redimensionne et convertit les images de la Médiathèque, contre des crédits (10 crédits par image, inclus dans l’abonnement Elementor One, qui en fournit 25 000 par mois). La seconde est de refaire le travail à la main ou avec un outil de compression en ligne (Squoosh, gratuit, est un exemple), puis de remplacer les fichiers dans la Médiathèque. Pour un site de cinq pages et une trentaine d’images, la seconde option prend une heure et ne coûte rien.

• Chaque image de bandeau mesure 1 600 à 2 000 px de large et pèse moins de 300 Ko ; les images de cartes, moins de 150 Ko.
• Deux familles de polices au plus, quatre graisses au plus, chargées localement, affichage swap.
• Méthode d’impression CSS en fichier externe ; chargement optimisé des images et de Gutenberg activés.
• Aucune vidéo d’arrière-plan sur mobile ; aucune animation sur le premier écran.
• Widget Google Maps remplacé par une image cliquable, sauf besoin réel.
• Extensions inutiles désinstallées ; moins d’une dizaine d’extensions actives.
• Cache de l’hébergeur ou extension de cache actif, et vidé après chaque modification.
• PHP 8.3 ou plus récent, 512 Mo de mémoire au moins.
• Score PageSpeed mobile relevé avant et après, Core Web Vitals dans le vert.