En effet, outre le fait que je n'ai plus que mes weekend à consacrer sur Your-Mix (stage chez Orange Labs la semaine oblige), sachez tout de même que beaucoup de bonnes choses sont en préparation !

Pour vous mettre l'eau à la bouche, commençons par l'annonce du nouveau Webdesign du site que vous pourrez admirer d'ici peu en remplacement de ce blog : un Webdesign beaucoup plus orienté Web 2.0 avec au programme nuage de tags, icones shiny, un nouveau logo, coloration syntaxique des snippets de code informatique, etc. etc.

Ensuite, comme une bonne nouvelle n'arrive jamais seule, sachez que le projet Your-Mix ne va plus seulement être réservé aux DJs, il ouvrira ses portes à TOUS LES PODCASTEURS quels qu'ils soient (radios, émissions, interviews, ...) et ce notamment avec la nouvelle version du site mais aussi avec l'arrivée de la version 2 beta de notre Player Flash, entièrement repensé et comprenant énormément de fonctionnalités supplémentaires (dont la liste sera dévoilée au fur et à mesure sur ce blog) ... mais pour cela il faudra être encore un tantinet patient ...

Et enfin, pour terminer ce billet sur une note tout aussi positive, sachez qu'après réflexion j'ai décidé de ne plus insérer de publicité sur aucune page du futur service Your-Mix, de même qu'il existera une offre totalement gratuite (certes limitée) dont je dois encore déterminer les modalités.

Cordialement.

PS : Pour des mises à jour plus courtes mais plus régulières, vous pouvez d'ores et déjà me suivre sur Twitter.

PS 2 : Suite à la mise à jour du noyau du blog, tous les commentaires ont momentanément été perdus, de plus des spammeurs commençaient à faire des siennes sur mes billets j'ai donc décidé de désactiver le module de commentaires jusqu'à nouvel ordre. Dernière chose, toujours à cause de cette mise à jour, toutes les statistiques de consultation de billets ont aussi été perdues ce qui a pour effet de mettre un "beau" 0 partout donnant ainsi la fâcheuse impression que personne ne me lis ...

Les expressions CSS - comme on les appelle - ne sont qu'un moyen d'intégrer du JavaScript dans vos feuilles de style CSS. Elles sont supportées uniquement sous Internet Explorer de la version 5 à la version 7 (eh oui, ils les ont abandonnées dans la version 8 !).

