Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear.

On peut regretter l’expiration très courte (une journée) accompagniée d’un must-revalidate, mais je me permet d’insister avec intérêt sur le Cache-Control: public très important dans le cas d’une application PHP. EzPublish utilise très probablement les sessions PHP, qui ajoutent par défaut un Cache-Control: private. il faut donc le corriger.

Dans un autre billet on voit le résultat sur le squid de la gestion du cache des images et de la compression HTTP :

Dans une seconde partie il nous parle de compression d’images. Là aussi les solutions sont connues mais c’est appréciable de voir quelqu’un le mettre en œuvre et en parler ensuite. Sur les PNG il identifie un gain moyen d’un tiers pour le poids des images. C’est plus que conséquent, et ça aura un effet visible et sur le client et sur votre infrastructure. Je me permet juste d’apporter un bémol sur l’utilisation du paramètre -brute de pngcrush, qui est loin d’être le meilleur compromis gain/temps.

Toutefois, une fois dépassé ce stade il faudrait se détacher un peu des chiffres pour parler de performance ressentie et pas toujours de performance mesurée. Parfois peu importe la durée de l’attente si on voit que nous progressons régulièrement et que l’attente n’est pas frustrante en elle même. C’est vrai aux caisses d’un supermarché comme sur une page web.

Les éditeurs de navigateurs l’ont bien compris. Ils jouent sur les indicateurs de chargement et sur l’interface pour donner une impression de vitesse à l’utilisateur. L’impression de vitesse est l’unique chose qui compte pour ce dernier, même si au final ça veut dire que les temps mesurés sont objectivement plus lents.

C’est avec cette idée en tête que je vous propose de lire le document de Mozilla à propos de la performance perçue. On y retrouve certaines techniques à mettre en oeuvre sur les versions actuelles ou futures de Firefox. Le document mériterait une traduction tellement il fourmille d’idées, dont certaines sont lumineuses.  Je vous en retransmet certaines, avec mes commentaires.

Dans les « on reste très classique »

Préchargement de Firefox au démarage de windows : On va _encore_ ralentir l’ouverture de session pour pouvoir avoir une ouverture quasi instantanée de Firefox lors du clic sur l’icone. Le résultat sur le ressenti de performance est évident mais je suis assez mitigé. J’en ai ma claque des sessions qui prennent 5 minutes à s’ouvrir à cause de tout ce qui est chargé dans le systray. Là on déshabille Paul pour habiller Pierre et on donne l’impression à l’utilisateur que c’est la faute de Paul. Je comprend l’effet mais je n’aime pas le principe.

Garder le logiciel ouvert un bref moment après sa fermeture, au cas où l’utilisateur le réouvre juste après : Ca me fait penser à la fermeture de session de mon poste Linux. Il prend en compte mais n’éteint le poste que 60 secondes après la demande (sauf si je confirme ma demande), me laissant la possibilité de changer d’avis. J’aime bien le principe mais normalement l’OS fait une partie du travail en mettant en cache toutes les bibliothèques logicielles. Normalement un second démarage est déjà plus rapide. Si ce n’est pas le cas je préfèrerai qu’ils trouvent pourquoi plutôt que de chercher des astuces (oui, je sais, c’est facile à dire).

Installer un intersticiel (splash screen) : C’est assez dangereux. D’un côté on donne immédiatement un feedback à l’utilisateur, ce qui est très bien pour donner une impression de réactivité et éviter qu’il lance deux fois le navigateur en pensant que ça n’a pas fonctionner (je compatis, ça m’arrive régulièrement), de l’autre on va renforcer l’idée de l’utilisateur qu’il s’agit d’un logiciel long à charger alors que d’autres sont instantanés sans intersticiel.

Dans les « c’est astucieux »

Accélérer l’indicateur de chargement : Ils disent qu’ils le font à chaque version. Un indicateur qui tourne plus rapidement c’est pour l’utilisateur un logiciel qui fonctionne plus rapidement. C’est idiot mais on a tous le même ressenti inconscient. Par contre on va vite arriver à une limite pour ce genre d’astuces.

Avoir une progression non linéaire pour l’indicateur de progression : Faire qu’il avance plus lentement au début (quand l’utilisateur accepte l’attente) et plus rapidement vers la fin (quand il en a marre et a besoin de voir que « ça avance bien »). Dans le même ordre d’idée la suggestion précédente propose de faire accélérer l’indicateur de chargement (celui qui tourne) avec le temps.

Dans la catégorie « ça c’est génial »

