110 conseils de pro pour améliorer la performance de votre site

J’ai constaté début avril 2022 que sur LinkedIn, de nombreux posts sur la web performance véhiculent des idées fausses, des « on-dit » et des méthodes « magiques » pour avoir un site rapide. Agacé et attristé par le volume de J’aime, de partages et de commentaires de ces posts, j’ai entrepris de partager à mon tour une partie de mes connaissances et de mon expérience sur LinkedIn.

Je répertorie ci-dessous, avec une réorganisation par grandes thématiques, les informations concrètes, vérifiables et éprouvées que j’y ai partagé au fil des semaines. Cela peut parfois sembler technique mais le format concis de chaque point permet de comprendre ce qu’il faut mettre en oeuvre concrètement pour améliorer la performance d’un site web. J’espère que vous apprécierez cette compilation et vous en souhaite une excellente lecture.

Rendu navigateur

Pour qu’un site soit rapide à s’afficher (métrique LCP typiquement), le html doit être chargé au plus tôt (après avoir été rendu côté serveur), suivi du CSS (en synchrone si moins de 50 ko), des fontes, des images puis du Javascript (en async ou defer). Le JS vient donc en DERNIER !
Plus la structure d’une page est lourde, moins elle sera performante : les temps de rendu du navigateur s’allongent. Cela se matérialise via le DOM, qui doit être le plus léger possible (moins de 1500 noeuds) et avec un minimum de niveaux d’imbrication (moins de 32). C’est un point qui pèche avec la plupart des Page Builders pour WordPress.
Pré-charger des ressources comme les fontes ou certains scripts (preload) est une bonne pratique. Mais gare aux effets de bord : en abuser peut avoir l’effet inverse, avec parfois un impact majeur. Il vaut souvent mieux laisser les navigateurs gérer les priorités, ce qu’ils font de mieux en mieux.
Le nouvel attribut html fetchpriority permet de modifier la priorité de téléchargement des ressources. Il peut être utile pour modifier le comportement par défaut du navigateur, en dé-priorisant les scripts tiers ou en re-priorisant une image qui constitue le LCP, par exemple.
Vous souhaitez accélérer le téléchargement de ressources hébergées sur un serveur tiers ? Privilégiez le resource hint « preconnect » plutôt que « dns-prefetch » : ce dernier effectuera non seulement la résolution dns, mais aussi la connexion initiale et la négociation SSL.
Vous utilisez des Resource Hints de type dns-prefetch ou preconnect ? Veillez à en limiter le nombre et à les prioriser (les plus importants en premier). Ces outils n’offrant aucune garantie d’exécution, il arrive souvent que les derniers soient tout simplement ignorés.
Les navigateurs peuvent désormais afficher instantanément une page en naviguant via leurs boutons Précédent et Suivant. Vérifiez que votre site ne bloque pas l’utilisation de cette fonctionnalité « Back/Forward cache » qui garantit des Core Web Vitals au top (DevTools > Appli > Cache amélioré).
Si votre site est « Responsive », le mécanisme de basculement doit intégralement reposer sur les Media Queries CSS et des points de rupture définis. On ne doit jamais utiliser JavaScript, et encore moins une détection de User Agent, pour adapter le rendu aux différents terminaux.
Si vos pages intègrent des animations, notamment sur action utilisateur (survol, clic…), la mise en place d’une compartimentation CSS peut aider à en améliorer la fluidité. Compartimenter réduit les repaint et reflows inutiles, ce qui se traduit par une meilleure interactivité (métrique INP).
Si vos pages intègrent des embeds (YouTube, TikTok, Instagram…), veillez à mettre en place un lazy-loading natif sur leur <iframe> via l’attribut loading="lazy". Cela améliorera nettement la performance, car ces outils tiers exécutent entre autres un important volume de JavaScript.
N’animez jamais les éléments principaux du viewport initial comme les titres ou les images à la Une. Au delà de la charge CPU supplémentaire due au rendu, un effet d’apparition tardive retarde artificiellement les métriques orientées performance visuelle (LCP et Speed Index).

Core Web Vitals

