Group items tagged

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

Traditional Yahoo! web servers serve compressed content to only 'good' browsers, and always with "Cache-Control: private". Newer Yahoo! web servers serve compressed content if the incoming request asks for it. No check is performed on the UA.

en même temps les "fortune 1000" ne sont surement pas tout purement Web, et pour les sites corporates, je ne pense pas que le manque de performance soit très grave

Après avoir parlé de minimisation, il est temps de parler de compression, la règle 4 des recommandations de l'équipe performance Yahoo!.

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.