Utiliser les composants en cache en attendant de vérifier qu’ils sont toujours frais : J’adore l’idée. Il s’agit d’utiliser les feuilles de styles, les images en cache en parallèle aux requêtes HTTP de revalidation. S’il s’avère que le contenu a changé, alors on mettra la page à jour. On tient là une réelle avancée. Il faudrait peut être toutefois montrer à l’utilisateur que l’image en question est potentiellement temporaire (par exemple la griser légèrement, ou monter le gamma : l’image reste visible mais on voit qu’elle est « en cours »).

Dans le même ordre d’idée on propose, à défaut de réutiliser les images elles-mêmes, de réserver la place dans le rendu en fonction de la taille de l’image qui est en cache. On évite de trop triturer la page, ce qui est une bonne chose, mais là je suis moins enthousiaste. Sur une page ou une connexion lente, ça peut inciter à réserver des places vides pendant longtemps, et déteriorer le ressenti utilisateur au lieu de l’améliorer. Je préfère nettement l’idée d’utiliser l’image elle-même, car l’utilisateur a au moins un contenu utile.

Mieux, on propose même de lancer immédiatement des requêtes vers les scripts et feuilles de styles référencées dans la page en cache en attendant de recevoir la nouvelle page. C’est quelque chose qui peut réduire le chargement de la page de plusieurs centaines de milli-secondes, plus sur les pages HTML vraiment lentes. Je ne sais cependant pas si le rapport bénéfice sur complexité est assez intéressant pour que ce soit implémenté. Il faudrait en effet que ces requêtes aient une basse priorité par rapport aux autres requêtes (histoire qu’on ne précharge pas en priorité des choses qui sont potentiellement inutiles) et que ces requêtes soient annulées dès qu’on sait que la page HTML a changée.

Plus intéressant encore : charger la page à partir du cache en attendant que la nouvelle page soit chargée. L’idée est intéressante mais la réalisation risque d’être difficile. La page en cache fait probablement référence à des composants qui eux ne sont pas en cache (les pubs) ou peut faire des requêtes Ajax. Est-ce pertinent d’occuper le réseau avec cette ancienne page ? Pire, on va aussi occuper le cpu puisque beaucoup de sites ont des pages qui mettent un temps significatif à effectuer le rendu même quand tout est en cache. On risque de ralentir inutilement la machine.

Pourquoi dis-je que c’est encore plus intéressant alors que je détruis l’idée ? parce que j’avais ça sur Safari (si je choisis une des pages proposées au démarage c’est d’abord une image de la page en cache qui se charge le temps que la page réelle arrive) et j’ai ça depuis peu sur gmail (le temps que gmail se charge j’ai une version HTML non clicable des titres des quelques derniers mails de ma boite). Ca a l’air inutile mais ça améliore vraiment l’expérience. On peut se concentrer immédiatement sur la tâche prévue au lieu d’attendre que la page se charge. La performance ressentie c’est finalement surtout ça.

Alors ?

Je laisse les histoire d’indicateurs plus ou moins rapides à d’autres mais je verrai bien les effets suivants (cumulatifs) :

• S’il s’agit d’une page fréquemment visitée (en bookmark ?) charger une image de la page telle qu’elle était la dernière fois en attendant que la page se charge effectivement. Point bonus si les liens restent clicables (mais je n’ai pas besoin des autres interactions avec la page comme le javascript).
• Quand la page arrive, on utilise par défaut immédiatement les précédentes versions des images et feuilles de style en attendant les nouvelles. Les images sont toutefois grisées/blanchies pour bien symboliser l’état « en chargement ».

Notez que cela demande d’augmenter l’espace dédié au cache, et pour les pages ciblées de mettre en cache même ce qu’habituellement on n’y met pas (quitte à identifier que c’est un cache déjà expiré).

On y retrouve une réflexion sur comment regrouper les fichiers javascripts entre eux et comment les compresser. La note sur mod_gzip est toutefois assez contestable. Il est désormais sans risque d’activer mod_gzip ou mod_deflate, et ceux qui veulent absolument éviter tout risques peuvent trouver facilement sur internet des listes d’exclusions pour cibler les navigateurs défectueux.

La politique de cache est intéressante à étudier. Ils ont évité les paramètres en ?xxx et ont choisit de versionner le nom de fichier directement. Pour éviter d’avoir à créer un fichier par version, c’est à mod_rewrite qu’il revient de faire la liaison entre l’url et le fichier à jour. Les adresses main.v27.css et main.v256.css mènent toutes vers le même fichier main.css, toujours à jour.