Outre le fait que les expressions CSS sont assez puissantes (vous imaginez bien que rendre dynamiques les propriétés de vos styles peut-être intéressant), sachez qu'elles sont aussi fortement déconseillées du point de vue des performances ! En effet, premièrement, si l'on sépare les CSS et le JS du HTML dans des fichiers bien distincts ce n'est justement pas pour aller mélanger les CSS et le JavaScript ! Ensuite, la raison principale avancée par l'équipe Yahoo pour oublier les expressions CSS est que ces dernières sont recalculées à chaque fois que l'utilisateur redimensionne la page, utilise le scroll, à chaque fois qu'il bouge la souris, etc. Bref, une horreur, un peu comme le coup du mode de rendu des tableaux HTML (pour faire court, utilisez la directive CSS table-layout:fixed et les navigateurs Web lutteront moins pour l'affichage et le reflow de vos grands tableaux aux multiples lignes et colonnes) ; les propriétés CSS à base d'expression JavaScript peuvent donc être recalculées des dizaines de milliers de fois en peu de temps ce qui arrive à être plutôt lourd à digérer pour quelque chose de si simple à éviter !

Malgré tout, pour ceux ou celles qui seraient tout de même intéressé(e)s et qui souhaiteraient en savoir plus sur les expressions CSS, vous pouvez toujours consulter la page officielle Microsoft ou bien ce blog ci et encore ce blog là.

Cordialement.

PS : par manque de temps ces dernières semaines, je n'ai pas pu assurer la mise en ligne régulière de mes posts sur le sujet des performances Web, veuillez m'en excuser, on se retrouve donc très bientôt avec la règle numéro 8, externaliser le JavaScript et les CSS.

À l'heure actuelle, notre développeur attitré se heurte aux dernières difficultés concernant principalement un plugin de notation en étoile récalcitrant allant de paire avec l'établissement d'un classement des DJs. Visiblement, le plugin en question n'est pas compatible avec le travail déjà réalisé sur la présentation (réécriture) des URL de notre plateforme qu'est Your-Mix.

Pour des raisons évidentes de gain de temps de développement et de capacité à mettre en place un système tel que celui que nous souhaitons réaliser, notre développeur s'est basé dès le départ sur un CMS (Content Management System) bien connu : SPIP, alors dans sa mouture 1.9.2. Après avoir eu du mal avec la réécriture d'URL sous SPIP afin d'obtenir un résultat de type "arborescence", des petits soucis sont apparus notamment dans la gestion et l'administration du cache applicatif page par page qui est alors devenue impossible ainsi que dans la compatibilité avec le plugin "notation".

Depuis quelques temps, SPIP est disponible en version publique 2.0.3, une mise à jour importante qui laisse entrevoir le bout du tunnel quant au plugin "notation" puisqu'une version plus récente - et plus performante - a été réalisée uniquement pour SPIP 2. De même, la gestion des URL en modèle arborescent est maintenant native, ce qui devrait régler les conflits rencontrés actuellement avec le cache de SPIP. Enfin, dans le souci d'améliorer l'expérience utilisateur, nous explorerons les nouvelles pistes offertes par SPIP 2 concernant l'usage d'AJAX dans l'intégration des formulaires et de plusieurs pages pour les commentaires. En résumé, le prochain grand pallier à passer pour l'avancement de la plateforme Your-Mix est la mise à jour et l'assimilation de son noyau : SPIP en version 2.0.3.

Pour accompagner ce noyau, nous avions déjà évoqué notre choix du Framework JS JQuery ; eh bien pour accompagner ce Framework, nous avons décidé de le compléter par sa branche orientée interface utilisateur nommée JQuery UI. Cet ajout - pas des moindres - permet notamment de gérer le glisser/déposé (drag & drop) que nous mettrons en place dans l'interface d'administration du Your-Mix DJ Web MP3 Player pour chaque DJ. Cependant, un petit travail supplémentaire sera à réaliser : revoir le Web Design final des pages DJ pour intégrer par la suite JQuery UI selon un thème personnalisé.

Pour terminer ce billet, il nous faut replacer ces annonces dans le contexte actuel : notre développeur commence dès aujourd'hui un stage chez Orange Labs (France Télécom département Recherche et Développement) à cause de quoi l'avancée des travaux sur la plateforme Your-Mix sera d'autant compromise.

Merci de votre compréhension, cordialement.

Contrairement à la croyance générale, il est préférable d'appeler vos fichiers JS le plus tard possible dans la page, c'est à dire juste avant de refermer la balise body. La plupart du temps, nous insérons notre ligne type : (oui, application/javascript est le nouveau mime-type certifié à utiliser en remplacement de text/javascript maintenant obsolète) dans head probablement plus par souci d'une certaine élégance pour notre source ; or cette pratique n'est absolument pas obligatoire, et ce n'est pas la W3C qui démentira, les standards sont clairs, on peut aussi bien déclarer un script dans head que dans body et la seconde solution est loin de ne pas être "propre" ...

Le fait est que lorsqu'un navigateur Internet (actuel) détecte un appel de script, il bloque totalement le rendu de la page jusqu'à ce que le fichier soit chargé et le code interprété (à la différence par exemple des images qui seront téléchargées en parallèle ... j'y reviendrai). Ce comportement est dû au fait que le JavaScript peut entre autres modifier le contenu d'une page notamment via la méthode document.write(...) ; Dans ce cas, la déclaration du script est bien faite dans le body, à l'endroit même de la page où vous avez souhaité que quelque chose soit écrit via JavaScript ; cette méthode est cependant fortement à déconseiller car le JavaScript devient alors ici intrusif comme si vous l'insériez dans un attribut HTML de type gestion d'évènement que sont par exemple : onmouseover, onmouseout, onkeydown, etc. Il est évident qu'un script faisant usage de document.write ne pourra être déplacé plus bas dans la page (un exemple courant est la publicité Google Adsense qui est difficilement déplaçable sauf éventuellement grâce à une triche à base de CSS).

De plus, dans le cas contraire (pas de document.write et un appel du script dans head), le navigateur réagira de la même façon, le problème étant que le blocage du rendu se fait au niveau du header de la page, autrement dit rien ne sera encore affiché puisque le body n'est pas encore interprété. Quel est alors l'intérêt de bloquer le rendu si rien n'est rajouté à la page via JavaScript ? Eh oui, sinon vous auriez utilisé document.write et alors déplacé votre déclaration de script dans le body. D'une manière très générale, ce qu'il faut retenir avec le JavaScript, c'est qu'il est un élément bloquant pour le moteur de rendu d'un navigateur Web.

Afin de limiter la casse dans les deux cas de figure présentés ci-dessus, on évitera d'écrire du JavaScript dit intrusif par exemple grâce à l'utilisation d'un Framework JS tel que JQuery, on pourra - et l'on devra - alors toujours déplacer sa/ses ligne(s) d'appel de script pour l'écrire juste avant de refermer la balise body. Par conséquent, tout le rendu de la page sera fait (c'est à dire que votre visiteur aura rapidement accès à l'information recherchée) avant le blocage lié au chargement de vos scripts. J'en avais déjà parlé, il s'agit ni plus ni moins de privilégier le fond à la forme lors du rendu afin que vos visiteurs aient moins l'impression d'attendre. En plus, ceci vous assurera que l'arbre de vos pages (constitué par les "noeuds" de balises) sera entièrement disponible avant que votre Framework JS fasse les attributions pour la gestion des évènements (onclick, ...) ; le cas contraire étant une aberration.

Cordialement.

J'en avais déjà parlé dans le quatrième paragraphe de ce billet, le principe pour cette règle d'optimisation est le même, à savoir permettre à la page de faire son rendu progressivement et ainsi que le visiteur ait accès plus rapidement au fond (à l'information recherchée) qu'à la forme (le Web Design et tous les évènements JavaScript par exemple). Pour ce faire, l'équipe de Yahoo - ayant mené toutes sortes de recherches sur la question des performances - nous conseille fortement d'appeler nos feuilles de style CSS très tôt dans la page c'est à dire entre les balises et .

Je pense qu'il n'est pas nécessaire de s'étendre sur le sujet car il me semble que cette pratique - de surcroit recommandée aussi dansles spécifications HTML du W3C - est plus que courante ; cependant, il y a une subtilité concernant la méthode d'appel des CSS, il existe en effet la méthode dite "link" :

et la méthode dite "import" :

Ces deux méthodes ont toutes deux pour effet d'appliquer vos styles dans vos pages ; certains vous diront que choisir "import" est une bonne pratique pour se faciliter la vie lorsqu'il s'agit de regrouper de vos différents fichiers afin de créer des feuilles de style "dynamiques", alors que d'autres vous diront - du point de vue des performances - qu'utiliser "link" n'est pas bloquant donc plus rapide et à conseiller si l'on souhaite rejoindre les recommandations données par l'équipe Yahoo.

Ce que j'en dis : puisque vous avez normalement déjà (dans la mesure du possible) regroupé vos fichiers en un seul, il me semble alors qu'utiliser la méthode "import" perd toute son utilité ; préférez donc en général (sauf rares cas exceptionnels où vous ne pourrez pas faire autrement) la méthode "link" et le problème sera réglé.

Enfin, une dernière petite précision concernant les sélecteurs CSS : sachez que le rendu pour un élément du DOM ciblé de la manière suivante (exemple donné arbitrairement) : table#monTableau tr td.maCellule {...} sera moins rapide que pour : .maCellule {...} En effet, contrairement à ce que l'on pourrait croire, donner plus de précision dans le ciblage n'aide pas le moteur de rendu du navigateur, ceci lui fait au contraire calculer plus de choses. En plus, simplifier vos sélecteurs allègera vos CSS, c'est tout bénef' !

Cordialement.

Cette mise à jour s'accompagne même de deux ajouts non annoncés supplémentaires. Il s'agit de la présentation du numéro de version lors d'un clic droit (menu contextuel de Flash) n'importe où dans la zone du Player permettant à tout-un-chacun de savoir si le navigateur Web utilisé aura appliqué les prochaines mises à jour ou si il faudra actualiser son cache. De plus, le code HTML pour exporter le Player a été retravaillé pour être raccourci et simplifié.

La version 1 Beta révision 9 du DJ Web MP3 Player Your-Mix est d'ores et déjà finalisée et comporte donc les améliorations et nouvelles fonctionnalités suivantes :

1) Correction de bug lecture aléatoire.
2) URL permanente page du DJ.
3) Code pour exporter le Player.
4) Choix de la couleur de fond.
5) Ajout du texte "[Explicite]".
6) Affichage du numéro de version.
7) Code HTML d'export simplifié.