Page Speed Insights N’EST PAS ce que Google prend en compte ! C’est un outil de test (dit synthétique) dont le volet mobile est fortement biaisé. Certains outils tiers (GTmetrix, Webpagetest…) offrent un aperçu plus juste des performances réelles sur mobile.
Ce que Google prend en compte, ce sont les données des visiteurs RÉELS, notamment sous Google Chrome. Ce sont ces données que l’on retrouve dans la Search Console (CrUX) et qu’il utilise dans son algorithme (volet Page Experience).
L’espace Signaux Web Essentiels de la Google Search Console est idéal pour comprendre les problèmes de performance qui affectent un site. On y voit quels ensembles de pages rencontrent des problèmes de LCP, CLS et FID sur desktop et sur mobile. C’est pratique pour démarrer un chantier d’optimisation de la performance.
Le Time To First Byte (TTFB) est pratique pour identifier les problématiques de temps de réponse serveur et/ou de mise en cache. C’est un indicateur de performance essentiel et incontournable dans la mesure où il impacte mécaniquement le FCP, le LCP et le Speed Index.
La nouvelle métrique INP introduite par Google vise à s’assurer qu’une page est fluide tout au long de son utilisation. Elle témoigne de la volonté de Google de mieux estimer la qualité de l’expérience utilisateur tout au long de sa navigation, et plus seulement à son chargement.
Le « load time » fourni par Google Analytics n’est pas un indicateur de performance pertinent : il n’est ni fiable, ni exhaustif, ni représentatif de l’expérience utilisateur réelle. Pour du pilotage de la web performance, privilégiez des métriques comme les Core Web Vitals issues du CrUX.
S’il faut choisir un unique KPI pour la webperf, le LCP (Largest Contentful Paint) est le plus pertinent. Il s’obtient en effet facilement pour les utilisateurs réels (données terrain CrUX) et via les outils synthétiques, tout en reflétant assez bien l’expérience de chargement globale d’une page.
Les métriques officielles ne répondent pas aux besoins spécifiques d’un site ? Utilisez l’API Performance Element Timing : elle permet de définir vos propres indicateurs de performance avec un simple attribut html elementtiming= »nom », puis de les récupérer avec un outil de RUM.

Hébergement / serveur

