Was ist mit der Regel "Effektive CSS-Selektoren verwenden" passiert?

Im Februar 2011 wurde der Webkit-Kernentwickler Antti Koivisto verschiedene Verbesserungen für CSS Selector Performance in Webkit gemacht.

  

Antti Koivisto lehrte den CSS Style Selector, um Geschwisterselektoren und schnelleres Sortieren zu überspringen, was einige kleinere Verbesserungen mit sich brachte, woraufhin er zwei weitere tolle Patches erhielt: eines, das die Filterung von Vorfahrenidentifizierern für Baumbildung ermöglicht und die verbleibende Zeit stilistisch halbiert Anpassung an eine typische Seitenauslastung und ein schneller Pfad für einfache Selektoren, die das Abstimmen um weitere 50% auf einigen Websites beschleunigen.

CSS Selector Performance hat sich geändert! (Zum Besseren) von Nicole Sullivan geht diese Verbesserungen genauer durch. Zusammenfassend -

  

Laut Antti können direkte und indirekte Nachbarkombinatoren immer noch langsam sein, aber Vorfahrenfilter und Regel-Hashes können den Einfluss verringern, da diese Selektoren nur selten zusammenpassen. Er sagt auch, dass Webkit immer noch viel Platz für die Optimierung von Pseudoklassen und -elementen hat, aber sie sind viel schneller, als wenn sie versuchen, dasselbe mit JavaScript und DOM-Manipulationen zu machen. In der Tat, obwohl es noch Raum für Verbesserungen gibt, sagt er:

     

"In der Moderation wird so ziemlich alles verwendet, was aus der Perspektive des Stilvergleichs gut funktioniert."

Obwohl Browser die CSS-Selektoren viel schneller anpassen, sollte dennoch darauf hingewiesen werden, dass CSS-Selektoren immer noch optimiert werden sollten (z. B. so flach wie möglich), um Dateigrößen zu reduzieren und Spezifitätsprobleme zu vermeiden.

Hier ist ein gründlicher Artikel (der Anfang 2014 datiert ist)

Ich zitiere Benjamin Poulain , ein WebKit-Engineer, der viel über die Leistung der CSS-Selektoren zu sagen hatte Test:

  

~ 10% der Zeit werden im Rasterizer verbracht. ~ 21% der Zeit sind verbraucht   auf dem ersten Layout. ~ 48% der Zeit werden im Parser und DOM verbracht   Baumbildung ~ 8% werden für die Stilauflösung ausgegeben ~ 5% werden ausgegeben   den Stil sammeln - das sollten wir testen und was?   sollte die meiste Zeit dauern. (Die verbleibende Zeit ist über viele verteilt   viele kleine Funktionen)

Und er fährt fort:

  

"Ich stimme völlig zu, dass es sinnlos ist, Selektoren im Voraus zu optimieren, aber   aus ganz anderen Gründen:

     

Es ist praktisch unmöglich, den endgültigen Leistungseinfluss vorherzusagen   eines gegebenen Selektors durch bloßes Untersuchen der Selektoren. Im Motor,   Selektoren werden neu geordnet, aufgeteilt, gesammelt und kompiliert. Um das zu wissen   endgültige Leistung eines bestimmten Selektoren, müssten Sie wissen in   In welchem ​​Bucket der Selektor gesammelt wurde, wie er kompiliert wird und   Wie sieht der DOM-Baum schließlich aus?

     

All das ist zwischen den verschiedenen Motoren sehr unterschiedlich und macht das   ganze Prozess noch weniger vorhersehbar.

     

Das zweite Argument, das ich gegen Web-Entwickler habe, die Selektoren optimieren   ist, dass sie die Dinge wahrscheinlich verschlimmern werden. Die Menge an   Fehlinformationen über Selektoren sind größer als der korrekte Cross-Browser   Information. Die Chance, dass jemand das Richtige tut, ist schön   niedrig.

     

In der Praxis entdecken die Leute Leistungsprobleme mit CSS und starten   Regeln nacheinander entfernen, bis das Problem verschwindet. ich denke, das ist   Der richtige Weg, um dies zu tun, ist einfach und wird zur Korrektur führen   Ergebnis. "

Es gibt Ansätze, wie zum Beispiel BEM , die das CSS so flach wie möglich modellieren, um die DOM-Hierarchie-Abhängigkeit zu minimieren und Webkomponenten zu entkoppeln, so dass sie über das DOM "verschoben" werden und unabhängig arbeiten können.

Vielleicht, weil CSS für CMSes oder Frameworks jetzt häufiger verwendet wird und es dann schwierig ist, allgemeine CSS-Selektoren zu vermeiden. Dies begrenzt die Komplexität des Stylesheets.

Auch moderne Browser sind sehr schnell beim Rendern von CSS. Selbst mit riesigen Stylesheets auf IE9 fühlte es sich nicht so an, als wäre das Rendering langsam. (Ich muss zugeben, dass ich an einem guten Computer getestet habe. Vielleicht gibt es dort Benchmarks).

Wie auch immer, ich denke, Sie müssen sehr ineffizientes CSS schreiben, um Chrome oder Firefox zu verlangsamen ...

Es gibt einen 2 Jahre alten Beitrag über die Leistung @ Welche CSS-Selektoren oder -Regeln können die Front-End-Layout- / Rendering-Leistung in der realen Welt erheblich beeinträchtigen?

Ich mag seine One-Liner-Schlussfolgerung: Alles in den Grenzen von "Ja, dieses CSS macht Sinn" ist in Ordnung.