Au final ils passent encore par un script PHP pour délivrer leurs fichiers javascript et css au lieu d’utiliser mod_expires, mais vous avez une expérience concrête, et reproductible en une journée pour améliorer vos performances.

Les absolus

Quoi que vous disiez, quoi que vous fassiez, si le serveur vous a répondu avec un code d’erreur 400, le navigateur devrait mettre en cache se résultat et ne pas refaire la même requête. C’est plutôt logique pour une requête que le serveur a considéré comme invalide.

Quoi que vous disiez, quoi que vous fassiez, si le code de retour était 303 ou 307, le navigateur ne devrait pas mettre en cache ce résultat. La redirection est temporaire, marquée comme telle, mettre en cache du temporaire c’est faire du permanent, donc contredire la réponse.

L’heuristique

S’il s’agit d’une requête de type GET avec un code de retour 200, 203, 206, 300, 301 ou 410, alors le navigateur ou le proxy sont encouragés à mettre en cache suivant leurs propres heuristiques. Le plus souvent la page HTML elle-même n’est pas mise en cache par défaut, mais les composants référencés par cette page sont mis en cache pour la durée de la session.

Il est à noter que la spécification HTTP 1.1 prévoit la fonctionnalité de retour arrière des navigateurs et incite le navigateur à réutiliser la page précédente sans la réactualiser, quand bien même elle aurait expiré. Le visiteur l’a déjà vu, il s’agit de lui représenter là où il était avant, pas de revenir sur la page actualisée.

L’invalidation

Quand le serveur répond à une requête POST, les versions en cache de cette URI ou de celle dans les entêtes Location ou Content-Location doivent être effacés. Ceci implique immédiatement que par défaut une requête POST ne sera pas mise en cache.

La spécification HTTP 1.1 va même un peu plus loin en prenant en compte l’usage des paramètres de requêtes dans les URI. Certains utilisent ainsi des paramètres en GET pour réaliser des actions qui devraient être faites en POST (puisque provocant un changement dans l’entité résultat). Pour y palier, HTTP 1.1 demande à ce que ces requêtes (contenant un point d’interrogation dans le chemin) ne soient pas mises en cache quand bien même elles seraient faites avec le verbe GET.

Petite note : Si vous renvoyez un document avec une entête Date inférieure à celle qu’avait eu le navigateur la dernière fois, cette réponse ne devrait être pas mise en cache.

La déclaration explicite

Maintenant, hors les premiers cas absolus, les entêtes explicites ont priorité. Une entête Cache-Control à public, private, ou no-cache change le comportement par défaut. Un max-age ou Expires impose un cache et un must-revalidate impose une revalidation, même si ces règles contredisent le comportement par défaut pour la ressource en question.

Enfin, les caches sont toujours dépendants de l’entête Vary, qui permet de restreindre le cache à un navigateur, ou des visteurs avec un certain cookie, etc.

Je ne parle même pas de ce que pourraient nous apporter HADOPI et LOPSI2 s’ils filtrent les accès côté FAI (on peut leur faire confiance pour affirmer que les débits ne bougeront pas, mais en ce qui concerne la latence…). À 120ms de latence c’est d’un coup plusieurs secondes qui partent en fumée. En fait ce sont souvent les publicités qui ont la plus grande latence. Quand le javascript qui gère la pub est bloquant et qu’on a deux ou trois redirections HTTP, on peut facilement perdre une seconde. Si vous ne me croyez pas, regardez l’exemple de Right Media.

Les solutions

Pour aller plus vite il faut donc soit avoir moins de composants par page, soit faire en sorte que la latence entre ces composants et le visiteur est réduite. Moins de composants c’est renouveler des solutions que j’ai déjà abordé ici : mettre en cache tout ce qu’on peut, container les fichiers javascript, faire de même avec les feuilles de style, et explorer les sprites CSS pour les images. Réduire la latence elle-même est par contre plus complexe. Comme on ne peut pas d’un coup de baguette magique améliorer la connexion du visiteur (quoi que certains tentent de jouer avec TCP), il ne reste plus qu’à approcher le serveur au maximum près du fournisseur d’accès du visiteur.

Pour un public français c’est réalisable, les FAI français font du peering entre eux, tout est regroupé entre quelques gros, la latence due au placement géographique est probablement proche de zéro (pour un site américain, avoir des serveurs sur les deux côtes au lieu d’une seule fait une réelle différence par contre). Sauf qu’assez souvent ce n’est pas un site français c’est un site francophone, ou adressé aux français (qui sont peut être en déplacement). Reste que même pour un site non touristique qu’on croit adresser aux français métropolitain, il y a des requêtes qui viennent des DOM TOM, des pays limitrophes, des pays européens (oui, je travaille tous les jours de Paris avec une adresse IP londonienne ) et finalement d’un peu partout dans le monde (je suis toujours étonné de voir les statistiques géographiques de ce blog).

