Home > Développement Web > Yahoo vous aide à accélérer votre site internet

Yahoo vous aide à accélérer votre site internet

Après avoir publié ses “Best Practices for Speeding Up Your Web Site” (comprendre: meilleures pratiques pour accélérer votre site internet”, Yahoo met désormais à disposition des développeurs YSlow!, une extension pour FireBug, célèbre plug-in Firefox, qui permet de faire un rapport d’optimisation pour la vitesse du site que vous visitez.

Le plug-in, très simple d’utilisation (un click dans la barre d’état lance l’analyse, qui apparait dans le panneau FireBug), recense toutes les modifications que vous pouvez apporter pour atteindre le fameux Speed Rank A, réservé à l’élite des sites rapides… (disons que les 34 critères définissent le « site rapide théorique parfait », mais ne sont pas tous applicables dans le monde réel. Par exemple, Yahoo recommande d’utiliser un CDN (Content Delivery Network), solution généralement assez chère pour ne pas être déployable sur des sites à moyen traffic et peu monétisés.

Voici un rappel de ce qu’il faut faire et éviter, aux yeux de Yahoo.


Les critères ont été classés en 7 catégories :

  1. Le contenu
  2. Le serveur
  3. Les cookies
  4. Les CSS (Cascading Style Sheets… les feuilles de style, quoi)
  5. Le Javascript
  6. Les images
  7. Version « mobile »

Tour d’horizon des critères que je trouve utiles parmi les 34 proposés :

Faire le moins de requêtes HTTP possible

Partant du principe que 80% du temps de rendu d’une page consiste en téléchargement (vu la source des données –Yahoo- je pense qu’on peut considérer ce chiffre comme fiable), Yahoo recommande clairement de « combiner » les fichiers : regroupez toutes vos classes CSS dans un seul fichier, toutes les fonctions Javascript dans un autre. A noter que, même si personnellement, je ne suis pas fan de la méthode, cela permet de maximiser l’effet des caches navigateur. Au premier chargement d’une page de votre site, l’utilisateur dispose de tous les éléments dont il aura besoin au fil de la navigation. On gagne donc pas mal de temps (et de bande passante) pour toutes les autres pages qu’il verra.

Dans la même optique, Yahoo recommande d’utiliser des « CSS Sprites » pour afficher les images (coins arrondis et compagnie) et des « Images Map », ce qui réduit le nombre de fichiers à télécharger.

Jouer avec les sous-domaines, mais en réduisant les DNS Lookups

Les navigateurs internet comme Internet Explorer ou Firefox, quand ils récupèrent les éléments d’une page, ne peuvent faire que deux téléchargements simultanés par nom de domaine. En gros, si vous mettez vos pages statiques (donc, le HTML) sur www.domain.tld, vos images sur img.domain.tld et vos feuilles de styles et javascripts sur elements.domain.tld, vous accélèrerez le téléchargement total de la page en multipliant les requêtes simultanées.

Attention, les DNS Lookups nécessaires pour récupérer l’adresse IP des sous-domaines prend du temps, donc n’en abusez pas. Yahoo considère que 2 à 4 sous-domaines est une fourchette acceptable.

Utiliser un Content Delivery Network ou CDN

Alors là, rien à redire : il est parfaitement logique qu’un CDN accélère votre site. C’est le but. Les Content Delivery Networks sont, en gros, des réseaux de serveurs qui vont « capturer » votre contenu statique (Javascript, CSS, images, mais aussi HTML) et le servir à votre place. Parmi les plus connus, Akamai comprend 20000 serveurs répartis dans 71 pays (données corporate). En effet, difficile de rivaliser ;)

Ajouter des headers « Expires » ou « Cache-control »

Là, deux cas :

  • Soit on parle de contenu statique et on peut utiliser un Expires, qui indique au navigateur quand est-ce qu’il devra recharger le composant au lieu de le piocher dans son cache,
  • Soit on parle de contenu dynamique, et on devra plutôt se servir de Cache-Control pour définir le comportement à adopter.

Le header « Expires » sert à spécifier au browser une date d’expiration pour le document visé. En gros, si j’ajoute à ma feuille de style un “Expires: Thu, 15 Apr 2010 20:00:00 GMT”, votre navigateur n’essaiera même pas de la télécharger avant cette date.

Bonne idée de Yahoo : utiliser une norme de nommage des fichiers qui consiste à suffixer le nom par le numéro de version (comme dans « yahoo_2.0.6.js ») : cela permet d’être sur que le fichier ne sera jamais modifié (sauf en cas de changement de version, où il sera renommé), et donc d’utiliser le plus souvent un Expires : aucun travail pour le serveur quand le document est déjà dans le cache du navigateur.

GZipper votre contenu

En compressant ce qui sort de votre serveur, vous améliorez le temps de chargement des éléments (logique). Il faut prendre en compte l’impact que la compression peut avoir sur les performances de votre site : le processeur de votre serveur sera plus sollicité, mais vous économiserez de la bande passante.

La plupart des clients qui suivent la norme HTTP/1.1 envoient un header « Accept-Encoding : gzip, deflate » auquel le serveur, s’il le peut, répondra par du contenu zippé avec un header « Content-Encoding : gzip ».

Pour que cela soit le cas, avec Apache 1.3, il faut installer et activer mod_gzip, remplacé pour Apache2 par mod_deflate.

Feuilles de style en haut et javascripts en bas, flush() fréquents

En embarquant vos feuilles de style dès le tag <head> de votre page, vous permettez au navigateur du client d’afficher celle-ci de manière progressive au cours de son chargement. Même si techniquement, cela ne change en rien la vitesse de chargement, l’impact psychologique de voir la page de remplir est tel qu’on a une impression de vitesse. Vous pouvez lire l’étude UseIt sur le “progressive rendering. Dans la même idée, utiliser un flush() après votre header (fonction qui ordonne au serveur d’envoyer le HTML déjà généré sans attendre la fin de la création de la page) permettra à la page de s’afficher plus rapidement, puisque les téléchargements connexes pourront commencer avant que le serveur n’aie fini ses calculs.

Selon la norme HTTP/1.1, les navigateurs ne doivent télécharger que deux éléments en parallèle par hostname. Si vous placez vos Javascripts en haut de votre code-source, le navigateur les téléchargera et donc bloquera l’un des deux téléchargements pour eux, qui n’ont pas d’impact visuel. A choisir, mettez les donc vers le bas du document, après que la structure de la page, les feuilles de styles et les images aient été chargées.

Minifier le code Javascript et les CSS (feuilles de style)

Minifier le code revient à en enlever les espaces inutiles, tabulations, retours à la ligne… On se retrouve avec une bouillie illisible mais beaucoup plus rapidement chargée qu’un code propre et indenté. Regardez le code-source de la home de Google… Il faudra bien évidemment garder une version « non-minifiée » de vos scripts, pour pouvoir les retoucher en cas de besoin. Yahoo propose 2 outils de minification : JsMin et YUI Compressor. J’en ai développé un aussi, mais je pense que le leur marchera mieux ;)

