Nos navigateurs sont performants, ils savent gérer plusieurs téléchargements en parallèle. Ca nous permet de palier les serveurs lents, et d'optimiser le réseau. Le temps qu'on se connecte sur un serveur, qu'on fasse une requête DNS, le réseau reste occupé avec d'autres téléchargements.
Présentation rapide des 11 sous-systèmes utilisés par un navigateur Web pour effectuer le rendu de la page, en partant du réseau pour terminer à l'affichage.
Quelques chiffres montrent qu'en tant que développeur Web, on a la main sur les temps utilisés sur chacune des couches ... pour peu qu'on l'ait en tête.
C'est chose faite ;-)
On parle de temps, de performance, mais finalement que mesure t-on ? La question n'est pas inutile puisque pour une même requête il y a bien trois étape visibles du point de vue du visiteur, cinq du point de vue du navigateur et autant pour le serveur. Alors, que mesure t-on ?
Le pipelining HTTP c'est faire gérer au serveur une file de requêtes. Le navigateur envoie plusieurs requêtes à la suite les unes des autres sans attendre la réponse du serveur. Le serveur renvoie alors les réponses dès qu'il les a, potentiellement en parallèle aux requêtes du navigateur. Non seulement on utilise le principe de la connexion persistante, mais on évite d'attendre la réponse précédente avant d'envoyer la suite. Pour chaque ressource à télécharger après la première, c'est un aller-retour réseau à rien faire qui est évité.
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.
Après avoir parlé hier des stratégies d'optimisation, parlons rapidement de ce qu'il y a à gagner. Je me concentre sur la stratégie la plus fréquente : tenter de regrouper nos ressources dans des gros fichiers globaux.
Web developers using high amounts of domain sharding to work around low connection per host limits in old browser should reconsider their number of shards for newer browsers. Anything over 2 is probably too much, unless most of your user base is using older browsers.
"Slowy is a tool which simulates custom connection's conditions and limits the network traffic to a specified destination port. It is created for web developers, like me, who need to test a website with a real-world connection, even on a local server. Slowy is an OSX MenuBar app, so it is lightweight and is placed only on the system topbar. "
J'ai beaucoup parlé de CSS, de réseau, de javascript, et j'entend parfois dire que le HTML lui n'a aucune importance. Ce n'est malheureusement pas vrai. Il y a au moins trois points à regarder dans le HTML : la qualité syntaxique du code, le mode de rendu des tableaux, et le nombre de noeuds DOM.
Je vous détaille le premier ici, les deux autres bénéficieront d'un billet dédié afin de mieux organiser les commentaires.
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.
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.
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.