Cependant, l'affichage de l'URL permanente vers la page du DJ pose un problème puisque les pages en question ne sont pas encore terminées et pleinement fonctionnelles. Nous avons alors décidé de ne rendre cette nouvelle version de notre Player publique que lorsque les pages DJ en question le seront. Merci de votre compréhension.

Cordialement.

Compresser vos composants a pour effet de diminuer les temps de réponse aux requêtes HTTP que font vos visiteurs. Autrement dit, moins un composant pèse lourd et plus vite il sera acheminé à travers les tuyaux du réseau jusqu'aux ordinateurs des internautes, ce qui est logique. On pourra alors, de la même façon que nous le faisons avec Photoshop, SmushIt ou autre pour nos images, compresser via le serveur tout ce qui est à base de texte (et uniquement, j'y reviendrai). Par exemple, pourquoi ne pas compresser vos pages HTML, vos feuilles de style CSS, vos fichiers JavaScript, XML, TXT et/ou JSON avant de les envoyer au client ? Ceci peut être d'autant plus intéressant que ces fichiers ont pu être alourdis lorsque vous les avez tous regroupés afin de faire moins de requêtes HTTP comme je vous l'avais suggéré et vivement conseillé.

Ceux qui on lu au moins mon billet précédent concernant la mise en cache navigateur des composants me diront "pourquoi compresser les CSS, fichiers JS et autres pour réduire les temps de réponse alors qu'à partir de leur second accès sur le site, les visiteurs auront un cache plein et ces fichiers seront renvoyés par leur disque dur et non plus par le réseau ?". Eh bien la réponse réside plus ou moins dans la question, il s'agit d'accélérer le chargement des pages lors d'une première visite et donc d'un accès fait avec un cache vide ; ceci se justifie encore une fois du fait que les fichiers sont regroupés et donc potentiellement plus lourds car certaines directives (CSS, JS, ...) sont inutilisées sur certaines pages mais bien présentes dans ces fichiers.