Gérer intelligemment les tailles d’images

Il ne faut jamais utiliser une image carrée de 500px de côté avec un width= »100 » pour la redimensionner en HTML. Le navigateur devra toujours télécharger l’image dans sa taille originale. Faites une copie plus petite de l’image !

Pensez à ajouter une favicon à votre site. Dans tous les cas, les navigateurs la demandent, et auront donc à télécharger votre page d’erreur 404 personnalisée (vous en avez une, n’est ce pas ? … Yahoo recommande d’éviter pour ne pas gaspiller de ressources serveur, mais Yahoo n’est pas référenceur…) en lieu et place de la petite icône qui apparaitra dans les favoris de vos utilisateurs et dans les onglets de leur navigateur. Même combat pour le robots.txt : il sera de toute façon demandé, donc autant en avoir un.

D’après Yahoo, le meilleur format d’images actuel est PNG (« Give PiNG a Chance », qu’ils disaient…) : tout ce qu’un GIF peut faire, un PNG8 peut le faire aussi, pour une taille de fichier souvent moindre. A essayer :)

Voici une rapide présentation des points qui m’ont semblés être des “quick-win” dans ce que propose Yahoo. La liste est loin d’être exhaustive, j’ai volontairement “oublié” des items de la liste qui avaient l’air moins importants (ou plus complexes à mettre en place) pour un site de taille raisonnable.

