Est-ce important pour la performance?

Je les déteste, il défie la nature en cascade de CSS, et si vous ne les utilisez pas avec soin, vous vous retrouvez dans une boucle d’ajout de plus !important

Mais je veux savoir s’ils sont mauvais pour la performance?

MODIFIER
D’après les réponses (rapides), je peux conclure que cela n’aura pas un impact (significatif) sur les performances. Mais c’est bien de savoir, même si c’est juste un argument supplémentaire pour décourager les autres;).

EDIT 2
BoltClock a souligné que, s’il y avait 2 déclarations !important , les spécifications indiquaient qu’elles choisiraient la plus spécifique.

Cela ne devrait pas vraiment avoir d’effet sur la performance. Voir l’parsingur CSS de firefox sur /source/layout/style/nsCSSDataBlock.cpp#572 et je pense que c’est la routine pertinente, gérant le remplacement des règles CSS.

cela semble juste être une simple vérification de “important”.

  if (aIsImportant) { if (!HasImportantBit(aPropID)) changed = PR_TRUE; SetImportantBit(aPropID); } else { // ... 

Aussi, commentaires à la source/layout/style/nsCSSDataBlock.h#219

  /** * Transfer the state for |aPropID| (which may be a shorthand) * from |aFromBlock| to this block. The property being transferred * is !important if |aIsImportant| is true, and should replace an * existing !important property regardless of its own importance * if |aOverrideImportant| is true. * * ... */ 

  1. Firefox utilise un parsingur descendant écrit manuellement. Dans les deux cas, chaque fichier CSS est analysé dans un object StyleSheet, chaque object contient des règles CSS.

  2. Firefox crée alors des arborescences de contexte de style qui contiennent les valeurs de fin (après application de toutes les règles dans le bon ordre)

CSS Parser Firefox

De: http://taligarsiel.com/Projects/howbrowserswork1.htm#CSS_parsing

Maintenant, vous pouvez facilement voir, par exemple dans le cas du modèle d’object décrit ci-dessus, que l’parsingur peut facilement marquer les règles affectées par le !important La dégradation des performances n’est pas un bon argument contre !important .

Cependant, la maintenabilité prend un coup (comme mentionné dans d’autres réponses), ce qui pourrait être votre seul argument contre eux.

Je ne pense pas que !important est insortingnsèquement mauvais en termes de rapidité avec laquelle le navigateur correspond aux règles (il ne fait pas partie du sélecteur, seulement une partie de la déclaration)

Cependant, comme cela a déjà été indiqué, cela réduira la maintenabilité de votre code et entraînera probablement une augmentation inutile de sa taille en raison de modifications futures. L’utilisation de !important réduirait également probablement les performances du développeur.

Si vous étiez vraiment pointilleux, vous pourriez aussi dire que !important ajoute 11 octets supplémentaires à votre fichier CSS, ce n’est pas vraiment beaucoup, mais j’imagine que si vous avez un bon nombre de !important

Juste mes pensées, malheureusement je n’ai pas trouvé de points de repère sur la façon dont !important pourrait affecter les performances.

!important a sa place. Croyez-moi sur celui-là. Il m’a sauvé plusieurs fois et est souvent plus utile en tant que solution à court terme, avant de trouver une méthode plus longue et plus élégante à votre problème.

Cependant, comme la plupart des choses, il y a eu abus, mais il n’y a pas lieu de s’inquiéter de la «performance». Je parie qu’un petit GIF 1×1 aura plus de succès sur une page Web que!

Si vous souhaitez optimiser vos pages, il existe de nombreux autres itinéraires importants à prendre;);)

Bonne lecture: CSS! Important référence complète

Ce qui se passe en coulisses, c’est que le navigateur le lit, rencontre un atsortingbut !important et que le navigateur applique les styles définis par !important . Ce processus supplémentaire peut sembler une petite étape supplémentaire, mais si vous répondez à de nombreuses demandes, vous obtiendrez un résultat performant. (La source)

Utiliser! Important dans votre CSS signifie généralement narcissique et égoïste ou paresseux. Respectez les devs à venir …

La pensée d’un développeur en utilisant !important :

  1. Mon CSS à bascule ne fonctionne pas … grrrr.
  2. Qu’est-ce que je devrais faire maintenant??
  3. Et puis !important ouais … maintenant ça marche bien.

