Comment utiliser Google Page Speed pour améliorer la vitesse de son site ?

Vitesse… Rapidité… Des mots que l’on entendait avant pour évoquer l’expérience utilisateur sur les sites web. Notamment pour insister sur une constatation : un site e-commerce lent pousse à l’abandon de panier. Mais depuis quelques temps, ce ne sont plus seulement chez les marketeux que l’on entend prononcer ces mots. Les référenceurs s’y mettent, avec plus ou moins de bonheur et plus ou moins de sérieux.

Vitesse = crawl en hausse

Observons deux graphiques sortis de Webmaster Tools, pour deux sites différentes sur lesquels des efforts ont été fait pour améliorer la vitesse de chargement.

On voit que lorsque le temps passé à télécharger les pages diminue, le nombre de kb téléchargés et le nombre de pages crawlées augmente.

Même phénomène sur ce deuxième graphique : si on veut avoir plus de crawl, avoir plus de pages indexées (ou remises à jours), il semble empiriquement important d’avoir un site rapide.
Bien entendu, ce n’est pas la seule façon d’augmenter le crawl d’un site (faire de l’actualité, ça aide beaucoup, par exemple).

La vitesse, c’est l’indexation

Mais en tout cas, la vitesse est un facteur important pour augmenter le crawl de Google sur un site. Donc, quelque part, améliorer l’indexation. Est-ce que la vitesse est important pour le positionnement ? C’est une autre histoire que personne n’a encore réussi à élucider de façon certaine.
Pour un site d’actualité, c’est sûr, le crawl est important : si les nouvelles pages ne sont pas indexées en quelques minutes, les informations ne seront pas visibles assez rapidement dans Google… Pour un site qui change son contenu une fois par an, c’est une autre histoire…

Mais on peut parier que de toute façon ce sera un enjeu important de 2013, parce qu’à force de vouloir trouver de nouveaux critères pour alimenter les filtres de son algorithme, Google va bien finir par être obligé de chercher de nouveaux paramètres représentatifs de la qualité, et vu la taille de son index, le moteur de recherche pourrait se permettre de tailler dans le gras, sans prendre en compte les dégâts collatéraux.

Google raisonne-t-il vitesse pour classer les sites ?

• Ton site est trop lent ? Je le déclasse et je dirige vers un autre site.
• Tu avais du contenu pertinent ? Peut-être, mais vu le volume de sites que j’indexe, je parie qu’un autre site a du contenu tout aussi pertinent. Et comme il est plus rapide, je préfère autant que mes utilisateurs aillent voir celui-ci.
• Je vais me tromper parfois, proposer des choses moins intéressantes dans certains cas. Peut-être, mais encore une fois, j’améliore ton expérience utilisateur. Tu me dis merci et tu vas modifier ton site si tu veux revenir en tête.

Le scénario est caricatural ? Peut-être pas. De la même façon qu’un Pingouin ou un Panda touche parfois des sites qui n’ont rien fait de “mal” (en tout cas, pas volontairement), on pourrait très bien avoir un arbitrage fort sur la vitesse. Après tout, il y a toujours un site pour en remplacer un autre… C’est la loi de la jungle, et en cela, Google a raison de faire appel à un imaginaire animalier. Même si c’est plutôt Bienvenue chez les Bisounours dans la sémantique…

Google, une énorme machine… qui coûte chère.

De façon plus prosaïque, Google a tout intérêt à inciter à rendre le web rapide. C’est un boulot énorme de crawler tout le web, et si les sites sont lourds, c’est encore plus énoooorme. L’infrastructure technique coûte chère, et le moindre centième de secondes gagnés sur l’ensemble des sites web provoque une baisse significative des besoins techniques.

Le seul réel obstacle à un positionnement absolu sur la vitesse à site équivalent, c’est si un site en particulier se mettait à être à la fois bon et très rapide. On se retrouverait alors quelques années en arrière, quand Wikipedia sortait premier sur toutes les recherches. Google peut favoriser les bons élèves, il a tout intérêt à le faire, mais il doit en même temps garder sur les bancs de ses premiers rangs assez d’élèves pour pouvoir justifier de l’intérêt de passer par ses services.

