Articles avec le tag ‘parallélisation’

Séparer en plusieurs domaines ?

Jeudi 28 mai 2009

L’année dernière je parlais du nombre de requêtes simultanées vers un même domaine. L’année dernière Internet Explorer 6 et 7 (2 requêtes simultanées) étaient fortement majoritaire, Firefox 3 (6 requêtes simultanées) était moins répandu que maintenant. L’étude de Yahoo! a été faite il y a deux ans, sur des bases encore moins favorables.

Avec ces statistiques la recommandation était de répartir les téléchargements sur deux domaines, quatre maximum. On arrive donc à 4 ou 8 requêtes simultanées. Plus consomme inutilement du processeur et provoque un surplus inutile de requêtes DNS. (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.

Javascript en ligne

Mercredi 6 août 2008

Je fais suite au précédent billet sur la présentation de Steve Souders aux conférences Velocity 2008. Tout à la fin il nous donne une seconde information sur le javascript inline, et ceci est une nouveauté pour moi.

La situation de base : Firefox bloque tous les nouveaux téléchargements quand il récupère une feuille de style. Une fois n’est pas coutume c’est Internet Explorer qui est le plus efficace, car il permet de paralléliser tous ces téléchargements.

Enfin presque. (Lire la suite…)

Javascript non bloquant

Lundi 4 août 2008

Je vous l’avais dit, une balise <script> bloque le rendu et les nouveaux téléchargements dans le navigateur le temps que le javascript soit complètement téléchargé et exécuté. Une des solutions c’est de reléguer cette balise à la fin du document.

Il y a des fois où ce n’est pas idéal et c’est Steve Souders qui étudie les solutions dans sa présentation aux conférences Velocity 2008. (Lire la suite…)

Keep-alive et connexions persistantes

Mardi 8 avril 2008

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