Content Delivery Network

L’idéal serait donc d’avoir un serveur local chez chaque FAI. Malheureusement on se doute bien qu’au niveau coûts c’est infaisable, d’autant plus s’il faut les synchroniser. Les CDN, puisque c’est comme ça que ça s’appelle (Content Delivery Network, réseau de distribution de contenu), se placent à quelques endroits géographiques, avec des liens réseaux spécifiques vers les FAI principaux et entre les différents emplacements. Amazon propose donc quatorze emplacements, huit aux USA, quatre en Europe (Londres, Dublin, Amsterdam et Francfort), ainsi que deux en Asie (Hong Kong et Tokyo). Akamaï, le leader, propose 71 pays différents (et probablement plusieurs emplacements aux USA).

Dans l’ensemble sur les CDN donnant des listes précises, les pays du nord et les USA semblent les mieux couverts mais ce peut être un biais du à mes sources d’information. N’ayant pas eu à faire de recherche spécifique  l’Asie l’Afrique ou l’Europe ont peut être quelques CDN spécifiques. À vous de fouiller dans la cinquantaine de CDN dans le monde. Akamaï propose une petite application pour constater la latence entre deux villes. Bon, c’est visiblement très biaisé, mais le principe est bien là, lui.

Fonctionnement

Sur le principe un CDN ce n’est pas bien compliqué. Il s’agit de modifier le DNS pour faire pointer vers celui du CDN. Là on utilise des DNS personnalisés chez différents FAI, ou un système de tracking géographique des adresses IP pour renvoyer les différents utilisateurs chacun vers le serveur le plus proche de chez eux. Le serveur lui même est soit pré-rempli avec tous les composants utiles, soit fonctionne comme un proxy évolué (ce qui demande que vous même gériez correctement toutes vos entêtes de cache).

Dois-je utiliser un CDN ?

Pour un petit site français, pas certain. Pour un site plus gros, cela peut permettre de déporter les coûts de serveurs et de bande passante, c’est uniquement une question financière. Par contre, dès que vous visez plus international, en dehors de la simple Europe occidentale, ça peut commencer à prendre son sens. Les coûts sont assez progressifs et abordables même pour une petite société (Akamaï part à partir de 150$/mois, Amazon a un prix au consommé qui semble ridicule pour des petits trafics).

Une seule chose, ne vérifiez pas l’efficacité depuis votre bureau français, avec une faible latence. Au mieux entre un CDN avec un serveur à Paris et votre propre serveur parisien, il n’y aura pas grande différence. Il se pourrait même que le CDN semble ralentir vos pages (vu qu’il faudra peut être joindre Londres pour certains réseaux). Par contre pour d’autres, aux DOM TOM ou à l’étranger, la différence sera notable. Un petit coup par webpagetest peut donner un premier aperçu si vous le souhaitez.

Au pire, rien ne vous empêche de fournir un lien directement vers votre serveur quand le visiteur est dans la même zone géographique, et un lien vers le CDN sinon. Une petite reconnaissance de l’adresse IP devrait suffire et le risque de dégrader les performances en cas d’erreur est assez faible.

Oui il faut, quand vous le pouvez, utiliser les liens centralisés de Google ou de Yahoo pour vos bibliothèques javascript. Je parle de ne pas recopier jquery ou yui directement sur vos serveurs, mais d’utiliser les liens centralisés proposés par les deux moteurs de recherche.

Voilà pour la réponse générique, ensuite on peut détailler un peu.

Content delivery network

Le premier gain c’est l’utilisation des CDN de Yahoo! et de Google. Le principe du CDN c’est plus ou moins placer des serveurs dans plusieurs pays, voire directement chez les FAI, pour que le trajet fait sur le réseau soit le plus court possible. On vise une latence réduite. La latence ça peut tuer un site web.

Seuls les plus gros sites web peuvent s’offrir des CDN. Profiter de Yahoo! ou Google c’est toujours appréciable.

Maintenant vous n’utiliserez qu’une seule grosse bibliothèque javascript. En échange vous allez utiliser un nom de domaine supplémentaire, donc une requête DNS supplémentaire et une connexion de plus. Le deal est intéressant si ce qu’on gagne en latence dépasse ce que coûte la requête DNS.

