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.
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.
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.
Les mobiles ont longtemps été une cible très spécifique à base de WAP. C'est maintenant révolu et on a de réels navigateurs complets avec javascript et CSS. Que peut-on faire de spécifique pour le Web mobile ?
C'est Jason Grigsby de cloudfour qui vient de donner une présentation "Going fast on the mobile web".
La communication des éditeurs de navigateur ressemble plus en plus à celle des vendeurs de lessive, mais au moins on commence à voir l'importance des performances.
J'abuse, il parait. Je parle de demi seconde ou même de centaines de milli-secondes. Je parle de quelques dizaines de kilo-octets là où la plupart ont des pages qui en font cinq ou dix fois plus.
Alors voilà, j'assume. Mais peut être que ça vaut le coup de rappeler trois chiffres qui permettront à chacun d'avoir des arguments quand on ne les prend pas au sérieux :
On en parlait il y a peu mais ça vaut le coup de faire un petit billet dédié : L'équipe de WebKit vient d'annoncer l'intégration de SquirrelFish. SquirrelFish c'est une réécriture de Javascript Core, leur moteur Javascript.
Et si on parlait un peu des images ? du point de vue des performances web, toujours.
Sur un site classique comme TF1, Amazon, LeMonde, on dépasse les 100 images sur la page d'accueil, pour un total de près de 300ko. Les sites plus au fait des problèmes de performance ont entre 30 et 50 images mais le poids total est encore souvent supérieur à 100ko.
Un petit peu de Javascript ? C'est Peter-Paul Koch aussi dit PPK qui lance la question sur Quicksmode il y a trois mois. Il tente de comparer diverses méthodes pour ajouter du contenu à une page, et plus spécifiquement innerHTML et les fonctions DOM (par DOM j'entend appendChild, createElement et associés).
On créé un tableau de 50×50 avec une astérisque dans chaque cellule et on compare. Le résultat est joli, en couleurs : DOM est lent, innerHTML est rapide. On parle d'un facteur 2 à 3, sauf pour Internet Explorer (oui, toujours) où on parle d'un facteur 20 à 30. Oui, vous avez bien lu.
Ceux qui ont utilisé les jeux vidéo il y a 10 ou 15 ans connaissent forcément les sprites. Pour économiser les ressources on regroupe toutes les icônes et les images dans un ou plusieurs fichiers. Le résultat c'est une sorte de tableau d'images, le jeu utilise alors simplement une partie de cette image à chaque fois qu'il a besoin d'une icône.
Tout est une question de ressources disponibles, à l'époque on parlait de mémoire occupée et d'accès disque. Plusieurs années après, le Web a les mêmes problématiques : la poids et le nombre d'éléments à charger impactent directement et fortement les performances des pages. Il est donc logique qu'on utilise les mêmes solutions.
En avril je vous parlais du packer de Dean Edwards qui permet de miniser le code javascript avant envoi. J'émettais un doute sur l'option base62. Avec cette option le code javascript est codé avant envoi. Une fois ce javascript reçu, le navigateur va le décoder, puis utiliser eval() pour l'exécuter. C'est tout sauf transparent pour le client, surtout que pendant ce temps de traitement supplémentaire, c'est tout le rendu et les téléchargements de la page qui sont bloqués.
Camille Roux me fait part qu'il co-animera avec Nicolas Chevallier une présentation sur l'optimisation des performances d'un site web dans le cadre des Intellicore Tech Talks. Cette présentation se tiendra le mardi 8 Juillet à 13h à Sophia-Antipolis.
Aujourd'hui je fais réviser les bases avec Yslow. Il s'agit d'un outil développé par Yahoo! pour vérifier de façon automatisée l'application des règles de performances web internes. Il offre une vue rapide du poids et du temps de rendu de la page, une notation après vérification une à une de 13 des règles de performance web Yahoo!, des graphiques statistiques sur la gestion du cache, et des informations détaillées sur tous les composants de la page
je vous en avais parlé, maintenant c'est fait. Camille Roux et Nicolas Chevallier ont ont réalisé une présentation sur l'optimisation des performances d'un site web aux Intellicore Tech Talks.
Vous avez donc maintenant la vidéo et les slides disponibles en ligne. Commentaires et comptes rendus bienvenus.
Stoyan Stefanov, de l'équipe Performance de Yahoo! a donné une présentation fin juin sur l'optimisation des images. J'ai déjà parlé de plusieurs choses, il en rajoute d'autres, avec des chiffres percutants et des explications concices.
Je vous avais rapidement parlé de pngcrush pour optimiser les images PNG, sans aucune perte de qualité. Stoyan Stefanov nous propose jpegtran dans sa dernière présentation sur l'optimisation des images.
Utiliser les filtres CSS d'Internet Explorer n'est pas une bonne idée. Déjà ils sont inutiles la plupart du temps, quand vous pouvez vous contenter d'un PNG8 avec une transparence binaire (c'est à dire la plupart du temps si vous avez suivi le début de la phrase), mais en plus ils sont lents.
Le favicon je pense que vous voyez ce que c'est : cette petite icône bête et méchante qu'on voit à côté de l'URL dans la barre d'adresse du navigateur. Là où c'est moins intuitif c'est que ce favicon peut avoir un impact important dans les performances de votre site.