Quoiqu’il en soit, pour optimiser la vitesse de chargement d’un site web, il y a de nombreuses petites choses à connaître et à appliquer. Beaucoup sont assez faciles à mettre en place. Alors pourquoi se priver ? En plus, cela soulagera votre serveur, ce qui permettra d’accueillir plus de visiteurs sans en changer…

On référence avant tout pour Google, donc on va avant tout s’intéresser aux bonnes pratiques que Google diffuse concernant l’optimisation de la vitesse des sites web.

Google demande. Google aide.

Ce qui est merveilleux, c’est que Google fournit un audit en ligne, rapide et automatique pour détecter les défaillances : https://developers.google.com/speed/pagespeed/insights.
Il n’est bien sûr pas totalement complet, il y a (beaucoup) d’autres astuces et bonnes pratiques pour améliorer la vitesse de chargement d’un site. Mais, malgré tout, c’est déjà une très bonne piste.

En indiquant une URL, vous obtenez un score sur 100, avec une liste des choses à corriger, par ordre de priorité.

31 Bonnes pratique pour optimiser son site web pour la vitesse

Google, à l’heure actuelle, a 31 bonnes pratiques dans ses tiroirs :

1. Avoid bad requests
2. Avoid CSS @import
3. Avoid CSS expressions
4. Avoid document.write
5. Combine external CSS
6. Combine external JavaScript
7. Combine images using CSS sprites
8. Defer loading of JavaScript
9. Defer parsing of JavaScript
10. Enable compression
11. Leverage browser caching
12. Leverage proxy caching
13. Make landing page redirects cacheable
14. Minify CSS
15. Minify HTML
16. Minify JavaScript
17. Minimize request size
18. Minimize DNS lookups
19. Minimize redirects
20. Optimize images
21. Optimize the order of styles and scripts
22. Parallelize downloads across hostnames
23. Prefer asynchronous resources
24. Put CSS in the document head
25. Remove unused CSS
26. Serve resources from a consistent URL
27. Serve scaled images
28. Serve static content from a cookieless domain
29. Specify a character set
30. Specify image dimensions
31. Use efficient CSS selectors

Nous allons en détailler quelques unes dès à présent.

Optimisations Page Speed : Avoid Bad Request

Avoid Bad Request dans la langue de Molière, c’est “éviter les requêtes incorrectes”.C’est à dire qu’il faut éviter de faire appel à des éléments qui n’existent pas ou plus. Un code d’erreur 404 ou 410 n’est pas une bonne chose, ou tout du moins, il faut faire en sorte que tout morceau de code qui mène à une telle page d’erreur soit supprimé ou modifié pour amener sur une page valide.

Cela se comprend pour deux raisons :

1. Pour la vitesse ! En effet, pour savoir qu’un élément n’existe plus, le navigateur doit l’interroger, ainsi que le serveur. On a une demande faite de façon inutile au serveur. Pourquoi générer des requêtes http inutiles ? Moins on interroge un serveur, plus il répond rapidement.
2. Pour l’ergonomie ! Tomber sur des pages n’existant pas ou plus, ne pas pouvoir afficher correctement une page parce qu’il manque un CSS, un Javascript, etc. C’est une mauvaise expérience utilisateur. Et si on va plus loin, c’est un indice de mauvaise qualité d’un site.
   Honnêtement, si vous étiez un moteur de recherche, vous garderiez dans votre index un site qui semble bugger à tout va ou diriger dans le vide ?

Pour résoudre ce problème de ressources n’existant plus, il suffit d’éditer le code source pour modifier les liens. Parfois il faudra créer des pages alternatives ou rediriger via une 301 vers une page à la thématique très proche (pour respecter la continuité sémantique).

Si on est confronté à des pages qu’on ne peut pas remplacer par d’autres, alors on pourra garder une 404, supprimer tous les liens pointant vers ces pages, et demander à Google de désindexer les pages concernées (via GWT)

Pour récupérer la liste des liens en erreurs, rien de mieux que de faire un crawl intégral du site ou de consulter les logs d’apache, voire d’utiliser Google Webmaster Tools.

En pratique, on peut utiliser Screaming Frog SEO Spider pour récupérer la liste des ressources posant problème. Ou bien encore utiliser SeeUrank.

