Group items tagged

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.

Je cherche encore l'intérêt par rapport à un mod_gzip ou mod_deflate

Deux recherches plus approfondies sur le sujet : http://www.iamcal.com/png-store/ http://iamcal.github.com/PNGStore/ Au final, entre les problèmes de génération d'images (liés aux librairies), les problèmes d'implémentation des canvas dans les navigateurs, les limitations liées au format d'image et le peu de gain retiré face au mod_gzip, je ne suis pas convaincu que ce sera la révolution de l'année en matière de performance front...

C'est franchement de la grosse bidouille, le seul avantage que je vois c'est que ça permet de charger des JS et CSS sans les exécuter, de faire du préchargement en background pour un futur module à afficher, une popin par exemple... Mais il existe déjà des techniques plus simples pour faire ça donc...

Proposition pour embarquer l'alpha dans un fichier JPEG

j'espère que ça restera vraiment une "expérience", utiliser canvas, javascript, css pour afficher une image transparente, avec ces inconvénients : # By default, the images load without their alpha, then get alpha'd causing a flash. This can be worked around by making them invisible until correctly loaded. # The image must reside on the same server as the web page or the cross site scripting prohibitions in AJAX will come into play. # My examples are double loading the image, for some reason the AJAX fetch is not using the cache. I don't know why, but it is probably just me. ça reste un affreux bricolage qui pourrait donner des envies à des gens qui n'y connaissent rien et pourrir des sites avec ça. Mais l'expérience est "amusante" de là à en faire une "proposition", j'ai des doutes

C'est clair qu'afficher l'alpha avec canvas+js reste du bricolage. En revanche, si les implémenteurs arrivent à se mettre d'accord pour le faire directement dans le navigateur, ça pourrait être intéressant.

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

Je vous l'avais dit, une balise

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.

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 favicon je pense que vous voyez ce que c'est : cette petite icône bête et méchante qu'on voit à côté de l'URL dans la barre d'adresse du navigateur. Là où c'est moins intuitif c'est que ce favicon peut avoir un impact important dans les performances de votre site.

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.

La communication des éditeurs de navigateur ressemble plus en plus à celle des vendeurs de lessive, mais au moins on commence à voir l'importance des performances.

Les mobiles ont longtemps été une cible très spécifique à base de WAP. C'est maintenant révolu et on a de réels navigateurs complets avec javascript et CSS. Que peut-on faire de spécifique pour le Web mobile ? C'est Jason Grigsby de cloudfour qui vient de donner une présentation "Going fast on the mobile web". 

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.

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.