Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, et qui peut s’ajouter avant gzip ou deflate. Le serveur découpe sa page en paquets, qui peuvent chacun avoir des métadonnées et une expiration explicite. Le tout est stocké dans un dictionnaire du côté du navigateur, un peu comme les cookies actuellement. Quand le navigateur demande une page il envoie les identifiants de paquet qu’il connaît déjà, le serveur peut donc se contenter de compléter ce qui manque. On a donc le même fonctionnement que les Etag du point de vue de la négociation.

Les entêtes HTTP en jeu sont Avail-Dictionnary (l’équivalent de Etag pour SDCH) et X-SDHC (pour déclarer la version et l’implémentation de SDCH utilisée) du côté du navigateur, et X-SDCH-Dictionary du côté du serveur.

Reste que cela implique que la réponse du serveur soit codée suivant une forme bien particulière, non compatible avec les anciens clients HTTP. Google a donc prévu une auto-négociation et la réutilisation de l’entête Accept-Encoding. Grâce à cela, les navigateurs qui le peuvent auront un contenu SDCH puis compressé par gzip, les autres se contenteront du gzip.

Si vous voyez passer un Accept-Encoding: sdch, gzip c’est que votre navigateur supporte ce codage. Si en plus vous voyez une réponse Content-Encoding: sdch, gzip c’est que le serveur a bien compris que vous supportiez SDCH et va utiliser ce codage.

Je n’ai vu aucun mouvement ni aucune volonté de mouvement de la part de Mozilla, en fait depuis la communication de Google l’idée n’a pas l’air d’avoir fait recette où que ce soit. Seul un groupe de discussion, quasi vide, a fait suite à la communication de juin 2008.

Chrome a un premier support de SDCH (non activé par défaut pour la version publique actuelle) mais ça ne changera pas la face du monde. Le point intéressant est toutefois que SDCH est automatiquement intégré à Microsoft Internet Explorer si la Google toolbar est installée. La page d’aide de Google indique comment désactiver tout ça.

Si l’idée peut être intéressante, je suis un peu étonné que Google tente de l’imposer de lui-même sans avoir le support d’au moins un intervenant (Mozilla, Opera, Apple, Microsoft) ou une publication normative officielle de type RFC. La seule chose qui sauve cet unilatéralisme est la présence d’une version dans l’auto-négociation (donc on pourra gérer d’éventuelles évolutions dans les spécifications si jamais tout le monde se met autour de la table pour en rediscuter).

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.

La mesure

J’ai donc repris les chiffres de vendredi dernier et j’ai tenté de mesurer combien de temps est pris par cette page HTML principale. Je compte le temps de la requête, la latence, le temps de génération de la page, et le temps de téléchargement du code source.

Voici mes résultats :

Le cas France Telecom

Encore une fois, le temps pour France Telecom est pris en comptant les redirections sur la page d’accueil, et on voit ici bien pourquoi. Ces redirections plombent complètement le site puisqu’elles représentent 3,6 secondes, sur un total de 10 secondes. C’est délirant, et sans justification aucune vu la simplicité qu’il devrait y avoir dans un système de redirection de pays comme celui ci.

Sans ses redirections on arrive à 90 milli secondes sur un total de 6 secondes environ, donc un poids relatif de la page d’accueil inférieur à 2%.

Les deux catégories

Ce qui m’intéresse c’est deux choses :

Tout d’abord on voit que les seuls qui ont une page d’accueil significative sont ceux qui ont déjà travaillé et optimisé le côté client, et qui s’en sortent avec des performances bonnes ou honorables. Bref, avoir un bon rapport contenu / poids total est un bon critère de réussite.

Ensuite on voit que dans les autres, la page d’accueil, son poids, et le temps pour la générer, n’ont quasiment aucune influence significative sur le temps de chargement subit par l’utilisateur. Ce n’est clairement pas ça qu’il faut optimiser et vous pouvez laisser votre ingénieur et ses micro optimisations applicatives de côté (sauf si vous êtes à France Telecom).

La conséquence

Le temps de génération de la page représente une part infime, et il vaut mieux gagner 5% dans le reste du chargement que de gagner 50% sur le temps de génération de la page principale. La chance c’est que non seulement c’est plus rentable mais c’est aussi plus facile. Souvenez-vous, smushit c’est 10 minutes de travail pour une efficacité bien plus importante que ça.

Bref, travaillez sur le côté client, le retour sur investissement est bien plus important, bien bien plus.

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.