<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Performance web &#187; Jim Barrau</title>
	<atom:link href="http://performance.survol.fr/avec/jim-barrau/feed/" rel="self" type="application/rss+xml" />
	<link>http://performance.survol.fr</link>
	<description>Quelques mots pour des sites web rapides</description>
	<lastBuildDate>Fri, 18 Jun 2010 12:47:47 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Gains de performance des sélecteurs CSS</title>
		<link>http://performance.survol.fr/2008/05/gains-de-performance-des-selecteurs-css/</link>
		<comments>http://performance.survol.fr/2008/05/gains-de-performance-des-selecteurs-css/#comments</comments>
		<pubDate>Mon, 12 May 2008 18:45:18 +0000</pubDate>
		<dc:creator>Éric</dc:creator>
				<category><![CDATA[Performance]]></category>
		<category><![CDATA[css]]></category>
		<category><![CDATA[Dave Hyatt]]></category>
		<category><![CDATA[Jim Barrau]]></category>
		<category><![CDATA[Jon Sykes]]></category>
		<category><![CDATA[sélecteur]]></category>
		<category><![CDATA[style]]></category>
		<category><![CDATA[test]]></category>

		<guid isPermaLink="false">http://performance.survol.fr/?p=31</guid>
		<description><![CDATA[Je parlais il y a quelques jours de performance des sélecteurs CSS. Il y a eu quelques réactions et j&#8217;ai échoué dans mes explications : les différences de performance dont on parle ici sont probablement négligeables la plupart du temps. &#8230; <a href="http://performance.survol.fr/2008/05/gains-de-performance-des-selecteurs-css/">Continuer la lecture <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>Je parlais il y a quelques jours de <a href="http://performance.survol.fr/2008/05/performance-des-selecteurs-css/">performance des sélecteurs <acronym title="cascading style sheet">CSS</acronym></a>. Il y a eu quelques réactions et j&#8217;ai échoué dans mes explications : les différences de performance dont on parle ici sont probablement négligeables la plupart du temps. Hors commentaires, certains m&#8217;ont rappelé que la documentation de Mozilla concerne d&#8217;ailleurs au départ les interfaces <acronym title="xml user interface language">XUL</acronym> avec de gros documents <acronym title="extensible markup langage">XML</acronym> complexes agrémentés de très grosses feuilles de style.</p>
<h3>Quelle importance ?</h3>
<p>Il n&#8217;y a pas lieu de refaire vos CSS ou de commencer à mettre en place des solutions qui handicapent la maintenance du site (par exemple ne plus utiliser aucun sélecteur descendant). Il y a toutefois parfois utilité. Sur de grosses pages spéciales ou simplement sur les gros sites, ça peut avoir une influence.<span id="more-26"></span> Je pense en particulier à la philosophie du « on ajoute les nouvelles règles, on modifie parfois, mais on ne supprime pas » qui prévaut sur certains gros sites, par peur de casser quelque chose ou parce que le site est trop gros pour garantir qu&#8217;on ne casse rien.  Là il est peut être possible de gagner une centaine de millisecondes ou deux. On ne changera pas la feuille de style mais connaître les motifs qui posent problème permet éventuellement d&#8217;anticiper et d&#8217;écrire autant que possible quelque chose de performant. Ca ne fera de toutes façons pas de mal.</p>
<h3>Où on précise ce qui doit l&#8217;être</h3>
<p>Tout ceci est confirmé par quelques unes de mes lectures récentes. J&#8217;aurai préféré les intégrer dans les billet précédent mais les liens de départ viennent seulement de sauter dans mon aggrégateur <acronym title="really simple syndication">RSS</acronym>.  Dans l&#8217;ordre chronologique c&#8217;est <a href="http://www.shauninman.com/archive/2008/05/05/css_qualified_selectors#comment_3942">Dave Hyatt qui répond à une proposition d&#8217;évolution de CSS</a> (commentaire 37). Il explique le fonctionnement interne des navigateurs pour tracker les règles applicables et les continuer à appliquer vos CSS malgré les changements dans le <acronym title="document object model">DOM</acronym>. Le tout rejoint ce que j&#8217;avais retenu du document de Mozilla. En même temps c&#8217;est logique car c&#8217;est le même auteur, et lui l&#8217;explique bien mieux que moi.</p>
<h3>Et ce qu&#8217;il faut en conclure</h3>
<p>C&#8217;est Jim Barraud qui en sort <a href="http://jimbarraud.com/2008/05/07/css-inefficiency/">la conclusion que j&#8217;aurai bien aimé écrire</a>. Pas de chance pour moi, j&#8217;ai toujours voulu en écrire des tartines en cherchant tous les détails quand seule la conclusion est primordiale. Tel qu&#8217;il faut le lire : <strong>intuitivement on peut penser que spécifier l&#8217;ascendance des balises ou préciser des détails comme le nom de la balise peut aider le navigateur, en réalité c&#8217;est le contraire</strong>. Relisez cette phrase, c&#8217;est l&#8217;unique d&#8217;importance. Tout le billet précédent est composé de détails de moindre importance pour ceux qui sont aussi curieux que moi.</p>
<h3>Pour ceux qui veulent des chiffres</h3>
<p>JP Sykes a lui tenté de mesurer le gain de performance concret. Je n&#8217;ai pas eu le courage de le faire, prévoyant des résultats peu concluants. Avec <a href="http://jpsykes.com/151/testing-css-performance">son premier essai</a> il a été dans l&#8217;impossibilité de distinguer une quelconque différence. Il lui a fallu faire <a href="http://jpsykes.com/152/testing-css-performance-pt-2">un second essai</a> avec tableau de 20.000 cellules bourré d&#8217;identifiants et de classes, avec autant de déclarations de style (donc une par cellule) pour trouver des différences significatives. Avec ces tests peu représentatifs on arrive enfin à des différences jusqu&#8217;à 60% (pour Safari 3) qui représentent plus d&#8217;une seconde.  Si on considère les performances comme linéaires par rapport au nombre de sélecteur et par rapport au nombre de cellules, un document HTML plus raisonnable (environ l&#8217;équivalent de 50&#215;20 cellules) la différence de performance dépasse à peine les 10ms. Bref, intéressant à connaître mais certainement pas le point le plus important.</p>
]]></content:encoded>
			<wfw:commentRss>http://performance.survol.fr/2008/05/gains-de-performance-des-selecteurs-css/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
