56 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 « rendering » 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 WordPress.
  • Pré-loader des ressources comme les fontes ou certains scripts 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.

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.
  • 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.

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.
  • 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.
  • 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.
  • 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.

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 cela, il génèrera des « Layout Shift » 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.

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.

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 Shifts au chargement des pages.
  • 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 plugin ou CDN (comme Cloudflare).
  • Si vous utilisez un script / plugin de lazy-loading, désactivez la fonctionnalité 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.
  • 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.
  • 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.

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.

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 et plombent ainsi la performance.
  • Les polices d’écriture doivent toujours être chargées localement. Google Fonts est certes pratique, mais c’est un gouffre en matière de performance. L’effet négatif est double : temps de téléchargement rallongé en raison des échanges TCP/TLS supplémentaires et impossibilité de précharger les fontes.
  • 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

  • Les animations, c’est le mal. Les Loaders full-page (type spinner) sont une catastrophe pour la web performance. Il faut également éviter toute animation sur les éléments visibles en haut de page de même que les sliders / carousels, souvent catastrophiques niveau perf.
  • Si vous utilisez des sliders, carrousels ou zones à défilement horizontal automatique, veillez à y intégrer des contenus de même hauteur. De nombreux plugins 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.

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 (hors Google Discover). 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.

WordPress

  • 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.
  • 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.

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 plugins. 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.

Plugins

  • Il n’existe pas de plugin 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 plugins de cache améliorent drastiquement le FPC et le LCP pour les visiteurs et robots. Ils 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’un plugin 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 !

Réagissez à cet article

Vous souhaitez être accompagné par l'Agence Web Performance ?
Sollicitez-nous
dès maintenant
Vous êtes ici : Accueil / Blog / 56 conseils de pro pour améliorer la performance de votre site