Soyons clairs, si vos contenus ne sont pas sur le même continent qu’une partie sensible de vos clients, alors c’est un bon deal, n’hésitez pas. Aux États-Unis, éviter de traverser de l’Alaska vers New-York, c’est du temps gagné, non négligeable. Mais en même temps les sociétés vraiment internationales ont déjà souvent un hébergement par pays ou continent, ou utilisent déjà un CDN.

Si vous restez en Europe occidentale ça devient déjà moins clair. Si vous êtes hébergés en France dans un gros datacenter et que vos clients sont en France … là pas sur que le bénéfice du CDN soit réel. Les FAI ont des liens de peering entre eux et avec les hébergeurs français, la latence est globalement faible dès le départ. (Note: ceci n’a pas été vérifié par des tests, je suis preneur d’avis et de retours d’expérience sur la pertinence de CDN pour un trafic français avec un hébergement en France)

Nombre de domaines

Le second aspect de ces caches centralisés c’est le fait qu’ils sont justement sur un domaine séparé. Il y a du pour et du contre.

Dans le pour, votre Javascript peut être téléchargé immédiatement même si les files de téléchargement sont déjà occupées avec d’autres éléments de votre site. Maintenant comme on définit souvent ce genre de bibliothèques javascript tout en haut de page, les files de téléchargement sont généralement vides à ce moment là de toutes façons. Bref, je ne suis pas convaincu.

Toujours dans le pour, si votre navigateur est très récent (comprendre : IE 8, Safari 4, Firefox 3.1) le javascript ne bloque pas les autres téléchargements. Là aussi, avoir un domaine différent évite d’utiliser un slot dans vos autres téléchargements. En pratique, avec six slots simultanés minimum sur ces navigateurs, je ne suis pas convaincu que cela fasse une différence fondamentale.

Bref, pas convaincu, sachant qu’il y a du contre qui s’ajoute : avec un nom de domaine en plus, comme on l’a vu, il y a une requête DNS supplémentaire. Est-ce que ça vaut le coup pour un unique fichier ? pas sûr du tout.

Cache centralisé

Troisième aspect, en utilisant les liens de Google et Yahoo! on finit par tous utiliser les mêmes URL pour nos bibliothèques javascript.

Le résultat c’est que pour les bibliothèques les plus populaires, cela augmente la probabilité que vous l’ayez déjà en cache à cause d’un site précédent. Là le gain est important, surtout pour vos pages d’accueil (celles qui ont le plus gros trafic « cache vide »). Reste qu’en réalité l’URL contient la version de la bibliothèque et tous les sites n’utilisent pas les mêmes versions, ou même les mêmes bibliothèques. La mutualisation est assez limitée et le gain reste à prouver.

L’avantage concret est par contre visible pour les entreprises et pour les universités. Ces dernières ont des proxys cache qui auront toutes les chance d’avoir déjà votre bibliothèque en cache, dans la bonne version. Sur la cinquantaine (ou le millier) de collègues, il y en aura bien un qui aura téléchargé la bibliothèque avant vous.

La question est donc, vos visiteurs sont-ils sur des lignes professionnelles ou des lignes de particuliers ? dans ce second cas le gain n’est pas évident.

Mais alors, pourquoi répondre « oui » ?

Parce que je parlais jusqu’à maintenant du cas idéal. Si vous avez déjà un CDN, que vos ressources statiques sont déjà sur domaine séparé, et que vos entêtes de cache sont bien réglées, alors gardez vos bibliothèques chez vous. Mais … ce n’était le cas pour aucun de ceux qui m’ont posé la question.

En fait je doute que ce soit le cas pour quiconque se pose la question. Ceux qui ont déjà fait tout le chemin de performance avec CDN, domaine tiers et entêtes de cache, ils ont souvent les moyens de tester eux même quelle est la meilleure solution. Ou mieux, ils ont déjà réalisé que pour éliminer une requête HTTP il faut déjà fusionner leur bibliothèque javascript avec leur code javascript spécifique. Bref, la question est sans objet pour eux.

Pour les autres, qui n’ont pas les moyens d’utiliser un CDN quand bien même ils en auraient besoin, ou qui n’ont pas déjà un domaine séparé pour les ressources statiques, ou qui ne gèrent pas correctement leurs entêtes de cache, pour eux c’est intéressant. Ce n’est pas parfait, mais c’est un mieux, une démarche d’amélioration progressive. Pour vous, qui vous posez la question, la réponse est probablement « oui, utilisez les liens de Yahoo et Google pour vos bibliothèques javascript ». Et puis … ça fait autant de bande passante en moins à payer.

