Performance web » réseau

Latence et CDN

Éric — Wed, 03 Jun 2009 11:00:57 +0000

La latence est une des composantes qui pénalise le plus les performances actuellement. Les connexions Internet françaises se font plutôt à haut débit, et même un mauvais wifi laisse finalement passer assez de trafic pour que ce soit viable. Par contre, avec l’explosion du nombre de composants par page, la latence est probablement le facteur le plus limitant. 40 composants à 50ms de latence, c’est 2 secondes de perdues. Même en imaginant utiliser deux fils de téléchargement, c’est encore une seconde d’attente. Sur une mauvaise connexion (wifi ?) ou quand on s’adresse à un site qui n’a pas de serveur en France (ou très proche), la latence peut vite exploser.

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.

Préchargement des images CSS avec Jquery

Éric — Fri, 17 Apr 2009 11:00:44 +0000

Dans le préchargement l’idée est de faire travailler le navigateur avant que l’utilisateur ne demande les documents pour que ce soit quasiment instantané ensuite. On attend la fin de chargement de la page, et on lance par avance le téléchargement de plusieurs liens dont on pense qu’ils serviront plus tard. C’est très intéressant pour quelques logos, css ou javascript. Imaginez une page d’accueil avec un style bien différent du reste du site : il peut être avantageux de précharger la feuille de style ou le javascript qui seront utilisés sur les autres pages.

C’est Marc Hertzog qui se colle à l’exercice avec JQuery. Il a amélioré un module de Scott Jehl qui lit une feuille de style et tente de précharger toutes les images qui y sont référencées. L’idée est séduisante. On supprime alors les temps d’attente pour les images qui s’affichent au survol de la souris ou sur les pages suivantes.

L’idée est séduisante mais je n’accroche pas tout à fait. Tout d’abord parce que c’est au navigateur de faire ça. J’ai souvent dit que sur les performances on compensait les manques des navigateurs et qu’il fallait être pragmatiques (le faire quand même même si dans l’idéal c’est le boulot du navigateur) mais là il s’agit de quelque chose de simple, très simple. Quand un « quick win » n’est pas réalisé par des gens intelligents – et les développeurs de navigateur le sont – c’est qu’il y a anguille sous roche.

Le plus gros défaut que je vois est celui inhérent à tout préchargement : on fait travailler le navigateur. Sur un poste personnel avec une navigation très linéaire ça n’a d’effet négatif quasi que sur les prestataires réseau. Mais sur une ligne partagée (entreprise, wifi), avec des gens très connectés (vidéo en streaming parallèle, deezer ou spotify en tâche de fond), ou simplement sur une navigation avec beaucoup d’onglets (vous faites une recherche, vous ouvrez beaucoup de pages en parallèle), vous pénalisez l’utilisateur ou ses voisins. Même chose pour un utilisateur en itinérance : utiliser son réseau et son processeur pour ça aura une influence forte sur sa batterie.

Le préchargement reste une bonne idée, mais à petite dose, pour des choses ciblées, prévues. Ici on télécharge tout sans discernement. C’est certain, on va aussi télécharger des éléments qui ont une faible probabilité d’être utile. Dans les commentaires de la version originale du script on propose de faire un tri sur l’url de chaque image, suivant son répertoire on décide si c’est une image qui doit être préchargée ou pas. On résout ainsi l’occupation réseau (mais pas l’occupation processeur), mais ça commence à faire usine à gaz. Sans compter que une même image peut avoir du sens pour un préchargement sur certaines pages mais pas sur d’autres.

À ce compte là autant lister les images à précharger dans un tableau javascript au lieu de lire toute la feuille de style. Ou mieux, des parce que c’est fait pour ça.

Enfin, c’est surtout utile pour les changement d’image au survol de la souris, ou sur une action utilisateur. Dans ce cas on modifie l’image en cours, ou on affiche des icônes. Bref, on se retrouve très généralement dans des cas où les images concernées sont de toutes façons dans des sprites, soit avec une liste d’icône, soit avec l’image qu’on remplace – l’image contient alors et la version sans survol et la version avec survol.

