Effizientes Rendern von CSS

Ich gebe zu, dass ich nicht sehr oft über diese Idee nachdenke… wie effizient ist das CSS, das wir schreiben, in Bezug darauf, wie schnell der Browser es rendern kann?

Dies ist definitiv etwas, worüber sich Browser-Anbieter Gedanken machen (je schneller Seiten geladen werden, desto zufriedener sind die Leute mit ihren Produkten). Mozilla hat einen Artikel über Best Practices. Google ist ebenfalls ständig auf einem Kreuzzug, um das Web schneller zu machen. Sie haben auch einen Artikel darüber.

Lassen Sie uns einige der wichtigsten Ideen behandeln, die sie präsentieren, und dann die praktischen Aspekte des Ganzen diskutieren.

Von rechts nach links

Eine der wichtigsten Dinge, die man verstehen muss, wie Browser Ihre CSS-Selektoren lesen, ist, dass sie sie von rechts nach links lesen. Das bedeutet, dass im Selektorul > li a[title="home"]das erste interpretierte Element ista[title="home"]. Dieser erste Teil wird auch als „Schlüsselselektor“ bezeichnet, da er letztendlich das Element ist, das ausgewählt wird.

IDs sind am effizientesten, Universal-Selektoren am wenigsten

Es gibt vier Arten von Schlüsselselektoren: ID, Klasse, Tag und Universal. In dieser Reihenfolge sind sie auch effizient.

#main-navigation {   }      /* ID (Fastest) */
body.home #page-wrap {   }  /* ID */
.main-navigation {   }      /* Class */
ul li a.current {   }       /* Class *
ul {   }                    /* Tag */
ul li a {  }                /* Tag */
* {   }                     /* Universal (Slowest) */
#content [title='home']     /* Universal */

Wenn wir diese Rechts-nach-links-Idee und die Schlüsselselektor-Idee kombinieren, können wir sehen, dass dieser Selektor nicht sehr effizient ist

#main-nav > li {   }  /* Slower than it might seem */

Auch wenn sich das seltsam kontraintuitiv anfühlt… Da IDs so effizient sind, würden wir denken, dass der Browser diese ID schnell finden und dann die li-Kinder schnell finden könnte. Aber in Wirklichkeit wird zuerst der relativ langsame li-Tag-Selektor ausgeführt.

Keine Tag-Qualifizierung verwenden

Niemals so etwas machen

ul#main-navigation {  }

IDs sind eindeutig, daher benötigen sie keinen Tagnamen, um damit einherzugehen. Dies macht den Selektor weniger effizient.

Machen Sie es auch nicht mit Klassennamen, wenn Sie es vermeiden können. Klassen sind nicht eindeutig, so dass man theoretisch einen Klassennamen haben könnte, der auf mehreren verschiedenen Elementen nützlich sein könnte. Und wenn Sie möchten, dass das Styling je nach Element unterschiedlich ist, müssten Sie möglicherweise eine Tag-Qualifizierung verwenden (z.B.li.first), aber das ist ziemlich selten, also im Allgemeinen nicht.

Nachfahren-Selektoren sind am schlechtesten

David Hyatt

Der Nachfahren-Selektor ist der teuerste Selektor in CSS. Er ist furchtbar teuer – besonders wenn der Selektor in die Kategorie Tag oder Universal fällt.

Mit anderen Worten, ein Selektor wie dieser ist eine Effizienzkatastrophe

html body ul li a {  }

Ein Selektor, der fehlschlägt, ist effizienter als derselbe Selektor, der übereinstimmt

Ich bin mir nicht sicher, ob wir viel daraus lernen können, denn wenn Sie viele Selektoren in Ihrem CSS haben, die nichts abgleichen, ist das, ähm, ziemlich seltsam. Aber es ist interessant festzustellen, dass bei der Rechts-nach-links-Interpretation eines Selektors, sobald er bei einer Übereinstimmung fehlschlägt, aufhört zu suchen und somit weniger Energie verbraucht, als wenn er weiter interpretieren müsste.

