tw-rl

Petite info, ça c’est les ressources chargées par le dev, mais il faut savoir que WordPress et certains plugins chargent du CSS et du JS, comme Contact Form 7 ou WPBakery. WordPress charge aussi nativement le CSS de Gutenberg, et le JS des emojis.

Voila ça c’est pour le contexte, on passe aux actions ! Première action que je mets en place : je vire le builder WPBakery, et je rebuild les templates avec des beaux champs ACF (vive ce plugin), ça me prend facile 2h.

Le score monte à plus de 40, mais on est toujours dans le rouge. Le soucis avec les builders c’est qu’il génère du code HTML lourd avec des div dans des div dans des div.. Regardez la quantité de widgets, ces ressources (CSS et JS) finissent dans par alourdir le site.

J'ai jamais vu un client aimer maintenir son site avec ce genre de truc, après ça peut être pratique quand on veut monter une page rapidement (et encore..) Surtout qu’avec Gutenberg on a un système de colonnes et pleins de widgets (mais ce n'est que mon opinion).

Ensuite je fais un truc facile mais qui peut être long, je vire Font Awesome, à quoi bon charger une librairie de plusieurs milliers d’icônes si on en utilise 20. Donc je remplace les balise <i class=”fa ...”> par le code svg qui est directement dispo sur leur doc.

Cela me prend une grosse demi heure car il faut modifier le CSS. Le score monte mais on est toujours à moins de 50 😭 Je ne me laisse pas abattre je continue.

Je décide de regarder comment le dev a intégré le site, je constate qu’il n’utilise à aucun moment le JS de Bootstrap. Donc je le vire. Je vire aussi popper.js par la même occasion, c’est une lib de 3 kb mais c'est toujours ça de gagner !

Le CSS minifié de Bootstrap 4 c’est 160kb, c’est beaucoup. Voyons si on ne peut pas l’alléger, je regarde ce que le dev a utilisé : - la grille (évident) - les boutons - les formulaires Donc je vire Boostrap pour importer seulement le bootstrap-grid.min.css qui fait 60kb.

Je reconstruis le CSS des boutons et des formulaires en regardant la doc de Bootstrap. J'ai importé la grille de Bootstrap 5 pour avoir les gap sur les class row. Le score monte on passe tout juste la barre des 60, ça me prend environ 1h.

Ensuite je me dis que je pourrais virer ce bon vieux jQuery. Par chance aucun plugin frontend n’en a besoin. Par contre il y a des sliders construits avec Slick, si je vire jQuery les sliders vont pétés.

Pas grave, je vire Slick (le JS et le CSS) et j’importe Splide, une librairie de sliders qui est Lighthouse friendly. Cela ne me prend pas longtemps pour refaire les sliders, environ une grosse demi heure.

J'utilise Splide sur tous mes projets car la librairie est légère et qu'elle ne pose apparemment pas de problèmes sur les autres catégories de Lighthouse (Accessibilité, Bonnes pratiques et SEO). Voici l'audit Lighthouse de la frontpage de Splide.

Je réécris le code jQuery en JS Vanilla, le dev qui a codé le site n'a utilisé que les sélecteurs $ et quelques fonctions, je trouve facilement l’équivalent en JS Vanilla. Je vire donc jQuery ET le JS et CSS de Slick, on arrive bientôt à la barre des 70 😭

Ensuite il y a du Leaflet qui est chargé sur ma home page, alors qu’il n’y qu’un type de page qui en a besoin, je décide de ne charger ces ressources que sur les pages concernées, avec ce genre de condition.

Je souhaite faire pareil pour Contact Form 7, mais il y a des formulaires sur toutes mes pages 😢 Mais si sur votre site vous avez un formulaire sur la page contact, ne chargez les ressources de CF7 que sur cette page !

Ensuite il faut savoir que les nouveaux WordPress chargent par défaut le CSS de Gutenberg, le site que j’optimise ne l’utilise pas, donc je vire. Le code à mettre dans functions.php pour dequeue le CSS : https://gist.github.com/someguy9/1f51a7cb3349cc32d00f5aaa5d3b3e19#file-wp-remove-gutenberg-block-library-css-php