Bref, l’idée est bonne mais je reste septique sur la pertinence de mettre en place une solution générique de ce type.

Cache central des bibliothèques javascript

Éric — Tue, 17 Feb 2009 11:00:15 +0000

On m’a posé quelques fois la question alors voici la réponse : Oui.

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.

Quelques outils en ligne

Éric — Wed, 17 Dec 2008 11:00:53 +0000

Je vous avais présenté quelques outils, aujourd’hui en voilà trois autres, en ligne.

Le concept de ces outils est le même : on prend une URL, on lance la page, et on trace la cascade des requêtes HTTP avec quelques statistiques. C’est là qu’on voit le temps pris par chaque composant, par la somme des composants, et les éventuels problèmes de performance comme les scripts bloquants.

Pingdom : simple et clair

Le plus simple, et peut être le plus joli, c’est Pingdom. Il se contente de tracer la cascade, en précisant les temps de connexion TCP, d’envoi et de réception, ainsi que les poids des divers composants. Il n’y a pas de paramétrage, et il semble que le moteur se permette de lancer presque 10 connexions simultanées. Bref, n’en faites pas des analyses trop poussées. Par contre pour montrer l’aperçu de la cascade ou un problème significatif au détour d’une conversation, c’est clairement un des outils à retenir. L’interface est en effet suffisamment jolie pour attirer le non-spécialiste.

Site-perf : paramétrable jusqu’au bout

Le deuxième outil en ligne est site-perf. Le site se veut regrouper des informations sur la performance des sites web, mais c’est surtout pour son test de performance en ligne qu’il est intéressant. Il offre plusieurs sources géographiques pour lancer le test et un paramétrage complet : nombre de connexions simultanées, bande passante, latence, qualité de la ligne (% de perte de paquets), compression, keep-alive, login, adresse IP… tout y est. Je n’ai pas fait suffisamment de test pour m’assurer que le résultat est précis ou cohérent avec les outils « de confiance » comme IBM Page Detailer, mais le résultat est sans appel : une cascade précise avec six états, dont le temps de résolution DNS, le détail des informations de cache HTTP, et un résumé cohérent.

Les deux seuls défauts sont la largeur de la cascade, qui mériterait de pouvoir prendre plus de place pour une meilleure lecture, et le manque d’un résumé par type de composant (combien m’ont coûté les images au total ?).

Web Page Test : aussi complet que la version bureau

Le dernier outil c’est webpagetest, la version en ligne de AOL Page Test. La cascade est précise et on peut avoir confiance dans l’outil si c’est juste une automatisation de la version bureau du logiciel. Moins joli que pingdom (en fait même carrément moche), webpagetest est aussi légèrement moins paramétrable que site-perf.

On a accès à trois sources géographiques avec leurs spécificités, et un choix du nombre de requêtes simultanées. Pour rattraper le tout il est possible de scripter le test. On peut aller réaliser un parcours sur le site, envoyer un formulaire ou accéder une page protégée par authentification. Il manque malheureusement la possibilité de modifier finement la bande passante ou de modifier la latence artificiellement. Vu l’importance de la latence dans les tests, c’est dommage.

L’intérêt de webpagetest c’est surtout le résultat. On y retrouve une cascade précise et très claire (en grande largeur), qui comprend aussi les temps de début de rendu et de fin de rendu de la page : indispensable si on veut jouer sur le ressenti utilisateur et pas uniquement sur les chiffres bruts. Derrière cette cascade on a un résumé ressource par ressource des différents temps et poids, avec toutes les entêtes HTTP. Bref, tout ce qui est nécessaire pour travailler. Il y a même un tableau avec des recommandations pour vérifier des critères comme le cache, gzip, la concaténation css/js, le keep-alive, la minimisation ou le keep-alive.