Überlegen Sie, warum Sie den Selektor schreiben

Betrachten Sie dies

#main-navigation li a { font-family: Georgia, Serif; }

Font-familykaskadiert, daher benötigen Sie möglicherweise von vornherein keinen so spezifischen Selektor (wenn Sie nur die Schriftart ändern). Dies kann genauso effektiv und weitaus effizienter sein

#main-navigation { font-family: Georgia, Serif; }

CSS3 und Effizienz

Ziemlich traurige Nachrichten von David Hyatt

Die traurige Wahrheit über CSS3-Selektoren ist, dass sie wirklich überhaupt nicht verwendet werden sollten, wenn Ihnen die Seitenleistung wichtig ist.

Der ganze Kommentar ist lesenswert.

CSS3-Selektoren (z.B. :nth-child) sind unglaublich toll, um uns zu helfen, die gewünschten Elemente anzusprechen und gleichzeitig unser Markup sauber und semantisch zu halten. Aber Tatsache ist, dass diese ausgefallenen Selektoren ressourcenintensiver für den Browser sind.

Was ist also los, sollten wir sie tatsächlich nicht verwenden? Denken wir ein wenig über die praktischen Aspekte nach…

Praktische Aspekte

Dieser Mozilla-Artikel, den ich oben verlinkt habe? Im wahrsten Sinne des Wortes 10 Jahre alt. Fakt: Computer waren vor 10 Jahren viel langsamer. Ich habe das Gefühl, dass diese Dinge damals wichtiger waren. Vor zehn Jahren war ich kurz davor, 21 zu werden, und ich glaube nicht, dass ich überhaupt wusste, was CSS ist. Daher werde ich nicht auf „alte Schule“ machen… aber ich habe das Gefühl, dass wir nicht sehr oft über diese Rendering-Effizienz sprechen, weil es kein so großes Problem mehr ist.

So sehe ich das: Die Best Practices, die wir oben behandelt haben, sind so oder so sinnvoll. Sie können sie genauso gut befolgen, weil sie Ihre Fähigkeiten mit CSS ohnehin nicht einschränken. Aber Sie müssen nicht dogmatisch sein. Wenn Sie sich in der Lage befinden, die letzte Leistung aus einer Website herauszuholen, und Sie diese Dinge noch nie zuvor in Betracht gezogen haben, kann es sich lohnen, Ihre Stylesheets zu überprüfen, um zu sehen, wo Sie sich verbessern können. Wenn Sie keine große Rendering-Langsamkeit auf Ihrer Website feststellen, machen Sie sich keine Sorgen, seien Sie sich dessen nur für die Zukunft bewusst.

Superschnell, null Praktikabilität

Wir wissen also, dass IDs die effizientesten Selektoren sind. Wenn Sie die effizienteste Rendering-Seite erstellen wollten, würden Sie buchstäblich jedem einzelnen Element auf der Seite eine eindeutige ID geben und dann das Styling mit einzelnen ID-Selektoren anwenden. Das wäre superschnell und auch super lächerlich. Es wäre wahrscheinlich extrem unsemantisch und extrem schwierig zu pflegen. Sie sehen diesen Ansatz nicht einmal auf Hardcore-Performance-basierten Websites. Ich denke, die Lektion hier ist, Semantik oder Wartbarkeit nicht für effizientes CSS zu opfern.

 

Vielen Dank an Jason Beaudoin für die E-Mail zu dieser Idee. Wenn jemand mehr über diese Dinge weiß, oder wenn Sie zusätzliche Tipps haben, die Sie in diesem Sinne verwenden, lassen Sie es uns wissen!

Nur als kurze Anmerkung möchte ich auch erwähnen, dass, da CSS-Stilselektoren auch in vielen JavaScript-Bibliotheken verwendet werden, dieselben Konzepte auch hier gelten. ID-Selektoren sind am schnellsten, während komplizierte qualifizierte Nachfahren-Selektoren und dergleichen langsamer sind.