Cependant, ce n’est pas une bonne approche à utiliser !important parce que nous n’avons pas bien géré le CSS. Cela crée beaucoup de problèmes de conception – qui sont pires que les problèmes de performances – mais cela nous oblige également à utiliser plusieurs lignes de code supplémentaires car nous avons priorité sur les autres propriétés avec !important et notre CSS devient encombré de code inutile. Ce que nous devrions faire à la place, c’est d’abord de bien gérer le CSS, et de ne pas laisser les propriétés se substituer les unes aux autres.

Nous pouvons utiliser !important . Mais utilisez-le avec parcimonie et seulement quand il n’y a pas d’autre issue.

entrer la description de l'image ici

Je suis d’accord avec vous pour ne pas l’utiliser parce que c’est une mauvaise pratique, quelle que soit la performance. Pour ces seules raisons, j’éviterais d’utiliser !important chaque fois que possible.

Mais sur la question de la performance: non, cela ne devrait pas être perceptible. Cela pourrait avoir un effet, mais il devrait être si petit que vous ne devriez jamais le remarquer, et vous ne devriez pas vous en soucier.

Si cela est suffisamment significatif pour être perceptible, vous avez probablement de plus gros problèmes dans votre code que !important L’utilisation simple d’un élément de syntaxe normal des langages principaux que vous utilisez ne sera jamais un problème de performance.

Permettez-moi de répondre à votre question avec une question de rétorsion en retour; un angle que vous n’avez probablement pas pris en compte: quel navigateur voulez-vous dire?

Chaque navigateur a évidemment son propre moteur de rendu, avec ses propres optimisations. La question devient donc: quelles sont les implications de performance dans chaque navigateur? Peut-être !important comporte mal dans un navigateur mais très bien dans un autre? Et peut-être dans les prochaines versions, ce sera l’inverse?

Je pense que ce que je veux dire ici, c’est qu’en tant que développeurs Web, nous ne devrions pas penser (ou avoir besoin de penser) aux implications de performance des constructions de syntaxe individuelles des langages que nous utilisons. Nous devrions utiliser ces constructions syntaxiques car elles sont le bon moyen de réaliser ce que nous voulons faire, à cause de leur performance.

Les questions de performance doivent être posées en conjonction avec l’utilisation de profileurs pour parsingr les points de pincement dans votre système. Réparez les choses qui vous ralentissent vraiment en premier. Il est presque certain que vous devrez résoudre des problèmes beaucoup plus importants avant de passer au niveau des constructions CSS individuelles.

Cela n’affecte pas sensiblement les performances. Cela réduit cependant la maintenabilité de votre code et risque donc de dégrader les performances à long terme.

Ayant dû utiliser !important plusieurs resockets auparavant, je n’ai personnellement remarqué aucun problème de performance démontrable lors de son utilisation.

Comme note, voyez la réponse à cette question de stack pour une raison que vous pourriez vouloir utiliser !important .

Je mentionnerai aussi quelque chose que tout le monde a omis de mentionner. !important est le seul moyen de remplacer les css en ligne sans écrire une fonction javascript (ce qui affectera vos performances, même si c’est seulement un petit peu). Ainsi, vous pourriez gagner du temps si vous avez besoin de remplacer le css en ligne.

hmm …! important ou !! important?

Passons par là étape par étape:

  1. Le Parser doit vérifier! Important pour chaque propriété, que vous l’utilisiez ou non – donc la différence de performance est de 0
  2. Lors de l’écrasement d’une propriété, l’parsingur doit vérifier si la propriété en cours de remplacement est! Important ou non. La différence de performance est donc de 0
  3. Si la propriété en cours de remplacement est !! important, elle doit écraser la propriété – succès de performance de -1 pour ne pas utiliser! Important
  4. Si la propriété en cours de remplacement est importante, elle ne remplace pas la propriété – un gain de performance de +1 pour l’utilisation de!
  5. Si la nouvelle propriété est importante, l’parsing doit l’écraser, quelle que soit la propriété écrasée, c’est important ou important.

Donc, je suppose que! Important a en fait de meilleures performances car il peut aider l’parsingur à ignorer de nombreuses propriétés qu’il ne va pas ignorer autrement.

et comme @ryan le mentionne ci-dessous, le seul moyen de remplacer le css en ligne et d’éviter d’utiliser javascript … donc un autre moyen d’éviter un impact inutile sur les performances

