Développement, annonces, mises à jour, insolite : le Blog.

Accueil / Blog / Développement / Faire moins de requêtes HTTP

mar.		Faire moins de requêtes HTTP  Catégorie : Développement.  Tags : Performances, Web.
13	/01
	09

"Précédemment dans la série des performances sur le Web" : je vous avais expliqué en détails comment vous servir de YSlow, outil nécessaire à tout bon développeur soucieux des performances de ses pages Web. J’espère que vous avez pu jouer un peu avec et déjà essayer d’obtenir des notes pour quelques pages. Quoi qu’il en soit, YSlow se base sur 13 règles d’optimisation lors de l’analyse de chaque page passée au crible afin de décerner des notes ; comme prévu, je vais aujourd’hui me concentrer sur la règle numéro 1 : réduire le nombre de vos requêtes HTTP (minimize HTTP requests sur la page dédiée Yahoo).

Le nombre de requêtes HTTP correspond au nombre de composants que vous chargez avec le document (x)HTML. Il s’agit des fichiers CSS, JavaScript, des images (images de fond et icônes), du Flash si vous en avez, etc. Par conséquent, c’est très simple, plus vous avez de composants plus votre page est riche mais plus vous êtes pénalisés.

Dans le temps du bas débit, quand on surfait sur le Web avec 56kbps comme limite de réception maximale, les Webmestres (pour être générique) concevaient et développaient des pages mal faites à base de tableaux à outrance mais on n’y retrouvait ni JavaScript (ou très peu), ni CSS (ou très peu), presque pas de Flash (beaucoup de gif animés par contre) et une attention toute particulière était apportée au poids et à la taille des photos car sinon j’imagine que chacun pouvait aller se chercher un café après avoir cliqué sur un lien en attendant que la page ne s’affiche (j’exagère à peine). Certes de nos jours le haut débit permet de faire passer plus d’informations plus rapidement, certes les sites que nous visitons sont dans l’ensemble mieux codés mais les Webmestres ont une forte tendance à abuser de ce haut débit et de ce fait bourrent leurs pages de JavaScript (parce que c’est la mode), apportent un peu moins d’attention à compresser et réduire leurs images, etc. J’espère que vous n’êtes pas dans ce cas parce que globalement le débit, la qualité et l’accessibilité ont augmenté mais du point de vue des performances ce n’est pas mieux qu’une dizaine d’années auparavant.

J’ai parlé de faire passer plus d’informations plus rapidement, dans l’idéal c’est ce que l’on devrait faire : favoriser le fond plutôt que la forme ou du moins trouver un juste milieu. Vos visiteurs viennent - il me semble - pour du contenu plus que pour votre beau Web design ou vos événements JavaScript évolués. Bien sûr tout ceci joue un rôle important et même si, pour réduire le nombre de vos requêtes HTTP, un premier conseil est de simplifier vos pages (prenez exemple sur Google ou FeebBurner, ils sont "beaux" et font très professionnel tout en étant simples et Google se trouve bien en-dessous des 500ms), on n’a pas toujours l’envie ou la possibilité de procéder à une telle simplification pouvant dénaturer l’image et/ou le(s) message(s) que l’on souhaite faire passer. Dans ce cas on peut au moins faire en sorte que le contenu informatif s’affiche avant tout le reste pour que le visiteur ait moins l’impression d’attendre (qu’apporte le fait d’avoir sous les yeux tout un design qui se construit au fur et à mesure alors que ce que l’on souhaite lire n’est pas encore affiché ? Là aussi j’exagère à peine). On peut aussi commencer (oui c’est un - bon - début mais ce n’est qu’un début) par faire moins de requêtes HTTP. Je vous entends déjà penser tout fort "Sebastien tu viens de nous dire que ceci revient à simplifier nos pages", eh bien figurez-vous que l’on peut tout à fait faire autrement !

