Comment rendre votre site web plus rapide (et plus éco-responsable!)

Identifier les pages lentes

La première chose à toujours garder à l'esprit est qu'environ 60% du trafic sur internet se fait via un appareil mobile. En 2015, ce chiffre n'était que de 30 %. Et les utilisateurs qui naviguent via des appareils mobiles le font avec moins de bande passante que les utilisateurs de bureau. Autrement dit, leur expérience est plus lente.

C’est la raison pour laquelle nous allons nous concentrer principalement sur l'expérience mobile. Et puis vous savez quoi : si ça se charge vite sur mobile, ça se chargera encore plus vite sur desktop.

**C'est mon conseil numéro 1 : Concentrez-vous sur la vitesse mobile. **

Maintenant, comment identifier les pages qui doivent être optimisées ?

Pour une vue d'ensemble, j'utilise “Google Search Console”.

Dans cet outil il y a une section "expérience", sur la gauche. Dans celle-ci nous avons les "Core Web Vitals". Elle nous indique quelle experience les utilisateurs on eu sur nos pages Web sur les appareils mobiles et les ordinateurs, grâce aux données fournies par les navigateurs des utilisateurs. Cela nous montre donc les pages qui posent le plus de problèmes.

Maintenant, comment faire pour identifier les problèmes sur des pages spécifiques ?

Ouvrons le rapport sur les mobiles. Nous voyons une liste de problèmes de pages. Cet exemple mentionne un problème "CLS" et un problème "LCP". De quoi s'agit-il ?

Le CLS est le "Content Layout Shift". Il mesure dans quelle mesure la mise en page de votre page change pendant son chargement.

Le LCP signifie "Largest Contentful paint". Il s'agit du temps nécessaire pour que l'élément le plus grand soit affiché à l'écran.

Maintenant, comment identifier les problèmes sur une page donnée ?

Pour cela, nous allons utiliser un autre outil : "Page Speed Insights".

Dans la Search Console, si nous cliquons sur le groupe, ici, puis sur une URL ici, nous obtenons une fenêtre contextuelle où le dernier élément est "Page Speed Insights". Cela ouvre l'outil pour cette URL.

Nous pouvons, bien sûr, exécuter l'outil Page Speed Insights directement pour une page donnée. ET pendant que nous y sommes, l’outil Lighthouse de Chrome donne des indications similaires

Que peut nous apprendre la page Page Speed Insights ?

La première chose que nous voyons, ce sont 6 métriques.

Ce sont les valeurs que nos utilisateurs expérimentent en pratique. Leurs navigateurs envoient les informations relatives à ce que ces "métriques de base" étaient lorsqu'ils ont chargé la page.

Nos amis les CLS et LCP sont là. Que sont les quatre autres ?

L'outil fournit une explication détaillée de chacune de ces métriques. Jetons un coup d'œil à la TTFB.

D'abord, le TTFB

Le TTFB, ou Time To First Byte, est crucial pour la vitesse de la page. Le TTFB est essentiellement le temps que prend le navigateur pour recevoir les données de la page.

Cette mesure est essentielle car elle a un impact sur toutes les autres mesures basées sur le temps. En gros, tout sauf le Cumulative Layout Shift.

Et la raison en est simple : Le navigateur ne peut pas commencer à réagir avant d'avoir reçu les informations du serveur. Il n'y a rien que vous puissiez faire côté client si le serveur met trop de temps à répondre.

Le conseil n ° 2 est donc : Faites en sorte que votre serveur réponde rapidement

Comment y parvenir ?

C'est un sujet à part entière. La réponse dépend très de la technologie du serveur et de ce que vous construisez. La plupart du temps — et c’est le cas pour nous — la réponse est triple :

• supprimer la logique et les requêtes inutiles
• optimiser les requêtes pour les rendre plus efficaces
• stocker des données dans le cache

Ce qu'il faut retenir ici, c'est que si votre serveur est lent, vous ne pouvez rien faire côté client pour accélérer le chargement de la page.

LCP

Examinons maintenant de plus près le “LCP” ou Largest Contentful Paint.

Il s'agit du temps nécessaire pour faire le rendu de l'élément le plus grand à l'écran. Google l'utilise pour mesurer le moment où l'utilisateur a l'impression que la page est en grande partie chargée.

Qu'est-ce qui détermine le LCP ?

Eh bien, lorsque le navigateur reçoit la page (au moment du TTFB, donc), il doit ensuite lire tout le contenu de la page, le HTML. Ensuite, il interprète le HTML et télécharge les images, les feuilles de style et les scripts. Et enfin, il évalue les scripts. Pour finir, il les exécute.

Pour une simple page HTML, le LCP se produit lorsque la plus grande image est téléchargée et affichée.