Ok, alors comment je fais pour compresser mes composants ? C'est très simple, depuis l'arrivée du protocole HTTP 1.1 et depuis Internet Explorer 4, presque tous les navigateurs sont capables de décompresser un contenu renvoyé compressé par le serveur ; ne vous préoccupez pas de ceux qui n'en sont pas capables, le même contenu leur sera alors automatiquement renvoyé non-compressé pour qu'il n'y ait aucun risque d'incompatibilité. Concrètement, vous configurez votre serveur Apache (pour ceux qui ne me suivent pas régulièrement, je ne fais état sur ce Blog que d'Apache étant le seul que je connais) via httpd.conf ou .htaccess (à la racine) pour qu'il compresse les fichiers souhaités avant de les renvoyer à vos visiteurs qui les décompresseront ensuite avant de les lire (et les stocker dans leur cache navigateur), le tout d'une manière totalement transparente et automatique. Sachez que les résultats de cette méthode sont visibles dès les premières secondes après sa mise en place et que son efficacité permet de réduire - d'après Yahoo - les temps de réponse d'environ 70%, pour une seule ligne de code !

La syntaxe à adopter est différente selon la version d'Apache que vous utilisez. En effet, Apache 1.3+ se sert du module mod_gzip (à télécharger sur cette page, aide à l'installation et à l'utilisation sur cette page) tandis qu'Apache 2+ intègre par défaut le module mod_deflate qui est très simple à utiliser. Si vous ne savez pas lequel choisir, vous pouvez toujours essayer le code suivant :

SetOutputFilter DEFLATE

qui fait un test de présence pour mod_deflate avant de compresser uniquement vos fichiers HTML, PHP, TXT, XML, JS et CSS. Vous pourrez ensuite vérifier si ce snippet a fonctionné grâce au sous-menu "Components" de YSlow. Ces quelques lignes de code donnent exactement le même résultat que celle-ci qui est toutefois plus propre (se servant des mime-type) : AddOutputFilterByType DEFLATE text/html text/xml application/xhtml+xml text/plain application/javascript text/css Une dernière chose, n'essayez pas de compresser via Gzip/Deflate vos images, PDF ou autre qui sont des fichiers déjà compressés lors de leur production logicielle. Les risques sont de consommer des ressources processeur de votre serveur pour rien (eh oui, compresser c'est nécessaire, très bien, mais pas gratuit ni magique) voire d'augmenter leur poids.

Des questions ?