Un peu de lecture pour aller plus loin :

Et vous, quelles sont vos habitudes ?

Ce post vous a été utile ? Re-Twittez le ! ReTwittez ce post

Développement Web , ,

  1. Unknownn
    | #1

    Excellent article, je n’étais même pas au courant de celui de Yahoo !

    Bonne continuation,
    Unknownn

  2. Didier
    | #2

    Merci !
    J’avoue que l’article de Yahoo n’est pas tout récent, mais j’étais passé à côté pendant longtemps, je me suis dit que je ne serais surement pas le seul ;)

  3. | #3

    Je cherchais une traduction de Yslow.. j’ai même eu la synthèse ! ;-)

    Merci pour cet article qui m’a bien aidé.

    Bonne continuation.

  4. | #4

    Je suis moyennement d’accord avec le dernier point (celui qui traite du PNG et du GIF).

    Le GIF a deux points forts :
    - pour des petits fichiers, la taille est toujours inférieure à celle des PNG
    - du point de vue de l’utilisateur, le GIF est mieux géré par IE (ça évite les mauvaises surprises une fois la découpe terminée).

    Merci pour cet article de synthèse, j’aurais néanmoins apprécié avec plus d’informations sur le CDN.

    Bonne continuation.

  5. Didier
    | #5

    Dopaweb: en fait, j’ai “zappé” les CDN pour leur consacrer un post entier avec comparatif etc. Je mets juste plus de temps que prévu pour réunir toutes les informations nécessaires ;)

  6. | #6

    @Dopaweb: un PNG8 est quasiment toujours plus petit une fois optimisé qu’un GIF de même contenu. Les seules différences se font généralement sur les toutes petites images de moins de 1ko. Dans tous les cas où le GIF arrive avant PNG, la différence entre les deux est négligeable (alors que dans l’autre sens le PNG peut être sensiblement plus petit)

    Et non, le GIF n’est pas fondamentalement mieux géré par IE, pour peu que tu utilises un PNG8 et pas un PNG24.

  7. | #7

    @ Eric :
    Fais une comparaison entre un gif et un png ayant l’un et l’autre un fond transparent…

  8. | #8

    Ah mais je confirme, même avec de la transparence ça ne change rien.

    Pour confirmation j’ai pris les images de http://www.webreference.com/dev/graphics/compress.html
    J’ai converti le blanc en transparent et j’ai lancé le photoshop pour comparer. J’obtiens grosso modo les mêmes chiffres à quelques octets près. Et ces chiffres confirment mes dires (ainsi que ceux d’a peu près tous ceux qui bossent sur les performances web).

    D’ailleurs si je peux me permettre, le simple fait de demander de mettre un fond transparent montre qu’il y a méconnaissance du sujet. Sur les GIF il y a juste une transparence binaire et 256 couleurs indexées. Si on prend une transparence binaire et une palette de couleurs fixe, que ce soit en GIF ou en PNG, le transparent est une couleur comme une autre. Que le fond soit blanc, noir, bleu ou transparent, l’image aura la même taille, à l’octet près.

  9. Dopaweb
    | #9

    @ Eric :
    Je voulais surtout insister sur le rendu sous IE, pas sur la taille !

  10. Manu
    | #10

    Didier :
    Dopaweb: en fait, j’ai “zappé” les CDN pour leur consacrer un post entier avec comparatif etc. Je mets juste plus de temps que prévu pour réunir toutes les informations nécessaires

    Bonne idée. Quand on parle de CDN, on dirait qu’il n’y a qu’Akamai, mais en réalité il y a une offre assez importante et qui ne cesse de se diversifier. Rien que pour parler de l’actualité, en Angleterre, Velocix vient de lancer Metro, un truc pour FAI. Sans parler du “service CDN” d’Amazon. Plein de choses intéressantes…

  1. No trackbacks yet.