Si vous effectuez un rendu côté client, par exemple avec React, le chemin critique est plus long. Le JavaScript doit être interprété et exécuté, puis toutes les images doivent être téléchargées et affichées. C'est pourquoi React est mauvais pour le SEO, et pourquoi des solutions comme Next JS existent.

Ce qui m'amène au conseil n ° 3 : Utilisez les applications côté client avec parcimonie.

A présent: Comment savoir ce qu'il faut améliorer ?

Eh bien, la bonne nouvelle est que le travail a déjà été fait pour nous. Page Speed Insights vous donne toute une série d'indications sur la manière de résoudre les problèmes.

Les indications exactes dépendront, bien sûr, de la page et de la façon dont elle a été codée. Mais voici quelques-unes des choses que nous avons mises en place en fonction des problèmes que nous avons vus.

Quoi faire ?

Il y a plusieurs choses à faire. Je vais aller des conseils les plus généraux aux plus spécifiques.

Et la première chose que vous pouvez faire, et c'est mon **conseil numéro 4: être minimaliste. ** Supprimez les choses inutiles. Limitez le nombre de polices que vous utilisez. Ne chargez pas des choses inutiles. N’utilisez pas le Font Awesome ou les Material Design icons juste pour afficher quelques images.

Ne chargez pas non plus de grosses bibliothèques de script comme jQuery ou React lorsque vous pouvez utiliser du JavaScript classique. De notre côté, on utilisait Bootstrap 4, et on a donc des bouts de jQuery un peu partout. On vient de terminer la migration vers Bootstrap 5 (qui ne dépend pas de jQuery), et on va maintenant travailler à la suppression de tout le jQuery.

D'ailleurs, la règle du minimalisme peut servir partout — que ce soit au moment de la conception ou du code serveur.

On a supprimé du code qui n'est plus appelé, des champs des la base de données qui sont devenus obsolètes. On a passé en revue nos pages pour supprimer tous les bouts de code qui ne sont plus utilisés.

On a pour but de n’inclure que ce qui sert les besoins de votre utilisateur. Un contenu hyper interactive ca peut flatter l’égo. Mais si cela nuit à la vitesse de chargement et détourne les gens c’est contre productif. Les objectifs de nos pages web sont plus importants que nos egos.

Alors supprimez le contenu futile. N'obligez pas l'utilisateur à télécharger des trucs inutiles. Et cela m'amène à notre prochain point.

**Conseil n ° 4 : Précisez aux navigateurs ce qu'ils n'ont pas besoin de télécharger à nouveau. ** Lorsque vous fournissez du contenu aux utilisateurs, vous pouvez configurer vos serveurs pour qu'ils ajoutent des informations aux fichiers indiquant qu’il est “inutile de télécharger à nouveau ce fichier si vous l'avez déjà en mémoire. Vous pouvez le garder pendant au moins un an”. Cette mémoire du navigateur est appelée le cache, et la valeur de l'en-tête permettant de définir la durée est le champ "Cache-Content".

Conseil n ° 5 : utilisez le chargement différé ou “lazy” L'autre moyen de limiter ce que les utilisateurs téléchargent est de dire au navigateur de ne charger le contenu que si l'utilisateur est sur le point de le voir. La plupart des utilisateurs ne regardent que le tiers supérieur de la page. Il n'y a vraiment aucun intérêt à charger une image tout en bas de la page. C'est ce qu'on appelle le "chargement différé” ou lazy.

Autrefois, il n'y avait pas de moyen simple le faire. Il fallait utiliser le plugin d'une bibliothèque javascript appelée jQuery. Aujourd’hui 92% des navigateurs supportent le chargement différé de manière native.

Et pour ça il suffit d'ajouter loading="lazy" sur les images qui ne sont pas tout en haut d’une page. Le navigateur ne chargera alors l'image que si l'utilisateur la fait défiler vers le bas.

Maintenant, sur 74% des navigateurs, cette directive fonctionne également sur les “iframes”. Les iframes sont un moyen d'intégrer le contenu d’autres sites Web sur le vôtre. Lorsque vous copiez le code d'intégration d'une vidéo Youtube, il s'agit en fait d'une iframe. Et cet iframe charge environ 250 kilooctets de données. C’est plus lourd que beaucoup d’images.

Il y a donc une solution rapide qui consiste à ajouter loading="lazy" au code de l'iframe. Mais il existe une solution encore meilleure.

Conseil n°6 : Charger les iframes à la demande

Ce que nous avons fait est plus complexe mais aussi plus efficace et plus largement pris en charge. Au lieu d'intégrer l'iframe de Youtube, nous ne montrons que la vignette. Ensuite, nous avons ajouté du code JavaScript pour intégrer la iframe dans la page lorsque les internautes cliquent sur la vignette. De cette façon, nous ne chargeons l’iframe que pour les personnes qui l'ont effectivement demandée.