En cas de doute, le « oui » a plus de chance d’être positif ou sans effet que de réellement être négatif.

Reste que compresser les images correctement c’est long. Smushit accélère tout ça mais c’est du one shot. Ce qu’il faut c’est intégrer des outils comme optipng dans votre processus de publication.

Alors voilà, pour un gros site au travail c’est réalisable avec un peu d’investissement. Sur un site de moindre importance c’est tout aussi important mais l’investissement devient lourd. C’est là que des outils automatiques sont intéressants, et le premier que je vous propose est un plugin wordpress, wp-smushit, qui envoie automatiquement vos images à smushit. Plus besoin d’opérations manuelles, wordpress s’occupe de tout.

Le second que j’ai croisé est un script PHP qui prend la main sur tout téléchargement CSS ou Javascript : SmartOptimizer. PHP permet de concaténer, minimiser, compresser, et envoyer avec les entêtes de cache appropriées. Le résultat côté serveur est bon, mais je reste dubitatif sur l’idée de faire passer par PHP toutes les ressources statiques. Les ressources serveur vont souffrir de manière importante, et si vos serveurs deviennent lent votre performance client ne va finalement pas y gagner.

Une mise à jour attendue …

J’avais, comme tout le monde, deux principaux reproches à faire sur l’outil. Tout d’abord il ne vérifie qu’une liste très spécifiques de critères. Ce sont une partie des 14 premiers critères retenus par l’équipe performance de Yahoo! mais depuis d’autres recommandations ont pu être dégagée. Il était nécessaire que l’outil s’étoffe.

C’est donc 10 règles supplémentaires qui sont intégrées dans l’outil, pour un total de 23. Mais là où Yslow aurait pu avoir une simple mise à jour, l’équipe Yahoo! a permis l’arrivée d’un modèle communautaire, où chacun peut ajouter facilement ses propres critères. C’est l’histoire de quelques lignes de javascript dans une extension Firefox.

Le second point contestable était le système de notation. Toutes les règles ne sont pas adaptables à tout le monde, avec la même importance. Le premier exemple c’est la question des ETags qui pénalise des notations pour rien, soit parce que l’ETag n’est pas généré avec le système par défaut d’Apache, soit parce qu’il n’y a qu’un seul serveur web derrière le site. Chacun a ses spécificités et je retiens encore l’exemple qu’on m’a donné des sites chinois qui ont tendance à avoir des pages web longues de plusieurs dizaines d’écran parce les usages locaux font qu’on télécharge la page pour une lecture hors ligne, et qu’on espère donc en avoir le plus possible dedans quitte à attendre longtemps.

Bref, là aussi Yslow est personnalisable et il sera possible de définir vos propres algorithmes de notation, voire de choisir le type de notation souhaité parmi une liste. À vous de définir vos limites, vos paliers, vos pénalités et les règles qui sont pertinentes à votre site … ou plutôt à choisir un algorithme créé par quelqu’un d’autre et adapté à votre cas. L’idée est de non seulement pouvoir modifier ces préférences via une interface mais aussi de pouvoir les exporter automatiquement pour les diffuser à d’autres.

… et efficace …

Bref, c’est une très bonne nouvelle, qui va permettre de voir fleurir des personnalisations de Yslow propre à certains types de sites, aux recommandations internes de votre société, ou simplement adaptées à votre échelle. Je m’abstiens de recopier les images ou le code, vous trouverez tout ça dans la présentation de Stoyan.

Mais on trouve encore d’autres petits outils. Parmi eux des menus pour réindenter le code javascript et faire un passage par JSLint. Là encore, quelques lignes de javascript sont prévues pour rajouter vos propres outils.

Mieux, et ça c’est excellent, il est prévu de sauvegarder votre session de résultat pour une étude plus tard et d’importer de sessions crées par Fiddler ou HttpWatch.

… mais imparfaite

Mais tout n’est pas parfait. Dans les recommandations on trouve la #14 (Make Ajax cacheable). Difficile à dire pour un outil automatisé s’il est normal que tel ou tel appel Ajax soit en cache ou dynamique. Je suis dubitatif sur l’idée d’avoir automatisé cette règle là. Même chose pour la #33 (Components under 25k). La limite de 25k est celle de l’Iphone, mais on a vu que les nouveaux firmware Iphone et Ipod Touch permettent de dépasser allègrement cette limite. Bref, on l’ajoute dans Yslow quand il serait presque venu le temps de la retirer de la liste globale des recommandations.

Il y en a d’autres que j’aurai aimé voir, mais qui doivent être bien plus complexes à automatiser. Par exemple :