Combiner plusieurs fichiers CSS ou JS offre un gain de poids intéressant : 2 fichiers de 10 ko ne pèseront que 17 ko si on les regroupe. C’est lié aux mécanismes de compression (Gzip et à fortiori Brotli), très performants avec ces langages au code répétitif.
Minifier du code HTML n’apporte pas de gain de performance significatif, en raison notamment de la compression Gzip et Brotli. La durée de l’opération peut même être supérieure aux gains en termes de temps de téléchargement, impactant négativement les métriques TTFB et LCP.
Si un site est optimisé avec un système de cache + minification / combinaison / defer (type WordPress + WP Rocket), un CDN comme Cloudflare n’apportera pas grand chose et peut même générer des latences côté page si le serveur est localisé dans le pays cible.
Déployer un cdn améliore la performance globale des sites internationaux. Privilégiez toutefois un cdn global, en mode proxy, plutôt qu’un cdn qui ne cible que les images et/ou les ressources statiques. Cela réduit en effet l’impact et peut même avoir des effets négatifs sur le FCP et le LCP.
Tout serveur Apache, Nginx ou autre doit impérativement servir les ressources en http/2. Le protocole offre une marge d’amélioration considérable par rapport à http/1.1 en matière de web performance (côté téléchargements simultanés notamment). Pourtant, de nombreux sites fonctionnent toujours avec l’ancien protocole http/1.1.
Si votre hébergeur ou cdn propose l’activation de HTTP3, activez-le ! Comparé à HTTP2, le protocole permet une amélioration significative des temps de réponse serveur (TTFB), grâce notamment au multiplexage des requêtes et à une meilleure compression des en-têtes http.
Définissez systématiquement une entête Content-Security-Policy. La démarche améliore non seulement la sécurité pour vos visiteurs, mais permet aussi de réaliser un état des lieux des ressources utilisées par un site. Savoir ce qui est chargé en JS, CSS, images ou fontes est essentiel pour la performance !
Activez la toute dernière version de TLS sur votre serveur (1.3 actuellement). Le protocole de communication sécurisé évolue régulièrement pour assurer des échanges toujours plus rapides entre le navigateur et le serveur. Cela contribue à améliorer le FCP, le LCP et le Speed Index.
Les ressources statiques (images, webfonts, JavaScript, CSS…) doivent être servies avec une entête définissant une politique de cache de navigateur. La bonne pratique est de définir un délai d’expiration d’un an (31536000 secondes) pour éviter tout re-téléchargement inutile.
Testez systématiquement votre site avec la dernière version de php. S’il fonctionne correctement (absence d’erreurs 500), conservez-la : chaque nouvelle évolution du langage serveur offre des gains de performance, ce qui permet de réduire les temps de réponse (métrique TTFB).
Vos pages mettent du temps à se charger sans système de cache activé (TTFB élevé) ? C’est que votre serveur est sous-dimensionné par rapport à vos besoins (processeur et ram). Passez sur un hébergement plus performant ou réduisez le volume / optimisez la qualité de votre code.
Activer OCSP Stapling sur un serveur permet d’améliorer le TTFB à la première connexion pour certains utilisateurs. Le navigateur n’a en effet plus besoin de vérifier la validité du certificat TLS servi auprès de l’autorité d’émission, supprimant des allers-retour réseau coûteux.
Évitez de multiplier les redirections 301 au sein de votre fichier .htaccess : cela ralentit Apache et augmente donc les temps de réponse serveur (TTFB). Si leur nombre est supérieur à 500, privilégiez l’utilisation d’un script php ou d’une extension spécialisée s’il en existe pour votre CMS.
Votre hébergeur ou cdn permet l’utilisation des « 103 Early Hints » ? Activez la fonctionnalité : bien configurée, elle permet de démarrer le téléchargement des ressources critiques (CSS, webfonts) avant les pages en elles-mêmes. Les gains sur le FCP et le LCP peuvent être majeurs.
Les ressources encodées en texte (CSS, JavaScript, HTML…) doivent être compressées en Gzip ou mieux encore, en Brotli. Cela réduit considérablement leur poids, avec un impact majeur sur les métriques liées au temps de chargement comme le FCP, le LCP et le Speed Index.
Si vous utilisez un CMS comme WordPress ou Prestashop et que votre hébergeur propose une technologie de cache objet comme Redis, Memcached ou APCu, activez-la. Un cache objet réduit le volume de requêtes SQL, améliorant significativement le TTFB pour les pages dynamiques.
Privilégiez systématiquement les solutions de sécurité côté serveur. Un Web Application Firewall (WAF) ou scanner de malwares seront toujours nettement plus performants gérés côté hébergement que via une extension ou un script écrits en php. L’impact sur le TTFB peut être significatif.
Votre CMS ou page builder vous propose d’afficher une sélection de contenus (articles, produits…) de façon aléatoire ? N’optez jamais pour une telle fonctionnalité : cela se traduit par des requêtes SQL peu performantes qui impactent négativement les temps de réponse (TTFB).
Assurez-vous que la configuration DNS de vos sous-domaines, www inclus, n’utilise pas de champ de type CNAME. À défaut de pointer directement vers l’adresse IP de votre serveur (champs A ou AAAA), cela impacte les temps de réponse (métrique TTFB) à hauteur de 30% environ.
Si votre hébergement web possède une adresse IPv6, ajoutez les enregistrements DNS adéquats (champs de type AAAA) pour votre domaine racine (clé @) et ses sous-domaines, www inclus. Les gains côté temps de réponse (métrique TTFB) peuvent être significatifs.

CSS (styles)

