Archive pour avril 2008

Les outils : le Cuzillon

Vendredi 25 avril 2008

Tester les performances nécessite du temps, beaucoup de temps. Il y a de nombreux outils qui permettent de tracer les téléchargements, les requêtes, les temps d’attente, etc. Ce qui manque c’est la page à tester. À chaque itération il faut changer le code html, le css, le javascript, les images.

J’ai de mon côté un petit script PHP qui peut simuler à peu près tout et n’importe quoi à partir de paramètres dans l’url : types de retour, contenu, temps d’attendre, taille, etc. Je pense que tous ceux qui testent les performances côté clients ont leur outil du même genre.

En combinant plusieurs URLs on arrive à obtenir un jeu de test, puis à faire varier les paramètres pour vérifier plusieurs cas. C’est long, surtout à cause d’une ergonomie en plein échec.

Le merveilleux Steve Souders a commis le Cuzillon. C’est exactement la même chose, mais avec une interface super pratique. Obtenir le résultat à un test est simple, naturel, agréable. Bon, c’est encore très limité dans les possibilités mais s’il relache le code source on devrait pouvoir arriver à un outil très efficace.

JSON ?

Vendredi 25 avril 2008

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. (Lire la suite…)

Pages d’erreur

Mardi 22 avril 2008

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. (Lire la suite…)

CSS et @import

Vendredi 18 avril 2008

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.

La question des performances

Si vous gérez plusieurs CSS sur une même page vous avez le choix entre faire un javascript qui va parcourir toutes vos feuilles de style à chaque changement pour reporter le changement (et faire attention à ne pas le faire pour les CSS externes que vous ne contrôlez pas), ou imbriquer vos feuilles de styles les unes dans les autres à coups de @import.

S’en suit quelques commentaires sur le blog de l’excellent Laurent Jouanneau à propos du coût en performance de @import. C’est une syntaxe déconseillée un peu partout du point de vue des performances et j’ai entendu des choses étranges, comme le fait que les CSS en @import seraient téléchargées après tout le contenu, voire après le onload de la page, ou que ça bloque tout le navigateur au même titre qu’un <script>. (Lire la suite…)

Compression avant transfert

Mardi 15 avril 2008

Après avoir parlé de minimisation, il est temps de parler de compression, la règle 4 des recommandations de l’équipe performance Yahoo!.

Trop gros

Une part importantes des téléchargements sont réalisés sur de simples fichiers textes : HTML, javascript, CSS, XML et JSON. Mis côte à côte ils peuvent représenter un poids non négligeable. C’est particulièrement vrai avec les bibliothèques javascript récentes. On dépasse alors les 50 ko pour la base, et plus si on ajoute les composants optionnels.

Un site classique avec Jquery c’est 25 ko pour le HTML, 10 ko pour les feuilles de style, 100 ko pour la bibliothèque javascript et encore bien 10 ko pour les fichiers javascript qui utilisent cette bibliothèque. La minification nous fait tomber respectivement à 15, 7, 50 et 6 ko, mais le total reste encore proche des 80 ko. (Lire la suite…)