Ich gebe zu, dass ich nicht oft über diese Frage nachdenke ... Wie effizient ist das von uns geschriebene CSS und wie schnell rendert der Browser?
Darüber sollten sich Browser-Entwickler Gedanken machen (Seiten werden schneller geladen und die Benutzer werden zufriedener sein). Mozilla hat einen Artikel über Best Practices . Natürlich ist Google auch sehr besorgt über dieses Problem, und es gibt auch einen solchen Artikel: Browser-Rendering optimieren .
Werfen wir einen Blick darauf, was sie hauptsächlich befürworten, und diskutieren wir dann ihre Praktikabilität.
von rechts nach links
Ein wichtiges Prinzip, wie Browser Ihre CSS-Selektoren lesen, besteht darin, dass sie sie von rechts nach links lesen. Das bedeutet, dass für einen Selektor wie ul > li a[title="home"] zuerst a[title="home"] gelesen wird. Dieser Teil wird normalerweise als „Schlüsselselektor“ bezeichnet (kann man ihn auch als „Zielselektor“ bezeichnen -_-!) Der letzte Teil des Selektors ist auch die ausgewählte Bezeichnung.
IDs sind am effizientesten, Universals am langsamsten
Es gibt vier Zielselektoren: ID, Klasse, Tag und universelles Zeichen. Werfen wir einen Blick auf ihre jeweilige Effizienz:
#main-navigation { } /* ID (am schnellsten) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Klasse */
ul li a.current { } /* Klasse *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universell (am langsamsten) */
#content [title='home'] /* Universal */ Dann kombinieren wir die Konzepte von Rechts-nach-Links- und Zielselektoren und können erkennen, dass der folgende Selektor nicht effizient ist:
#main-nav > li { } /* Es sieht schnell aus, ist aber tatsächlich sehr langsam*/
Obwohl dies etwas verwirrend ist ... da IDs am effizientesten sind, können Browser li anhand von IDs schnell finden. Tatsache ist jedoch, dass das li-Tag zuerst gelesen wird.
Ändern Sie es nicht mit Tags
Tu das nicht bis zu deinem Tod:
ul#main-navigation { }
IDs sind eindeutig und müssen daher nicht mit Tags versehen werden, was sie nur weniger effizient macht.
Verwenden Sie es nicht zum Ändern von Klassen, wenn Sie es vermeiden können. Die Klasse ist nicht eindeutig, daher könnten Sie sie theoretisch in verschiedenen Tags verwenden. Wenn Sie möchten, können Sie Tags verwenden, um verschiedene Stile zu steuern. Daher müssen Sie möglicherweise Tag-Änderungen vornehmen (z. B. li.first), aber nur wenige Leute tun dies, also tun Sie es nicht.
Es gibt absolut nichts Schlimmeres als die Verwendung eines Nachkommenselektors
David Hyatt:
Der Descendent-Selektor ist der teuerste Selektor in CSS und unerschwinglich teuer – insbesondere, wenn er nach Tags und Universals platziert wird.
Genau wie die folgenden Dinge ist es ein absoluter Effizienzkrebs:
HTML-Körper ul li a { }
Es ist effizienter, wenn ein Selektor nicht gerendert wird, als wenn der Selektor gerendert wird
Ich bin mir nicht sicher, ob es dafür bessere Beweise gibt, denn wenn Sie viele Selektoren haben, die nicht in einem CSS-Stylesheet zu finden sind, mag das bizarr erscheinen, aber es ist wichtig zu beachten, dass man einen Selektor von rechts nach links umschreiben kann Sobald es es nicht finden kann, hört es auf, es zu versuchen. Wenn es jedoch gefunden wird, ist die Erklärung mit größerem Aufwand verbunden.
Denken Sie einfach darüber nach, warum Sie den Selektor so schreiben
Denken Sie darüber nach:
#main-navigation li a { Schriftfamilie: Georgia, Serif }
Sie müssen wahrscheinlich nicht mit einem Selektor beginnen (wenn Sie nur die Schriftart ändern möchten). Das könnte effizienter sein:
#main-navigation { Schriftfamilie: Georgia, Serif }
Praktikabilität
Auch der zuvor erwähnte Mozilla-Artikel eingraviert? Es ist zehn Jahre her. Tatsache ist: Computer sind langsamer als vor zehn Jahren (nicht, dass ich das falsch verstanden hätte, oder der Autor möchte sagen, dass das aktuelle WEB immer komplexer wird). Ich habe das Gefühl, dass dieses Thema damals ernster genommen wurde. Vor zehn Jahren war ich ein hübscher 21-jähriger Junge. Natürlich hätte ich nicht gedacht, dass ich dort etwas über CSS wissen würde. Ich kann Ihnen also nichts über die vorherige Situation sagen ... aber ich denke, der Grund, warum das Thema Rendering-Effizienz nicht ernst genommen wurde, liegt darin, dass es nie ein großes Problem war.
Hier sind einige meiner Meinungen: Egal was passiert, die oben genannten Dinge machen Sinn, und Sie können es mit der oben genannten Methode tun, weil es Ihre CSS-Produktion nicht einschränkt. Aber man muss nicht zu dogmatisch sein. Wenn Sie ein Perfektionist sind und darüber noch nie nachgedacht haben, ist es an der Zeit, einige der Stile, die Sie zuvor geschrieben haben, noch einmal zu prüfen, um zu sehen, ob es Raum für Verbesserungen gibt. Wenn Sie nicht feststellen, dass Ihre Website offensichtlich langsam gerendert wird, schenken Sie ihr bei zukünftigen Arbeiten nicht zu viel Aufmerksamkeit.
Superschnell und null Praktikabilität
Wir wissen, dass IDs die effizientesten Selektoren sind. Wenn Sie die Rendering-Geschwindigkeit maximieren möchten, können Sie für jedes einzelne Tag eine ID konfigurieren und diese IDs dann zum Schreiben von Stilen verwenden. Das wäre superschnell und superlächerlich. Das Ergebnis ist eine äußerst schlechte Semantik und eine äußerst schwierige Wartung. Dies sollte nicht einmal im Kern geschehen. Ich denke, dies dient als Erinnerung daran, Semantik und Wartbarkeit für effizientes CSS nicht aufzugeben.
Vielen Dank an Jason Beaudoin, der mir die Idee per E-Mail mitgeteilt hat. Wenn jemand mehr über dieses Thema weiß oder weitere Tipps hat, die Sie in diesem Sinne verwenden, lassen Sie es uns hören!
Da CSS-Selektoren übrigens von vielen JavaScript-Bibliotheken verwendet werden, gelten die oben genannten Dinge immer noch, der ID-Selektor ist immer noch der schnellste und die abgeleiteten Selektoren und ähnliche Dinge sind langsamer.
PS : Mal sehen, wer es wagt, mehr als N Nachkommenselektoren zu verwenden. . . Es gibt auch Leute, die gegen die Verwendung meines Ausweises Einspruch erheben. . . Wow, haha. . .