Your-Mix.Podcasting/Broadcasting

Externaliser le JavaScript et les CSS

MAXymeum Prod. — 2010-04-07T11:02:55Z

"Précédemment dans la série des performances sur le Web" : je vous avais expliqué qu'il est déconseillé d'utiliser les expressions CSS parfois pratiques mais souvent trop lourdes en recalcul. Parlons maintenant de la règle numéro 8 : externaliser le JavaScript et les CSS.

Avant de vous intéresser au domaine des performances sur le Web, vous avez probablement - comme moi - adopté le réflexe de produire un code de qualité ; sinon, au nom de l'Internet, faites le ! Cette généralité vaut pour bien des points de vue : accessibilité, référencement, performance, maintenance, etc.

Concrètement, au-delà d'un code bien structuré, du retrait d'un grand nombre de balises trop souvent inutiles, du respect de la sémantique et des standards, vous devez prendre l'habitude de séparer vos fichiers suivant leurs types : le HTML ne doit donc contenir que du HTML, idem pour le JavaScript et les CSS. Par la suite, les trois seront liés par un appel du CSS dans head de cette façon : et par un appel du JavaScript juste avant la fermeture du body de cette manière :

Comprenez par là que, dans la mesure du possible, on évitera avec acharnement les styles et évènements en ligne, soit une horreur du type : Mon beau lien magnifique ! dans ce cas, le style et l'évènement pourront facilement être déplacés dans des fichiers adéquats tandis qu'un simple attribut id en assurera la liaison.

On notera alors dans le HTML : Mon beau lien magnifique ! Dans le CSS : #fake{ display:inline-block; padding:10px; background:#f00; border:1px solid #0f0; color:#00f } Enfin dans le JS : document.getElementById('fake').onclick = function(){ alert('En fait mon lien est un fake !'); return false };

Bon, tout ceci est bien beau mais en fait pourquoi ? Prenons l'exemple d'une maison : il faut voir le HTML comme ses fondations, les CSS comme ses peintures ou sa décoration et le JavaScript comme l'électricité (ça n'est théoriquement pas vital mais apporte du confort). De là, on se rend bien compte que seul le HTML (réel contenu) est pleinement important, le reste est une sur-couche agréable sans laquelle votre site se doit d'être pleinement fonctionnel (structuration du code, respect de la sémantique et des standards W3C obligent). Cette séparation est naturellement simple à comprendre pour les CSS ; pour le JavaScript, on parlera d'intrusivité.

Mais revenons au sujet des performances, j'avais parlé de réduire le nombre de requêtes HTTP, pour ce faire il est certes préférable de regrouper tous vos fichiers du même type en un seul quand cela est possible ; mais vous avez bien lu : "du même type". De ce fait, vous profiterez du cache. Délocaliser vos styles et scripts dans des fichiers dédiés décroit remarquablement le poids du HTML qui chargera donc plus vite ; pour le reste, le cache règlera le problème des requêtes HTTP indésirables pour les prochaines visites. D'une pierre deux coups !

Malheureusement, ceci n'est pas une science exacte. En théorie, pour des pages sur lesquelles les visiteurs n'auront pas à revenir plusieurs fois, le cache se révèlera alors inutile et il vaudra mieux privilégier la disposition en ligne (théoriquement car ce type de code est difficile à maintenir). Il est aussi possible de combiner les deux techniques comme le précise Yahoo : profiter des quelques bienfaits de la disposition en ligne et télécharger dynamiquement des fichiers externes après la fin du chargement de la page.

Conclusion : séparer vos types de fichiers est souvent la meilleure solution.

Cordialement.

Brèves et petite mise au point

Sebastien P. — 2010-03-29T09:11:18Z

Bonjour, me revoici en mode blogueur pour vous apporter quelques nouvelles sur le futur du projet Your-Mix. Certaines sont bonnes, d'autres moins ; à vrai dire tout dépend du point de vue. Du mien, il s'agit d'un simple tournant, d'une évolution dans mes goûts ; une toute nouvelle naissance pour Your-Mix en quelque sorte ...

Commençons par quelques petites brèves :

Concernant le retour du module de commentaires du blog (ainsi que de celui des statistiques qui affiche toujours zéro), il se fera en même temps que le passage au nouveau design.

Pour ce qui est du passage au nouveau design, je n'ai malheureusement toujours pas de date précise à avancer mais peut-être que je posterai quelques captures d'écran sur le Twitter ou mon Twitter afin de vous faire patienter.

Ma série d'articles sur les performances du Web vous intéresse beaucoup, tout comme moi ; sachez-le, je suis de retour en mode blogueur, attendez vous à du contenu dans les prochains jours !

Ceci fait, passons maintenant aux choses sérieuses :

Je suis de très près les évolutions du Web depuis maintenant une dizaine d'années durant lesquelles j'ai beaucoup appris mais face aux réels et assez récents changements qu'apportent le HTML 5, les CSS 3 et l'Internet mobile mes intérêts se sont recentrés. Toutes ces technologies sont prometteuses, tellement que j'ai eu envie de m'y plonger entièrement. Le modèle que proposait alors Your-Mix (création, gestion et promotion de Podcasts musicaux) me parait aujourd'hui avoir un peu mal vieillit. Cependant, il contient quelques bonnes idées qui m'ont convaincu de ne pas l'abandonner totalement. L'ancien Your-Mix (Podcasting/Broadcasting) est donc officiellement en pause pour une durée indéterminée (probablement le temps qu'il faudra aux navigateurs modernes pour supporter pleinement l'audio sous HTML 5).

