Group items tagged

On fait quoi avec Retina et HiDPI ? On propose une image à résolution plus importante alors qu'on s'est battu des mois à améliorer les performances de nos sites Web ? Comparatif de compressions et de rendus pour haute densité … et où l'on peut constater que cette réduction de poids sera plus efficace et simple à gérer qu'une multiplication des résolutions d'image.

L'approche est maligne mais me dérange sur quelques aspects : 1. Si elle vient à se populariser on va se retrouver avec un Web remplies d'images de qualité médiocre uniquement exploitable sous forme de miniatures. En outre, nous pourrons faire une croix sur les recherches d'images ciblées par dimensions. 2. La contribution par des utilisateurs lambdas ne sera pas aisée de par la validation du rendu après réduction du visuel. 3. Quid de l'automatisation ? Les images présentées dans les exemples de Daan sont de qualité studio et supportent parfaitement le traitement. Enrichir le billet par des photos de moindre qualité serait intéressant.

détaille les différents sous systèmes du navigateur et leur répartition dans le temps total de rendu de la page

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

cette partie a constitué le gros des innovations des finalistes

La partie la plus importante car la plus technique (à mes yeux) : le chargement des dépendances d'une page. Plusieurs techniques, pour des effets variés, mais permettant un rendu rapide.

gros parti pris de Souders sur l'exécution de javascript : il ne devrait même pas être asynchrone, mais différé jusqu'à ce que la page soit rendue

Il n'a pas tout à fait tort, mais il oublie quand même pas mal de choses sur les interfaces modernes. Beaucoup n'ont pas de fallback, ou un fallback très mauvais. Genre un bouton commander qui ouvre une popin. Il est impossible d'envisager ne pas accrocher immédiatement le gestionnaire javascript

Une bonne solution pour s'occuper du cas des 15% de personnes ne recevant pas de contenu compressé, pour cause de proxy ou d'entête mal formée.

Attention qu'on risque de casser le rendu pour certains quand même. Je préfère l'optique de http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/ et http://velocityconf.com/velocity2010/public/schedule/detail/14334 Il s'agit de faire passer un petit js gzipé. S'il s'exécute correctement c'est que le navigateur sait lire gzip. On met alors un cookie et c'est la présence de ce cookie qui permet de forcer gzip côté serveur. La conséquence c'est que ces 15% n'auront pas gzip lors de leur premier accès, mais en retour on sait qu'on n'activera pas gzip s'ils ne le supportent vraiment pas

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.

Je vous l'avais dit, une balise

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.

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

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.

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.

C'est peut être ce qui résoudrait quelques problèmes de performances : une option "fast" en javascript. Cela permettrait de déclarer qu'on n'utilise pas de document.write et ne plus bloquer le rendu du navigateur. On pourrait aussi déclarer ne pas toucher aux prototypes des objets de base pour bénéficier de meilleures optimisations de l'interpréteur.

Nous avons peu d'informations officielles de la part des navigateurs sur les performances de leurs moteurs. Le Mozilla Developer Center nous propose tout de même une courte page sur comment écrire des feuilles de style efficaces.