Plus le volume de CSS augmente, moins bonne est la performance. La sanction est double : un fichier plus gros est plus long à télécharger, et son temps d’exécution par le moteur de rendu du navigateur est rallongé. Cela impacte le FCP et le LCP.
CSS offre plusieurs propriétés très utiles d’un point de vue web performance. C’est le cas d’aspect-ratio, qui peut intervenir en dernier recours pour diminuer le CLS. Mais aussi de content-visibility qui, réglé sur auto et associé à un contain-intrinsic-size, diminue les temps de rendu. Ou encore de contain: content, qui réduit les risques de repaint/reflow.
Tout encart publicitaire dont les contenus sont chargés via JavaScript (comme Google Ads ou Taboola) doit avoir une hauteur minimum définie en CSS. Sans cette « réservation d’espace », il génèrera des Layout Shifts lors de son chargement. C’est bien souvent la première cause de CLS sur les sites éditoriaux / publisher.
Si votre site utilise des animations, tout particulièrement en boucle, veillez à ce qu’elles reposent sur les propriétés CSS transform et opacity. Ce sont les seules qui permettent de profiter du plus haut niveau de performance graphique disponible dans les navigateurs modernes.
N’intégrez JAMAIS d’images et encore moins de webfonts encodés en base64 dans vos fichiers CSS. Cela contribue à faire exploser le poids des fichiers, ce qui pénalise fortement le FCP et le LCP. Il ne doit y avoir que du CSS dans les fichiers CSS.
L’approche mobile-first doit systématiquement être privilégiée lorsque vous ciblez un type d’appareil via CSS. Dans cette optique, privilégiez les Media Queries basées sur min-width plutôt que max-width : le comportement d’origine est le petit écran, que l’on complète sur tablette puis ordinateur.
Le hack populaire permettant de télécharger des feuilles de style en asynchrone (preconnect avec événement onload) peut avoir des effets négatifs sur la performance. Il peut générer des Layout Shifts ainsi que des repaint er reflow qui augmentent le temps de rendu de la page.
Évitez de modifier l’ordre d’éléments verticaux via les propriétés « flex-direction » et « order » de CSS Flexbox : cela peut générer des Layout Shifts (métrique CLS) et du Blocking Time (métrique TBT). Pour un rendu optimal, privilégiez une modification de l’ordre directement dans le code html.
Limitez l’utilisation des déclarations CSS intégrant le sélecteur universel (*) : les navigateurs doivent les évaluer pour chaque élément du DOM. Cela génère une forte consommation de ressources CPU, ce qui rallonge les temps de rendu et peut impacter l’INP lors des interactions.
Les pseudo-classes fonctionnelles CSS comme :is(), :has(), :where() et :not() offrent une grande flexibilité dans le ciblage du DOM. Cela se fait toutefois au prix d’une consommation CPU accrue, avec un impact potentiel sur le Blocking Time et la métrique INP. Limitez donc leur usage.
Vous utilisez des pré-processeurs CSS pour créer vos feuilles de styles ? Limitez les niveaux d’imbrications : cela génère des sélecteurs CSS très spécifiques qui alourdissent les ressources et ralentissent le moteur de rendu des navigateurs. Cela impacte notamment le TTI et le LCP.
À de rares exceptions comme font-smooth, text-stroke ou box-reflect, les préfixes vendeurs ciblant les navigateurs webkit (-webkit), Firefox (-moz), Opera (-o) et IE/Edge (-ms) sont inutiles. Les utiliser augmente inutilement le poids des feuilles de styles et les temps de génération du CSSOM.

JavaScript