Le double effet kisskool de webpagetest c’est que ces informations sont fournies en double : une fois pour le premier accès avec un cache vide, et une seconde fois, pour simuler un cache correctement initialisé. Indispensable là aussi. Mieux, cascade et résumés sont disponibles sous forme d’image et peuvent donc facilement être sauvegardés pour un rapport ou pour comparaison entre deux dates.

Analyse d’une requête HTTP – serveur et réseau

Éric — Wed, 23 Jul 2008 10:00:02 +0000

On parle de temps, de performance, mais finalement que mesure t-on ? La question n’est pas inutile puisque pour une même requête il y a bien trois étape visibles du point de vue du visiteur, cinq du point de vue du navigateur et autant pour le serveur. Alors, que mesure t-on ?

Je vous propose un petit schéma incomplet des interactions lors de la requête d’une page HTML (attention, aucune échelle ou proportion n’est respectée).

Alors, vous mesurez quoi ?

La requête DNS

Une fois que le visiteur clique sur un lien, c’est une requête DNS qui est lancée par le navigateur et environ 30ms qui sont perdues, parfois même jusqu’à 100 ou 150ms (triangle gris sur le schéma). Microsoft Internet Explorer 6 cache cette information pendant 30 minutes mais les autres navigateurs la relancent plus souvent. Mozilla Firefox ne garde le résultat de la requête DNS que pour une petite minute. Vous l’aurez donc quasiment à chaque nouvelle page. Vous pouvez réduire l’influence des requêtes DNS en limitant le nombre de domaines et sous-domaines utilisés par votre site. Gardez le nombre de domaines en dessous de quatre.

La connexion au serveur

L’étape suivante c’est l’établissement de la connexion avec le serveur que vous souhaitez joindre (triangle vers sur le schéma). C’est assez rapide mais ça reste quelque chose qui va impacter les performances. Autorisez le keep-alive pour les ressources statiques (images, feuilles de styles, javascript) : Le navigateur et le serveur vont réutiliser la connexion existante au lieu de rétablir une nouvelle connexion pour chaque composant. Le gain est notable, j’en avais déja parlé.

Maintenant le keep-alive c’est aussi ce qui va garder la connexion ouverte inutilement une fois que vous aurez téléchargé tous les composants. C’est le rectangle vert en bas sur le schéma. C’est coûteux pour vs serveurs. Désactivez donc le keep-alive sur le serveur qui renvoie les pages HTML, et réduisez la valeur pour les autres : cinq secondes sont bien suffisantes.

La requête HTTP elle-même, et l’attente qui suit

Vient ensuite la requête HTTP elle-même (parallélogramme jaune sur le schéma). Vous voyez qu’elle prend un certain temps, symbolisée par une épaisseur sur le schéma. En cumulant toutes les entêtes et un cookie classique, votre requête peut facilement prendre 1ko. Pensez donc à réduire la taille du cookie, et même à ne pas avoir de cookie pour les ressources statiques en les mettant sur un domaine tiers.

Par la suite, pour réduire l’influence des requêtes HTTP, il ne reste plus qu’à en faire moins. En fait c’est assez simple. Il suffit d’aggréger plusieurs fichiers en un seul, qu’on parle de CSS et javascript, ou de sprites pour les images. Vous épargnez le temps de faire la requête, mais aussi tout le temps d’attente du navigateur entre la fin de la requête et la réception de la réponse (espace blanc entre les parallélogrammes bleus et jaunes sur la ligne de temps du navigateur).

Une autre possibilité c’est d’envoyer plusieurs requêtes HTTP coup sur coup sans attendre les réponses. On utilise alors au mieux cet espace inutile entre la fin de la requête et le début de la réponse. On se permet même d’envoyer des donner dans un sens pendant qu’on en reçoit de l’autre côté, donc superposer des requêtes jaunes dans mon schéma avec des réponses bleues. C’est ce qui est réalisé avec le pipelining HTTP.

Le calcul de la page par le serveur

