Les performances vues des CSS - commentaires Les performances vues des CSS 2016-02-20T08:20:59Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2805 2016-02-20T08:20:59Z <p>@Matthieu => Qu'on s'entende bien : si l'on prend l'axe strict des performances, c'est de la micro-micro-optimisation. Et ce n'est franchement pas grave.</p> <p>Après il y a d'autres considérations : supposons que ce menu doive être dupliqué et adapté, puis adapté en responsive, puis re-dupliqué, etc. là on va apprécier de cibler directement chaque élément et d'éviter des sélecteurs à rallonge très pénibles (et un joyeux bordel).</p> <p>Dans l'absolu, si c'est dans une situation avec très peu d'évolution, non, ce n'est pas grave.</p> <p>Sur la question de la lourdeur, ce n'est qu'un point de vue : perso je me suis habitué à faire ainsi, et j'y trouve plus agréable. ;)</p> Les performances vues des CSS 2016-02-19T14:18:31Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2804 2016-02-19T14:18:31Z <p>Bonjour,</p> <p>Je sais que cet article n'est pas tout récent, mais je me posais une question par rapport à l'efficacité des sélecteurs.</p> <p>J'ai l'habitude d'écrire :</p> <div style="text-align: left;" class="spip_code" dir="ltr"><code><ul class="mon-menu"><br /> <li>item 1</li><br /> <li>item 2</li><br /> <li>item 3</li><br /> <li>item 4</li><br /> </ul></code></div> <p>et de sélectionner mes items de la façon suivante en CSS :<br class="autobr" /> <code class="spip_code" dir="ltr">.mon-menu li { ... }</code></p> <p>D'après vous, je devrez plutôt écrire :</p> <div style="text-align: left;" class="spip_code" dir="ltr"><code><ul><br /> <li class="item-menu">item 1</li><br /> <li class="item-menu">item 2</li><br /> <li class="item-menu">item 3</li><br /> <li class="item-menu">item 4</li><br /> </ul></code></div> <p>et sélectionner mes items de la façon suivante en CSS :<br class="autobr" /> <code class="spip_code" dir="ltr">.item-menu { ... }</code></p> <p>C'est bien ça ?</p> <p>Ça devient lourd je trouve, non ?</p> Les performances vues des CSS 2015-07-24T08:19:42Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2739 2015-07-24T08:19:42Z <p>Olivier C. : le problème de ces sélecteurs vient du fait de l'analyse des sélecteurs, de droite à gauche (le navigateur va tout prendre, et regarder lesquels sont dans le sélecteur suivant).</p> <p>Après, outre ces considérations, je trouve que c'est un peu comme !important : c'est un bazooka, et un bazooka mal manié fait beaucoup de dégâts inutiles.</p> Les performances vues des CSS 2015-07-23T14:11:41Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2738 2015-07-23T14:11:41Z <p>Je suis en phase avec tous les points abordés dans cet article, sauf avec celui des sélecteurs universels. En effet, outre le fait qu'ils permettent une grande polyvalence j'attends toujours une preuve de leur contre-productivité, chiffre à l'appui.</p> Les performances vues des CSS 2014-08-14T07:29:18Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2518 2014-08-14T07:29:18Z <p>Michael : en effet, ça implique de penser via noscript aussi pour que ça ne casse pas.</p> <p>Pascal : effectivement, très bonne ressource que tu mentionnes, en voici le lien : <a href="http://filamentgroup.com/lab/performance-rwd.html" class="spip_url spip_out auto" rel="nofollow external">http://filamentgroup.com/lab/performance-rwd.html</a></p> Les performances vues des CSS 2014-08-13T20:37:14Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2517 2014-08-13T20:37:14Z <p>En ce qui concerne les css dans la page HTML, c'est intéressant pour les mobiles lorsque la quantité de css est importante. La mise en oeuvre est relativement complexe : il faut prévoir une mise en cache (lorsque la page est rendue) & utiliser les cookies (en js) pour ne pas le faire sur les pages / accès suivants.<br class="autobr" /> Le dernier article de Filament Group décrit bien le processus, les outils, le pourquoi (désolé pas de lien je suis en vacances avec un réseau chaotique...)<br class="autobr" /> Parmi les outils uncss (grunt par Adi Osmani ) et loadCSS (Filament Group) permettent d'identifier les styles nécessaires à une page (à mettre dans <code class="spip_code" dir="ltr">style</code>) puis de charger la feuille complète (pour le cache).<br class="autobr" /> Évidemment, ce type d'amélioration de la perf n'a d'impact que si tous les autres voyants sont au vert (images, scripts & styles concaténés et minifiés etc.)<br class="autobr" /> L'article de Filament Group contient les stats avant/après et l'impact semble important surtout sur mobile.</p> Les performances vues des CSS 2014-08-13T14:49:55Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2516 2014-08-13T14:49:55Z <p>On peut utiliser un cookie pour détecter le premier chargement de la page et afficher le CSS critique seulement dans ce cas, tout en ayant un fichier externe avec le CSS qui sera en cache, mais je suis pas sur de l'impact sur les performances du Javascript qui va tester l'existance du cookie.<br class="autobr" /> Après les cookies/Javascript peuvent être désactivés toussaaa donc bon.. perso, je pense qu'on est dans la trache des 20% (règle des 80-20) non ? :)</p> Les performances vues des CSS 2014-08-13T08:14:49Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2515 2014-08-13T08:14:49Z <p>Ca fait partie des équilibres à étudier au cas par cas.</p> <p>Je pense qu'on peut facilement conseiller d'avoir une CSS unique en ressource externe, mise en cache pour le cas générique. L'idée c'est que l'utilisateur a des chances de revenir plusieurs fois, profitant de la mise en cache et donc de l'économie d'un second transfert. C'est d'autant plus vrai si la CSS est la même pour toutes les pages du site.</p> <p>Certains ont tenté, avec des résultats intéressants, de mettre la CSS de certaines pages en inline. Généralement c'est pour des <i>landing page</i> : page d'accueil, adresse pour un concours, pour une page avec conversion immédiate, etc. L'idée c'est de faire en sorte que la toute première impression soit exceptionnelle, quitte à rajouter le poids d'une CSS téléchargée une seconde fois (cette fois ci en fichier lié et mis en cache) sur les pages suivantes.</p> <p>Le cas parfait pour moi c'est sur une page autonome où on attend un fort taux de conversion (genre inscription de l'utilisateur) et où l'utilisateur arrive directement. Le temps d'attente peut faire gagner quelques dixièmes de points de conversion.</p> <p>Ca peut aussi s'envisager sur une page d'accueil qui aurait peut de fichiers annexes et qui de toutes façons ne partagerait pas exactement la même CSS que le reste du site (ce qui arrive finalement fréquemment). La page du moteur Google est un très bon exemple mais ça n'a pas besoin d'être aussi spécifique que ça.</p> <p>Par contre ça veut dire ne pas gâcher la même page avec plein de ressources externes ou un rendu long, sinon le gain sera nul au premier passage, et négatif sur tous les suivants.</p> Les performances vues des CSS 2014-08-13T08:14:01Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2514 2014-08-13T08:14:01Z <p>L'intérêt de mettre une partie minime (mais critique) du CSS est en effet la sensation de vitesse apportée à l'utilisateur, en chargeant en priorité le contenu "above the fold".</p> <p>Je vous renvoie vers les slides de Patrick Hamann [<a href="https://speakerdeck.com/patrickhamann/css-and-the-critical-path" class="spip_url spip_out auto" rel="nofollow external">https://speakerdeck.com/patrickhamann/css-and-the-critical-path</a>] qui prend l'exemple du jounal The Guardian.</p> <p>En mettant le CSS critique dans les 1ers 14Kb (<a href="http://blog.jingleweb.fr/2014/07/performance-web-limpact-tcp/" class="spip_url spip_out auto" rel="nofollow external">http://blog.jingleweb.fr/2014/07/performance-web-limpact-tcp/</a>) on arrive à afficher du contenu très rapidement à l'écran.</p> <p>Quant à l'alourdissement des pages HTML, il est évident. Je pense qu'il est indispensable de combiner cette optimisation avec d'autres techniques, telles que le GZIP des pages par exemple.</p> Les performances vues des CSS 2014-08-13T07:55:48Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2513 2014-08-13T07:55:48Z <p>Effectivement, cela a des inconvénients ou du moins des contreparties.</p> <p>Je la vois utile pour certains cas : <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> effectivement, le nombre de pages très réduit <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> donner une « sensation » de vitesse en mettant le CSS critique en inline (j'ai reformulé la phrase qui était en effet un peu légère)</p> <p>À mon avis personnel, c'est vraiment à utiliser dans des cas bien particuliers de recherche de performance, ou de sensation de performance (pour que le navigateur commence déjà à afficher la page pendant que les assets continuent à se charger). Cela implique de mettre en place tout un système un poil compliqué (et qui doit être automatisé). En gros :</p> <p><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> au first load, il faut mettre le CSS critique en inline pour accélérer le rendu <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> idéalement, il faudrait pouvoir quand même mettre en cache ce CSS, donc le lazy-loader + mise en cache <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> et à un second load ou sur une autre page, ne plus avoir ce CSS en inline vu qu'il a été mis en cache au coup précédent (ou le ré-avoir systématiquement si le lazy-load était impossible au coup précédent, etc.).</p> <p>Bien sûr, si les gabarits changent, ça complexifie encore plus le tout.</p> <p>Je ne vais pas mentir : même si j'ai fait qq essais en mode curieux, je n'ai eu à mettre un tel système en place sur mes réalisations. Dans les cas où je suis, j'ai franchement plus à gagner à tout servir de manière très classique en concentrant mes optimisations sur la CSS en elle-même et en limitant le nombre de requêtes. Cela me permet de descendre régulièrement en-dessous de 3s de temps d'affichage sur un navigateur moderne (avec serveur en Europe et testé depuis les USA), je n'ai clairement pas le temps ni le budget pour aller gratter encore des ms supplémentaires. :)</p> <p>Il faudrait demander à quelqu'un qui utilise ça, je vais essayer de pinger Kaelig, je crois qu'il a déjà fait ça.</p> Les performances vues des CSS 2014-08-12T22:44:50Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2511 2014-08-12T22:44:50Z <p>Correction je ne voulais pas dire "inline" mais "Embedded"</p> Les performances vues des CSS 2014-08-12T22:36:01Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2509 2014-08-12T22:36:01Z <p>"Dans certains cas extrêmes de recherche de performance, il est même conseillé de mettre le CSS directement en embarqué dans la page".</p> <p>Cette phrase mériterait d'être détaillée. En utilisant du CSS inline<br class="autobr" /> 1. On perds l'intérêt de la mise en cache<br class="autobr" /> 2. On surchage chaque page HTML<br class="autobr" /> 3. Plus de parallélisation possible.</p> <p>L'intérêt d'une telle pratique ce limite au site web composé d'un nombre très réduit de page HTML et encore. Je dirai même qu'a partir de deux pages HTML cette technique devient une mauvaise pratique. Votre avis ?</p> Les performances vues des CSS 2014-05-28T08:52:58Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2416 2014-05-28T08:52:58Z <p>Haha excellent le coup du caddie dans le supermarché !</p> <p>Pour ceux qui souhaitenent faire un audit de leur CSS pour vérifier sa santée j'ai écrit un article qui reprends certains concepts : <a href="http://davidl.fr/blog/css-evolutif.html" class="spip_url spip_out auto" rel="nofollow external">http://davidl.fr/blog/css-evolutif.html</a></p> Les performances vues des CSS 2014-05-16T07:40:22Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2403 2014-05-16T07:40:22Z <p>Comme d'habitude, article très intéressant. Merci !</p> Les performances vues des CSS 2014-05-15T18:02:48Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2400 2014-05-15T18:02:48Z <p>merci pour l'article ;)</p> Les performances vues des CSS 2014-05-15T10:24:13Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2399 2014-05-15T10:24:13Z <p>Ta dernière partie sur les sélecteurs peut également être justifiée par le fait que plus le sélecteur est efficient, plus il est <strong>simple</strong> à lire et comprendre - et pas seulement pour le navigateur mais <i>pour le développeur suivant</i> également.</p> Les performances vues des CSS 2014-05-15T09:29:44Z https://openweb.eu.org/articles/les-performances-vues-des-css#comment2398 2014-05-15T09:29:44Z <p>Pour de l'optimisation sur la syntaxe (ce qui est abordé au début), un outil comme CSSO (<a href="http://bem.info/tools/optimizers/csso/" class="spip_url spip_out auto" rel="nofollow external">http://bem.info/tools/optimizers/csso/</a>) fait très bien ce taf.<br class="autobr" /> Pour les sélecteurs, utiliser BEM est une bonne idée : <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> <a href="https://github.com/suitcss/suit/tree/master/doc" class="spip_url spip_out auto" rel="nofollow external">https://github.com/suitcss/suit/tree/master/doc</a> <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> <a href="http://putaindecode.fr/posts/css/petite-definition-bem/" class="spip_url spip_out auto" rel="nofollow external">http://putaindecode.fr/posts/css/petite-definition-bem/</a></p>