• trop de présentation en HTML au lieu de CSS
• code javascript lent
• présence de eval() en javascript
• sélecteurs CSS vraiment mal fait
• événements DOM mutualisables avec de la délégation
• processeur excessivement utilisé lors du rendu
• tableaux html dynamique trop gros ou imbriqués

Ah et … pas de date de sortie ni de version béta publique, pour l’instant. Reste que ces nouvelles sont bonnes.

Apple lui même met clairement en avant les performances de la navigation iPhone, au point de tricher dans ses publicités en montrant un scénario de navigation accéléré par rapport aux situations réelles (la publicité a d’ailleurs été interdite au Royaume Uni à cause de cela).

Reste que la bataille des performances n’est pas gagnée.

Encore il y a peu nous parlions d’un cache HTTP limité à 25ko par composant sur l’iPhone, 500ko au total. On parle de la taille une fois la ressource décompressée (sans gzip donc). 25ko c’est peu, la plupart des sites ont un composant qui dépasse cette taille. 500ko ce n’est pas beaucoup mieux, naviguez sur un ou deux sites et le cache aura complètement oublié vos précédentes visites. Pire, des bibliothèques javascript comme jquery dépassent les 25ko et donc ne passeront jamais dans le cache.

Moins de restriction par composant

La bonne nouvelle c’est que cette limite est désormais dépassée. Une présentation de Nicole Sullivan indique que la limite des 25ko a disparue, et que la taille globale du cache a été doublée.

Malheureusement je n’ai trouvé aucune autre source d’information, donc avec Anthony Ricaud nous avons lancé un petit test. Le résultat c’est que l’iPhone 3G (firmware 2.1) met bien en cache les images de plus de 25ko. Je n’ai pas tenté de trouver la limite, mais une image de 180ko part dans le cache correctement.

Mais un racisme anti-HTML

La mauvaise nouvelle c’est que dans nos tests Safari iPhone ne met jamais en cache la page HTML principale. Nous avons tenté des entêtes d’expiration explicites, des pages de 3ko. Rien n’y fait. la page elle-même est à chaque fois retéléchargée par l’iPhone alors que sur mon Safari Mac classique, lui, se sert bien du cache.

C’est un moindre mal, mais c’est une limitation assez peu compréhensible. Si quelqu’un me trompe une raison légitime de castrer le cache ainsi seulement sur le mobile, je suis preneur.

À vous pour la suite

Le cache de l’iPhone est définitivement différent de celui d’un Safari classique. Je n’ai malheureusement pas d’iPhone pour tester* donc à ceux que ça intéresse, je suis preneur des résultats suivants (pour la v1 et la version 3G) :

• quelles sont les nouvelles limites par composant ?
• quelle est la nouvelle limite globale ?
• ces limites sont-elles les même wifi et en 3G ?
• le HTML principal est-il mis en cache lors d’une connexion wifi ?
• nous avons testé avec une image, est-ce la même chose avec une feuille de style ou un javascript ?

Le protocole de test est assez simple, je vous met ici en copie une petite archive des fichiers PHP que j’ai utilisé pour mon test avec Anthony.

Bref, à vous de tester, et de commenter ici avec vos résultats (n’oubliez pas de faire un lien vers votre protocole de test et de donner la version exacte de votre iPhone, sans ça les résultats sont moins utiles).

(* Ceci est un message subliminal à celui qui veut financer mes recherches sur le sujet)

Il s’agit d’informer le navigateur que votre contenu est valable pendant une certaine durée. Cela peut être dix minutes, une heure, un jour, un mois, ou plusieurs années. Tant que cette durée n’a pas expirée, le navigateur sait que son contenu est à jour, il peut donc éviter de le retélécharger. Vous gagnez du temps en évitant la requête HTTP et vous laissez de la place pour d’autres téléchargements. Au lieu de prendre une demi seconde, votre contenu sera lu quasiment instantanément.

Les détails HTTP 1.0

En fait tout ça c’est assez simple. En HTTP 1.0, le serveur envoie avec le contenu une entête Expires avec une date au format de la RFC 1123.

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Le navigateur et les proxy stockent dans le cache la ressource avec cette date. Les prochaines fois c’est le contenu sauvegardé dans le cache qui est utilisé, sans aucun appel au serveur.

Une fois la date dépassée, le navigateur fait de nouveau appel au serveur pour obtenir un contenu mis à jour, et éventuellement une nouvelle date d’expiration explicite. C’est normalement une requête conditionnelle qui est faite à ce niveau là donc si le contenu n’a toujours pas changé il ne sera toujours pas retéléchargé inutilement.