Avoid Bad Request est bien plus qu’une façon d’éviter de ralentir un site sans raison, c’est avant tout représentatif du minimum d’effort que doit faire un webmaster pour garder son site en état de marche.

Normalement, si vous suivez bien la vie de votre site, il y aura peut de choses à corriger. Et je vous le souhaite car c’est une tache fastidieuse !

Optimisations Page Speed : Avoid CSS @import

Pour resituer le contexte, je rappelle qu’il y plusieurs façon de charger des feuilles de style CSS.
Celle la plus utilisée est la plus efficace, et consiste à placer un link rel stylesheet dans le header de la page html :

Mais il existe une autre façon de faire, en utilisant @import :
@import url('style2.css');
Le hic c’est que dans ce dernier cas, on a tendance à placer le @import à l’intérieur de la feuille de style qu’on charge avec la première méthode. Du coup, le navigateur doit télécharger style1.css avant de repérer les instructions de chargement de style2.css.

Si on feinte et qu’on utilise deux imports sur la même page html, entre les balises style :
@import url('style1.css');
@import url('style2.css');
les téléchargements se font de façon parallèle. Mais si on reproduit la chose avec davantage d’import, ça devient aléatoire.

Conclusion évidente : il faut mettre @import à la poubelle. Ne jamais l’utiliser. Toujours préférer le link href, et si possible en n’en ayant qu’un seul pour éviter de trop nombreuses requêtes http. Mais c’est une autre histoire !

Optimisations PageSpeed : Avoid document.write

Aujourd’hui, direction le joli monde du document.write. Ca vous rappelle sans doute quelque chose, non ? On le voit régulièrement utilisé pour faire de l’insertion de scripts de publicités.

Ainsi, une utilisation “classique” sera de la forme :

document.write('');

Si on traduit ça, et ce n’est vraiment pas compliqué, l’instruction document.write va insérer dans le corps du document le code , c’est à dire un chargement de script externe à la page.

Imaginons maintenant que ce document.write soit lui-même contenu dans un fichier JS externe. Que se passe-t-il alors ? Le navigateur commence à charger le premier fichier, puis seulement une fois ledit fichier récupéré, la seconde ressource est téléchargée. Le chargement est donc sérialisé, l’un intervient seulement après l’autre.

Si on n’utilise pas de document.write, le navigateur aura toute les chances de faire le chargement des ressources en parallèle, ce qui accroit la vitesse de rendu de la page.

Alors, n’hésitons-plus, et n’utilisons plus document.write, en tout cas pas sans réfléchir aux conséquences parfois désastreuses que cela peut avoir sur le temps de chargement.

Si on utilise document.write pour provoquer une intervention visuelle sur une page, il faut d’autant plus y faire attention.

En attendant, avoir document.write doit figurer en bonne place sur la liste des critères à prendre en compte pour optimiser une page web.

Optimisations PageSpeed : Combine external Javascript

Mais pourquoi Google recommande-t-il de combiner les ressources Javacript externes (ou dans la langue de Shakespeare : combine external Javascript) ?

Quand on fait plusieurs appels à des ressources JS externes, le navigateur doit faire des requêtes http pour chacune. Ces requêtes sont génératrices de délais, les adresses devant être résolues à chaque fois.

En combinant les ressources externes dans un seul fichier, on réduit sensiblement le délai de résolution, ce qui permet généralement d’accroitre fortement la vitesse de chargement du site.

Si le concept de gain est simple à appréhender dans ce cas, il doit cependant être combiné à un test : doit-on vraiment placer tous les JS dans un seul fichier externe, ou bien faut-il en faire deux, le premier contenant tout le JS nécessaire au bon affichage de la page, et le second contenant les scripts JS s’exécutant après le chargement de la page ?

L’arbitrage se fait de façon très lucide : on teste les deux solutions et on compare les vitesses.

Il y a d’autres subtilités à tester :

• un bout de JS rarement utilisé sur un site n’est peut-être pas à sa place avec le reste du code JS : le charger sur chaque page est-il optimal ?
• un code JS très réduit en taille n’est-il pas plus rapidement servi si on l’insère directement dans la page plutôt qu’en ressource externe ?