Plus le volume de JavaScript augmente, moins bonne est la performance. Les scripts tiers comme Google Analytics, Google Ads ou Recaptcha consomment notamment beaucoup de temps processeur pour s’exécuter, ce qui génère des latences et saccades dans le navigateur (TBT et FID côté métriques).
Certains outils comme WP Rocket permettent de retarder l’exécution des JavaScript en attendant la première interaction (clic, scroll ou hover). Ne l’utilisez pas sur les scripts de votre thème sous peine de rendre votre menu mobile peu fonctionnel, voire de générer du CLS sur les thèmes mal codés.
Besoin de mettre en avant des encarts de rassurance comme votre note clients Trustpilot ou Avis Vérifiés ? N’utilisez pas les widgets fournis par vos partenaires, non optimisés. Une simple image avec un lien aura le même effet et améliorera considérablement les temps de chargement.
Les CMP / gestionnaires de cookies RGPD offrent un gain de performance intéressant pour les nouveaux utilisateurs et les outils de test synthétiques comme Page Speed Insights. Les scripts tiers ne sont en effet chargés que dans un second temps, après que l’utilisateur ait consenti.
Ne modifiez jamais le style initial d’une page via JavaScript ou jQuery. Toute modification visuelle doit se faire directement en CSS et non via l’ajout dynamique de classes ou de styles. Cette pratique entraîne des repaint et reflow consommateurs en ressources CPU et peut générer du CLS.
Les tags de chargement asynchrone fournis par la plupart des outils tiers, dont Google Tag Manager, ont un impact majeur sur la performance. Privilégiez un appel natif via une balise <script> avec un attribut defer plutôt qu’async : c’est la seule solution pour ne pas bloquer le rendu de la page.
Les outils d’A/B testing comme Kameleoon et AB Tasty doivent être utilisés très ponctuellement et désactivés à chaque fin de campagne de test. Leur impact est en effet majeur en termes de Blocking Time, ce qui contribue à augmenter les métriques FID et LCP.
Un script tiers ne s’exécute qu’au survol d’un bouton ? La mise en place d’une « façade » permet de réduire son impact au chargement des pages (TBT, FID…) en conditionnant son chargement au survol de cette zone. Les outils de VOC comme Zendesk se prêtent particulièrement bien à ce jeu.
Vous avez besoin d’afficher des boutons de partage social ? N’utilisez pas d’outil tiers comme AddThis ou ShareThis, qui chargent des dizaines de kilo-octets de ressources JavaScript et génèrent du Blocking Time. Privilégiez les outils auto-hébergés avec un minimum de JavaScript et CSS.
Si votre site propose une fonctionnalité interactive nécessitant d’importants calculs côté utilisateur, utilisez un Service Worker ou Web Worker. Ces API navigateur peuvent exécuter du JavaScript avec leurs propres ressources CPU, réduisant significativement les métriques TBT, FID et INP.
Vous devez sécuriser un formulaire d’inscription, de contact ou de souscription à une newsletter ? Évitez à tout prix les Captcha reposant sur du JavaScript, et tout particulièrement Google ReCaptcha. Privilégiez un Honeypot (piège à robots) ou une vérification côté serveur, après envoi.

Images

Toutes les images appelées via une balise html <img> doivent systématiquement être associées aux attributs width et height. Cela permet au navigateur de connaître leur ratio d’affichage avant de les télécharger, supprimant tout risque de Layout Shift au chargement des pages.
Veillez à intégrer à vos contenus des images dont les dimensions intrinsèques se rapprochent des dimensions affichées à l’écran. Dans WordPress comme avec les autres CMS, les page builders permettent de choisir une taille d’image, et cela à la fois pour mobile et pour desktop.
Utilisez les bons formats d’images : PNG ou SVG pour les logos, icônes et pictos, JPG pour les photos. Ne vous embêtez pas à générer vous-même des images en WEBP ou AVIF, qui doivent forcément être proposés avec un « fallback » en PNG ou JPG : utilisez un outil de type extension ou CDN (comme Cloudflare).
Si vous utilisez un mécanisme de lazy-loading, ne l’appliquez pas sur les images visibles dans le viewport. Cela concerne notamment le logo en header, mais aussi parfois les images à la Une sur les pages d’articles. Désactiver le lazy-loading sur ces éléments peut réduire fortement le LCP.
Privilégiez dès que possible le lazy-loading natif (attribut html loading="lazy") aux solutions reposant sur du JavaScript (Lazysizes, Lozad…). Cela sera en effet plus performant, notamment sur le volet interactivité où TBT et INP pâtissent de l’exécution des scripts dans le thread principal.
Si votre site n’affiche que quelques icônes, n’utilisez pas l’icon-font Font-Awesome qui contient plus de 700 caractères. Privilégiez l’utilisation d’images SVG en inline, qui assurent elles aussi un rendu vectoriel mais avec un poids largement inférieur. Ou, à défaut, une custom icon-font réalisée via Icomoon.
L’affichage des images peut bloquer le rendu d’autres éléments, impactant le temps d’affichage et la fluidité. Pour éviter cela, les images appelées via une balise html <img> doivent toutes posséder l’attribut decoding="async". Elles seront alors affichées une fois décodées indépendamment du reste de la page.
L’utilisation de SVG est optimale pour les logos et pictogrammes. Attention toutefois : le fichier doit être basé sur des tracés pour être vectoriel, et ne doit jamais intégrer d’images PNG ou JPEG encodées en base64. Une telle utilisation est totalement contre-productive.
Si une image de type photo doit être affichée avec des zones transparentes, ne vous tournez pas vers le format PNG. Privilégiez du classique JPEG associé à une mise en forme CSS de type border-radius ou un masque SVG. Cela sera toujours nettement plus léger.
Vous utilisez des images vectorielles en SVG pour vos icônes, logos ou illustrations ? Excellent, mais veillez à optimiser leurs tracés avant de les mettre en ligne. La plupart des fichiers téléchargeables en ligne ou fournis par les graphistes intègrent des éléments inutiles qui les alourdissent.