WordPress charge aussi nativement un fichier JS pour les émojis, ça ne sert a rien et ça dégrade les perfs, on vire aussi, vous pouvez passer par un plugin mais le plus simple et de le faire avec du code : https://kinsta.com/fr/base-de-connaissances/desactiver-emojis-wordpress/#2-dsactiver-les-emojis-dans-wordpress-avec-du-code

Même après tout ce travail je n’arrive pas à franchir la barre des 80, je reste à 70 environ. Je suis plutôt déçu mais je ne me laisse pas abattre, je vais donc m’attaquer aux ressources qui “bloquent le rendu”, mais qu’est ce que ca veut dire au juste ?

Un peu de lecture : https://kinsta.com/fr/blog/eliminer-javascript-css-bloquant-rendu/ En gros ça veut dire que lors du parsing du HTML par la navigateur, lorsqu'il rencontre un script, il s'arrête pour l'exécuter, bloquant le reste. Lorsqu'on a des gros fichiers JS et CSS, c'est problématique.

Le navigateur ne sait pas si le code JavaScript va contenir des instructions spécifiques à exécuter immédiatement qui pourront avoir une conséquence importante sur.. le code HTML/CSS lui-même.

Le CSS bloque aussi le rendu, ce qui peut entrainer du FOUC (un flash de contenu non stylisé). Un très bon article sur le sujet : https://dev.to/lyqht/what-the-fouc-is-happening-flash-of-unstyled-content-413j Voici une illustration pour comprendre le phénomène :

Il y a plusieurs choses à faire pour corriger ce problème de ressources bloquantes, commençons par lister les ressources qui posent problème : - Google reCaptcha - GTM - Google Analitycs - Google Fonts - Ainsi que mon propre fichier CSS

Commençons par Google Fonts, j'ai trouvé cet article qui explique comment les charger pour que Lighthouse soit content : https://css-tricks.com/how-to-load-fonts-in-a-way-that-fights-fout-and-makes-lighthouse-happy/#aa-the-optimal-way-to-load-fonts

J'explique le code proposé sur CSS Tricks : - rel="preconnect" permet d'indiquer au navigateur qu'il va avoir besoin des ressources que l'on passe dans le href - rel="preload" fait un preload asynchrone avec une basse priorité

- le media="print" car que le navigateur donne une basse priorité aux "print stylesheets" Le &display=swap dans l'url permet d'utiliser une police de remplacement déjà disponible sur le navigateur pour afficher du texte immédiatement tant que la police n'est pas chargée.

Ensuite j'ai voulu mettre un defer sur certains scripts, mais je me suis rendu compte que ça faisait péter certains éléments de la page (carte Leaflet), dommage. Les attributs async et defer permettent d'indiquer au navigateur comment charger le script. https://www.alsacreations.com/astuce/lire/1562-script-attribut-async-defer.html

Voila une image pour comprendre. C'est simple, avec defer le navigateur attend d'avoir parser le HTML pour exécuter le script. Source : https://flaviocopes.com/javascript-async-defer/#async-and-defer

Je me demande alors si je peux mettre un defer sur GTM. Oui on peut, on peut changer le code async=true par defer=true. Cela permet de plus avoir le warning de Lighthouse qui indique que c'est une ressource bloquante, mais j'ai fait pété les scripts qui sont injectés par GTM...

Tant pis, je vais essayer de faire avec, mais l'idéal serait de se passer de GTM. Dans mon cas il injecte beaucoup d'outils de tracking (Bing Ads, Google Ads...) je ne préfère pas y toucher.

Dans les ressources bloquantes c'est surtout Google reCaptcha qui fout la merde. Celui là on peut lui mettre un defer, mais le script est injecté par CF7. Je trouve alors un plugin pour le faire : https://fr.wordpress.org/plugins/cf7-google-captcha-load-after-page/ Le score fait +10 facile, à ce moment je suis comme ça 🤯

