Quels sélecteurs ou règles CSS peuvent significativement affecter les performances de mise en page / rendu front-end dans le monde réel?

Question

Vaut-il la peine de se préoccuper de la performance du rendu CSS? Ou devrions-nous simplement ne pas nous soucier de l'efficacité du tout avec CSS et nous concentrer plutôt sur l'écriture d'un CSS élégant ou maintenable?

Cette question est destinée à être une ressource utile pour les développeurs front-end sur quelles parties du CSS peuvent avoir un impact significatif sur la performance des appareils, et quels appareils / navigateurs ou moteurs pourraient être affectés. Il ne s'agit pas d'une question sur comment écrire un CSS élégant ou maintenable, il s'agit uniquement de performance (bien que ce qui est écrit ici puisse informer des articles plus généraux sur les bonnes pratiques).

Preuves existantes

Google et Mozilla ont rédigé des directives sur l'écriture efficace de CSS et l'ensemble de règles de CSSLint inclut:

Évitez les sélecteurs qui ressemblent à des expressions régulières .. n'utilisez pas les opérateurs d'égalité complexes pour éviter les pénalités de performance

mais aucun d'entre eux ne fournissent de preuves (que j'ai pu trouver) de l'impact qu'ils peuvent avoir.

Un article de css-tricks.com sur le CSS efficace soutient (après avoir exposé une multitude de bonnes pratiques d'efficacité) que nous ne devrions pas .. sacrifier la sémantique ou la maintenabilité pour un CSS efficace de nos jours.

Un article du blog perfection kills suggérait que border-radius et box-shadow rendaient des ordres de grandeur plus lentement que des règles de CSS plus simples. C'était très significatif dans le moteur d'Opera, mais insignifiant dans Webkit. De plus, un test de performance CSS de smashing magazine a trouvé que le temps de rendu des règles d'affichage CSS3 était insignifiant et significativement plus rapide que de rendre l'effet équivalent en utilisant des images.

Know your mobile a testé divers navigateurs mobiles et a constaté qu'ils rendaient tous le CSS3 de manière équivalent insignifiante rapidement (en 12ms) mais il semble qu'ils ont réalisé les tests sur un PC, donc nous ne pouvons rien déduire sur la performance des appareils portables avec CSS3 en général.

Il y a beaucoup d'articles sur internet sur comment écrire un CSS efficace. Cependant, je n'ai pas encore trouvé de preuves complètes que CSS mal conçu ait effectivement un impact significatif sur le temps de rendu ou la réactivité d'un site.

Contexte

J'ai offert une prime pour cette question pour essayer d'utiliser la puissance communautaire de SO pour créer une ressource utile bien recherchée.

Answer 1

La première chose qui me vient à l'esprit ici est : à quel point le moteur de rendu que vous utilisez est-il intelligent?

.class1 {
    /*rendre les éléments avec "class1" plus jolis*/
}

Donc, quand un moteur très basique voit cela (et puisque c'est la première règle), il parcourt tous les éléments de votre DOM, et vérifie l'existence de class1 dans chacun. Les moteurs plus performants cartographient probablement les noms de classe sur une liste d'éléments DOM et utilisent quelque chose comme une table de hachage pour une recherche efficace.

.class1.class2 {
    /*rendre les éléments avec à la fois "class1" et "class2" encore plus jolis*/
}

Notre exemple de "moteur basique" irait revoir chaque élément dans le DOM à la recherche des deux classes. Un moteur plus intelligent comparera n('class1') et n('class2') où n(str) est le nombre d'éléments dans le DOM avec la classe str, et prendra le plus petit ; supposons que ce soit class1, puis passera à tous les éléments avec class1 à la recherche d'éléments qui ont également class2.

En tout cas, les moteurs modernes sont intelligents (beaucoup plus intelligents que l'exemple discuté ci-dessus), et les nouveaux processeurs rapides peuvent effectuer des millions (voire des dizaines de millions) d'opérations par seconde. Il est peu probable que vous ayez des millions d'éléments dans votre DOM, donc les performances dans le pire des cas pour toute sélection seront de toute façon correctes.

---

Mise à jour :

Pour avoir une preuve illustrative pratique réelle, j'ai décidé de faire quelques tests. Tout d'abord, pour avoir une idée du nombre moyen d'éléments DOM que l'on peut voir dans des applications du monde réel, regardons combien d'éléments se trouvent sur les pages web de certains sites populaires :

Facebook : ~1900 éléments (testé sur ma page principale personnelle).
Google : ~340 éléments (testé sur la page principale, sans les résultats de recherche).
Google : ~950 éléments (testé sur une page de résultats de recherche).
Yahoo! : ~1400 éléments (testé sur la page principale).
Stackoverflow : ~680 éléments (testé sur une page de question).
AOL : ~1060 éléments (testé sur la page principale).
Wikipedia : ~6000 éléments, dont 2420 ne sont pas des spans ou des anchors (testé sur l'article Wikipedia sur Glee).
Twitter : ~270 éléments (testé sur la page principale).

En les additionnant, nous obtenons une moyenne d'environ ~1500 éléments. Maintenant, c'est le moment de faire quelques tests. Pour chaque test, j'ai généré 1500 divs (imbriqués dans d'autres divs pour certains tests), chacun avec des attributs appropriés selon le test.

---

Les tests

Les styles et les éléments sont tous générés en utilisant PHP. J'ai téléchargé les PHP que j'ai utilisés et créé un index, afin que d'autres puissent tester localement : petit lien.

---

Résultats :

Chaque test est effectué 5 fois sur trois navigateurs (le temps moyen est rapporté) : Firefox 15.0 (A), Chrome 19.0.1084.1 (B), Internet Explorer 8 (C) :

                                                                        A      B      C
1500 sélecteurs de classe (.nomDeClasse)                               35ms   100ms  35ms
1500 sélecteurs de classe, plus spécifiques (div.nomDeClasse)          36ms   110ms  37ms
1500 sélecteurs de classe, encore plus spécifiques (div div.nomDeClasse)  40ms   115ms  40ms
1500 sélecteurs d'identifiant (#id)                                   35ms   99ms   35ms
1500 sélecteurs d'identifiant, plus spécifiques (div#id)               35ms   105ms  38ms
1500 sélecteurs d'identifiant, encore plus spécifiques (div div#id)    40ms   110ms  39ms
1500 sélecteurs de classe, avec attribut (.classe[titre="ttl"])        45ms   400ms  2000ms
1500 sélecteurs de classe, attribut plus complexe (.classe[titre~="ttl"]) 45ms   1050ms 2200ms

---

Expériences similaires :

Apparemment, d'autres personnes ont mené des expériences similaires ; celle-ci propose également des statistiques utiles : petit lien.

---

La conclusion :

À moins que vous ne vous souciez de gagner quelques millisecondes lors du rendu (1ms = 0.001s), ne vous embêtez pas trop avec ça. D'un autre côté, il est bon de pratiquer en évitant d'utiliser des sélecteurs complexes pour sélectionner de grands ensembles d'éléments, car cela peut faire une différence notable (comme nous pouvons le voir à partir des résultats des tests ci-dessus). Tous les sélecteurs CSS courants sont raisonnablement rapides dans les navigateurs modernes.

Supposons que vous construisez une page de chat, et que vous voulez styliser tous les messages. Vous savez que chaque message est dans un div qui a un titre et est imbriqué dans un div avec une classe .chatpage. Il est correct d'utiliser .chatpage div[titre] pour sélectionner les messages, mais c'est aussi une mauvaise pratique en termes d'efficacité. Il est plus simple, plus facile à maintenir et plus efficace de donner à tous les messages une classe et de les sélectionner en utilisant cette classe.

---

La conclusion en une ligne élégante :

Tout ce qui est dans les limites du "oui, ce CSS a du sens" est correct.

Answer 2

La plupart des réponses ici l'accent sur le sélecteur de performance, comme si c'était la seule chose qui compte. Je vais essayer de couvrir certains spriting trivia (spoiler alert: ils ne sont pas toujours une bonne idée), le css utilisé la valeur de la performance et de la reddition de certaines propriétés.

Avant d'en arriver à la réponse, laissez-moi obtenir de l'OMI de la route: personnellement, je suis en total désaccord avec le besoin de "données probantes". Il fait tout simplement une allégation de performance apparaissent crédibles, alors qu'en réalité le domaine des moteurs de rendu est hétérogène assez pour faire une telle conclusion statistique inexact de mesure et peu pratique à adopter ou à un moniteur.

Que les originaux des résultats rapidement devenir obsolète, je préfère la voir avant la fin de l'devs ont une compréhension des principes fondamentaux et leur valeur relative à l'encontre de la maintenabilité et la lisibilité de bons points - après tout, l'optimisation prématurée est la racine de tout mal ;)

---

Commençons avec le sélecteur de performance:

Peu profonde, de préférence d'un niveau spécifique de sélecteurs sont traitées plus rapidement. Explicite des mesures de performance sont absents de l'original de la réponse, mais le point clé reste à l'exécution: un document HTML est analysée dans une arborescence DOM contenant N éléments avec une profondeur moyenne D et que a un total de S règles CSS appliquées. De plus faible complexité de calcul O(N*D*S), vous devez

1. Ont le plus à droite des touches de match aussi peu d'éléments que possible - les sélecteurs sont appariés de droite à gauche^ pour chaque règle d'admissibilité ainsi, si le plus à droite de la clé ne correspond pas à un élément particulier, il n'est pas nécessaire de poursuivre le processus de sélection et il est éliminé.

   Il est couramment admis qu' * sélecteur devrait être évité, mais ce point doit être pris de nouvelles. Un "normal" CSS reset n'a, en fait, correspondre à la plupart des éléments - lorsque cette SORTE de page est profilé, la réinitialisation est responsable d'environ 1/3 de l'ensemble du sélecteur correspondant de temps de sorte que vous pouvez préférer normaliser.css (encore, qui n'ajoute jusqu'à 3,5 ms - le point contre l'optimisation résiste)

2. Éviter descendant sélecteurs comme ils ont besoin de jusqu'à ~D des éléments à parcourir. Ce sont essentiellement les impacts incompatibilité de confirmation - par exemple un positif .container .content match ne peuvent demander qu'une étape pour les éléments d'une relation parent-enfant, mais l'arbre du DOM devra être parcouru tout le chemin jusqu'à l' html avant une correspondance peut être confirmé.

3. Minimiser le nombre d'éléments du DOM que leurs styles sont appliqués individuellement (à noter, cela est compensé par navigateur logique comme référence la mise en cache et de recyclage des styles à partir d'éléments identiques - par exemple, lorsque le style identique frères et sœurs)

4. Supprimer les règles depuis le navigateur finit par avoir à évaluer leur applicabilité pour chaque élément de rendu. Assez dit, le plus rapide de la règle est celle qui n'est pas là :)

Il en résultera quantifiables (mais, selon la page, pas nécessairement perceptible) des améliorations à partir d'un moteur de rendu du point de vue des performances, cependant, il existe toujours des facteurs supplémentaires tels que les frais généraux du trafic et DOM analyse etc.

---

Ensuite, propriétés CSS3 performance:

CSS3 nous a apporté (entre autres choses) des coins arrondis, dégradés d'arrière-plan et d'ombre portée variations - et, avec eux, un camion plein de questions. Pensez à ce sujet, par définition, un pré-rendu de l'image est plus performante qu'un ensemble de règles CSS3 qui doit être affiché en premier. De webkit wiki:

Les dégradés, les ombres, et d'autres décorations dans le CSS doit être utilisé uniquement lorsque cela est nécessaire (par exemple, si la forme est dynamique basée sur le contenu) - sinon, les images statiques sont toujours plus vite.

Si cela ne suffisait pas, les dégradés, etc. peut-être recalculées à chaque repeindre/refusion de l'événement (plus de détails ci-dessous). Gardez cela à l'esprit jusqu'à ce que la majorité des utilisateurs, l'utilisateur peut parcourir un css3-lourds de la page comme ceci , sans aucun lag.

---

Ensuite, spriting performance:

Éviter de haut et de large sprites, même si leur trafic empreinte est relativement faible. Il est souvent oublié qu'un moteur de rendu ne peut pas travailler avec des gif/jpg/png et à l'exécution de tous les éléments graphiques sont exploités avec non compressé bitmaps. Au moins c'est facile à calculer: sprite's la largeur multipliée par la hauteur de fois quatre octets par pixel (RGBA) 238*1073*4≅1MB. L'utiliser sur quelques éléments à travers les différents onglets ouverts simultanément, et il ajoute rapidement jusqu'à une valeur significative.

Plutôt un cas extrême, il a été ramassé sur mozilla webdev, mais ce n'est pas à tous les imprévus lors de pratiques douteuses comme la diagonale des sprites sont utilisés.

Une alternative à prendre en compte est individuel, encodée en base64, les images intégrées directement dans le CSS.

---

Ensuite, les remboursements et repeint:

Il est faux de croire qu'une redistribution ne peut être déclenchée avec JS de manipulation du DOM - en fait, toute application de mise en page-affectant le style déclencher affectant l'élément cible, ses enfants et ses éléments à la suite de ça etc. La seule façon d'éviter d'inutiles itérations de c'est pour essayer d'éviter de rendu des dépendances. Un simple exemple de ceci serait rendu des tables:

Tables souvent besoin de plusieurs passages avant la mise en page est totalement établie, car ils sont l'un des rares cas où les éléments peuvent incidence sur l'affichage des autres éléments qui sont venus avant eux sur les DOM. Imaginez une cellule à la fin de la table avec un très large contenu les causes de la colonne pour être complètement redimensionnée. C'est pourquoi les tables ne sont pas rendu progressivement dans tous les navigateurs.

---

Je vais faire des modifications si je me souviens de quelque chose d'important qui a été manquée. Quelques liens pour en finir avec:

http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

http://jacwright.com/476/runtime-performance-with-css3-vs-images/

https://developers.google.com/speed/docs/best-practices/payload

https://trac.webkit.org/wiki/QtWebKitGraphics

https://blog.mozilla.org/webdev/2009/06/22/use-sprites-wisely/

http://dev.opera.com/articles/view/efficient-javascript/

Answer 3

Alors que c'est vrai que

les ordinateurs étaient beaucoup plus lents il y a 10 ans.

Vous avez également une plus grande variété d'appareils capables d'accéder à votre site Web ces jours-ci. Et même si les ordinateurs de bureau/portables ont fait de grands progrès, les appareils du marché des smartphones milieu de gamme et bas de gamme, dans de nombreux cas, ne sont pas beaucoup plus puissants que ce que nous avions dans les ordinateurs de bureau il y a dix ans.

Cela dit, la vitesse de sélection de CSS est probablement en bas de la liste des choses auxquelles vous devez vous préoccuper pour offrir une bonne expérience à un large éventail d'appareils.

En approfondissant ce sujet, je n'ai pas pu trouver d'informations spécifiques sur le fait que les navigateurs plus modernes ou les appareils mobiles ont du mal avec des sélecteurs CSS inefficaces, mais j'ai pu trouver ce qui suit :

1. http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/

   Plutôt daté (IE8, Chrome 2) maintenant mais fait une tentative décente d'établir l'efficacité de divers sélecteurs dans certains navigateurs et tente également de quantifier comment le nombre de règles CSS affecte le temps de rendu de la page.

2. http://www.thebrightlines.com/2010/07/28/css-performance-who-cares/

   Encore assez daté (IE8, Chrome 6) mais va jusqu'aux extrêmes dans les sélecteurs CSS inefficaces * * * * * * * * * { background: #ff1; } pour établir la dégradation des performances.

Answer 4

Pour une prime aussi importante, je suis prêt à risquer la réponse Null : il n'y a pas de sélecteurs CSS officiels qui provoquent des ralentissements significatifs dans le rendu, et (à l'ère des ordinateurs rapides et des itérations rapides des navigateurs) ceux qui sont trouvés sont rapidement résolus par les fabricants de navigateurs. Même dans les navigateurs mobiles, il n'y a aucun problème, à moins que le développeur imprudent ne soit prêt à utiliser des sélecteurs jQuery non standard. Ceux-ci sont considérés comme risqués par les développeurs jQuery, et peuvent en effet poser problème.

Dans ce cas, l'absence de preuves est une preuve de l'absence de problèmes. Donc, utilisez un balisage sémantique (en particulier OOCSS), et signalez tout ralentissement que vous trouvez lors de l'utilisation de sélecteurs CSS standard dans des navigateurs obscurs.

Les gens du futur : les problèmes de performance CSS en 2012 étaient déjà de l'histoire ancienne.

Answer 5

N'est-ce pas que le CSS est un moyen irrélevant de le rendre plus rapide, cela doit être la dernière chose à laquelle vous regardez en termes de performance. Faites votre CSS de la manière qui vous convient, compilez-le, et ensuite mettez-le dans l'en-tête. Cela peut être rude mais il y a plein d'autres choses à vérifier lorsque vous regardez la performance du navigateur. Si vous travaillez dans une agence digitale, vous ne serez pas payé pour gagner ces 1ms supplémentaires en temps de chargement.

Comme je l'ai commenté, utilisez PageSpeed pour Chrome, c'est un outil de Google qui analyse le site web selon 27 paramètres dont le CSS.

Mon message concerne exactement le fait de préférer avoir environ 99% des utilisateurs web capables d'ouvrir le site web et de le voir correctement, même les personnes utilisant IE7 et autres. Plutôt que d'exclure environ 10% en utilisant CSS3, (au cas où cela vous permettrait d'obtenir un gain de performance de 1-10ms).

La plupart des gens ont au moins une connexion de 1 Mbit/512 kbit ou plus, et si vous chargez un site lourd, cela prend environ 3 secondes à charger, mais vous pouvez gagner peut-être 10ms sur le CSS??

Et en ce qui concerne les appareils mobiles, vous devriez créer des sites spécifiquement pour les mobiles, ainsi lorsque vous avez un appareil avec une taille d'écran inférieure à "Largeur"px, vous avez un site séparé.

N'hésitez pas à commenter ci-dessous, c'est ma perspective et mon expérience personnelle en matière de développement web.