Voilà la mesure du diable. Dès qu’on parle de performance tout le monde va vite mesurer ce temps de génération des pages, en mauve sur le schéma. Même si l’échelle et les proportions ne sont pas respectées sur le schéma, il est évident que cette mesure n’est vraiment pas la a seule, ni même la plus importante. Pour des pages bien faites et des serveurs qui ne sont pas surchargées, il est très rare d’avoir des pages qui prennent plus de 100ms pour le calcul serveur. C’est généralement dix fois moins, alors que le chargement complet de la page pour le visiteur prend lui plusieurs secondes.

Mais surtout, c’est létape qui est souvent la première à être optimisée, et celle où il est assez complexe de gagner encore des performances si on a déjà penser au cache. Ne vous focalisez pas sur le temps de génération des pages, sauf s’il est flagrant qu’il est disproportionné par rapport aux besoins.

Éventuellement, si votre page peut mettre longtemps à se générer et que c’est facile à faire, vous pouvez forcer un vidage du tampon au milieu de la génération de la page, pour que l’utilisateur commence à voir le contenu réel de la page et télécharge les composants tiers pendant que le calcul de la page continue à se faire. L’équipe Performance de Yahoo! en parle, l’équipe Search aurait eu de bons résultats avec cette technique.

Le téléchargement de la page

La dernière étape du point de vue du serveur c’est le téléchargement de la page elle-même. C’est un des postes qui impactent le plus les performances. On a beau faire des publicités pour des liaisons à 24mb/s, si vous téléchargez une pages HTML à 2mb/s c’est bien. Et derrière si on compte les images, les cookies, les javascript, les feuilles de style, le flash, les vidéo, et la page HTML elle-même, ça prend du temps, incompressible.

Enfin certaines choses sont incompressibles, d’autres justement… vous pouver minimiser les javascript et CSS, mais aussi utiliser la compression HTTP pour tout ce qui est fichier texte (HTML, javascript, CSS, XML, Json, etc.). Les résultats sont spectaculaires et il est facile de diviser le poids par dix, donc le temps de téléchargement d’autant.

On peut aussi faire bien mieux, et réduire tout le téléchargement de la page à quelques octets. Il s’agit simplement de repérer quand le navigateur a déjà une page similaire en cache, et de lui répondre un code HTTP 304 « la page n’a pas changée ». Ca fonctionne à base d’ETag, de date de modification et de requête conditionnelle HTTP.

Et entre le visiteur et son navigateur ?

Je n’ai parlé que de la partie basse du schéma, en oubliant tout ce qu’il se passe entre le navigateur et l’humain derrière son écran. Ca a l’air plus simple parce qu’il y a moins de composants en jeu, mais c’est là que se passe une bonne partie des problèmes de performance, et pas forcément les plus simples à gérer.

On en parlera dans un prochain billet, vous voulez bien ?

En attendant retenez :

Le début du rendu du navigateur ne correspond pas avec le début de la réception de la page HTML.
La fin l’interprétation du HTML ne correspond pas du tout avec la fin de la réception de la page HTML.
La fin du rendu total de la page peut intervenir plusieurs secondes après la fin de la réception de la page HTML.

Mais de toutes façons le jeu c’est le plus possible d’éviter tout le schéma en lui même : réduire le nombre de requêtes HTTP, soit par une réduction du nombre de composants, soit par une exploitation au mieux du cache.

Désactiver les ETags ?

Éric — Wed, 11 Jun 2008 10:00:19 +0000

Après un test de votre site sur Yslow vous retrouvez une recommandation qui vous propose de désactiver les ETags. Une recherche rapide vous mène sur les pages de l’équipe performance de Yahoo! qui vous disent la même chose.

Qu’est ce qu’un ETag ?

