Ein geradliniger Beitrag mit einigen Leistungsdaten von Tomas Pustelnik. Es ist eine gute Erinnerung daran, dass CSS ein entscheidender Teil der Betrachtung der Web-Performance ist, und das aus einem sehr guten Grund
Immer wenn [der Browser] auf eine externe Ressource (CSS, JS, Bilder usw.) trifft, weist er ihr eine Download-Priorität zu und initiiert ihren Download. Prioritäten sind wichtig, da einige Ressourcen für das Rendern einer Seite entscheidend sind (z. B. die Haupt-Stylesheet- und JS-Dateien), während andere weniger wichtig sein können (wie Bilder oder Stylesheets für andere Medientypen).
Im Fall von CSS ist diese Priorität normalerweise hoch, da Stylesheets zur Erstellung von CSSOM (CSS Object Model) erforderlich sind. Um eine Webseite zu rendern, muss der Browser sowohl DOM als auch CSSOM konstruieren.
Deshalb wird CSS oft als "blockierende" Ressource bezeichnet. Das ist bis zu einem gewissen Grad wünschenswert: Wir wollen kein Flackern von ungestylten Websites sehen. Aber wir erzielen echte Leistungssteigerungen, wenn wir CSS kleiner machen, da es schneller heruntergeladen, analysiert und angewendet werden kann.
Abgesehen von den Techniken in diesem Beitrag bin ich sicher, dass Befürworter von atomarem/Utility-CSS es lieben würden, darauf hinzuweisen, dass die Stylesheets aus diesen Ansätzen im Allgemeinen *viel* kleiner und damit performanter sind. CSS-in-JS-Ansätze bündeln manchmal Stile in Skripte, also fairerweise erhalten Sie oben einen kleinen Leistungsgewinn, indem Sie CSS dort nicht laden, aber einen Leistungsverlust durch die Vergrößerung der JavaScript-Bundle-Größe im Prozess. (Ich habe jedoch keine Studie mit einem fairen Vergleich gesehen, daher weiß ich nicht, ob es sich ausgleicht oder was.)
CSS blockiert immer meine Website-Anzeige, um so schnell wie möglich zu rendern, aber es ist immer gut, sie alle minimiert zu haben
Immer wenn ich auf Artikel stoße, wie man beeinflusst, wie und wann CSS geladen und angewendet wird, denke ich darüber nach, anstatt damit herumzuspielen, wäre es cool, wenn wir einen standardisierten Dateinamen für "diese Haupt-CSS-Datei, die wir sowieso in allen Fällen brauchen" hätten – nennen wir sie base.css
Wenn dieser Name standardisiert wäre (und seine Position relativ zur URL / Domain), dann könnte der Browser einfach danach suchen und ihn gleichzeitig mit dem Download des HTML-Dokuments herunterladen – ohne darauf warten zu müssen, dass dieses HTML heruntergeladen wird, es geparst wird, externe Quellen gefunden und Downloads priorisiert, sie heruntergeladen, auf das Dokument angewendet werden, ... ...
Also wäre das CSS schon da oder auf dem Weg, während das HTML noch geparst wird? Ein Meta-Tag könnte dem Browser mitteilen, ob dieses base.css auf das Dokument angewendet werden soll oder eine Ausnahme gemacht und es pro Dokument ignoriert werden soll.
Schlechte Idee?
Ja, es wäre eine zusätzliche Anfrage, die nutzlos sein könnte, wenn es kein "base.css" gäbe ... könnte man das dann protokollbasiert machen, während das HTML-Dokument geladen wird (wie der Server dieses base.css liefert, wenn es automatisch vorhanden ist, und der Browser versteht)?
Tun wir das nicht bereits, wenn Browser nach einer favicon.ico suchen, nur für den Fall, dass es keine Referenz darauf im HTML-Head gibt?
Alle sind besessen vom Laden von Ressourcen. Wie verhält es sich mit der Renderzeit bei komplexem CSS, wenn überall Gradienten und dreifache Boxschatten usw. verwendet werden?