Vidéos

Ne chargez JAMAIS de vidéo YouTube avec vos pages, et encore moins en auto-play (mauvaise pratique UX) car l’iframe appelle énormément de JavaScript mais aussi du CSS et une fonte. Différez son chargement avec du lazy-loading natif (attribut loading) ou une librairie de façade comme LazyTube.
Ne proposez jamais de vidéo en MP4 par défaut : privilégiez le Webm, qui supporte des codecs plus modernes et s’avère donc plus léger. Le format MP4 doit toutefois toujours être proposé en fallback grâce à une balise <video> associée aux sources adéquates.
Votre site intègre des vidéos hébergées sur votre propre serveur ? Proposez systématiquement une image d’aperçu via l’attribut « poster » de la balise <video>. Non content de s’afficher sur mobile par défaut, cette image constituera l’élément de LCP si la vidéo est dans le viewport initial.

Polices d’écriture

Gare aux fontes ! Utilisez si possible une famille, éventuellement 2 mais pas plus. Limitez le nombre de variations : une version Regular (400) et Bold (700) suffisent bien souvent. Beaucoup de thèmes et Page Builders chargent toutes les déclinaisons de styles et graisses et plombent ainsi la performance.
Les polices d’écriture doivent toujours être chargées localement. Google Fonts et Adobe Typekit sont pratiques, mais ce sont des gouffres en matière de performance. L’effet négatif est double : temps de téléchargement rallongé en raison des latences réseau et impossibilité de précharger les fontes.
Toutes les polices d’écriture ne se valent pas côté web performance : en fonction de la complexité de leurs glyphes, les fichiers pèsent plus ou moins lourd (à subset équivalent). Privilégiez les webfonts légères comme Poppins, Jost, Albert Sans ou Oswald, toutes autour de 10 ko en version Woff2.
Si vous utilisez une police d’écriture disponible au format « Variable Font », privilégiez ce dernier par rapport aux classiques variations de graisses individuelles. Il n’y aura plus qu’un unique fichier Woff2 à télécharger et à précharger, et vous aurez accès à davantage de graisses.
Si vous auto-hébergez des fichiers de fontes variables, bravo. Veillez toutefois à ce qu’ils n’intègrent que le nécessaire : on y trouve souvent des « axes » inutilisés : graisses (Regular, Bold…), strand (plus ou moins italique) ou encore width (plus ou moins condensé). Leur poids diminuera.
Les fontes textuelles hébergées localement doivent être préchargées via une balise <link rel="preload"> afin d’assurer un rendu plus rapide des textes et de réduire le CLS. Attention toutefois : seule la version woff2 doit être préchargée à raison d’un fichier par variation de graisse.
Les fichiers de polices ne doivent jamais inclure de subsets inutilisés : cela augmente inutilement leur poids, avec un impact majeur sur le LCP. Pour des sites en Français et/ou Anglais, les subsets « Basic Latin » et « Latin-1 Supplement » suffisent généralement à afficher l’intégralité des textes.
Lorsque vous déclarez une font-stack via la propriété CSS font-family, seule la première police doit être de type custom : les suivantes doivent être des polices système. Déclarer plusieurs polices custom peut conduire au téléchargement de multiples fichiers inutilisés, faisant chuter LCP et Speed Index.
De nombreux outils tiers et extensions affichés en front (CMP, VOC, popups marketing…) utilisent leurs propres jeux de polices d’écriture. Veillez, dès que possible, à modifier leur comportement afin qu’ils héritent de la police par défaut de vos pages (valeur « inherit »).