Comme promis, nous allons reparler ici du cache client. Sans entrer dans les détails, ajouter des en-têtes HTTP Expires et Cache-Control sur vos fichiers permet de contrôler ce cache. Le principe est simple, lors de sa première visite sur votre site, un visiteur lambda fera un certain nombre de requêtes HTTP à votre serveur (nombre que vous avez réduit grâce à ce billet) ; lorsque votre serveur enverra sa réponse pour chaque composant, il enverra aussi les fameuses en-têtes/directives qui donneront l'ordre au navigateur du visiteur de stocker les composants en question dans son répertoire dédié au cache. Autrement dit, vos composants seront ensuite copiés quelque-part sur les ordinateurs de vos visiteurs.

L'intérêt de cette méthode ne réside donc pas dans la première visite (cache vide) mais dans les suivantes (cache plein). Les composants ayant déjà été téléchargés et stockés, le navigateur ne renverra alors plus de requêtes HTTP, on élimine ainsi les temps de réponse et de trafic sur le réseau pour chacun d'eux ce qui est un gain conséquent ! De même, en plus d'un temps de chargement des pages diminué pour vos visiteurs (ce qui améliore leur expérience de navigation sur votre site), comme les composants ne sont pas téléchargés inutilement à chaque fois, vous faites des économies toutes aussi conséquentes sur votre bande passante. C'est à peu près tout pour le côté théorique, passons au côté pratique.