Mon fichier CSS est aussi considéré comme bloquant, c’est normal c’est un gros fichier, il y a tout Bootstrap dedans ainsi sur mon CSS custom. Ce qu’il faut faire c’est donner au navigateur le CSS prioritaire pour le rendu (Critical CSS), en gros le CSS de la zone de flottaison.

Dans mon cas j’ai juste pris le CSS de la nav et des headers et j’ai tout mis en CSS inline dans une balise <style> dans le head. Boom +10 en perfs, je passe largement au dessus des 85, mais c’est toujours en orange, objectif atteint mais je peux passer au dessus des 90.

Comme on l'a vu un peu avant, charger en defer certains scripts comme GTM n’est pas toujours possible, vous pouvez mais ça peut casser quelque chose. Par contre on peut faire un preconnect et un dns-prefetch, j’ai gratté 2 ou 3 points comme ça.

On l'a vu + haut pour Google Fonts avec le preconnect. Vous pouvez faire de même avec GTM et GA, et d'autres services : https://blog.luke.lol/webmaster/optimize-google-analytics-google-tag-manager-via-preconnect-headers/

À ce moment je suis à 90+ environ, le résultat varie un peu. Je me dis que je peux optimiser les images mais elles le sont déjà, le dev a fait du bon boulot. Elles sont toutes chargées avec du lazyloading et en responsive.

Elles sont aussi bien optimisées, entre 80 et 120kb pour les grandes images (>1600px de large). Pour charger des images responsives, WordPress a des fonctions pour ça : https://developer.wordpress.org/apis/handbook/responsive-images/#new-functions-and-hooks Aussi par défaut la fonction the_content() sort des images responsives.

Toujours avec les images, vous pouvez utiliser le format webp : https://developers.google.com/speed/webp C'est un format développé par Google, donc Lighthouse le recommande bien entendu. Le format permettrait d'avoir des images de 25 à 35% plus légère.

Je ne sais pas vraiment si ça vaut le coup mais WordPress supporte nativement ce format depuis la version 5.8 : https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/ Le site sur lequel j'étais avait déjà des images en webp.

Parlons du lazyloading : c'est le fait de différer le chargement d'une ressource. On peut le faire sur les images qui sont des ressources importantes, en demandant au navigateur de les charger que lorsque l'utilisateur scroll. https://developer.mozilla.org/fr/docs/Web/Performance/Lazy_loading

Pour se faire vous pouvez mettre un attribut loading="lazy" sur vos images. C'est supporté par tous les navigateurs, même Safari depuis peu il me semble. Mais si vous voulez supporter les anciens navigateurs, vous pouvez le faire en JS. Il y a pleins de librairies pour cela.

Si vous souhaitez le faire sans librairie, c'est possible avec l'API Intersection Observer : https://developer.mozilla.org/fr/docs/Web/API/Intersection_Observer_API

Toujours avec les images, il n’y avait pas tout le temps une width et une height dans le HTML. Je le fait pour toutes les images, c’est important pour éviter que ça “saute” au chargement (FOUC), car les dimensions sont dans le CSS.

J'ai un warning qui me dit également que le DOM est lourd, c’est sur ça que je vais passer environ 1h, je vais passer sur tous les templates et les templates-parts pour virer tout ce qui est inutile. Le dev qui avait fait l’inté avait mis des class inutilisées par exemple.

Donc je vire tout ce qui peut l'être, parfois des imbrications de div inutiles, j’allège aussi mon CSS en mettant la taille et la couleur de mes svg directement dans le markup HTML. Sur cette partie je pense avoir gratter 1 ou 2 points.

Voila ! C'est tout ce que j'ai fait pour améliorer les perfs, cela a eu aussi un impact positifs sur les autres metrics de Lighthouse (SEO, Accessibilité, et Bonnes pratiques). N'hésitez pas à compléter ou poser des questions si besoin. Merci d'avoir lu ! ❤️