UX/UI

Limitez le nombre d’animations : elles sont généralement aussi coûteuses pour la performance que perturbatrices en termes d’UX. Si vous devez en intégrer, elles doivent idéalement reposer sur les propriétés CSS transform et opacity. Évitez les frameworks JavaScript type animate.js, Lottie…
Les loaders full-page de type « spinner » ou « loading bar » sont fortement déconseillés. Ils pénalisent l’Expérience Utilisateur en masquant l’intégralité des contenus durant plusieurs secondes. Cela se traduit, côté métriques, par une hausse conséquente du LCP et du Speed Index.
Limitez l’utilisation des sliders et autres carousels. Ils rendent une partie des contenus invisible aux visiteurs tout en imposant une interface de navigation moins naturelle que le scroll. Ils reposent par ailleurs souvent sur de gros volumes de JavaScript, augmentant significativement le TBT et l’INP (plus d’infos).
Si vous utilisez des sliders, carrousels ou zones à défilement horizontal automatique, veillez à y intégrer des contenus de même hauteur. De nombreuses extensions adaptent en effet la hauteur de la zone à son contenu visible, si bien que l’ensemble de la page subit des Layout Shifts en permanence.
Ne modifiez pas le comportement de défilement natif des navigateurs avec du JavaScript. C’est justifié pour les sites de type « fullpage » qui fonctionnent comme des diaporamas, mais inutilement coûteux pour le navigateur et perturbant pour l’Expérience Utilisateur dans tout autre contexte.
Vous souhaitez afficher une donnée sensible (numéro de téléphone, adresse email…) tout en empêchant sa lecture par des bots peu scrupuleux ? Plutôt que d’utiliser des images, privilégiez le JavaScript avec un encodage en base64. Ainsi, le texte restera sélectionnable et cliquable par les (vrais) visiteurs.
Un texte est « trop long » pour s’afficher sur votre site mobile ? Ne le masquez jamais via CSS (avec du text-overflow: ellipsis par exemple). Dans une démarche mobile-first, l’intégralité des textes doit être lisible quelle que soit la résolution du terminal de consultation.
Si un template de page possède une largeur limitée, il ne faut jamais utiliser d’option pour étendre des zones horizontalement hors de cette dernière via JavaScript : cela est très coûteux en ressources CPU et génère des Layout Shifts. Privilégiez des templates natifs en pleine largeur.
Si votre site propose des notifications push, n’activez jamais de fenêtre d’invitation à l’abonnement au premier affichage : ce comportement est intrusif en termes d’Expérience Utilisateur et générateur de Blocking Time. Privilégiez un bouton au sein des pages, idéalement après les contenus.
Il est déconseillé de fournir une version mobile spécifique de votre site, AMP compris. Les API et outils natifs des navigateurs intègrent le nécessaire pour assurer une performance mobile optimale. Simplifiez votre stack avec un unique site « Responsive » basé sur les Media Queries CSS.

SEO

L’impact de la web performance sur les classements dans les pages de résultats de Google est inconnu : aucune étude ne prouve ses effets sur le SEO. Optimiser permet toutefois d’améliorer l’expérience utilisateur, et donc les conversions.
Contrairement aux idées reçues, obfusquer des liens pour optimiser le crawl d’un site, c’est simple à mettre en place avec une dizaine de lignes de JS. Il n’y a rien de complexe et cela peut avoir des effets très bénéfiques aussi bien pour le SEO que pour une bonne maîtrise du « crawl-budget ».
La Google Search Console offre un aperçu détaillé de la façon dont Googlebot crawle les sites. Cette fonctionnalité, peu connue, est accessible via le menu Paramètres > Statistiques sur l’exploration > Ouvrir le rapport. On y trouve les temps de répons moyen et volume de crawl quotidiens, ce qui permet de comprendre les problématiques d’indexation.
Certains outils de l’écosystème Alphabet, comme Google Discover, sont particulièrement sensibles à la web performance des sites. Pour intégrer l’outil et y rester visible durablement au fil des publications, il est ainsi indispensable de passer les Core Web Vitals au niveau du site (origine).