Il faut toujours séparer votre contenu en deux types : celui dynamique (qui est modifié souvent comme vos pages html sur lesquelles les visiteurs peuvent ajouter des commentaires ou votre page d'accueil par exemple) et celui statique (qui est très rarement modifié comme les images composant votre Web design, vos CSS, vos fichiers JavaScript et vos animations Flash, voire certaines pages par exemple). Cette distinction est très importante car les en-têtes Expires et Cache-Control servent à stocker vos composants dans le cache client, oui mais en précisant quand même une date de "péremption". Concrètement, on choisira de faire stocker (bien) plus longtemps les fichiers dits statiques que ceux dits dynamiques. On parle de faire expirer ces fichiers statiques à une date éloignée dans le futur, soit une ou plusieurs années ; vous imaginez avoir réglé vos fichiers dynamiques sur la même date d'expiration, admettons que les commentaires ajoutés aujourd'hui sur vos pages n'apparaissent à vos anciens visiteurs que dans deux ans. C'est un schéma absolument non-envisageable. Pour les fichiers dynamiques, on choisira une date d'expiration quelques dizaines de secondes (quelques minutes tout au plus) dans le futur après un premier accès ; même l'AJAX peut être mis en cache, c'est toujours ça de gagné.

A noter - et c'est très important - qu'une fois vos fichiers statiques mis en cache pour plusieurs années, les modifier et les ré-uploader sur votre serveur ne sera pas suffisant pour que vos visiteurs au cache plein voient les changements avant leur expiration (sauf après avoir vidé le cache manuellement) ; vous devez alors renommer tous vos fichiers statiques après chaque modification pour que les changements soient effectifs à tout un chacun. Personnellement, j'ajoute la date à laquelle j'ai modifié mes fichiers dans leurs noms comme ceci : maSuperCSS_150109.css, monSuperLogo_150109.png, etc. (il est aussi possible de passer la date en paramètre via l'url comme ceci : maSuperCSS.css ?date=150109).

Comment règle-t'on les en-têtes Expires et Cache-Control ? Ceci est très simple, c'est l'histoire de quelques lignes dans le fichier de configuration d'Apache (je ne parlerai ici que d'Apache étant le seul que je connais, désolé) si vous y avez accès, sinon vous pouvez les ajouter à un fichier htaccess à la racine de votre serveur. On pourrait tout à fait envoyer une directive pour Expires et une autre pour Cache-Control séparément (ce qui signifie un peu plus de lignes à coder) mais Apache 2.0+ nous propose un module qui se charge d'envoyer les deux tout en n'écrivant qu'une seule ligne par type de fichier (mime-type), pourquoi se priver ? Avant de vous donner un exemple de code, il est important de souligner que Cache-Control et Expires reviennent au même seulement Cache-Control est une version plus évoluée d'Expires apparue avec le protocole HTTP 1.1 pour répondre à des besoins plus spécifiques en proposant des paramètres optionnels poussés (Cache-Control prend alors le pas sur Expires si disponible) ; je ne rentrerai pas dans les détails sur ce billet mais en attendant, ceux que ça intéresse peuvent d'ores et déjà consulter cette page ou encore celle-ci qui traite de la mise en cache de contenu lié aux zones personnelles nécessitant une identification login/pass sur des réseaux partagés ...

Voici un exemple non exhaustif des directives les plus courantes que vous pouvez faire avec le fameux module mod_expires d'Apache : ExpiresActive On
ExpiresDefault "access plus 2 minutes"
ExpiresByType text/html "access plus 2 minutes"
ExpiresByType text/xml "access plus 2 minutes"
ExpiresByType application/xhtml+xml "access plus 2 minutes"
ExpiresByType application/x-shockwave-flash "access plus 1 day"
ExpiresByType text/plain "modification plus 1 day"
ExpiresByType image/vnd.microsoft.icon "modification plus 5 years"
ExpiresByType image/jpeg "modification plus 5 years"
ExpiresByType image/png "modification plus 5 years"
ExpiresByType image/gif "modification plus 5 years"
ExpiresByType application/javascript "modification plus 5 years"
ExpiresByType text/css "modification plus 5 years" On définit donc une ligne correspondant à la directive à adopter par défaut et/ou une ligne par type de fichier (dans l'ordre : html, xml, xhtml, swf, txt, ico, jpg, png, gif, js, css). Je vous l'avais dit, c'est très simple et c'est aussi très puissant permettant un réglage fin (années, mois, semaines, jours, heures, minutes, secondes) pour chaque type de composant. La date d'expiration peut aussi être absolue (modification plus ...) ou relative à la date à laquelle vos visiteurs viendront la première fois sur votre site.

Une dernière chose, j'avais parlé d'un intérêt de coupler les sprites à cette méthode de contrôle du cache client. En effet, si un visiteur arrive sur une page où il chargera une grosse image contenant des zones non utilisées (j'entends par là non affichées), cette image sera donc maintenant stockée dans son cache client, par conséquent si il parcours votre site c'est cette image stockée qui sera utilisée et uniquement pour toutes les autres pages (là ou seront affichées les zones précédemment non affichées). Autrement dit, on fait un pré-chargement valable pour tout le reste du site. Google notamment utilise cette technique.

Des questions ?

Un CDN (pour "Content Delivery Network" ou "réseau de 'livraison' de contenu" en bon français) est effectivement le mécanisme qui gèrera les réponses aux requêtes HTTP de vos visiteurs de manière à ce que vos fichiers leur soient acheminés par les chemins les plus courts possibles sur le réseau. Autrement dit, il s'agit de faire des économies en temps de réponse mais aussi en bande passante (et en heures de travail) car les CDN comprennent aussi leur propre gestion automatisée du cache client.

Utiliser un CDN c'est bien ; oui, utiliser un CDN c'est bien ...

D'après ce que j'ai compris ceci fonctionne plus ou moins comme un espace de stockage FTP sur lequel vous déposez vos fichiers et c'est tout. Vous devrez peut-être mettre à jour vos liens par la suite mais ça s'arrête là. En pratique on stocke donc tous les fichiers statiques (c'est à dire qui sont très rarement modifiés : css, js, swf, png, jpg, etc.) sur le CDN et tous les fichiers dynamiques (html, php, etc.) sur un serveur classique.

... Mais utiliser un CDN c'est cher !

Si votre site Web vous rapporte(ra), qu'il a pour vocation d'être internationalisé, que vous pouvez investir alors allez-y car le retour sur l'investissement devrait valoir le coup (chez Yahoo on parle d'une diminution des temps de réponse de 20% depuis qu'ils utilisent un CDN). Cependant dans la plupart des cas, les coûts liés à la mise en place et à l'utilisation d'un tel service sont rédhibitoires (soit plusieurs milliers d'euros par mois !) de même que cette utilisation n'est pas forcément justifiée (ceci dépend principalement de l'importance du site). Mon conseil est donc de passer outre cette règle d'optimisation (du moins pour l'instant), peu importe que YSlow vous octroie un méchant "F" tant que vous faites ce qu'il faut pour avoir un "A" resplendissant partout ailleurs.

Pour ceux qui souhaitent tout de même en savoir plus, j'ai trouvé cette page très bien faite où tout est détaillé comme il se doit et si ce n'est pas suffisant voici des liens directs vers les sites des trois fournisseurs de CDN cités par Yahoo : Akamai Technologies, Mirror Image Internet et Limelight Networks.

Cordialement.

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 ?