Les images sont une autre source de lenteur. Et d'après mon expérience, les graphistes ne cherchent pas toujours à maintenir une taille de fichier aussi faible que possible.

Ici, il y a plusieurs choses que vous pouvez faire.

Conseil n ° 7 : Préférez les fichiers SVG.

Premièrement : Pour les illustrations et les icônes, utilisez des fichiers SVG plutôt que des formats bitmap comme JPG ou PNG. En effet, les SVG sont un format vectoriel. Au lieu de stocker la valeur de chaque pixel, ils stockent l'information selon laquelle, par exemple, une ligne doit être tracée du point a au point b. Moins d'informations signifie des fichiers plus légers et plus rapides à transférer.

Conseil n ° 8 : Utilisez des images réactives

Le deuxième point est d'avoir à l'esprit la taille d'écran de vos utilisateurs. Il n’y a qu’1 % des utilisateurs sur desktop qui ont des écrans plus larges que 1920 pixels... et la plupart des utilisateurs sont sur des mobiles dont la largeur est comprise entre 360 et 440 pixels.

Si une image ne remplit que la moitié de la largeur de l'écran pour l'utilisateur, inutile de fournir une image de 4000 pixels de large. Et oui, c'est un exemple de la vraie vie.

Mais cela soulève une question importante : comment répondre à la fois aux besoins des utilisateurs de petits écrans mobiles et à ceux des utilisateurs de très grands écrans ?

Heureusement, il existe une solution au sein même du HTML. Lorsque nous affichons une image, nous utilisons une balise appelée <img>, et définissons la source de l'image à l'aide de l'attribut "src".

Mais il se trouve qu’on peut également fournir un ensemble de sources. Pour ca il y a l'attribut "srcset".

En gros, on indique au navigateur : cette source a une largeur de 400 pixels, cette source a une largeur de 1000 pixels, cette source a une largeur de 2000 pixels. En fonction de la taille que le navigateur pense afficher l'image, il peut charger le fichier approprié.

En fait, nous sommes même allés un peu plus loin. Vous voyez que la balise <img> est destinée aux images ayant des proportions fixes. Donc, par exemple, des images rectangulaires. Sur notre site Web, l'image principale en haut de l'écran est rectangulaire. Mais sur un mobile, la plupart de cette image serait de l'espace perdu. Donc pour nous, il est plus logique de charger une image carrée sur un mobile.

Et pour cela, nous pouvons utiliser l'élément HTML <picture>. Celui-ci nous permet de définir un groupe d'images différentes. Nous pouvons ensuite indiquer dans quelles conditions le navigateur doit afficher telle ou telle image. Sur mobile, montrer une version carrée. Sur desktop, montrer une version rectangulaire.

Et nous avons même poussé les choses un peu plus loin.

Conseil n ° 9 : Utilisez des formats d'image modernes. Vous voyez, la plupart des sites Web servent des images aux formats JPEG ou PNG. Mais il existe deux nouveaux formats de fichier image qui compriment encore mieux que le JPEG. Ces formats de fichier sont WebP, qui a maintenant quelques années et qui est donc pris en charge par 97 % des navigateurs. Et AVIF qui est plus récent, plus efficace et supporté par 75% des navigateurs.

Nous utilisons un réseau de distribution de contenu (ou CDN) pour servir nos fichiers d'images. (Cela nous permet également de servir les fichiers plus rapidement, et de préciser la durée du cache).

Nous avons ajouté du code au CDN qui interprète l’information qu’envoie le navigateur. EN effet il précise de lui même les formats d'image qu'il accepte. Ainsi, par exemple, si le navigateur dit : "Je voudrais une image basée sur celle-ci, mais je la veux de 128 pixels de large, et je suis capable de lire les fichiers Jpeg et WebP mais pas AVIF". Sur le CDN, nous vérifions si le fichier reformaté aux bonnes dimensions existe déjà. S’il n'existe pas, on le crée, on l’enregistre et on le renvoie.

Je pense que les services CDN de CloudFlare vous permettent d'acheter un service similaire mais... De notre côté on a codé le nôtre. J'ai partagé l'article de blog que nous avons utilisé comme base pour notre code dans la description.

Conclusion

Maintenant, je ne veux pas que vous ayez l'impression qu’on a résolu tous les problèmes. De notre côté il nous reste encore pas mal de bibliothèques javascript tierces qu’on aimerait pouvoir supprimer. Par exemple le bouton de connexion Google charge à lui tout seule 250 kilo-octets de données.

En fait, cela peut être assez décourageant. Mais l'amélioration de la vitesse des pages est une situation gagnant/gagnant. Tant en termes d’efficacité des pages qu’on construit, que de réduction de nos coûts et de limitation de notre empreinte carbone.

Et si vous voulez faire encore plus pour la planète... eh bien vous avez le code promo dans la description !