Brèves de webperf

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 d’en comprendre l’essentiel. 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.

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.

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.

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

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.

Images

  • 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 offrent elles aussi un rendu vectoriel idéal pour les écrans à haute densité de pixels. Mais avec un poids bien inférieur.

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 comme LazyTube.

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.

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égier 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.

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.

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 !

Vous souhaitez être accompagné par l'Agence Web Performance ?
Contactez-nous
Vous êtes ici : Accueil / Blog / Brèves de webperf