À quoi devez-vous donc vous attendre ? Eh bien c'est simple, Your-Mix - dont le blog seulement était accessible jusqu'alors - deviendra un blog à part entière. Un blog abordant les même sujets qu'aujourd'hui mais de manière plus poussée avec une place certaine pour des exemples de code. Your-Mix sera aussi le portail d'accès à mes projets actuels tels que YMslider, YMjsonp (traitement des résultats obtenus via les API à la mode et JSONP), sebastienp.net (sorte de CV et vitrine jQuery/performances encore en construction) et surtout YMiNgin : imaginez créer des interfaces utilisateur pour vos applications Web et natives iPhone/iPad en HTML 5/CSS 3, sans rien coder et surtout entièrement personnalisables ! On aura l'occasion d'en reparler dans ces pages rassurez-vous.

Voilà, je pense n'avoir rien oublié, j'espère aussi ne pas trop vous décevoir même si YMiNgin devrait plutôt vous mettre l'eau à la bouche. Je suis de retour, avec beaucoup de bonnes choses et donc beaucoup à raconter !

Cordialement.

Nouveau design du site à venir

Sebastien P. — 2009-11-21T09:24:31Z

Bonjour, comme vous avez-pu une nouvelle fois le constater, le blog est resté de nombreuses semaines en inactivité, je me devais donc d'éclaircir un certain nombre de points ne serait-ce qu'au regard des abonnés à mon flux RSS qui me font tout de même confiance, merci à vous !

Alors voilà, ayant décidé d'ouvrir ma future plateforme Your-Mix à tout Podcasteur et non plus seulement aux DJs, le design actuel n'était pas suffisamment extensible pour me permettre de mener à bien ce changement d'orientation. Il m'a alors fallu travailler d'arrache pied sur une nouvelle version du site sans pour autant avoir assez de moments de libres pour la sortir rapidement.

Qui plus est, j'ai développé plusieurs fonctionnalités sympathiques à l'aide du framework JavaScript jQuery qui - en plus du nouveau Web design m'ont pris énormément de temps, je n'ai d'ailleurs toujours pas terminé mais vous pourrez par exemple jeter un oeil à mon plugin YMslider sur Google Code (plugin de défilement de contenu) qui sera mis à jour en version 1.0.5 dans les heures à venir.

Bref, Your-Mix n'est pas mort, je n'ai pas non plus décidé d'abandonner ce Blog ainsi que les règles de performances YSlow. Vous devrez simplement me faire confiance et attendre encore un peu.

Je vous en remercie d'avance d'autant que vous êtes de plus en plus nombreux chaque jour à vous abonner à mon flux RSS alors que je ne poste rien de nouveau depuis des semaines.

Cordialement.

Stage et nouveautés Your-Mix

Sebastien P. — 2009-04-21T11:51:21Z

Bonjour, comme vous avez-pu le constater, suite à ce billet vous expliquant pourquoi, le blog est resté de nombreuses semaines en inactivité, période durant laquelle nous n'avons pourtant pas chômé, bien au contraire ...

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 ...

Eviter les expressions CSS

Sebastien P. — 2009-04-20T20:19:09Z

"Précédemment dans la série des performances sur le Web" : je vous avais expliqué qu'il est bénéfique et donc conseillé de déplacer toutes vos lignes d'appel de script juste avant de refermer la balise body. Parlons maintenant de la règle numéro 7 : éviter les expressions CSS.

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.

SPIP 2.0.3, JQuery UI et stage

MAXymeum Prod. — 2009-02-16T09:47:00Z

Un peu de nouvelles concernant l'avancée des travaux ne fait pas de mal. Après la finalisation de la version 1 beta révision 9 de notre player DJ et notre choix de ne rendre cette mise à jour disponible au public qu'en même temps que les pages dédiées aux DJs (car les deux sont étroitement liées), qu'en est-il du développement de ces dites pages ?

À 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.

... et le JavaScript très tard

Sebastien P. — 2009-02-15T11:06:00Z

"Précédemment dans la série des performances sur le Web" : je vous avais expliqué pourquoi séparer vos CSS de vos HTML dans un - seul - fichier dédié appelé dans head via la balise link permet un rendu progressif et donc un chargement plus rapide pour vos pages. Le cas inverse s'applique alors pour vos codes JavaScript, c'est la règle numéro 6 : mettre les scripts en bas.

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.

Appeler les CSS très tôt ...

Sebastien P. — 2009-02-02T11:04:00Z

"Précédemment dans la série des performances sur le Web" : je vous avais expliqué comment compresser vos composants à base de texte côté serveur via la méthode Gzip (ou Deflate). La conclusion à tirer de cette amélioration était son rapport efficacité/ressources élevé. En effet, pour une petite ligne de code, vous et vos visiteurs y gagnerez beaucoup ! Parlons maintenant de la règle numéro 5 : mettre les CSS en haut.

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.

Player v1 Beta révision 9

MAXymeum Prod. — 2009-01-29T09:46:00Z

Comme nous l'avions annoncé dans ce billet, une nouvelle mise à jour de notre DJ Web MP3 Player en version 1 Beta révision 9 était dans les cartons, prévue pour être rendue publique courant Janvier 2009 ; c'est maintenant chose faite ... ou presque ...

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.

Compression Gzip ou Deflate

Sebastien P. — 2009-01-23T11:03:00Z

"Précédemment dans la série des performances sur le Web" : je vous avais expliqué comment stocker vos composants dans le cache navigateur de vos visiteurs et comment définir une date d'expiration dans le lointain ou proche futur. Cette règle d'optimisation était très importante et permettait d'économiser beaucoup de ressources et de temps de chargement. Passons à la règle numéro 4, toute aussi importante : compresser les composants avec Gzip (ou Deflate).

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 ?