Categories: Archives Jobprod.comVie de développeur

Analyser les performances de son site web : PageSpeed et Yslow

Bonjour à tous !

Dans la partie précédente, on a analysé son site web. Maintenant on va essayer de comprendre pourquoi c’est long !

NB : Je vais volontairement omettre tout ce qui concerne les images, il y a tellement à en dire là-dessus que je me réserve ça pour un chapitre complet 😉

Bon c’est parti, on ouvre gtmetrix et on analyse son site !

On remarque qu’il y a 2 onglets et 2 notes, PageSpeed et Yslow. On va déjà voir avec pagespeed.

PageSpeed

La partie pagespeed correspond plutôt au contenu de la page

  • Defer parsing of JavaScript: quand on charge une page qui contient du code Javascript, celui-ci est analysé et interprété dans l’ordre de lecture de la page : c’est-à-dire dans le code suivant le script sera analysé, chargé et interprété avant La solution serait de mettre tout le javascript en fin de page, mais ce n’est pas si simple quand on utilise un CMS, ou que l’on a besoin qu’un script charge très vite.

    <html><head> <title>Test</title> <script>Script</script> </head> <body></body> </html>

    A éviter, faire plutôt

    <html> <head> <title>Test</title></head> <body> Contenu <script>Script</script> </body> </html>

    (celà concerne aussi les scripts google analytics ou google maps qui appellent plein d’autres scripts/images sur la page…)

  • Specify a cache validator: c’est pas mal d’activer le cache si on veut que son site aille plus vite, le cache d’active grâce à l’ajout d’en têtes http, telles que Etag ou Expires. Attention cependant à ce que le cache soit bien mis à jour lorsque les objets appelés sont différents. Solution : activer le cache
  • Remove query strings from static resources : lorsqu’une ressource est chargée, si le cache est activé, cette ressource est mise en cache. Le fait qu’il y ait une query string dessus peut empêcher cette mise en cache. Solution: charger des ressources sans query string
  • Specify a Vary: Accept-Encoding header: il faut préciser le type d’encodage de la page HTML, sinon le serveur proxy doit la deviner tout seul. Solution : ajouter une balise <meta content= »text/html; charset=UTF-8″ http-equiv= »Content-Type »> le plus tôt possible dans la page
  • Optimize the order of styles and scripts : Le petit frère de defer parsing of javascript, si du javascript est chargé avant du css, le chargement du css est différé le temps de l’interprétation du javascript, ça peut faire des bugs d’affichage et ça ralentit le site. Solution : charger les javascripts après les css
  • Inline small CSS: Il est plus long de charger 80 fichiers css de 100 lignes que 8 css de 1000 lignes, et en plus on a 10 fois plus d’entêtes http à charger. Solution : concaténer les petits css, ou les mettre dans le <head>
  • Inline small Javascript: comme au-dessus, à part que Defer parsing of JavaScript est valable aussi. Donc éviter de mettre dans le <head>
  • Avoid CSS @import: vous connaissez @import url(‘styles.css’); Oubliez le, certains navigateurs bloquent la parallélisation des requêtes http quand @import est utilisé, et cela augmente le risque de voir des petits css (voir au dessus). Solution : ne pas utiliser @import, concaténer les css, charger les css dans des <link rel= »stylesheet » href= »… » />
  • Prefer asynchronous resources: Certaines ressources déclenchent l’appel à d’autres ressources, ou sont longues à charger. Lorque ces ressources ne sont pas nécessaires en début de page on peut les différer ou les rendre asynchrones. Solution : mettre les attributs defer ou async dans les scripts concernés, ou charger ces scripts avec un script DOM plus tard dans la page.
  • Enable gzip compression: vous connaissez la compression ? Les pièces jointes, elles sont moins lourdes en .zip qu’en fichier normal non ? Eh bien les pages web (javascript html et css) peuvent être aussi compressées grâce à Gzip. Cette option n’est pas toujours activée par défaut, et certains serveurs ne l’implémentent pas correctement (hello nginx plesk < 11.5 qui ne fait pas de gzip sur des sous dossiers). Toujours est-il que cette option peut être activée via htaccess (et surement d’autres moyens mais j’ai pas encore tâté de serveurs IIS). Activer Gzip sera la méthode la plus efficace pour optimiser votre site, puisque gzip minifie également vos fichiers.
  • Minimize redirects : Vous savez ce que c’est qu’une redirection ? En gros on redirige une page vers une autre. Parfois cette autre page est redirigée vers une autre page et ainsi de suite (redirectception). A chaque redirection : une perte de temps. Solution : mettez directement l’adresse en fin de redirection
  • Minify CSS / JavaScript : assez simple à mettre en place (surtout avec Gzip), il est possible de retirer tous les espaces/sauts de ligne/commentaires de ces fichiers pour réduire leur poids, et donc accélérer leur téléchargement. De nombreux logiciels le font très bien ! A noter qu’il peut être utile de garder les versions non minifiées pour le développement.
  • Serve ressources from a consistent URL : En gros, il est plus rapide de chercher 20 ressources sur un seul et unique serveur, que de chercher 20 ressources sur 20 serveurs. Surtout si l’un des serveurs n’applique pas de cache ou est un peu encombré. Solution : internaliser les ressources le plus possible.