Les détails HTTP 1.1

Le gros défaut HTTP 1.0 c’est qu’en général on ne souhaite pas une date d’expiration fixe, on cherche une expiration de type « maintenant + 10 jours ». Résultat, il faut générer la date à chaque fois.

HTTP 1.1 nous propose un mécanisme plus sympathique avec l’entête Cache-Control dont je vous avais détaillé un des paramètres il y a quelques temps. Le paramètre qui nous intéresse ici est le paramètre max-age. Il prend un nombre de secondes pendant lesquelles le contenu doit être considéré comme à jour.

Cache-Control: public;max-age=3600

Cette directive est valable autant pour les caches partagés (proxy) que les caches personnels (navigateur). Il existe toutefois un second paramètre s-maxage, qui ne cible que les caches partagés. Le fonctionnement est similaire.

J’utilise quoi ?

Autant que possible, utilisez les deux. Rien n’est parfait dans ce bas monde et vous n’avez pas de garantie que la directive Cache-Control sera interprétée correctement, même si le client utilise la version 1.1 du protocole.

En cas de conflit le client est censé utiliser la directive Cache-Control. Mais après tout, pourquoi voudriez-vous envoyer deux informations contradictoires ?

Comment ?

Le plus simple sous Apache c’est mod_expires. Vous pouvez régler le comportement par défaut et par type de fichier. À chaque fois vous pouvez définir une durée pendant laquelle le contenu est considéré comme à jour, et si cette durée est à prendre à partir de la dernière modification de votre contenu ou de la date de la requête.

ExpiresDefault "access plus 1 month 15 days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3 minutes"

Pour Lighttpd le module a le même nom, et la syntaxe est assez similaire :

$HTTP["url"] =~ "^/images/" {
     expire.url = ( "" => "access 1 hours" )
}

Sur quoi ?

Ces entêtes sont pertinentes pour tout ce qui bouge peu, pas du tout, ou à une fréquence déterminée :

Prenez en compte au moins vos logos, vos icônes, vos images de fond, bref, ce qui ne change quasiment jamais, sans exception. Pour ces contenus vous pouvez mettre une expiration virtuellement infinie, de plusieurs années. Le jour où vous faites une modification il suffira de faire un nouveau fichier avec une nouvelle adresse publique.

Pour vos feuilles de style et vos javascript, même chose. Vos contenus changent plus souvent mais si vous arrivez à changer l’URL à chaque modification vous pouvez encore mettre une expiration quasi infinie. Pour changer l’adresse à chaque version vous pouvez ajouter le numéro de version dans le nom du fichier, ou ajouter un paramètre à l’url qui contient la date de dernière modification. Je ferai un billet plus complet sur le sujet plus tard.

Enfin, les pages HTML. Là il faut être plus fin. Toutes les pages ne sont pas pertinentes pour une expiration. Plus classiquement si à deux minutes d’intervalle il est important que le contenu change, oubliez l’expiration explicite. Par contre une bonne partie des pages peuvent avoir une expiration de quelques minutes, voire d’une ou deux heures. C’est souvent le cas des pages d’accueil et des pages principales. L’utilisateur y revient souvent lors de sa navigation. Si ces pages peuvent être instantanées, c’est un réel gain pour l’utilisateur. Si vous avez un système d’authentification sur vos pages, n’oubliez pas de déclarer aussi le cache comme privé avec la directive Cache-Control.

Le bénéfice

Un contenu avec une expiration explicite c’est un contenu qu’on évite de retélécharger plusieurs fois inutilement. Pour l’utilisateur c’est la sensation que le téléchargement est instantané, que l’interface et que le site réagissent immédiatement — et n’oubliez pas, cela a une influence importante sur votre business. Pour vous c’est autant de charge en moins pour votre serveur, et autant de bande passante économisée. Rien que là dessus vous pouvez économiser des sommes importantes.

Pour exemple, la page de Yahoo! met environ deux secondes tout compris à charger avec plus de 40 requêtes HTTP, ce qui en soit est assez honorable face au reste du web. Par contre sur cette quarantaine de requêtes HTTP, plus des trois quarts ont une expiration explicite comme détaillé plus haut. Le résultat c’est que ma seconde visite ne télécharge plus que 7 composants externes. Ma bande passante est libre pour autre chose et ma page se charge bien plus rapidement. Suivant les publicités sur la page, c’est entre une demi seconde et une seconde que je gagne. Pour une page d’accueil qui ne doit surtout pas donner une impression de lenteur, c’est significatif et même important.