La vitesse de chargement et d’affichage des pages est un critère pris en compte par Google pour le référencement, et le positionnement des pages dans les résultats de son index. A quel point ? Bien évidemment, ça reste encore l’inconnue mais cela fait maintenant 1 an que Google considère la vitesse comme un “signal”. Mais vu la lourdeur de la plupart des sites qui conserve un excellent ranking, ce critère représente sans doute une priorité très faible pour le moteur.
Néanmoins, en début d’année 2011, Matt Cutts en a reparlé lors d’une brève vidéo. A mon humble avis, ce n’est pas en 2011 que la donne va changer pour ce critère. En 2012 ? Pas forcément non plus. En 2013 ? Qui sait…
Quoiqu’il en soit, je pense que la donne va forcément changer à un moment ou à un autre car ce point a un impact sur l’expérience utilisateur. D’ailleurs, ces fameux utilisateurs deviennent de plus en plus exigeant puisque selon un sondage effectué pour des sites d’achats en ligne, 47% pense qu’un site doit se charger en 2 secondes ou moins et environ 47% pense quitter le site si le temps d’attente dépasse les 3 secondes. Bref, nous sommes de plus en plus impatients et cela ne vas pas aller en s’arrangeant avec le temps !
Lors d’une présentation de leur site et de leur performance, Wikia a montré un autre exemple qui illustre le taux de sortie à travers une slide de leur présentation.
La patience est une vertu mais tout le monde n’arrive pas à l’appliquer aussi facilement. Si la vitesse de chargement de vos sites est importante pour vos utilisateurs, elle reste également prise en compte par Google dans son algorithme. Ainsi, je considère qu’il faut travailler sur l’optimisation de la vitesse de votre site en tâche de fond, parallèlement aux autres efforts fournis en SEO.
1) Les outils
Tout d’abord, il vous faut des outils pour mesurer les performances de chargement de vos pages. En voici quelques uns :
- Le service Pingdom propose un outil de test de performance qui s’applique à la page racine du domaine. Gratuit et efficace !
- Webpagetestest un autre service gratuit qui vous montre les performances de votre site web sous différents navigateurs : assez complet aussi.
- Le plugin Pagespeed qui se greffe à Firebug est également un plus, même si les conseils affichés restent trop génériques à mon sens.
- Yslow, plugin Yahoo qui se greffe lui aussi à Firebug vous aide à mesurer les performances de vos pages web.
2) Les points à traiter pour l’amélioration des performances de vos pages web
- Appeler les images depuis un domaine externe (ça peut très bien être un site de type flickr ou smugmug).
- Redimensionner les images avant de les mettre en ligne (et pas le contraire qui donne souvent des images super lourdes qu’on ne voit qu’un pauvre 30×30 pixels à l’écran) : bien souvent les images représentent 30 à 50% du poids total de votre page.
- Choisir le format de l’image (GIF si on traite une illustration avec peu de couleurs, JPEG pour les images avec pas mal de détails, comme les photos et enfin PNG si on souhaite garder une excellente qualité des transparents) : je vous invite à lire ce guide plutôt complet sur l’utilisation d’images pour le web.
- Compresser le javascript et les CSS : la compression GZIP ne devrait pas vous être inconnue. En possédant le mod_gzip sur son serveur, il est possible de réduire la taille des fichiers javascript de plus de 70%. On gagne ainsi beaucoup dans le chargement des pages.
- Supprimer les espaces blanc inutiles dans le code : ça rajoute du poids pour rien dans la page et même si c’est chiant à faire, au final, n’importe quel développeur ou webmaster sera content de parcourir le code source.
- Appeler la CSS en haut de page : le chargement du style se fait ainsi plus rapidement sans casser la validation W3C.
- Appeler les scripts en bas de page, juste avant le </body> : l’intérêt de ce placement est de ne pas ralentir le chargement du cœur de la page.
- Externaliser le Javascript et la CSS : ça paraît basique mais je m’amuse encore à le faire sur la plupart des sites clients.
- Minimiser le nombre de redirections 301 : je sais, on en a besoin pour le SEO et c’est très bien de les utiliser. Faut juste faire comprendre à votre entourage qu’il faut pas en abuser car déjà 1)ça ne transmet pas toutes les performances accumulées et 2)ça ralentit les performances du serveur.
- Mettre les pages en cache quand cela est possible : réduire les requêtes faites à la base de données et accélérer le rendu visuel des pages. Beaucoup de CMS propose même des plugins pour faire ça facilement.
- Investir dans un hébergement récent : vous pouvez aller chez Bob pour héberger votre site en mutualisé avec 359 autre pour 3$/mois mais à ce moment-là, pas la peine de s’attendre à des miracles côté performances.
- Mettre les pages statiques en HTML : certes, votre site est dynamique mais il y a toujours certaines pages qui ne changent pratiquement jamais (Contact, Mentions légales, A propos). Si le gain de performance est minime, il est bel et bien présent si la page est statique.
- Configurer la gestion de mémoire du serveur : si ça reste trop technique pour moi à expliquer, ça signifie en gros qu’il faut faire en sorte d’éviter que votre serveur tombe si 200 utilisateurs se connecte au même moment. Demandez à quelqu’un de vous aider si vous n’êtes pas pro dans le domaine. Moi, je passe par Spamy, un excellent administrateur système… Et vous ? (je précise que c’est un ami, pas un service et non, je ne lui ai pas encore demandé son aide pour le blog Ramenos :) ).
- Si vous êtes sous Apache, chargez uniquement les modules nécessaires : ça sera toujours plus rapide que de laisser la configuration par défaut.
- Si vous êtes sous IIS, optimisez-le également : pour cela, vous pouvez vous aider de cette page.
Cette liste de tâches est bien sur non-exhaustive et si vous travaillez en entreprise et toujours pour les mêmes sites, je vous recommande fortement de sensibiliser l’équipe de développement sur sur tout ce qui touche à la vitesse de chargement des pages.
Normalement, ils doivent déjà être concernés par le problème (je l’espère pour vous) mais en remettre une couche avec l’argument seo ne peut pas faire de mal. Si vous souhaitez avoir d’autres informations supplémentaires, je vous invite à lire cette présentation sur les performances web.
De toute façon, je n’ai encore jamais entendu quelqu’un me dire “mon site s’affiche vraiment trop vite” ! Et encore une fois, même si l’impact seo est minime à ce jour, vous rendrez vos visiteurs heureux !
Bravo, article très complet même si certains point amélioreront la rapidité d’affichage mais ne changeront rien au poids de la page… :p
Pour les outils, il y a aussi l’excellent GTMetrix qui a récemment reçu une énorme mise à jour qui fait de cet outil le meilleur après webpagetest.org (car il utilise Firefox)
Je me permet d’ajouter quelques proposition :
– Minimiser le nombre de requetes HTTP faites (le principe le plus simple et le plus évident)
– Utiliser des data-uri pour les images (technique qui encode les images en texte pour être mieux compressée)
– Utiliser un minificateur de HTML (à manipuler avec précaution tout de même mais cela peut être utile pour des sites ou le HTML est lourd)
– Utiliser nginx en lieu et place d’Apache ou IIS (le meilleur serveur web tout simplement)
– Utiliser un loader de JS lorsque l’on a beaucoup de JS (améliorer la rapidité de chargement de la page, le JS est chargé une fois la page terminée, je schématise mais en gros c’est ca)
Je pense qu’il existe d’autres choses auxquelles je n’ai pas pensé…
Bonjour,
“Appeler les images depuis un domaine externe (ça peut très bien être un site de type flickr ou smugmug).”
Je suis étonné, je pensais qu’appeler des images externe ralentissait justement le chargement de celle-ci? Certes, ça diminue certainement le poids de la page, mais en terme d’affichage, ce n’est pas plus long?
@tous : à force d’écrire trop vite, j’ai oublié quelques mots à gauche à droite, c’est corrigé ! :)
@Antoine : j’ai répond à ta question directement dans le post.
Personnellement, je rajouterai deux choses :
– l’abandon des fonts en js passant par cufon etc, et redécouvrir font-face pour les css
-si il y a des images dans le menu ou autre, utiliser un sprite et économiser des appels http
Je me permet juste de rectifier un point sur la performance des pages, il faut distinguer 2 points, le chargement coté utilisateur et le chargement des pages coté robots.
Pour le chargement coté utilisateur c’est effectivement un critère de positionnement assez récent dans l’algorithme de google et qui serait assez minime pour l’instant. On peux parler également des effets indirects sur l’éxpérience utilisateur (pages vues, tux de rebond,etc..) que tu soulignes également et qui est un point qui est pris en compte dans l’algo de google également meme si en parle pas encore assez.
Mais le point le plus important, c’est le chargement des pages par les robots. Un site plus rapide à charger par google verra plus de pages crawlées, donc potentiellement plus de pages indéxées et au final qui peuvent générées du trafic.
C’est d’autant plus vrai pour des sites à gros volumes, où même une légère amélioration du chargement des pages peux avoir un effet important.
Voila, je tenais à préciser ce point, et bravo pour ton blog que je suis régulièrement.
Excellent post, j’ai tout de suite mis en pratique sur mon site de béton ciré. J’ai aussi noté un chargement plus fluide en allegeant mon fichier d’entête. Je n’appelle les gros bouts de code que lorsqu’ils sont requis.
Parmi les outils à citer, il y a aussi le module Apache Pagespeed (édité aussi par Google), et qui permet d’automatiser certaines règles d’optimisation : entêtes d’expiration sur les fichiers CSS/JS/images, concaténation et minification, …
Bonjour,
En lisant ce billet j’étais surprise que vous disiez que la vitesse n’a pas encore d’effet, alors que j’ai constaté le contraire… que serge esteves expliquer très bien c’est exactement ce que je constate sur mon blog, comme si google “redécouvrait” certaines parts “oubliées”.
Mais une question sup : dans webmaster google ils ont une vitesse, dans pingdom une autre plus rapide, sur mon navigateur encore une autre, et pagespeed et yslow … alors à qui se fier ? à un mix du tout ?
On m’avait dit que wbgg faisait un mixte de vitesse sur différents navigateur. Mais étant mac impossible de savoir ce qui se passe avec ie…
autre point sur les images chargées depuis flikr et autre, le problème est que ça envoie les gens sur ces sites, et on perd nos visiteurs pour définitif en général. J’ai tout rapatrié chez moi depuis un bail à cause de ça.
Des tests ont montré que placer Nginx en proxy à Apache était le couple le plus performant à l’heure actuelle… NginX étant spécialisé dans le service de fichiers statiques, et Apache dans celui de fichiers dynamiques.
Pour le cache, utiliser au maximum du cache mémoire distribué style Memcached, pour ne pas avoir à regénérer de cache sur un autre serveur pour la même page, mettre les sessions en Memcached
Il faut servir les images sur des sous domaines sur lesquels vous ne placez aucun cookie (un cookie, dans une requête demandant une image, prend des bytes pour rien !)
Il faut également obtenir un maximum de 304, NginX est très doué pour cela, aussi n’oubliez pas générer un cache fichier pour vos css et js, leur contenu devant être spécifique à la page en cours afin de ne pas loader de règles inutiles. Bien entendu, un seul fichier css et un seul fichier js par page, minimisés (le html aussi est à minifier).
Le Gzip est important, NginX est doué pour cela, mais n’oubliez pas le json si vous faites beaucoup d’AJAX. Attention à faire correspondre EXACTEMENT les mymetypes de NginX et d’Apache (application/javascript != application/x-javacript)
Pour les scripts en bas de page, utilisez l’attribut async=’async’ pour minimiser le blocage et taper un score Google Page Speed de +95% et sub seconde (Je pointe à 98% – 895 ms sur un projet perso de site de rencontre particulièrement graphique et AJAXé)