Der folgende Beitrag ist ein Gastbeitrag von Wladston Ferreira Filho. Wir haben Critical CSS bereits behandelt, aber die hier vorgestellte Technik war spezifisch für SCSS. Hier behandelt Wladston die Grundlagen und stellt eine weitere Methode über PostCSS vor, und zeigt ein Beispiel (mit Daten) des Ergebnisses.
Critical CSS ist ein effektiver, aber allzu selten genutzter Ansatz zur Verbesserung der Seitenladeleistung. Critical CSS ist zwei Dinge zusammen:
- Verzögertes Laden des Haupt-Stylesheets
- Einbettung der wichtigsten Stile ("above the fold")
Die Implementierung von Critical CSS erfordert einige Arbeit. Zum einen bedeutet es, das CSS in zwei Teile zu trennen (die kritischen Teile und den Rest), was ein Wartungsproblem darstellen kann.
Später in diesem Artikel werden wir uns ein Werkzeug ansehen, um diesem Nachteil entgegenzuwirken, indem wir CSS automatisch basierend auf Annotationen (d. h. /* Kommentare */) in der Haupt-CSS-Datei aufteilen.
The Facts
Forschungen von Mozilla, Akamai und vielen anderen Quellen bestätigen: geringe Änderungen in der Seitenladezeit können Leistungskennzahlen erheblich beeinflussen. Bei schlechter Netzwerkverbindung wird die Seitenleistung noch wichtiger, da die Downloadzeiten um ein Vielfaches höher sein können.
Google bietet sogar einen Dienst an, um Seiten eine "Geschwindigkeitsbewertung" zu geben, ein nicht so subtiler Hinweis darauf, dass die Leistung mit der Suchmaschinenoptimierung zusammenhängen kann. Die richtige Anwendung von Critical CSS wird von Google *empfohlen*, um Ihren Score zu verbessern. Die Technik wird mit Sicherheit einen positiven Effekt auf die Rendergeschwindigkeit haben. Die Reduzierung der Renderzeit hängt davon ab, wie klein Sie Ihr Critical CSS machen können und wie groß Ihr Haupt-Stylesheet ist.
Wie Critical CSS funktioniert
Der "normale" Ansatz für CSS besteht darin, Ihr Haupt-Stylesheet als <link> im <head> einzufügen. Der Download und das Parsen davon *blockieren das Rendering*. Critical CSS lässt Ihre Seite schneller rendern, indem es *dieses Blocking umgeht*.
Der erste Schritt besteht darin, die wesentlichen CSS-Regeln, die zum Rendern des Inhalts "above the fold" (oberhalb des sichtbaren Bereichs) der Seite benötigt werden, zu "inlinen" (ein gestraffter <style>-Tag im <head>). Dies ermöglicht den zweiten Schritt: Nicht-kritische CSS-Regeln können *asynchron* (nicht blockierend) geladen werden, während die Webseite gerendert wird. Sobald die große CSS-Datei angekommen ist, wird sie von JavaScript an die Seite angehängt.
Eine gängige Methode, dies in die Praxis umzusetzen, ist die Verwendung eines CSS-Präprozessors. Der Präprozessor kann speziell formatierte Kommentare im CSS erkennen, sodass er das kritische CSS unterscheiden und automatisch trennen kann. Dies wurde bereits auf CSS-Tricks behandelt, mit SCSS. Lassen Sie uns dies in nativer CSS-Syntax untersuchen.
Hinweis: Um dies zum Laufen zu bringen, benötigen Sie ein serverseitiges Werkzeug, um das kritische CSS in alle Seiten einzubetten, die Sie ausliefern, sowie einige Zeilen Inline-JavaScript, um das Haupt-Stylesheet (nicht-kritisch) zu laden.
Bestehende Techniken für Critical CSS
Critical CSS erfordert letztendlich zwei separate CSS-Teile: kritische und nicht-kritische. Wie bekommen wir sie?
Volle manuelle Wartung: Zwei CSS-Dateien pflegen
Bei dieser Strategie bearbeiten Sie direkt zwei CSS-Dateien anstelle einer. Während diese Strategie einfach ist und kein Werkzeug erfordert, ist sie viel schwieriger zu handhaben. Es ist schwieriger, Stile zu verstehen, zu lesen und zu ändern. Sie wird nur für statisches CSS empfohlen, das sich wahrscheinlich nie ändern wird.
Vollautomatisierung
Serverseitige Tools (wie die Google Page Speed Extension) erkennen automatisch, welches Ihrer CSS für das Rendern des Inhalts "above the fold" benötigt wird, und trennen das als kritisch eingestufte CSS und binden es für Sie ein, ohne Ihr Zutun.
Diese Technik hat einige Nachteile: Das automatisch generierte nicht-kritische CSS ändert sich wahrscheinlich für jede ausgewertete Seite, was die Effizienz des CSS-Cachings verringert. Außerdem wird das Critical CSS nicht fehlerfrei erkannt, insbesondere für kleine Bildschirme.
Darüber hinaus haben Sie keine Möglichkeit, den Prozess anzupassen oder fein abzustimmen.
SCSS mit Jacket-Plugin
Wenn Sie SCSS verwenden, können Sie das Jacket-Plugin installieren (Details hier). Jacket trennt CSS, das mit einer speziellen kritischen Klasse markiert ist, in eine separate Datei und generiert nach der Verarbeitung des LCSS kritische und nicht-kritische CSS-Dateien. Das Problem bei dieser Technik ist, dass sie Sie an SCSS bindet. Wenn Sie sich entscheiden, es nicht mehr zu verwenden oder wenn Sie Ihre Präprozessor-Sprache ändern möchten, müssen Sie zusätzliche Arbeit leisten, um Ihre Critical-CSS-Lösung anzupassen.
Meine Technik: PostCSS und PostCSS-Split
Meine Technik beruht darauf, alle Ihre Critical-CSS-Deklarationen mit einfachen, reinen CSS-Kommentaren zu markieren. Betrachten wir dieses super einfache HTML zur Veranschaulichung
<!DOCTYPE html>
<html lang="en">
<body>
<header>
<h1>I'm a big header</h1>
</header>
<p>I'm below the fold</p></body>
</body>
</html>header > h1 {
/* !Critical */ margin: 300px;
}
p {
border: 1px dotted black;
}Der erste Schritt ist die Markierung der CSS-Regeln, die zum Rendern des Inhalts "above the fold" benötigt werden, indem /* !Critical */ darin platziert wird.
Um herauszufinden, welche Deklarationen aus Ihrem Haupt-Stylesheet in Ihrem kritischen CSS enthalten sein sollen, können Sie Vorschläge von kostenlosen Diensten wie diesem erhalten.
Sobald Sie Ihre Basis-CSS-Datei mit "kritischen" Kommentaren haben, installieren Sie PostCSS-Split mit npm. Sie müssen Node.js installieren, falls Sie das noch nicht getan haben. Geben Sie in einem Terminal diesen Befehl ein, um PostCSS-Split zu installieren
sudo npm install -g postcss-splitDann können Sie diesen Befehl ausführen und Ihre kommentierte Basis-CSS-Datei an PostCSS-Split übergeben
postcss-split base.cssBrandneue Dateien base-critical.css und base-non-critical.css werden basierend auf Ihrer Eingabedatei erstellt. Der Inhalt von `base-critical.css` soll im <head> in einem <style>-Tag eingefügt werden.
Zum Laden von `base-non-critical.css` können Sie einen asynchronen CSS-Loader verwenden. Fügen Sie zum Beispiel Folgendes vor dem </body>-Tag ein (und ändern Sie <your_css_url> entsprechend)
<script>
function lCss(u, m) {
var l = document.createElement('link');
l.rel = 'stylesheet';
l.type = 'text/css';
l.href = u;
l.media = m;
document.getElementsByTagName('head')[0].appendChild(l)
}
function dCss() {
lCss('<your_css_url>', 'all')
}
if (window.addEventListener) {
window.addEventListener('DOMContentLoaded', dCss, false)
} else {
window.onload=dCss
}
</script>Potenzielle Fallstricke jeder Critical-CSS-Technik
Wenn Sie eine beliebige Critical-CSS-Technik verwenden, werden Sie wahrscheinlich auf einige Probleme stoßen. Sehen wir uns an, wie wir ihnen begegnen können
Präzedenz
Wenn Sie mehrere CSS-Regeln mit der gleichen Spezifität haben, werden später deklarierte Regeln Vorrang vor früher deklarierten Regeln haben.
Beachten Sie, dass sich die von Ihnen als kritisch bezeichneten CSS-Regeln ihren Speicherort ändern: Sie werden in Ihrem <head> inline sein, was bedeutet, dass sie zuerst geladen werden und von später geladenem CSS mit Selektoren gleicher Spezifität überschrieben werden.
Wenn Sie Probleme haben, Ihre korrekten CSS-Stile mit Critical CSS auf diese Weise zu erhalten, stellen Sie sicher, dass Ihr CSS nicht von der Reihenfolge abhängt. Wenn Sie seltsame Ergebnisse erhalten, verwenden Sie einen CSS-Inspektor, um Ihnen zu helfen, Ihre Spezifitätsprobleme zu beheben.
FOUC
Wenn Ihr Critical CSS nicht *jede* Regel enthält, die zum Rendern des gesamten Inhalts "above the fold" benötigt wird, oder wenn Ihr Benutzer beginnt, den Inhalt unterhalb des sichtbaren Bereichs zu durchsuchen, bevor der Großteil Ihres CSS geladen ist, erleben Sie den FOUC-Effekt (Flash of Unstyled Content).
Wenn Ihr nicht-kritisches CSS geladen wird, ändert der Browser die Stile Ihrer Seite, um die Regeln aus dem nicht-kritischen CSS anzuwenden. Dieser "Blitz" der Stiländerung kann unerwünscht sein.
Eine Möglichkeit, diese Peinlichkeit zu mildern, ist die Verwendung von CSS-<a href="https://css-tricks.de/almanac/properties/t/transition/">Übergängen</a>, um sanft von ungestylt zu gestylt zu wechseln. Während der Entwicklung können Sie dem JavaScript-Code, der Ihr Bulk-CSS injiziert, manuell eine Verzögerung hinzufügen.
Einbinden des Critical CSS in die HTML-Seiten
Sie benötigen ein Werkzeug, um das Critical CSS in den <head> Ihrer HTML-Seiten zu injizieren. Wenn Sie eine serverseitige Sprache wie PHP verwenden, können Sie dies einfach mit einer include()-Anweisung (oder ähnlich) tun.
<!DOCTYPE html>
<html lang="en">
<head>
...
<style>
<?php include_once("/path/to/base-critical.css"); ?>
</style>
...Wenn Sie nicht direkt mit dem Code arbeiten (z. B. wenn Sie ein Content-Management-System wie WordPress verwenden), können Sie nach einer Konfigurationseinstellung oder einem Plugin suchen, das dies für Sie erledigt. In WordPress können Sie einen "Hook" hinzufügen, um den Inhalt Ihrer CSS-Datei in Ihr finales HTML einzubetten.
Jeremy Keith hat einen Weg mit Grunt/Twig umrissen.
Ist es das wirklich wert?
Zusammenfassend…
Dies sind die Schritte zur Implementierung dieser Technik
- Identifizieren und markieren Sie Ihr Critical CSS in Ihrem Haupt-Stylesheet.
- Fügen Sie Ihrer Bereitstellungsroutine eine Aufgabe hinzu, um die Basis-CSS-Datei in zwei Dateien aufzuteilen.
- Fügen Sie den zusätzlichen JavaScript-Code hinzu, um Ihr Haupt-Stylesheet asynchron zu laden.
- Implementieren Sie eine serverseitige Include-Funktion, um den Inhalt Ihres Critical CSS in den
<head>jeder Seite einzufügen.
Fallstudie: Reale Website mit Critical CSS
Ich habe die Website https://code.energy so programmiert, dass sie Seiten mit oder ohne Critical CSS ausliefern kann. Sie verwendet standardmäßig Critical CSS, es sei denn, eine Abfragezeichenfolge nocritical wird hinzugefügt (Beispiel: https://code.energy?nocritical). Eine weitere Möglichkeit, Critical CSS zu deaktivieren, ist die Übergabe eines User-Agent-Headers, der die Zeichenfolge nocritical enthält.
Damit können wir leicht messen, wie Critical CSS die Geschwindigkeit Leistung dieser Website mit Online-Tools wie webpagetest.org beeinflusst. Webpagetest ermöglicht das einfache Ausführen von Tests mit einer benutzerdefinierten User-Agent-Zeichenfolge. Dies sind die Ergebnisse des Durchschnitts von 5 Experimenten für jedes Szenario
| Kritisch | Ladezeit | Start Rendering | Vollständiges Laden | Speed Idx |
|---|---|---|---|---|
| x | 0,949s | 0,988s | 1,003s | 1036 |
| ✓ | 0,838s | 0,695s | 0,893s | 755 |
Der beeindruckendste Unterschied ist die "Start Render"-Zeit. Durch das asynchrone Laden des CSS kann der Browser mehr Anfragen parallel ausführen, da er viel früher mit dem Parsen des HTML beginnt, wie hier zu sehen ist
Fazit
Wenn Sie die bestmögliche Leistung für Ihre Website wünschen, benötigen Sie eine Critical-CSS-Strategie. Und mit PostCSS-Split können Sie diese mit geringem Wartungsaufwand erhalten.
Bin ich der Einzige, der '!Critical' als *nicht* kritisch liest?
!Ja => Nein!
Ja, aber das ist *!important*...
Alain, das ist das erste Mal, dass ich so denke, obwohl ich Programmierer bin. Pat hat die Idee verstanden, die ich im Sinn hatte – das ist etwas *!important* :)
Sie können auch einen benutzerdefinierten regulären Ausdruck im PostCSS-Plugin-Code verwenden, wenn Sie möchten.
In meinem Magento/Gulp-Workflow verwende ich Penthouse (https://github.com/pocketjoso/penthouse) zur Generierung des Critical CSS, das ich über die Layout-Anweisungen von Magento in HTML injiziere. Und dann lade ich das vollständige CSS mit filamentgroup's loadCSS (https://github.com/filamentgroup/loadCSS).
Luis, interessant. Wie sind Ihre Erfahrungen mit Penthouse, wählt es das kritische CSS gut aus? loadCSS scheint ein gut gemachtes Stück JavaScript zu sein. Der Ansatz, den ich vorschlage, ist viel einfacher, aber er funktioniert fehlerfrei in den Browsern, die mir wichtig sind :)
Ich kann nicht verstehen: PHP soll doch *vor* dem Senden einer Seite an den Client funktionieren? Wie kann dieser Trick die Seitenladezeit beschleunigen, obwohl PHP darauf wartet, dass das kritische CSS geladen wird, bevor die Seite gesendet wird?
@Marcello, PHP wartet tatsächlich nicht auf das Laden von irgendetwas. Sie verwenden einen Build-Prozess (wie PostCSS), um das kritische CSS in eine separate Datei zu extrahieren, und verwenden dann PHP, um den Inhalt dieser kritischen Datei direkt in das generierte HTML einzubetten, damit der Browser keine separate Netzwerkanfrage stellen muss.
Dann können Sie *JavaScript* verwenden, um den Rest Ihres CSS asynchron zu laden. (Sie müssen nicht warten, bis der Rest geladen ist, bevor Sie damit beginnen, führen Sie den Code einfach sofort aus, und der Browser lädt die Datei automatisch herunter, ohne das Rendern des Rests der Seite zu blockieren)
Das PHP-Beispiel fügt die CSS-Datei in den Tag ein, sodass diese CSS-Regeln gerendert werden, was zu etwas wie diesem führen würde
Dies würde das kritische CSS "inline" in Ihrem Header ausgeben und dann Ihr CSS über
<link>ladenEs ist erwähnenswert, dass Jacket eine Compass-Komponente ist – diejenigen von uns, die libsass bevorzugen, werden es nicht verwenden können.
Ja, Michael. Das ist einer der Gründe, warum ich mich für etwas entschieden habe, das syntaktisch von nichts anderem als reinem CSS abhängt.
Ich weiß, das ist ein wenig pedantisch, aber ich halte es für erwähnenswert;
inline-Stile werden zum Element hinzugefügtwas in diesem Artikel gemeint ist, ist ein interner Stylesheet
Ups… Sie haben Recht. Ich frage mich, ob Chris den Beitrag bearbeiten lässt!
Was in diesem Artikel gemeint ist, ist tatsächlich ein eingebetteter Stylesheet, kein interner oder Inline-Stylesheet.
Um FOUC zu behandeln, könnten wir overflow:hidden am Body verwenden und es entfernen, sobald das nicht-kritische Styling geladen ist. Ich mochte den Ansatz zum Aufteilen von CSS mit post-css-split.
Danke
Kalpesh, danke, es freut mich zu wissen, dass es Ihnen gefallen hat :)
In der Tat, das Verstecken des Bodys, bis das gesamte CSS geladen ist, ist eine weit verbreitete Strategie zur Behandlung von FOUC. Ich bevorzuge eher eine Strategie, die es den Benutzern erlaubt, den Inhalt so schnell wie möglich *zu sehen*. Ich stelle mir gerne vor, dass Benutzer möglicherweise eine sehr schlechte/langsame Verbindung haben, und versuche, die Dinge in diesem Szenario bestmöglich funktionieren zu lassen.
@Wladston In der Tat, da ich standardmäßig jegliches JS blockiere, hasse ich es, die Entwicklertools öffnen zu müssen, um display (oder meistens: opacity) zu setzen, um den Inhalt überhaupt *sehen* zu können.
Sie können es leicht in *einer* Datei aufteilen. Verwenden Sie einfach PHP als CSS-Datei
link rel=”stylesheet” type=”text/css” property=”stylesheet” media=”screen” href=”style.php?id=blog”
und für den Rest id=bottom
Übrigens danke für den Beitrag "Why I don’t use CSS preprocessors". Ich habe den Bedarf an SASS, LESS usw. nie verstanden. Ich benutze PHP zum Minifizieren – kein Bedarf für ein zusätzliches Werkzeug und diese Arbeitskette. Alles, was ich tun muss, um an dieser einen Datei zu arbeiten, ist, die Syntaxfärbung zu ändern (unten rechts in Sublime Text).
Bester Workflow, den ich bisher zu diesem Thema gesehen habe, danke!!
Entschuldigen Sie, dass ich so schwer von Begriff bin, aber das Beispiel hier:
h1 { /*!CRITICAL*/ margin: 30px; }unterscheidet sich stark vom Beispiel des Plugin-Autors:h1 /*!CRITICAL*/ { margin:30px; }Hallo Robin, ich freue mich sehr, dass Ihnen der Beitrag gefallen hat! Danke!
Die Beispiele in der Dokumentation von post-css-split sind veraltet, als ich den Standard-Regex-Match geändert habe, habe ich vergessen, die Dokumentation zu aktualisieren… mein Fehler :/
Sie sind eingeladen, einen Pull-Request für den Code von post-css-split zu senden, um dies zu beheben :)
CriticalCss ist relevant in Bezug auf die Renderzeit einer einzelnen Seite.
Aber was passiert, wenn ein Benutzer mehrere Seiten auf derselben Website durchsucht?
Zum Beispiel: Eine Website, auf der das gesamte CSS etwa 30000 Zeichen lang ist und das kritische CSS 6700 Zeichen (22%) ausmacht.
Wenn ein Benutzer mehr als eine Seite durchsucht,
- Mit Critical CSS rendert die erste Seite schneller, aber dann lädt jede Seite 22% mehr CSS (intern).
- Ohne Critical CSS lädt das vollständige CSS und wird auf der ersten Seite gecached, und jede folgende Seite sollte schneller rendern.
Was denkst du?
Hallo fr, das ist ein wichtiger Kompromiss, über den Sie sprechen. Die Sache ist, dass das Hinzufügen von ein paar Bytes mehr in der primären GET-Antwort kaum Auswirkungen auf die Ladezeit hat, aber einen brutalen Effekt auf die Seitenrendergeschwindigkeit. Wenn Sie sich also für langfristiges Caching interessieren, können Sie einen Teil Ihres kritischen CSS reduzieren, bis Sie ein Gleichgewicht erreichen, mit dem Sie zufrieden sind. Das ist der Sinn meines vorgeschlagenen Ansatzes: Leuten die einfache Implementierung von Critical CSS zu ermöglichen, wie sie es möchten.
Hallo Wladston. Danke für Ihre Antwort. Es gibt noch einen weiteren Punkt, an dem ich ein (kleines) Problem sehe: Das kritische CSS ist möglicherweise nicht für verschiedene Seiten derselben Website dasselbe. Ich frage mich also, wie Sie verschiedene kritische CSS für verschiedene Seiten verwalten würden?
Ja, das ist tatsächlich schwierig. Diese Technik geht davon aus, dass Sie nur ein Seitenlayout haben oder sehr ähnliche Seitenlayouts, die dasselbe kritische CSS teilen können. Ich sehe also zwei Alternativen
Verwenden Sie für alle Seiten Ihrer Website dasselbe kritische CSS
Erweitern Sie das Post-CSS-Split-Plugin so, dass Sie auch das Seitenlayout beschreiben, für das die spezifische CSS-Regel kritisch ist. Zum Beispiel würde dies für alle kritischen Abschnitte gelten
Während dies nur für einen bestimmten Seitentyp gilt
Denken Sie daran, dass die nicht-kritischen CSS der beiden Seiten dadurch unterschiedlich sein werden, sodass Sie einen Teil der Effizienz des Browser-Caches verlieren.
Wie handhaben Sie diese Dinge auf mehreren Seiten? Zum Beispiel hat ein Webshop normalerweise verschiedene Landingpages mit unterschiedlichem kritischem CSS. Automatisch generiertes CSS ist aufgrund des Cachings von CSS (viele Unterseiten) nicht wünschenswert. Das Pflegen von kritischem CSS für jede Seite scheint jedoch nicht sehr praktikabel.
Hallo Ramon! Wie ich gerade @fr geantwortet habe, können Sie entweder das kritische CSS kombinieren oder das Post-CSS-Plugin erweitern, um seitenbezogene Tags zu verarbeiten.
Ich würde damit beginnen, das für alle Seiten erforderliche kritische CSS zu markieren. Wenn Seiten am Ende unnötigerweise viel kritisches CSS einbeziehen, würde ich beginnen, seitenbezogenes CSS zu taggen.
Ich freue mich, mit Ihnen zusammen das Post-CSS-Split-Plugin zu erweitern, um diesen Anwendungsfall zu unterstützen.
Schöner Beitrag! Diese Technik ist mir ein wenig zu manuell (deshalb habe ich Penthouse entwickelt), aber sie sollte gut funktionieren, wenn Sie eine einfache Website haben, die einer einzigen Vorlage folgt.
Nur eine Warnung: Das Extrahieren des kritischen CSS aus dem Original-CSS (Aufteilen in zwei Dateien) ist nur dann in Ordnung, wenn Sie eine kritische CSS-Datei/Vorlage für Ihre gesamte Website verwenden (im Gegensatz zu einzelnen kritischen CSS-Dateien für einzelne Seiten). Andernfalls erhalten Sie für jede Seite unterschiedliche "vollständige CSS"-Dateien (da Sie unterschiedliche kritische CSS extrahiert haben) und können das vollständige CSS nicht mehr cachen.
Aus diesen Gründen rate ich immer davon ab, kritisches CSS aus dem vollständigen CSS zu extrahieren, sondern es stattdessen dort zu belassen, dupliziert. Die Duplizierung spielt keine große Rolle, da das vollständige CSS nur einmal geladen (und dann gecacht) werden sollte, und der einzige Teil, der dupliziert ist, ist das kritische CSS, das klein sein sollte. Mit einem vollständigen "full CSS" müssen Sie sich auch keine Gedanken mehr über die Spezifität machen, da die Regeln in der vollständigen CSS-Datei die Regeln aus dem kritischen CSS übertrumpfen.
Beste Grüße
Ich stimme Ihnen vollkommen zu, und dies würde auch die Idee unterstützen, Cookies zu verwenden, um serverseitig zu bestimmen, ob die kritischen CSS für wiederkehrende Benutzer im Kopfbereich platziert werden sollen, die das vollständige CSS im Cache ihres Browsers haben sollten (obwohl ich auch gelesen habe, dass dies Schwierigkeiten bereiten könnte ...).
Ich stimme zu, dass das vollständige CSS mit allen Stilen beibehalten werden sollte. Das ist einfacher, wenn diese semi-automatischen Methoden verwendet werden.
Wir verwenden SCSS für Critical CSS, wobei das Haupt-Stylesheet alle importierten und per JS geladenen Stile enthält. Dann haben wir ein gemeinsames Critical CSS (Normalize usw.) und separate kritische Stylesheets für jede Website-Vorlage. In den Vorlagen fügen wir (via PHP) das gemeinsame Critical CSS und ggf. das vorlagenspezifische Critical CSS ein.
Auf der Startseite konnten wir etwa 12 kB an Inline-CSS einsparen, das von anderen Seiten stammte. Das kann wichtig sein, da Inline-Styles das HTML-Gewicht stark erhöhen und es schwierig sein kann, unter 14 kB zu bleiben (besonders wenn man noch etwas Inline-SVG verwendet).
sudo npm install -g postcss-splitOffensichtlich ist der Name des Plugins ohne Bindestrich nach "post" geschrieben, im Gegensatz zum im Artikel erwähnten Befehl.
Ich denke, die Vorab-Parser sind heutzutage ziemlich clever, um das CSS zu priorisieren – aber wäre es trotzdem eine gute Idee, die internen Stile ganz oben im Head zu platzieren (direkt unter der Charset- oder Titel-Deklaration)?
Schöne Zusammenfassung, übrigens :)
Auch, wenn Ihre Seite klein ist und Ihr gesamtes Markup und CSS, kombiniert und mit gzip komprimiert, unter 14 KB liegt (wie im Fall von code.energy), könnten Sie in Erwägung ziehen, Ihr gesamtes CSS im Head zu internieren. Natürlich muss der Browser alles im Voraus parsen, aber wenn Ihr Stylesheet klein genug ist... Ich habe keinen Geschwindigkeitsunterschied gemessen – aber Sie wären auch ohne JS vollständig gestylt :)
Ihre Websites sollten auch bei deaktiviertem JS vollständig gestylt sein, denn bei Verwendung von Critical CSS und dem Laden von Haupt-CSS mittels JS sollten Sie das Haupt-CSS normalerweise im noscript-Element verlinken :)
Guter Punkt :)
Wenn Sie nach jeder Millisekunde jagen (was Sie tun, wenn Sie Stylesheets nicht-blockierend laden), sollten Sie nicht nach allen
head-Elementen im gesamten DOM suchen. Verwenden Sie nichtdocument.getElementsByTagName('head')[0]; verwenden Sie die Referenz, die Sie bereits haben:document.head.Verwandt:
document.bodyfür dasbody-Element (das wussten Sie bereits),document.documentElementfür dashtml-Root-Element.