WordPress

Sur WordPress, les révisions et brouillons auto des publications peuvent rapidement faire gonfler la taille de la base de données. Il est important de nettoyer régulièrement ces éléments afin de réduire le temps d’exécution des requêtes SQL. Cela améliore le TTFB.
Gutenberg, c’est bien. L’éditeur natif de WordPress a énormément évolué ces 2 dernières années et est maintenant utilisable comme alternative aux page builders historiques. Associé à des librairies de blocs (GenerateBlocks, Ultimate Blocks…), il permet de créer n’importe quelle mise en page complexe en générant un minimum de DOM et de CSS.
Si vous n’utilisez pas l’éditeur de blocs Gutenberg en tant que Page Builder, désactivez ses feuilles de styles sur votre site. Cela n’est en effet pas automatique et peut augmenter inutilement le volume de CSS, et ainsi contribuer à augmenter le FCP et le LCP.
Au fil des évolutions d’un site WordPress, le thème et les extensions peuvent être amenés à changer. Or, à leur désactivation, ces derniers laissent généralement des traces dans la table wp_options. Les supprimer manuellement réduit la taille de cette table SQL cruciale, améliorant le TTFB.
Par défaut, WordPress exécute des tâches en arrière-plan à l’ouverture de pages, ce qui peut engendrer une montée en charge et des ralentissements. Privilégiez une exécution des crons côté serveur toutes les 2 à 5 minutes. Cela améliorera le TTFB des pages dynamiques.

Thèmes

Si vous souhaitez avoir un WordPress rapide, n’achetez pas de gros thème populaire sur Themeforest. La bonne logique est de partir de quelque chose de léger pour l’adapter à vos besoins via des extensions. La démarche contraire (désactiver plein de fonctionnalités) se paie souvent cher en termes de CSS et JS chargés.
Gare à certains thèmes « responsive » dont le header repose en fait sur la présence de 2 headers distincts : l’un pour mobile, l’autre pour desktop. L’ensemble des liens d’entête, et notamment du menu principal, y sont présents en double, ce qui alourdit le DOM et n’est pas optimal pour le SEO.
Lorsque vous créez ou refondez un site WordPress, utilisez systématiquement un thème enfant. Cela vous permettra d’y intégrer des modifications, pour la web performance entre autres, tout en continuant à profiter des mises à jour du thème de base.

Extensions

Il n’existe pas d’extension miracle pour améliorer la performance sous WordPress. Même l’excellent WP Rocket nécessite d’être configuré et ses options finement testées pour maximiser son impact sur les Core Web Vitals. La config diffère pour chaque site.
Sur WordPress, les extensions de cache améliorent drastiquement le FPC et le LCP pour les visiteurs et robots. Elles soulagent également le serveur en matière de ressources processeur et mémoire, ce qui réduit les temps de réponse pour les utilisateurs connectés.
Lorsqu’une extension WordPress nécessite une mise à jour de sa base de données (WooCommerce, Yoast SEO…), faites-le rapidement. Sans cela, les requêtes SQL ne seront pas optimisées, ce qui peut ralentir les temps de chargement dans l’administration et pour les pages non mises en cache.
Lors de l’installation d’une extension WordPress, vérifiez systématiquement le poids des ressources CSS et JS chargées sur le site public. Les extensions représentent souvent plus de 2/3 du volume de CSS, ce qui contribue à l’augmentation du FCP et du LCP.

Vous appréciez ce partage mais avez besoin d’accompagnement opérationnel pour aller plus loin ? N’hésitez pas à contacter l’Agence Web Performance, c’est notre métier !