Traditional Yahoo! web servers serve compressed content to only 'good' browsers, and always with "Cache-Control: private". Newer Yahoo! web servers serve compressed content if the incoming request asks for it. No check is performed on the UA.
JSON ! c'est le cri de tous les développeurs web à la mode dès qu'ils entendent parler d'échanges de données. Ce format est sensé être plus performant, plus simple, plus standard, plus performant, plus web 2.0 quoi.
Plusieurs points mériteraient un billet à part entière, et je suis en désaccord sur chacun d'eux, mais je me focaliserai ici sur un seul : la performance. Les performances peuvent se voir au niveau du téléchargement et au niveau de l'interprétation par le client.
Deux règles principales pour la performance des sites web sont de réduire le nombre de requêtes HTTP et de limiter la taille des données qu'on télécharge.
Malheureusement ces deux règles entre parfois en conflit. Si je fais un gros fichier unique pour toutes mes CSS, je vais inclure des règles qui seront inutiles pour la page courante, et qui augmenteront inutilement la taille totale à télécharger.
Le cache HTTP permet aux visiteurs de ne pas re-télécharger les pages ou les éléments de pages qui l'ont déjà été. C'est un des meilleurs mécanismes pour accélérer l'accès du navigateur au contenu mais il est mis en échec par de nombreux cas.
La directive Cache-Control est une vrai mine d'or pour la gestion du cache, au risque même de faire un peu fourre-tout. Aujourd'hui je m'intéresse surtout aux notions de document public et de document privé.
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.
Je parlais il y a quelques jours de performance des sélecteurs CSS. Il y a eu quelques réactions et j'ai échoué dans mes explications : les différences de performance dont on parle ici sont probablement négligeables la plupart du temps. Hors commentaires, certains m'ont rappelé que la documentation de Mozilla concerne d'ailleurs au départ les interfaces XUL avec de gros documents XML complexes agrémentés de très grosses feuilles de style.
Nous avons peu d'informations officielles de la part des navigateurs sur les performances de leurs moteurs. Le Mozilla Developer Center nous propose tout de même une courte page sur comment écrire des feuilles de style efficaces.
C'est peut être ce qui résoudrait quelques problèmes de performances : une option "fast" en javascript. Cela permettrait de déclarer qu'on n'utilise pas de document.write et ne plus bloquer le rendu du navigateur. On pourrait aussi déclarer ne pas toucher aux prototypes des objets de base pour bénéficier de meilleures optimisations de l'interpréteur.
Pour diminuer la taille des téléchargements on utilise la compression et la minimisation. La minimisation c'est l'art d'enlever tout ce qui est inutile dans un fichier : espaces blancs, commentaires, et éventuellement noms de variables longs.
Nos navigateurs sont performants, ils savent gérer plusieurs téléchargements en parallèle. Ca nous permet de palier les serveurs lents, et d'optimiser le réseau. Le temps qu'on se connecte sur un serveur, qu'on fasse une requête DNS, le réseau reste occupé avec d'autres téléchargements.
Après avoir parlé hier des stratégies d'optimisation, parlons rapidement de ce qu'il y a à gagner. Je me concentre sur la stratégie la plus fréquente : tenter de regrouper nos ressources dans des gros fichiers globaux.
Chaque fois que je parle de reléguer les codes javascript en fin de page, je vois une moue sur le visage de mon interlocuteur. Mettre le javascript dans le du document, et encore plus à la fin de celui-ci, et souvent préjugé comme une pratique "sale". Laissez moi vous convaincre du contraire.
Hier j'ai tenté de convaincre de mettre les codes javascript à la fin du document. Et là, d'ordinaire, chacun trouve une raison pour ne pas suivre le conseil. Des fois de très bonnes raison, souvent des contestables.
La latence réseau a un impact très important sur les performances. Si les ressources sont zippées, que vos images sont correctement compressées, et que les fichiers textes sont minimisés, la latence peut devenir presque plus pénalisante que les téléchargements eux même.
Le pipelining HTTP c'est faire gérer au serveur une file de requêtes. Le navigateur envoie plusieurs requêtes à la suite les unes des autres sans attendre la réponse du serveur. Le serveur renvoie alors les réponses dès qu'il les a, potentiellement en parallèle aux requêtes du navigateur. Non seulement on utilise le principe de la connexion persistante, mais on évite d'attendre la réponse précédente avant d'envoyer la suite. Pour chaque ressource à télécharger après la première, c'est un aller-retour réseau à rien faire qui est évité.
Il y a peu on a vu fleurir des liens vers des propositions au groupe de travail CSS. Et en particulier une proposition de variables CSS. Ces variables peuvent être changées dynamiquement en javascript. Le rendu est alors refait avec la nouvelle valeur, partout où la variable était utilisée.