Un ETag sert au serveur web à identifier une ressource et sa version. La valeur d’un ETag est libre, la seule contrainte est que l’ETag soit unique pour une URL donnée. Deux versions d’un même document auront donc deux ETags différents ; dans le temps la valeur d’un ETag ne devrait pas changer si le document lui même n’évolue pas. Cet ETag est renvoyé par défaut à chaque fois que le serveur web renvoie un contenu. On obtient donc quelque chose comme suit dans les entêtes d’une réponse HTTP 1.1 :

HTTP/1.1 200 OK
Date: Sun, 08 Jun 2008 13:53:40 GMT
Last-Modified: Mon, 04 May 2008 19:43:54 GMT
Etag: "3a4ea77d-baa-f3a45280"

Le navigateur s’en sert pour identifier les versions des documents qu’il met en cache. Quand on lui demandera de nouveau la même ressource, il fournira cet identifiant dans une entête de la requête HTTP. On parle alors d’une requête conditionnelle.

GET /test.html HTTP/1.1
Host: www.example.org
If-Modified-Since: Mon, 05 May 2008 19:43:54 GMT
If-None-Match: "3a4ea77d-baa-f3a45280"

Le serveur compare l’ETag reçu par le navigateur avec celui de la version actuelle du document demandé. Si les deux ne correspondent pas c’est que le document a été modifié depuis le dernier accès et on le renvoie normalement. Si les deux sont identique alors le serveur web peut utiliser le code de retour 304 et demander au navigateur d’utiliser sa copie en cache. On évite alors de télécharger de nouveau le document, inutilement. C’est intéressant autant pour le serveur que pour le client :

HTTP/1.1 304 Not Modified
Etag: "3a4ea77d-baa-f3a45280"

D’autres détails (presque) inutiles

En réalité c’est même un peu plus complet que cela puisque le navigateur peut retenir plusieurs versions du même document dans son cache et les renvoie toutes, séparées par des virgules. De son côté le serveur peut aussi avoir plusieurs formats pour un même document. Il va donc comparer toutes les dernières versions avec les identifiants proposés par le navigateur, et retourner un 304 pour la première qui correspond, en spécifiant bien pour que ETag il renvoie ce statut.

On peut aller plus loin en utilisant des identifiants dits forts et des identifiants dits faibles. Ces derniers sont préfixés par W/ et ne peuvent être utilisés que pour des requêtes GET et HEAD. Un identifiant faible est un identifiant qui peut correspondre à plusieurs représentations différentes d’un même document, ou à plusieurs versions d’une même représentation.

On trouve même la possibilité pour le navigateur d’utiliser un If-None-Match:*, qui ne va effectuer la requête que si la ressource ciblée n’existe pas encore. Soit que la représentation adaptée à cette requête particulière n’existe pas (version du navigateur par exemple), soit quelle n’a pas encore été générée et est générée à la demande.

Sur des requêtes de type POST ou PUT (en fait sur tout sauf GET et HEAD), la réponse n’est pas 304 (not modified) mais 412 (precondition failed). Sur un PUT le If-None-Match:* peut d’ailleurs gérer les problématiques de concurrence d’accès : la requête ne sera effectuée que la première fois, par la suite la ressource sera déjà crée et un statut 412 sera renvoyé.

Les problèmes d’ETag

En soit ce fonctionnement ne pose aucun problème. Il est supporté par l’essentiel des navigateurs et des serveurs. Quand un des intervenants ne connait pas les ETags ils sont ignorés et c’est le comportement Last-Modified / If-Modified-Since qui prend la main.

Il n’y a que deux problèmes potentiels : deux versions d’une même ressource avec le même ETag, ou deux ETags différents pour une même version d’une ressource. Dans le premier cas le navigateur risque de réutiliser son cache alors qu’il existe une mise à jour. Dans le second cas, celui qui nous préoccupe, le navigateur risque de re-télécharger un document qu’il a déjà en cache.

C’est ce dernier cas qui arrive parfois sur certains sites, et qui impacte les performances à cause de la bande passante utilisée inutilement. Cela arrive dès qu’il y a plusieurs serveurs derrière un même site web. Apache utilise par défaut un identifiant basé sur la date de dernière modification et l’inode du fichier. L’inode est garantit comme unique pour un même système de fichier.

