Articles avec le tag ‘webkit’

Quel avenir ?

Mardi 2 décembre 2008

Vouloir optimiser le code et régler les performances, est-ce un sujet qui sera obsolète bientôt ?

La question peut-être posée autrement : n’est-on pas en train de compenser les défauts des navigateurs dans quelques millions de sites avec des résultats discutables au lieu de fixer les quelques navigateurs ?

Sus au navigateur !

Ma première réponse habituelle est de dire que si, nous sommes, pour bonne partie, en train de compenser les manques et les défauts de nos navigateurs. C’est le cas quand on parle d’agréger les contenus (au lieu d’utiliser le HTTP pipelining), quand on parle de déplacer les javascript en fin de document (au lieu de laisser le navigateur les télécharger en parallèle) ou quand on parle de séparer les contenus statiques sur plusieurs domaines (pour exploiter au mieux la configuration de nos navigateurs).

Vive le navigateur !

Heureusement il y a beaucoup d’activité actuellement chez les éditeurs logiciels. Opera, Apple/Webkit, Mozilla et même Microsoft font des efforts. La génération qui arrive va avoir des navigateurs avec beaucoup moins de goulots d’étranglement côté performances, et un ressenti de vitesse non atteint jusque là : Les javascript vont enfin pouvoir se télécharger en parallèle et ne plus bloquer le rendu, on ouvre plus de requêtes simultanées par serveur, et on tente quelques optimisations.

C’est Steve Souders qui nous propose un petit tableau récapitulatif sur les possibilités de cette nouvelle génération de navigateurs (que John Resig commente). Tout n’est pas parfait mais vous noterez intuitivement une bonne dose de vert pour Microsoft Internet Explorer 8, Minefield 3.1 (qui est la version de Firefox en développement), et WebKit 4. Les cases faisant la différence entre ces trois là sont liées aux redirections et au prechargement, ce sont certainement les colonnes les moins importantes de la grille. Opera reste de côté tant qu’il ne permet pas de paralléliser les scripts, mais il y a tout lieu de penser que cela va s’arranger.

Agissons maintenant

Tout va bien, arrêtons tout parce que ça va être corrigé sur les navigateurs ? Surtout pas ! Tout simplement parce que vos utilisateurs et votre site ne peuvent pas attendre les multiples années nécessaires à ce que le parc des navigateurs soit mis à jour.

Bref, nous n’avons pas le choix. Le visiteur se moque de savoir que c’est la faute du navigateur, qu’un plus récent est en préparation, ou même qu’un plus récent est disponible en téléchargement. Lui voit que votre site est lent, agaçant, et peut être qu’en allant chez le concurrent ça sera mieux – à navigateur égal.

En attendant que toutes les versions actuelles des navigateurs soient remplacées, vous devez agir, quitte à agir en pompier pour corriger les défaillances de ces derniers.

Surtout que c’est un peu notre faute

Mais n’oubliez pas, derrière cette grille il y a encore beaucoup de choses qui sont de la responsabilité de l’intégrateur web ou de l’administrateur web. Je parle de cache, d’agrégation de contenu, de compression http, d’images en sprites, d’optimisations javascript, ou simplement d’ordonnancement des composants.

Ne croyez pas que même avec ces superbes moteurs de navigateur qui arrivent, la performance deviendra un sujet obsolète.

Performance des sélecteurs CSS, encore un mot

Vendredi 17 octobre 2008

On reparle des performances CSS. Souvenez-vous, je vous avais parlé d’un document de Mozilla faisant état des sélecteurs plus ou moins performants. S’était ensuivi une discussion à propos de la pertinence de tels sujets vu la différence de performance mise en oeuvre.

Je vous invite à relire ce second billet, qui résume assez bien. Si on remet le couvert c’est que Jon Sykes a refait un troisième test tout récemment, avec un graphique assez sympa

(Lire la suite…)

Interpréteur JSON natif pour webkit

Vendredi 25 juillet 2008

Je vous en parlais il y a presque deux mois, JSON c’est lent à interpréter si on le fait bien. C’est même globalement plus lent que XML parce que le code est en javascript, côté utilisateur, alors que XML est géré nativement par les navigateurs.

La solution c’est l’arrivée de moteurs JSON natifs dans les navigateurs. Mozilla Firefox l’a prévu (actuellement dans les plans pour la version 3.1). Anthony Ricaud m’a comme a son habitude fait passé des liens WebKit alors voilà : Adam Barth y travaille pour WebKit.

Nul doute qu’Opera suivra les deux premiers s’ils implémentent l’API de la même façon. Il restera Microsoft Internet Explorer, mais pouvoir utiliser l’API native et basculer sur le chargement d’une bibliothèque javascript uniquement si elle n’est pas présente, c’est déjà un gros pas en avant.

Limitations du cache Safari

Mardi 6 mai 2008

Pour l’iphone

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. Des objets de plus de 25 ko on en trouve malheureusement fréquemment, par exemple une grosse feuille de style. Bref, minifiez vos fichiers javascript et CSS, compressez vos images. (Lire la suite…)