Articles avec le tag ‘Microsoft Internet Explorer’

Google SDCH et HTTP

Jeudi 12 février 2009

On vous a dit de compresser vos échanges HTTP avec gzip ou deflate, des les identifier avec des ETag, mais pouvons nous faire mieux ? C’est la question abordée par certaines équipes de Google (slides disponibles) en juin dernier aux conférences Velocity 2008. Ils partent du principe qu’une page web est composée de plusieurs éléments, dont certains sont communs à plusieurs pages et ne nécessitent pas d’être renvoyés.

Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, (Lire la suite…)

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…)

Ne pas filtrer les PNGs

Vendredi 18 juillet 2008

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.

Quand vous faites un filter:AlphaImageLoader dans vos CSS, Internet Explorer l’exécute à chaque apparition de l’image dans votre page. Oubliez l’idée qu’il met en cache le résultat ou même qu’il n’exécute le filtre qu’une seule fois par image. Si vous l’utilisez pour une petite icône de présentation qui apparaît vingt fois dans votre page, c’est vingt exécutions du filtres qui sont faites.

À chaque exécution du filtre le rendu est bloqué, en attente. Sur Yahoo! Search en retirant AlphaImageLoader de la feuille CSS c’est jusqu’à 100ms qu’ils ont gagné (information donnée par Stoyan Stefanov sur sa dernière présentation).

Faites un compromis avec vous-même et laissez une simple transparence binaire sur un PNG8. Mais si vous n’y êtes pas prêts, faites au moins en sorte que Internet Explorer 7 et plus n’utilisent pas le filtre, car eux savent nativement lire les couches alpha des images PNG. Transformer filter: en _filter: devrait suffire.