Performance Calendar » CSS Selector Performance has changed ! (For the better)

/css-selector-performance-has-changed-fo

    • Héhé... Je ne suis pas complètement d’accord avec leur « (And help you code better) » : n’oublions pas « Premature optimization is the root of all evil » (Knuth / Hoare) :

      – Certaines optimisations CSS (pas toutes) vont à l’encontre de ce qu’on cherche parfois à faire (modularité, réutilisation, généricité).
      – Les moteurs de rendu des navigateurs évoluent, et n’ont pas tous les mêmes performances, sur les mêmes règles/sélecteurs.

      Après, oui, le sélecteur « * » çaymal, je suis d’accord... ^^

      –---

      Il y a un buzz en ce moment sur ce sujet (performances et css), lire par exemple :

      http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes (border-radius ça fait mal, text-shadow c’est ok)

      http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better

      http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors (attention vieil article, plus trop à jour, mais point de vue intéressant ) :

      Based on these tests I have the following hypothesis: For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs. There are some types of CSS rules and interactions with JavaScript that can make a page noticeably slower. This is where the focus should be. So I’m starting to collect real world examples of small CSS style-related issues (offsetWidth, :hover) that put the hurt on performance.

      (je confirme pour le :hover sur certains navigateurs.... genre IE<=8 ^^)

      Bon, désolé pour la tartine... mais manifestement il fallait que ça sorte :-)

    • Intéressant pour les quelques avertissements d’incompatibilité. Pour les performances, en effet, on peut éventuellement s’en passer pour l’immense majorité des sites. En effet, c’est ailleurs que dans quelques règles CSS maladroites à réécrire que l’on gagne le plus de performances.

      Ceci étant, l’accessoire mobile devenant de plus en plus représentatif de l’Internaute, celui-ci étant habituellement branché sur batterie à la durée de vie limitée, il est pertinent d’optimiser les ressources nécessaires par le chargement et l’affichage d’un site web.

      En ce moment, je m’essaye à mod_pagespeed pour Apache :

      http://code.google.com/speed/page-speed/docs/module.html

      Une fois que l’on a compris comment le faire fonctionner sur un site (entre une demi-journée et deux jours ; enfin surtout selon le niveau de connaissance que l’on veut avoir du module et des tests que l’on veut effectuer), réutiliser ce savoir-faire par ailleurs paraît simple et se fait rapidement. Ce module Apache peut alors servir d’un ersatz de proxy intelligent, qui optimise notamment le CSS.

      En matière de CSS, en effet, mod_pagespeed peut :

      – convertir les images de fond en sprites (une seule requête au serveur pour charger l’ensemble des images utilisées dans la mise en page) ;
      – éliminer le chargement externe d’images de petite taille (grâce au locateur data ://) ;
      – re-compresser les images selon les formats supportés par les navigateurs (JPEG, PNG en général, WebP pour Chrome et Opera) ;
      – concaténer plusieurs CSS entre eux (une seule requête au serveur) ;
      – minimiser le CSS ;
      – compresser le CSS (gzip) ;
      – dispatcher les requêtes sur plusieurs hôtes distincts (chargement parallélisé, requêtes sans cookies) ;
      – etc.

      Certes, on peut atteindre la même chose, probablement de manière plus performante, en adaptant sa chaîne de production ou de déploiement, mais l’avantage ici de mod_pagespeed est d’éliminer ce type d’optimisations spécifiques au projet et réclamant des compétences éventuellement rares, rendant le projet difficile à maintenir, donc cher.

      #google #pagespeed #mod_pagespeed #apache