Les performances vues des CSS - commentaires

Les performances vues des CSS

@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.

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).

Dans l'absolu, si c'est dans une situation avec très peu d'évolution, non, ce n'est pas grave.

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. ;)

Les performances vues des CSS

Bonjour,

Je sais que cet article n'est pas tout récent, mais je me posais une question par rapport à l'efficacité des sélecteurs.

J'ai l'habitude d'écrire :

 item 1
 item 2
 item 3
 item 4

et de sélectionner mes items de la façon suivante en CSS :
.mon-menu li { ... }

D'après vous, je devrez plutôt écrire :

 item 1
 item 2
 item 3
 item 4

et sélectionner mes items de la façon suivante en CSS :
.item-menu { ... }

C'est bien ça ?

Ça devient lourd je trouve, non ?

Les performances vues des CSS

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).

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.

Les performances vues des CSS

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.

Les performances vues des CSS

Michael : en effet, ça implique de penser via noscript aussi pour que ça ne casse pas.

Pascal : effectivement, très bonne ressource que tu mentionnes, en voici le lien : http://filamentgroup.com/lab/performance-rwd.html

Les performances vues des CSS

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.
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...)
Parmi les outils uncss (grunt par Adi Osmani ) et loadCSS (Filament Group) permettent d'identifier les styles nécessaires à une page (à mettre dans style) puis de charger la feuille complète (pour le cache).
É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.)
L'article de Filament Group contient les stats avant/après et l'impact semble important surtout sur mobile.

Les performances vues des CSS

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.
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 ? :)

Les performances vues des CSS

Ca fait partie des équilibres à étudier au cas par cas.

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.

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 landing page : 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.

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.

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.

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.

Les performances vues des CSS

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".

Je vous renvoie vers les slides de Patrick Hamann [https://speakerdeck.com/patrickhamann/css-and-the-critical-path] qui prend l'exemple du jounal The Guardian.

En mettant le CSS critique dans les 1ers 14Kb (http://blog.jingleweb.fr/2014/07/performance-web-limpact-tcp/) on arrive à afficher du contenu très rapidement à l'écran.

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.

Les performances vues des CSS

Effectivement, cela a des inconvénients ou du moins des contreparties.

Je la vois utile pour certains cas :
– effectivement, le nombre de pages très réduit
– 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)

À 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 :

– au first load, il faut mettre le CSS critique en inline pour accélérer le rendu
– idéalement, il faudrait pouvoir quand même mettre en cache ce CSS, donc le lazy-loader + mise en cache
– 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.).

Bien sûr, si les gabarits changent, ça complexifie encore plus le tout.

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. :)

Il faudrait demander à quelqu'un qui utilise ça, je vais essayer de pinger Kaelig, je crois qu'il a déjà fait ça.

Les performances vues des CSS

Correction je ne voulais pas dire "inline" mais "Embedded"

Les performances vues des CSS

"Dans certains cas extrêmes de recherche de performance, il est même conseillé de mettre le CSS directement en embarqué dans la page".

Cette phrase mériterait d'être détaillée. En utilisant du CSS inline
1. On perds l'intérêt de la mise en cache
2. On surchage chaque page HTML
3. Plus de parallélisation possible.

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 ?

Les performances vues des CSS

Haha excellent le coup du caddie dans le supermarché !

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 : http://davidl.fr/blog/css-evolutif.html

Les performances vues des CSS

Comme d'habitude, article très intéressant. Merci !

Les performances vues des CSS

merci pour l'article ;)

Les performances vues des CSS

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 simple à lire et comprendre - et pas seulement pour le navigateur mais pour le développeur suivant également.

Les performances vues des CSS

Pour de l'optimisation sur la syntaxe (ce qui est abordé au début), un outil comme CSSO (http://bem.info/tools/optimizers/csso/) fait très bien ce taf.
Pour les sélecteurs, utiliser BEM est une bonne idée :
– https://github.com/suitcss/suit/tree/master/doc
– http://putaindecode.fr/posts/css/petite-definition-bem/