hmm … s’avère que! important est important

et aussi,

  • using! important permet de gagner beaucoup de temps pour un développeur
  • vous évite parfois de repenser l’ensemble du css
  • Parfois, le fichier HTML ou le fichier css parent n’est pas sous votre contrôle, ce qui vous permet de sauver votre vie
  • évite évidemment que des éléments importants ne soient écrasés accidentellement par d’autres éléments importants
  • et parfois, les navigateurs ne sélectionnent pas les bonnes propriétés, sans être trop spécifiques dans les sélecteurs, de sorte que l’utilisation de! important devient vraiment importante et vous évite d’écrire des tonnes de sélecteurs CSS spécifiques dans votre css. donc je suppose que même si vous utilisez plus d’octets pour l’écriture! important, cela pourrait vous faire économiser des octets ailleurs. et nous le soaps tous, les sélecteurs CSS peuvent devenir désordonnés.

Donc, je pense que l’utilisation de! Important peut rendre les développeurs heureux, et je pense que c’est très important : D

Je ne peux pas prévoir !important performance !important , pas de toute façon. Si, cependant, votre CSS est truffé de !important , cela signifie que vous avez dépassé les critères de sélection et que vous êtes trop spécifique et que vous n’avez plus de parents ou de qualificateurs pour append de la spécificité. Par conséquent, votre CSS sera gonflé (ce qui gênera les performances) et difficile à maintenir.

Important meme de règles CSS

Si vous voulez écrire des CSS efficaces, vous devez être aussi précis que nécessaire et écrire des CSS modulaires . Il est conseillé de ne pas utiliser d’identifiants (avec hachage), de sélecteurs de chaînage ou de sélecteurs de qualification.

Les identifiants avec le préfixe # dans CSS sont extrêmement spécifiques, à tel point que 255 classes ne remplaceront pas un identifiant (violon par: @Faust ). Cependant, les identifiants ont un problème de routage plus profond, ils doivent être uniques, ce qui signifie que vous ne pouvez pas les réutiliser pour des styles en double, vous finissez donc par écrire des css linéaires avec des styles répétés. La répercussion de cela va varier projet à projet, en fonction de l’échelle, mais la maintenabilité souffrira immensément et dans les cas extrêmes, la performance aussi.

Comment pouvez-vous append de la spécificité sans !important , chaînage, qualification ou ID (à savoir # )

HTML

 

foobar

foobar

foobar

CSS

 .eg1-foo { color: blue; } .eg1-bar { color: red; } [id='eg2-foo'] { color: blue; } [id='eg2-bar'] { color: red; } .eg3-foo { color: blue; } .eg3-foo.eg3-foo { color: red; } 

JSFiddle

Ok, alors comment ça marche?

Les premier et deuxième exemples fonctionnent de la même manière, le premier est littéralement une classe et le second est le sélecteur d’atsortingbut. Les sélecteurs de classes et d’atsortingbuts ont une spécificité identique. .eg1/2-bar n’hérite pas de sa couleur à partir de .eg1/2-foo car il a sa propre règle.

Le troisième exemple ressemble à des sélecteurs de qualification ou de chaînage, mais ce n’est ni l’un ni l’autre. Le chaînage est lorsque vous préfixez les sélecteurs avec les parents, les ancêtres, etc. cela ajoute une spécificité. La qualification est similaire, mais vous définissez l’élément auquel s’applique le sélecteur. qualifiant: ul.class et chaînage: ul .class

Je ne suis pas sûr de ce que vous appelleriez cette technique, mais le comportement est intentionnel et est documenté par le W3C

Les occurrences répétées du même sélecteur simple sont autorisées et augmentent la spécificité.

Que se passe-t-il lorsque la spécificité entre deux règles est identique?

Comme l’a souligné @BoltClock , s’il y a plusieurs déclarations importantes, la spécification précise que la plus spécifique devrait avoir la priorité.

Dans l’exemple ci-dessous, .foo et .bar ont une spécificité identique, de sorte que le comportement revient à la nature en cascade de CSS, où la dernière règle déclarée dans CSS revendique la priorité, à savoir .foo .

HTML

 

foobar

CSS

 .bar { color: blue !important; } .foo { color: red !important; } 

JSFiddle