Avant de vous donner mes petits secrets, je dois tout de même vous expliquer un peu pourquoi faire moins de requêtes HTTP permet à vos pages de charger plus vite donc pourquoi en faire trop est pénalisant. Concrètement, pour chaque composant d’une page, le navigateur Internet (peu importe qu’il soit Firefox, Opera, Safari, Internet Explorer ou autre) envoie au serveur (là où vos fichiers sont stockés) une requête soit l’ordre de servir/renvoyer le composant en question. Entre le départ de cet ordre (de votre ordinateur) et le temps qu’il arrive au serveur s’écoule un certain temps variable en fonction de beaucoup de paramètres tels que l’état de votre ligne, son débit, votre situation géographique (éloignement du serveur), etc. Une fois l’ordre arrivé au serveur, il se passe encore un certain temps avant qu’il ne soit exécuté (on appelle ça le temps de réponse). Ensuite, l’ordre est donc exécuté, le composant fait le chemin jusqu’à vous (la même chose en sens inverse) et aux caractéristiques de la ligne vient alors s’ajouter le poids du composant qui fait que cette dernière étape sera plus ou moins longue. En résumé, pour chaque composant est fait ce que l’on appelle un aller-retour serveur. Tous ces transits via le réseau (ne pas oublier qu’Internet n’est qu’un nombre incalculable d’ordinateurs inter-connectés) sont affectés par des données presque incontrôlables, en faire moins permet logiquement de grignoter plusieurs centaines de millisecondes sur le temps total d’affichage de vos pages. De même, chaque aller-retour serveur lui coûte en ressources et en bande passante, imaginez que vous ayez 500 000 visiteurs uniques par jour ... or c’est bien ce que vous voulez non ?

Première recommandation : si vous avez plusieurs fichiers JavaScript, regroupez-les en un seul à chaque fois que vous le pouvez, de même pour vos fichiers CSS. Il y a toujours des cas où il n’est pas évident de tout regrouper mais en général c’est possible et il s’avère que c’est la recommandation la plus simple de toutes celles qui suivront alors allez-y les yeux fermés, c’est toujours 2 aller-retour serveur économisés pour 3 fichiers JavaScript par exemple (et en avoir 3 est plutôt courant de nos jours). Seconde recommandation : pour ce qui est des images, du moins les images de fond définies dans vos CSS, je vous conseille vivement de créer ce que l’on appelle des "sprites". Il s’agit là encore de regrouper toutes vos images de fond - chaque fois que c’est possible - en une seule qui sera positionnée dans vos balises grâce à la propriété CSS background-position :[décallage en x]px [décallage en y]px ; Si il est difficile de regrouper toutes les images, il est tout à fait possible de le faire suivant leur thème ; par exemple, voici le sprite général Your-Mix, le sprite des icônes et enfin le sprite des fonds répétés sur l’axe des abscisses. Si l’on fait le total, au lieu de faire 69 requêtes HTTP pour des images, il n’en est fait que 3. De plus, une grosse image telle que le sprite général pèse moins lourd que la somme de toutes les petites images la composant séparément (60ko environ contre 120ko environ) mais je vous l’accorde, parfois on va faire charger des icônes inutilisées sur certaines pages ... c’est tout l’intérêt de cette méthode couplée au cache client, j’en reparlerai très bientôt. Pour utiliser les sprites en CSS, on appellera l’image une seule fois comme ceci : #bandeauHeader,#barreRecherche,#bandeauFooter{background-image:url(http://static.your-mix.net/img/sprites/spriteFonds_231208.png);background-repeat:repeat-x;} puis on se positionnera dans les blocs de cette manière : #bandeauFooter{background-position:0px -310px;} Une dernière chose (je sais c’est long), pour créer vos sprites, vous pouvez utiliser ce bon vieux Photoshop (et je vous le conseille !) mais sachez qu’il existe des outils en ligne tels que Website Performance CSS Sprite Generator ou CSS Sprite Generator.

Des questions ?

0 commentaire.

Billet lu 0 fois.   Écrit par : Sebastien P.

< Billet précédent | Haut de la page | Billet suivant >

Le module de commentaires est temporairement désactivé.
Merci de votre compréhension.