S’il y a plusieurs serveurs, chacun a son propre système de fichier. L’inode sera différent sur chaque serveur, et le client risque de recevoir des ETag différents pour la même ressources. Pour peu que la requête du navigateur ne soit pas toujours gérée par le même serveur, tout le système de cache basé sur l’ETag sera mis en échec.

Sur certaines anciennes versions de lighttpd, des serveurs 32bits et des serveurs 64bits peuvent aussi donner des ETags différents bien que l’inode n’intervienne pas dans le calcul.

Désactiver les ETags

Conclusion simple et rapide de l’équipe performance de Yahoo! : désactiver les Etags. En l’absence des ETags c’est en effet le mécanisme habituel de date de modification qui est utilisé pour générer les 304 et les caches. Ce système n’est pas parfait mais pour des ressources qui ne sont pas amenées à changer plusieurs fois par seconde il n’amène aucun problème.

En suivant les recommandations habituelles on ne modifie justement presque jamais une ressource statique, on créé la nouvelle version avec une nouvelle URL et on laisse l’ancienne telle quelle. Les ressources dynamiques, elles, à cause des personnalisations et des mises à jours très fréquentes, n’utilisent de toutes façons que rarement les 304 et ces systèmes de validation de cache. Quand elles le font c’est que les mises à jour ne sont pas trop fréquentes ; la limitation imposées par la résolution à la seconde des dates de modification n’est alors pas gênante.

Bref, on ne perd pas grand chose et on évite des problèmes dont on sait qu’ils vont survenir.

Sous Apache c’est fait avec FileETag none. Pour Microsoft IIS il y a toute une procédure.

Réactiver les ETags ?

Déjà, tant que vous avez un seul serveur derrière votre site web, n’hésitez pas : activez les ETags même si Yslow vous dit le contraire. Vous avez tout à y gagner et rien à y perdre.

Ensuite, activer tout de même les ETags n’est pas forcément une mauvaise idée. Le problème n’est pas sur la fonctionnalité elle-même, mais juste sur la façon par défaut pour Apache et IIS de générer ces identifiants. Bref, en général un cumul entre la date de modification et la taille du fichier suffit. Dans ce cas vous pouvez demander à Apache d’utiliser FileETag MTime Size.

Enfin, ne changez pas et ne supprimez pas le calcul des ETags sur les sites qui utilisent DAV via le mod_dav_fs. Ce dernier risque de ne plus fonctionner de manière optimale.

Limitations du cache Safari

Éric — Tue, 06 May 2008 10:41:45 +0000

Pour l’iphone

Safari a de sérieuses limitations sur le cache. Yahoo! avait déjà débusqué les limites de la version iphone : les fichiers ne doivent pas dépasser 25 ko une fois décompressés et le total doit être strictement inférieur à 500 ko. Ces limitations semblent raisonnables pour un téléphone mais ce téléphone navigue souvent sur des sites classiques, avec une bande passante très réduite. Des objets de plus de 25 ko on en trouve malheureusement fréquemment, par exemple une grosse feuille de style. Bref, minifiez vos fichiers javascript et CSS, compressez vos images.

Vous trouverez aussi des sites vous parlant d’une limitation à 19 fichiers en cache sur l’iphone, mais j’ai clairement l’impression qu’il s’agit d’une mauvaise compréhension des premiers résultats. 19 c’est le nombre maximum de fichiers de 25 ko qu’on peut faire tenir dans moins de 500 ko (donc dans 499 ko). Si vos fichiers sont plus petits je m’attends à ce qu’il puisse y en avoir plus que ça en cache, mais je n’ai pas d’iphone pour tester.

Pour Safari 3