YSLOW

La partie Yslow se réfère plutôt aux performances du serveur Web, certains éléments font doublon avec Pagespeed et je ne m’attarderai pas trop dessus

  • Make fewer HTTP requests : Pour chaque requête http, un entête est envoyé. Cet entête http a un poids. En réduisant le nombre de requêtes http on diminue le poids des requêtes HTTP. D’où l’importance de concaténer au maximum ses fichiers de sources. En effet si tous les fichiers Javascript sont regroupés en un seul, on a qu’un seul entête. Si en plus ce fichier est minifié, gzippé, sans query string et sur le même serveur que le reste de la page, ben ça c’est cool et ça nous fait 6 points de vérifications de faits d’un coup ! Solution : concaténer les fichiers .js .css et spriter les images
  • Use a CDN : Si votre site est consulté partout dans le monde, ou si votre serveur se trouve assez loin géographiquement du pays principal d’utilisation, cette solution peut être intéressante pour réduire les temps de chargement en diminuant la distance géographique entre les utilisateurs et le serveur. Un site dont les donnés doivent passer par (dessus ou dessous) l’Atlantique sera toujours plus long à charger qu’un site dont les données sont sur un serveur à 200km de chez soi. Un CDN permet de délivrer les données à partir de différents endroits dans le monde. Bon par contre c’est pas gratuit, et c’est pas très adapté si votre cible est très locale. Solution : utiliser un CDN
  • Avoid CSS expressions : Les expressions CSS permettaient de mettre du Javascript dans la feuille CSS. En plus de problèmes d’adaptation sur les navigateurs, les expressions CSS sont très lourdes à interpréter pour les navigateurs. Solution : à éviter (comme la peste)
  • Avoid empty src or href : Des liens ou des sources vides (en plus de faire des bugs graphiques et de plomber votre SEO) sont aussi une source de ralentissement lors de la génération d’une page. Solution : bien vérifier ses pages et remplir les propriétés vides
  • Remove duplicate Javascript and CSS : bon ça veut tout dire, si on charge 2 fois le même truc, ben c’est pas terrible.
  • Avoid HTTP 404 : Charger une 404, en plus de potentiellement faire planter le style ou les scripts de votre page fait ralentir le chargement de la page. Solution : corriger ou supprimer les liens, ou sources mort(e)s sur la page.

Bon c’est fini pour le moment ! Les images arriveront par la suite ! Bonnes optimisations à tous

 

Thibault Poisson

Leave a Comment
Share
Published by
Thibault Poisson
10 ans ago

Recent Posts

On accueille le nouveau CTO 🎉

Un nouveau capitaine technique débarque à la barre de WeLoveDevs ! Après le rachat par…

3 jours ago

AI Act for Developers : comprendre les 5 niveaux de risques

L’AI Act pour les développeurs, c’est la première loi vraiment impactante depuis le RGPD. Et…

1 semaine ago

Angular, mais en mode « easy » : interview avec Gaetan Redin.

"Venez, faites le module 1 et on en reparle." C’est le défi lancé par Gaetan…

2 semaines ago

OWASP Top 10 : 10 erreurs que les développeurs web font tous les jours (et comment les éviter)

L’OWASP Top 10, c’est un outil pour les développeurs web. Et pourtant, il est largement…

3 semaines ago

RGPD pour les développeurs : coder la confiance avant tout.

Dans cet article, on va parler du RGPD pour les développeurs. C’est un sujet que…

1 mois ago

Monolithe vs Microservices : comment choisir la bonne architecture pour votre application ?

En 2025, le débat monolithe vs microservices n’est toujours pas tranché. Faut-il garder une architecture…

1 mois ago