Comment améliorer la vitesse de chargement de vos pages Web sur tous les appareils ? Voilà la question que se posent de nombreux propriétaires et éditeurs de sites voire d’agences notamment la notre.

Page Speed Insights est là pour nous aider. Cet outil proposé par Google himself nous fournit des indications de temps de chargement et téléchargement ainsi que des indications pour corriger le tir le cas échéant.

Notes de Page Speed Insights

Google nous fournit 2 notes : une pour mobile, une pour PC.

La note mobile est celle à prendre en compte pour l’aspect SEO, Google se comportant comme un smartphone lors de son passage sur votre site.

Vous pouvez également utiliser Lighthouse de Google Chrome qui vous donne des notes similaires.

En fonction de l’audience de votre site, Page Speed vous fait remonter des data utilisateur par rapport aux data similées ici « en laboratoire ».

Parlons des perfs sur Desktop : c’est très facile d’avoir 90+ dessus, donc inutile d’en parler.

Si vous avez 90+ sur mobile, vous aurez facile 99 sur Desktop.

Comment optimiser son temps de chargement ?

Plus bas, Page Speed donne quelques indications.

Il existe 2 types d’actions :
– celles qui prennent du temps
– celles qui se mettent en place très vite.

Parfois une action va nous faire gagner 1 ou 2 points, une autre + de 10 d’un coup.
Pour améliorer sensiblement le score, il faut optimiser tout ce qui peut l’être.

Ressources « bloquant le 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 convient de placer du Google Tag Manager, qui injecte du Google Analytics et autres scripts pour faire du tracking qui ralentissent le site.

Idem pour Google Recaptcha v3, éviter le spam.

Lighthouse et Page Speed Insight sont des services proposés par Google : c’est assez drôle de voir ces deux services mettre un warning sur d’autres services Google (reCaptcha, GTM etc..).

Réseaux

En cliquant sur « Consultez la carte proportionnelle, on se rend compte du poids de la page.

On est sur du 2mb de mémoire, je considère que c’est plutôt léger, on peut faire mieux mais c’est déjà bien.

Les scripts de tracking sont à basculer sur GTM et cela fera économiser de la ressource.

Images et cache

La page d’accueil est plutôt bien fournie en images.
Les 2mb correspondent au total des ressources téléchargées en scrollant jusqu’au footer (il y a déjà du lazy loading).

Pour le cache, oui il y en a un (WP Rocket). Le plugin est bien configuré, il met en cache, minifie et concatène le HTML, le CSS et le JS…

Bon.. voyons ce qu’on peut trouver d’autre.

Plugins, B.O. et PHP

Je vais regarder en BO les plugins front qui sont chargés.

Pas de builder ici (Pas d’Elementor ou WPBakery). Le soucis avec les builders, c’est qu’ils génèrent du code HTML lourd avec des div dans des div dans des div..

Un builder serait utilisé sur certaines pages. Cela vaudrait le coup de rebuild les templates avec du ACF.

Il faut aller voir ensuite dans le functions.php, dans header.php et dans footer.php quelles sont les ressources utilisées.

Il est possible alors de trouver :
– jQuery v3
– Slick pour les sliders
– Bootstrap 4 CSS et JS, popper.js (dépendance de Bootstrap)
– Font Awesome 5
– Leaflet

Ce sont des 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.

Actions à mener

1/Supprimer les bulder et rebuild les templates avec des beaux champs ACF (vive ce plugin).
Avec Gutenberg on a un système de colonnes et pleins de widgets.

2/Supprimer Font Awesome, à quoi bon charger une librairie de plusieurs milliers d’icônes si on en utilise 20.
En gros, il faut remplacer les balise <i class=”fa …”> par le code svg qui est directement dispo sur leur doc.

3/Supprimer Bootstrap s’il n’est pas utilisé et des librairies js non utilisées.
Il est possible d’enlever Boostrap pour importer seulement le bootstrap-grid.min.css qui fait 60kb.

4/Idem pour jQuery. Voir si des slider ne l’utilisent pas.

5/Pour les sliders, pourquoi ne pas utiliser Splide, une librairie de sliders qui est Lighthouse friendly. Cela ne me prend pas longtemps pour refaire les sliders.

Le code jQuery peut être réécrit en JS Vanilla. Le site peut n’utiliser que les sélecteurs $ et quelques fonctions, l’équivalent en JS Vanilla se trouve facilement. Exit donc jQuery ET le JS et CSS de Slick.

6/Pour Contact Form 7, 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. A voir si le site l’utilise.
Le code à mettre dans functions.php pour dequeue le CSS.

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.

Optimisation du blocage du rendu

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

1/ Commençons par Google Fonts : voici 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

Voici quelques 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.

2/ Mettre un defer sur certains scripts, cela peut casser certains éléments de la page (carte Leaflet), attention.

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

Avec defer, le navigateur attend d’avoir parser le HTML pour exécuter le script.

Peut-on 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 cela peut affecter les scripts qui sont injectés par GTM… L’idéal serait de se passer de GTM.

Dans les ressources bloquantes c’est surtout Google reCaptcha qui est long.

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 !

3/Le 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.

On peut prendre le CSS de la nav et des headers et tout mettre en CSS inline dans une balise <style> dans le head.
Boom +10 en perfs !

4- preconnect et dns prefectch

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. + 2 ou 3 points.

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/opti

5/ Images

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.

6/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.

7/ Tailles des images

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

8/ Poids excessif du DOM

Un warning vous dit également que le DOM est lourd ? Il faut passer sur tous les templates et les templates-parts pour enlever tout ce qui est inutile. Des class inutilisées peuvent rester par exemple.

Donc à supprimer tout ce qui peut l’être, parfois des imbrications de div inutiles. Idem pour le CSS en mettant la taille et la couleur de mes svg directement dans le markup HTML. Gain: 1 ou 2 points.

Voila pour améliorer les perfs : cela a un impact positif sur les autres metrics de Lighthouse (SEO, Accessibilité, et Bonnes pratiques).

N’hésitez pas à compléter ou poser des questions si besoin.