Là où c’est plus étonnant c’est que Safari 3 a lui aussi des limitations qu’on n’attendait pas. En particulier les objets supérieur à 104 ko (le double si vous avez plus de 1 Go de RAM) ne sont pas mis en cache. Contrairement aux 25 ko de l’iphone, on ne sera pas vraiment limité sur les CSS et le JS. Par contre il nous reste des gros fichiers qu’on aimerait en cache : principalement les grosses images et les animations flash. Et ce sont justement ces fichiers qui devraient être prioritaires dans le cache. Hors de question de recharger la grosse animation flash à chaque passage. Bref, la limitation est gênante.

Il y a tout lieu de penser que ce sera corrigé à l’avenir, en tout cas un bug a été soumis en ce sens. Visiblement le problème vient d’un framework qui gère la couche HTTP et pas de Safari/WebKit. Si quelqu’un est motivé, je suis curieux de savoir si la version Windows de Safari 3 ou les navigateurs webkit Linux souffrent du même problème.

Pages d’erreur

Éric — Tue, 22 Apr 2008 10:00:56 +0000

Rappelez-vous : cool URIs don’t change (les URIs sympa ne changent pas), et mieux, autant que possible elle ne disparaissent pas non plus. Reste que beaucoup d’éditeurs ne tiennent pas compte de cette recommandation, et que les développeurs ne peuvent s’abstenir de faire des erreurs quand ils font des liens.

Ces pages d’erreurs donnent une piètre expérience à l’utilisateur, je ne l’apprend à personne. Je me concentre ici sur l’aspect performance mais sur cet aspect aussi il y a des conséquences.

Les URIs sympa ne changent pas

C’est toujours bon d’insister : les URIs sympa ne changent pas, et ne disparaissent pas. La solution unique et permanente à tous les problèmes d’erreurs est de ne pas en faire. Les erreurs 404 sont très souvent la faute des développeurs ou des éditeurs du site où elles arrivent :

Ne cassez pas les liens, qu’ils soient internes ou en provenance de l’extérieur. Laissez vos contenus à leur adresse actuelle, quitte à ne plus les lier nulle part et qu’ils soient là juste en archive au cas où. C’est simple à dire mais c’est aussi la règle la plus importante.

Pour vous y aider n’hésitez pas à jeter un oeil régulier à vos journaux d’accès pour repérer les 404 et les pages référantes à fixer. Faites aussi tourner des robots sur vos pages pour détecter les liens morts. Des outils comme les outils webmaster de Google peuvent vous y aider. Ils vous montreront tous les liens morts internes et externes que fait votre site.

Les page d’aide ou page d’erreur ?

Quand votre serveur renvoie une erreur, il retourne souvent une page complète. C’est le cas par exemple pour l’erreur 404 (page inexistante), l’erreur 403 (accès interdit) ou les erreurs 500 (problème serveur). La page en question sera affichée dans le navigateur du visiteur, avec une explication et parfois une aide ou un formulaire de recherche.

La page peut être un peu grosse mais elle a un rôle dans l’expérience utilisateur. C’est parfois une page d’aide autant qu’une page d’erreur (pour les erreurs 404 par exemple). Jusque là il n’y a rien de criticable, au contraire : le contenu sur la page d’erreur est un vrai plus s’il est bien fait.

De la taille des erreurs

Mais quand l’erreur survient sur un appel javascript, une feuille de style ou une image ? Votre serveur renvoie probablement la même bonne grosse page HTML. C’est 4ko pour les plus petites (Yahoo, Google) mais plus souvent 8 à 10ko (Le Monde, pages dynamiques de Skyrock blog) voire plus (Microsoft avec 18ko). Dans ces cas là vos 15ko de contenu sont totalement inutiles. Ils sont téléchargés mais ne seront jamais affichés. Plus votre page d’erreur est petite, mieux c’est.

Vos liens en erreur n’ont pas plus de raison d’être faits vers des pages HTML que vers des javascript, des images ou des feuilles de style. Il est même probable que vos erreurs suivent le même ratio html/autre que vos requêtes habituelles, ce qui revient certainement à dire que les erreurs sur des balises