Plus que les outils eux-même, qui n’ont rien de révolutionnaires, c’est la prise de conscience des questions de performance par les développeur d’applicatifs et de bibliothèques de code qui me réjouit. Il est vrai qu’on ne peut pas demander à tous de se préoccuper des performances. Beaucoup d’éditeurs n’ont pas vraiment de techniciens compétents et se contentent d’utiliser des solutions toutes faites.

Le fait qu’il existe des plugins ou des composants utilisables peut faire la différence entre « il faudrait » et « j’installe et configure ».

C’est dans cet esprit que je vois arriver trois plugins pour le framework PHP Symfony :

• sfOptimizeStyleAndScriptPlugin : concaténation et compression
• sfMinifyPlugin : concaténation, minimification et cache
• sfCombinePlugin : concaténation

J’ai aussi vu passer Minify, un script PHP qui fait concaténation, minimification et cache, et mod_concat (doc), qui s’occupe de la concaténation au niveau du serveur Web Apache.

Je ne suis pas fana des systèmes PHP qui fonctionne à l’exécution de l’applicatif. Les performances sont rarement au rendez-vous et il s’agit au minimum de faire traiter toutes les requêtes statiques par PHP, ce qui est franchement dommage. Je préfère sérieusement des outils qui s’intègrent à votre processus de publication : un bouton qui concatène et minimise une fois pour toutes les fichiers en les versionnant correctement et qui les pose au bon endroit sur un serveur avec de bonnes entêtes de cache.

Seul le système de concaténation mod_concat, qui ne prend virtuellement pas de ressources inutiles, remporte mon adhésion. On rejoint ce que fait d’ailleurs Yahoo! avec son combo handler.

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.

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.

L’expérience

Batiste Bieler a visiblement eu le même doute l’année dernière que moi et publie des tests réalisés sur Jquery. Après passage par mod_deflate le packer permet tout de même d’économiser presque 45% des 20ko de javascript. Ce n’est pas négligeable et on a naturellement tendance à foncer tête baissée. Le hic c’est que sur sa configuration ça multiplie par deux le temps total de gestion (téléchargement plus exécution) pour javascript. Julien Lecomte relève lui près de 200ms de délai à cause du travail supplémentaire côté client. 

Bref, tout ça n’est pas négligeable. Ce sera toujours un compromis entre le gain en bande passante et la perte en temps processeur, donc une machine très puissante avec une très mauvaise connectivité réseau aura potentiellement intérêt à utiliser le packer, mais Batiste a tout de même utilisé un code duo à 1.66Ghz par coeur et je doute que le portable ayant servi à Julien Lecomte soit obsolète au niveau des performances. Bref, sauf dans des conditions spécifiques, n’utilisez pas le packer/base62 pour des fichiers javascript compressés par mod_deflate ou mod_gzip.                         

John Resig en parlait aussi en février avec un mot d’ordre explicite :

La prochaine que vous choisisser une méthode de compression, rappelez-vous de cette formule : Performance_Total = Temps_de_Téléchargement + Temps_d_Exécution 

L’influence de gzip

En fait quand on regarde actuellement le site de Jquery c’est un peu plus clair. On vous propose une version décompressée pour les tests, une version minifiée et gzipée pour la production, et une version qui utilise le packer de Dean Edwards « pour ceux qui ne peuvent pas gziper leur javascript ». Au moins c’est clair.

Si on garde en tête les chiffres de Batiste on confirme cette idée : sans gzip 60ko de javascript sont transformés en 20ko compressés. Les différences sont alors plus importantes, l’impact sur le réseau est plus fort et le packer reprend de son intérêt. La question sera alors de savoir si vos visiteurs ont des machines puissantes ou pas. On choisira le packer de Dean dans le premier cas, et un procédé de minification plus classique dans le second cas. C’est d’ailleurs la recommandation de Dean Edwards lui-même : il ne destine pas son outil à tous les usages.