Der folgende Beitrag stammt von Ben Edwards. Ich habe gesehen, wie Ben über ein einfaches Sass @mixin getwittert hat, das es ermöglichte, CSS-Teile als "kritisch" zu bezeichnen – die Idee ist, dieses kritische CSS zuerst zu laden und den Rest des CSS später zu laden. Eine clevere Idee, und eine, die in der Web-Performance-Szene sehr beliebt wird. Ich dachte, ich lasse Ben diese Ideen ausführlicher für uns vorstellen.
Google PageSpeed Insights und meine Webseiten; es war eine himmlische Verbindung, bis sich die Dinge änderten… PageSpeed begann mir zu sagen, dass ich meine CSS-Auslieferung optimieren müsste, dass meine CSS-Dateien rendern-blockieren, dass kein Inhalt oberhalb des "Fold" meiner Seite ohne das Warten auf das Laden dieser Dateien gerendert werden könnte, und dass ich die kritischen Teile dieser Dateien direkt in mein HTML einfügen sollte.
Geh nach Hause, PageSpeed,
rief ich, wer in seinem rechten Verstand will schon einen Haufen CSS in seinem HTML? Ich bin ein legitimer Profi, ich habe einen Workflow, wussten Sie das?
Ich spottete.
Das war lange mein Standpunkt, bis ich den folgenden Tweet las
Ich würde gerne eine Seite wie CSS Zen Garden sehen, aber wo Entwickler versuchen,
die gleiche responsive Seite besser auf webpagetest.org abschneiden zu lassen
Scott Jehl
Ich habe mich schon lange dazu verpflichtet, meinen Webseiten die bestmöglichen Ergebnisse von webpagetest.org zu verschaffen, und das erforderte eine Änderung des Workflows. Warum sollte ich ihn also nicht für PageSpeed ändern? Wenn Sie bereits das mod_pagespeed-Modul von Google verwenden, lehnen Sie sich zurück und klopfen Sie sich auf die Schulter, denn das Modul hat Sie abgedeckt. Für diejenigen unter Ihnen, die wie ich nicht dazu gehören, hier ist, wie ich vorgegangen bin.
Jetzt kommt die Wissenschaft
Um das Problem zu lösen, musste ich zunächst verstehen, was PageSpeed mir sagte. Externe Stylesheets (lesen Sie die, die über link-Tags eingebunden sind) blockieren das Rendern. Das bedeutet, dass der Browser erst dann Inhalte auf dem Bildschirm anzeigt, wenn Ihr gesamtes CSS heruntergeladen wurde. Kombinieren Sie dies mit der Tatsache, dass, wenn die zur Darstellung der Seite benötigte Datenmenge das anfängliche Congestion Window (typischerweise 14,6 kB komprimiert) überschreitet, zusätzliche Roundtrips zwischen Server und Browser des Benutzers erforderlich sind. Dies alles führt zu zusätzlicher Netzwerklatenz und kann für Benutzer mit Netzwerken hoher Latenz, wie z. B. Mobilgeräte, zu erheblichen Verzögerungen beim Laden der Seite führen.
Die Empfehlung von PageSpeed ist, Ihr CSS in zwei Teile zu teilen; einen Inline-Teil, der für das Styling des Inhalts oberhalb des "Fold" verantwortlich ist, und den Rest, der verzögert werden kann. Bevor wir uns nun aufhängen, ob der "Fold" existiert oder nicht, lassen Sie uns einfach zustimmen, dass alles, was wir tun können, um unsere Daten so schnell wie möglich zu unseren Nutzern zu bringen, eine gute Sache ist, oder?
Bestimmen, was kritisch ist
Um zu bestimmen, welche Teile unseres CSS kritisch sind, mussten wir unsere Webseiten in "mobilen" und "Desktop"-Größen inspizieren und dann einen Schnappschuss der CSS-Regeln erstellen, die auf die im Viewport sichtbaren Elemente angewendet wurden. Das schien eine entmutigende Aufgabe zu sein, aber keine Angst, einige sehr kluge Leute waren da, um zu helfen
- Paul Kinlan hat ein Bookmarklet/Chrome Dev Tools Snippet erstellt, um bei diesem Prozess zu helfen
- ebenso wie Scott Jehl
welches auch als Node-Modul und als Grunt-Task verfügbar ist - Penthouse von Jonas Ohlsson ist als Node-Modul, als Grunt-Task und als Online-Tool erhältlich
Mit den Ergebnissen des Inspektionsprozesses bewaffnet, muss ich nun mein HTML ändern, um mein CSS nicht rendern-blockierend zu laden.
Eine asynchrone Last von meinen Schultern
Stellen wir uns vor, eines meiner HTML-Dokumente sähe so aus
<html>
<head>
<link rel="stylesheet" href="things.css">
</head>
<body>
<div class="thing1">
Hello world, how goes it?
</div>
...
<div class="thing2">
Hey, I'm totally below-the-fold
</div>
</body>
</html>Ebenso enthielte things.css Folgendes
.thing1 { color: red; }
.thing2 { background: green; }Mit den Ergebnissen des Inspektionsprozesses kann ich nun den kritischen, oberhalb des "Fold" liegenden Teil meines CSS im head wie folgt einfügen
<html>
<head>
<style>
.thing1 { color: red; }
</style>
</head>
<body>
<div class="thing1">
Hello world, how goes it?
</div>
...Kombinieren Sie dies mit Filament Group's loadCSS, und ich kann das verbleibende unterhalb des "Fold" liegende CSS asynchron wie folgt laden
...
<div class="thing2">
Hey, I'm totally below-the-fold
</div>
<script>
/*!
Modified for brevity from https://github.com/filamentgroup/loadCSS
loadCSS: load a CSS file asynchronously.
[c]2014 @scottjehl, Filament Group, Inc.
Licensed MIT
*/
function loadCSS(href){
var ss = window.document.createElement('link'),
ref = window.document.getElementsByTagName('head')[0];
ss.rel = 'stylesheet';
ss.href = href;
// temporarily, set media to something non-matching to ensure it'll
// fetch without blocking render
ss.media = 'only x';
ref.parentNode.insertBefore(ss, ref);
setTimeout( function(){
// set media back to `all` so that the stylesheet applies once it loads
ss.media = 'all';
},0);
}
loadCSS('things.css');
</script>
<noscript>
<!-- Let's not assume anything -->
<link rel="stylesheet" href="things.css">
</noscript>
</body>
</html>Ein Workflow für die Zukunft
Ausgezeichnete Nachrichten! PageSpeed ist begeistert! Es beschwert sich nicht mehr über rendern-blockierendes CSS und ist zufrieden, dass der Inhalt oberhalb des "Fold" die verdiente Priorität erhalten hat, aber in dieser modernen Welt der CSS-Präprocessor und Front-End-Tools reicht ein manueller Prozess wie der oben beschriebene einfach nicht aus.
Ein automatisierter Ansatz
Wer von Ihnen nach einem automatisierten Ansatz im Stil von mod_pagespeed sucht und auch mit Node vertraut ist (Entschuldigung an diejenigen, die es nicht sind, aber hier bei Clock ist es ein wichtiger Bestandteil von allem, was wir tun) wird sich definitiv Penthouse und Addy Osmani's experimentelles Node-Modul, Critical, ansehen wollen, die beide Mittel zum Inline-Einbinden oder Manipulieren von kritischem CSS bieten, wie es über die PageSpeed API ermittelt wird. Nun, während ein vollständig automatisierter Workflow wie der Himmel klingt, ist die eine Sache, die mich bei den aktuellen Tools stört, dass sie nicht berücksichtigen, dass jegliche inline eingebundenen CSS-Regeln erneut ausgeliefert werden, sobald das CSS unterhalb des "Fold" heruntergeladen wurde. Und im Sinne der Übermittlung von so wenig Daten wie nötig an unsere Nutzer, fühlt sich dies wie eine unnötige Duplizierung an.
CSS-Präprozessoren zur Rettung
Die Nutzung Ihres bevorzugten CSS-Präprozessors für die Erstellung von CSS oberhalb und unterhalb des "Fold" erscheint mir als ein No-Brainer und ist etwas, das das Front-End-Team derzeit bei Clock experimentiert.
Neue Projekte eignen sich sehr gut für diesen Ansatz, und kritisches und nicht-kritisches CSS könnte über gut strukturierte @import-Regeln erstellt werden
/* critical.scss - to be in-lined */
@import "header";/* non-critical.scss - to be asynchronously loaded */
@import "web-fonts";
@import "footer";Sollten sich Ihre Partials nicht für diese Art der Strukturierung eignen, kann das Team Sass's bedingte Stile Compass-Plug-in Jacket sehr nützlich sein. Wenn beispielsweise Ihr Partial _shared.scss Regeln für Elemente oberhalb und unterhalb des "Fold" enthielte, könnten die kritischen und nicht-kritischen Regeln von Jacket wie folgt umschlossen werden
@include jacket(critical) {
.header {
color: red;
}
}
@include jacket(non-critical) {
@include font-face(...);
...
.footer {
color: blue;
}
}Dann könnten critical.css und non-critical.css wie folgt bearbeitet werden, um dasselbe CSS zu erhalten
/* critical.scss - to be in-lined */
$jacket: critical;
@import "shared";/* non-critical.scss - to be asynchronously loaded */
$jacket: non-critical;
@import "shared";Dieser Ansatz scheint auch mit der Art und Weise übereinzustimmen, wie viele in der Community Media Queries auf Komponentenebene statt an globaler Stelle erstellen, und könnte gegebenenfalls verwendet werden, um kritische und nicht-kritische CSS-Regeln auf Komponentenebene zu definieren.
Wir arbeiten diese Dinge noch aus
Obwohl das Update der Webversion von PageSpeed Insights nun fast ein Jahr alt ist, habe ich das Gefühl, dass das Thema kritisches CSS und die Priorisierung von oberhalb des "Fold" liegendem Inhalt erst in den letzten Monaten an Bedeutung gewonnen hat.
Ich hoffe, dass ich Sie durch Einblicke in die Art und Weise, wie ich die Erstellung gehandhabt habe, dazu anrege, es in Ihren Workflow zu integrieren. Und achten Sie genau auf die oben aufgeführten Werkzeuge, da die meisten sich in frühen Entwicklungsstadien befinden und ich auf spannende Veränderungen hoffe.
Ich denke, ich mag die Denkweise "kritisch vs. nicht-kritisch" mehr als "oberhalb des Fold". "Oberhalb des Fold" impliziert eher "stellen wir sicher, dass der obere Teil der Website alle notwendigen Stile hat, um vollständig auszusehen, und unterhalb stuff kann warten". Vielleicht ist das in Ordnung, aber ich denke, das ist viel schwieriger zu erstellen und zu pflegen, als CSS in "kritisch vs. nicht-kritisch" aufzuteilen, wobei Sie als Autor nach eigenem Ermessen entscheiden. Vielleicht kennzeichnen Sie einige oberhalb des Seitenkopfes liegende Elemente als kritisch, aber auch alles, was mit Layout oder Typografie zu tun hat, damit die Seite strukturell solide, nutzbar und nicht unruhig ist, während der Rest der Stile herunterkommt.
Die geladene Natur von "oberhalb des Fold" war einer der Gründe, warum ich die Technik zunächst verworfen habe – ich werde der Erste sein, der argumentiert, dass der "Fold" im traditionellen Sinne nicht wirklich existiert, daher ist die Behandlung als kritisch und nicht-kritisch der Standpunkt, den ich in meinem Kopf eingenommen habe, sogar meine CSS-Dateien entsprechend benannt.
Zusätzlich ist die Vagheit meiner Inspektion bei "mobilen" und "Desktop"-Größen, wie im Artikel beschrieben, auf die Tatsache zurückzuführen, dass PageSpeed Insights die Größen und Heuristiken behandelt und Ihnen nicht tatsächlich eine spezifische Reihe von Dimensionen zum Testen gibt. Es ist wirklich eine Frage dessen, was für Sie, mit Ihren Webseiten und mit Ihrem Workflow funktioniert.
Danke, aber ich hätte gerne eine URL, wo ich nachweisen könnte, dass dies einen praktischen Unterschied gemacht hat, außer einer webpagetest.org-Punktzahl, die einfach eine heuristische Methode zur Messung der Leistung ist.
Warum nicht Ihr CSS vereinfachen und viele dieser Punkte hinfällig machen? Kompliziertes CSS wird unabhängig davon, was webpagetest sagt, auf allen Geräten nicht gut gerendert.
Es ist erwähnenswert, dass webpagetest.org bei der mobilen Benutzerfreundlichkeit 60% (ROT!!) erzielt. Das ist ziemlich lächerlich für eine Website, die im Wesentlichen ein Formularfeld mit einem Submit-Button ist.
Sehen Sie das Problem?
Das ist mehr Nabelschau von den CSS/HTML-Architektur-Astronauten, fürchte ich.
Das ist nur trolliges Bullshit. BEGRABEN.
Nur weil Sie nicht zustimmen, heißt das nicht, dass er ein Troll ist. Ich sag's nur...
So kommt es mir vor und das ist mein Haus, fürchte ich. Der Punkt bezüglich der schlechten Bewertung von webpagetest.org ist ein wenig verrückt. Es ist, als würde man sagen, ein Käsemesser schmeckt in einem Sandwich nicht sehr gut.
Guter Punkt bezüglich des Nicht-Lieferns der Ergebnisse eines Vorher-Nachher-Vergleichs. Dies werde ich nachholen, sobald ich diese Änderung in der kommenden Woche oder so auf der Website von Clock angewendet habe. Und ich stimme zu, dass kompliziertes und schlecht geschriebenes CSS nicht durch diese Tipps behoben wird, dies muss Hand in Hand mit so vielen Leistungsverbesserungen wie möglich gehen, da Inline-CSS allein keine schnelle Website ausmacht. Aber der Punkt, dass webpagetest.org schlecht abschneidet, ist weder hier noch dort, aber wenn Sie leidenschaftlich dabei sind, dessen Ratschläge zu befolgen, beteiligen Sie sich und sehen Sie, ob sie jemanden brauchen, der ihnen hilft – http://www.webpagetest.org/about
Hallo Ben – danke für die Antwort. Ich freue mich auf tatsächliche Vorher-Nachher-Ergebnisse, vielleicht in einem Folgebeitrag.
Ich bin mir nicht sicher, was heute mit Chris los ist (ein Beitrag ist "nicht schlau", dieser Beitrag ist "ein wenig verrückt" (er verpasst den Punkt *völlig* – sie folgen nicht einmal ihren eigenen pedantischen Ratschlägen!), aber ja, es ist "sein Haus", er kann Leute beschimpfen, so viel er will.
Ich danke ihm, dass er die Beiträge nur begraben und nicht gelöscht hat :-)
Wie kompliziert wird das? "Oberhalb des Fold" hängt vom Viewport ab, oder? *Seufz*
Zusätzlich mag ich die Idee von Inline-CSS und das Aufteilen von Stylesheets auf diese Weise nicht. Die ganze Zeit ging es darum, Design von semantischem HTML zu trennen. Jetzt sagt uns Google, wir sollen es wieder zusammenführen? Nein. Wirklich nein.
Ich stimme zu, dass "oberhalb des Fold" willkürlich und schwer zu definieren ist und daher hier weniger nützlich ist (siehe mein erster Kommentar). Aber Ideen wie diese einfach abzutun, nur weil Sie entschieden haben, dass Sie sie nicht mögen, ist seltsam. Es ist eine neue Idee, die die Geschwindigkeit von Websites verbessert, und es werden hier Werkzeuge vorgestellt, die sie weniger schmerzhaft machen. Fühlen Sie sich frei, skeptisch oder kritisch zu sein, aber die Augen davor zu verschließen ist nicht klug.
Wie ich im Artikel gesagt habe, war ich auch skeptisch gegenüber diesem Thema, verdammt, es ist fast ein Jahr her, seit Google PageSpeed Insights aktualisiert wurde und diese Dinge meldet. Wichtig ist, es nicht abzutun, ohne es auszuprobieren, und es aus der Perspektive anzugehen, dass alles, was Sie tun, um Ihre Ergebnisse zu verbessern, nur gut für Ihre Nutzer ist. Aber es kommt wirklich auf persönliche Vorlieben und Workflow an – entscheiden Sie, wie viel Sie tun wollen, finden Sie heraus, was für Sie für eine bestimmte Website funktioniert und wie Sie Ihren Workflow ändern müssen, um ihn zukünftig zu erleichtern.
Keine Ihrer besseren Antworten, Chris.
Mir kam es so vor, als ob Lars skeptisch und kritisch war und die Augen nicht "davor verschloss". Die passiv-aggressive, volkstümliche Formulierung "das ist nicht schlau" ist auch nicht konstruktiv. Er hat Vorbehalte, die substanzieller sind als die Terminologie "oberhalb des Fold", wenn Sie mich fragen.
Dies ist im Allgemeinen ein guter Blog, aber dieser Artikel und Ihre Kommentare sind unzureichend. Danke fürs Zuhören.
Es gibt nichts daran, das Inline-Styles nahelegt oder Ihre Erstellungsfähigkeit beeinträchtigt.
Das klingt nach Augenverschließen.
Erstens, toller Artikel Ben, mehr davon bitte!
Ich liebe die Technologie, aber das Konzept macht mir ein wenig Angst. Schafft dies eine bessere Benutzererfahrung oder wird nur eine bessere Punktzahl erzielt (etwas, das eine großartige pädagogische Herausforderung ist)? In jedem Fall weiß der Benutzer, dass mobile Websites nicht sofort geladen werden, und kümmert sich wahrscheinlich nicht darum. Selbst über WLAN laden Websites auf Mobilgeräten langsam, da Layout und Inhalt immer komplexer werden. Außerdem frage ich mich, wie sich dies auf das Bandbreitenmanagement von Mobile Chrome (oder die Komprimierung) auswirkt? Ich würde davon ausgehen, dass dies dieses Problem überflüssig macht. Sollte sich jedoch die Situation ergeben, dass Sie einen sofortigen Ladevorgang für den oberhalb des Fold liegenden Inhalt benötigen, ist es gut zu wissen, dass es eine Lösung gibt. Preprocessor FTW
Einige Vorher-Nachher-Videos wären ziemlich süß. Es gibt aber schon ziemlich solide Demos.
Von hier
Danke Simon
Ich stimme zu, es ist ein beängstigendes Konzept, und es fühlt sich auch ziemlich schmutzig an, CSS außerhalb seiner eigenen Datei zu entsorgen, wo wir es so gewohnt sind zu platzieren. Letztendlich geht es darum, eine bessere Benutzererfahrung zu schaffen, wir sollten uns nicht auf Nutzer verlassen, dass sie erwarten, dass Dinge auf Mobilgeräten langsam sind, und wenn es ein bisschen Gamification über Punktzahlen von einem Online-Tool braucht, bin ich dabei, denn wie Sie richtig sagen, ist Bildung der Schlüssel, und sowohl Chris als auch ich denken, dass dies etwas ist, das in den kommenden Monaten wahrscheinlich noch mehr an Bedeutung gewinnen wird (behalten Sie die Leute von Filament Group im Auge, da sie großartige Arbeit im Leistungsbereich leisten!).
Das ist ein interessanter Punkt in Bezug auf Mobile Chrome, und etwas, das ich sicher testen und berichten werde, wenn ich die oben genannten Änderungen auf clock.co.uk implementiere. Meine anfänglichen Gedanken sind, dass das Inline-Einbinden von CSS es noch schneller rendern lassen würde, anstatt es überflüssig zu machen, aber ich werde meine Ergebnisse teilen, sobald ich sie habe.
Es war nur beängstigend, als ich es als Code betrachtete, der besser in einem Leistungstest abschneidet. Natürlich ist die Schönheit des Webs, dass jede Website anders ist (und jeder Client), also ist diese Lösung, obwohl sehr spezifisch, eine neue Technik. Sie kann sogar zu Innovationen bei den Browserherstellern und sogar zu zukünftigen Web-Spezifikationen führen – die Idee, kritisches CSS zuerst auszuliefern, ist für mich völlig neu (außer dem Laden von CSS-Chunks inline mit Modulen usw.).
Wenn Sie das perfekte Beispiel finden könnten, wäre das ein großartiger Vortrag!
HTTP 2.0, auch bekannt als SPDY, wird "Server Push" unterstützen, was bedeutet, dass der Server die CSS-Datei parallel zum HTML an den Browser senden kann. Ich hoffe, dass dies den "Inline CSS"-Hack überflüssig macht.
Das ist interessant zu hören. Es wäre cool zu sehen, ob dies in Kombination mit Inline-CSS noch schneller sein könnte!?
HTTP2 ist für mich die richtige Antwort.
Wir brauchen Technologien, die unsere Arbeit erleichtern. Ich habe das Gefühl, dass so viel Hacking für Performance uns am Ende verrückt machen wird. Zumindest in meinem Fall weiß ich, dass es den Spaß am Web-Entwickeln nimmt.
Es wird auch JavaScript-Dateien-Konkatenation überflüssig machen, was Ihren Build-Prozess vereinfacht und die Cache-Nutzung verbessert.
Toller Artikel. Danke, Ben. Wenn ich die Möglichkeit habe, dies zu implementieren, werde ich diesen Weg gehen und Cookies verwenden, um sicherzustellen, dass die asynchron geladene CSS-Datei für zukünftige Besuche gecacht wird: https://github.com/filamentgroup/enhance#a-fully-configured-head-setup-for-enhancejs
Danke Kyle, und danke für den Link. Ich muss zugeben, dass Filament Group mir einige Last-Minute-Ergänzungen zum Artikel beschert hat, mit all den tollen Sachen, die sie in letzter Zeit veröffentlicht haben, aber dieser hier ist durchgerutscht :)
Die Verwendung des Begriffs "oberhalb des Fold" ist wie ein Schritt zurück im Krieg um Responsive Web Design. Das ist ein alter Begriff aus Zeitungen/Druck. Indem Sie ihn verwenden, ermutigen Sie andere Entwickler, ihn ebenfalls zu verwenden, was die Dinge weiter verkompliziert. Es gibt keinen Seiten-Fold.
Zu sehen, wie dieser Artikel mit dem Begriff übersät ist, lässt mich den Artikel komplett abtun, nachdem ich viele Gespräche mit traditionellen Printdesignern über diese Fehlannahme geführt habe, dass es einen Seiten-Fold gibt.
Ich respektiere, was Sie tun, und schätze Ihr Talent und Ihre Zeit, die Sie für das Schreiben dieses Artikels aufgewendet haben, aber bitte erkennen Sie an, wie schädlich dieser Begriff für die Weiterentwicklung von RWD sein kann. Insbesondere in der Agenturwelt, wo traditionelle Printdesigner, die die Grundlagen des Webdesigns lernen wollen, darin wimmeln.
Es spielt keine Rolle, welcher Begriff verwendet wird, "oberhalb des Fold" oder nur "Sichtlinie" ;-)
In meiner Surferfahrung macht das Laden einer Webseite einen großen Unterschied, ob ich etwas früher oder später sehe. Egal was es ist, solange ich früher oder später mit der Seite beschäftigt bin, macht es einen Unterschied in meinem Browser-Erlebnis und wird definitiv mein Frustrationslevel und meine "Bounce"-Rate beeinflussen, früher = glücklicher.
Responsive Design macht es nur noch komplizierter, da es Elemente geben kann, die einfach nicht wissen, ob sie für einige Benutzer sichtbar sein werden.
Einige Websites entscheiden sich dafür, das gesamte CSS zuletzt zu laden, was für mich meist nutzlos ist, da das Sehen der Text-/HTML-Version verwirrend ist. Daher ist dieser Artikel ein großartiger und glücklicher Mittelweg :-)
Hallo Erik
Als ich den Artikel schrieb, war mir bewusst, dass die Verwendung des Begriffs "oberhalb des Fold" wahrscheinlich zu Streitigkeiten führen würde, es war der Hauptgrund, warum ich die Vorschläge beim ersten Sehen abgewiesen habe. Da dies jedoch der Begriff ist, den PageSpeed Insights verwendet, hielt ich es für wichtig, ihn ebenfalls zu verwenden.
Ich bin ebenfalls ein Verfechter von Responsive Web Design, und das *Entwerfen* mit "dem Fold" im Hinterkopf ist etwas, das ich niemals befürworten würde, da es, wie Sie sagen, einfach nicht als Maßeinheit existiert.
Wenn es jedoch um die Bereitstellung von Assets geht, wenn man an willkürliche "mobile" und "Desktop"-Viewports und ihre willkürlichen "Folds" denkt, das Bestimmen der kritischen und nicht-kritischen Elemente auf den Seiten Ihrer Website und das Bemühen, die Assets, die zur Darstellung dieser Elemente benötigt werden, so schnell wie möglich bereitzustellen, wird allen Benutzern zugute kommen, unabhängig von ihren genauen Gerätedimensionen.
"Kritisches CSS" ist nicht dasselbe wie "CSS oberhalb des Fold".
Kritisches CSS ist all das Zeug, das Sie *jetzt sofort* brauchen, um die Seite anzuzeigen. Dies könnten Dinge am oberen Rand der Seite sein – sagen wir, Sie haben eine wirklich lange Seite und einen schicken Footer, dann könnten Sie den Footer-CSS verzögern. Es könnten aber auch CSS für Interaktionen sein, wie das Klicken auf ein Widget, das eine Überlagerung erzeugt.
Betrachten Sie es als das CSS, das benötigt wird, um den Anfangszustand der Seite anzuzeigen. Der Benutzer braucht einige Zeit, um mit der Seite zu interagieren – entweder durch Scrollen der Seite oder durch Aktivieren von Dingen – und Sie können diese Zeit nutzen, um das restliche CSS im Hintergrund herunterzuladen.
Ob sich das lohnt, hängt von Ihrer Website ab (und von Ihnen/Ihrem Team). Wenn Sie ein einfaches Design mit einer kleinen Menge gut organisierten CSS haben, dann lohnt es sich vielleicht nicht, diese schicken Tricks anzuwenden. Aber wenn Sie einen riesigen Mengen an widgetigen CSS-Bloat haben, könnte es einen großen Unterschied machen.
Natürlich ist der effektivste Weg, die CSS-Leistung zu optimieren, *weniger CSS zu schreiben*. ;-)
Ich stimme voll und ganz zu, dass weniger CSS zu schreiben der effektivste Weg zur Optimierung Ihres CSS ist, und ich plädiere nicht dafür, dass jemand denkt, seine Arbeit sei erledigt, indem er einfach die Änderungen in diesem Artikel implementiert, ohne so viel Optimierung, Minifizierung und Konkatenation wie möglich durchgeführt zu haben.
Um meine eigene Website als Beispiel zu nehmen, sie hat eine kleine Menge CSS und lud bereits ziemlich schnell. Aber durch das Inline-Einbinden aller CSS und das asynchrone Laden der Webfonts konnte ich die Ladezeiten weiter verkürzen.
Ja – ich denke, es ist eine gute Technik und dies ist der beste Artikel, den ich darüber gelesen habe. Das Inline-Einbinden von kritischem CSS ist klug.
Mein Kommentar richtete sich eher an die Antworten "es gibt keinen Fold". Es geht nicht nur um den Fold; wie Sie anfangs sagten, bleiben die Leute an diesem Begriff hängen und beginnen eine (meistens) irrelevante Diskussion.
Und natürlich haben Sie Recht – fast jede Website, selbst mit schlankem CSS, könnte die Leistung mit dieser Technik verbessern. Ihre Website "braucht" diese Optimierung wahrscheinlich nicht sehr, aber da Sie die zusätzliche Mühe auf sich genommen haben, haben Sie sie noch schneller gemacht.
Ich nehme an, was ich damit sagen will, ist, dass man die Leistung *immer* optimieren kann. Wie weit man geht, hängt von der Art Ihrer Website ab und auch davon, wie viel Zeit/Fähigkeit Sie dafür aufwenden müssen.
Ich habe es nicht eilig, dies auf meiner Website zu implementieren, da ich denke, dass es sich für mich derzeit nicht lohnt. Aber es ist großartig, dass ich diesen ausgezeichneten Artikel habe, zu dem ich in Zukunft zurückkehren kann!
Hmmmm, es gibt viel Hass gegen das hier. Aber ich denke, das liegt nur daran, dass es *schwierig* ist.
Das Bestimmen des oberhalb des Fold liegenden Inhalts, das wir alle schon lange aufgegeben haben, dann die Verwendung eines Drittanbieter-Tools zur Bestimmung, welches CSS für diesen Teil der Website verwendet wird, und dann muss dieses CSS in etwas Inline aufgeteilt werden – etwas, das auf einer Website, die in einem CMS mit etwas wie Sass erstellt wurde, nicht automatisch erfolgen kann.
Der Begriff „geschafft“ kommt mir in den Sinn, wenn die Zeit kommt, in der Sie jemals das CSS auf sinnvolle Weise ändern müssen.
Ich habe gerade das Skript von Scott Jehl auf einer der neuesten Websites meines Unternehmens ausgeführt, und es ergab, dass buchstäblich 50 % des gesamten Stylesheets (nach Zeichenanzahl) für den Inhalt oberhalb der "fold" benötigt wurden. Das ist eine ganze Menge, um es abzutrennen und inline zu setzen. Zum Teil wegen Reset-Styles – die niemand in seinen Demos erwähnen muss.
mod_pagespeed scheint die einfachste Methode zu sein.
Dieser Artikel könnte komplett umgeschrieben werden, um den Verweis auf "above the fold" und jeden Verweis auf Seitengeschwindigkeit zu entfernen, aber die vorgeschlagene Lösung war spezifisch für dieses Problem und nicht für jede Website anwendbar.
Die Technik ist jedoch tatsächlich sehr aufschlussreich und hat zahlreiche Anwendungsmöglichkeiten. Sie könnte implementiert werden, um nur das CSS zu laden, das sich auf die anfängliche Ansicht oder die erste Seite in ihrer Gesamtheit bezieht, oder auf kritische Funktionalität, wie Mike vorgeschlagen hat. Stellen Sie sich vor, Sie haben eine komplexe Webanwendung mit einer relativ einfachen Startseite, die nicht zu viele Stile teilt, oder sogar eine dynamische Website mit viel CSS-Animationen, die auf der Homepage nicht verwendet werden – wenn Sie sie mit Vendor-Präfixen versehen, können sie riesig werden!
Es wird oft empfohlen, dass der gesamte Javascript am Ende des DOM geladen wird, aber das ist oft nicht praktikabel und man braucht trotzdem etwas im Head. Das Gleiche könnte man über kritisches und nicht-kritisches CSS sagen, auch wenn es immer noch 50% des Gesamtkodes ausmacht. Dieser Artikel hat mich auf eine Technik aufmerksam gemacht, von der ich noch nie gehört hatte, und es wäre großartig zu sehen, wie sie sich entwickelt.
Das ist eine Sache, die der Artikel, soweit ich gelesen habe, nicht wirklich erwähnt hat. Es gibt viele Hänger am Begriff "fold", aber es wäre einfacher gewesen, ihn auf die erste Seite zu vereinfachen. Das macht mod_pagespeed sowieso.
Es gibt viele Fälle, in denen es nützlicher wäre als eine Geschäftswebsite, aber es ist eine dieser Techniken, die genug zusätzliche Zeit in Anspruch nimmt, um sie tatsächlich durchzuführen – besonders wenn die Website in einem CMS erstellt wurde, wo das Einfügen von Code nicht so einfach ist wie die Änderung einer HTML-Datei, und wenn sich das CSS in Zukunft ändert – ich glaube, deshalb mögen viele Leute es nicht.
Wenn es irgendwie automatisch wäre, wie viele andere Verbesserungen – oder einen greifbaren Nutzen für so wenig zusätzlichen Aufwand bieten würde (vorausgesetzt, nicht jeder hat Zugriff auf etwas wie mod_pagespeed), glaube ich nicht, dass die Hälfte der Leute, die es nicht mögen, es tun würden.
Schöner und interessanter Artikel – würde gerne mehr lesen.
Verschachtelung von kritischen vs. nicht-kritischen Elementen fühlt sich hier aufgebläht an. Ein Plugin (wahrscheinlich Compass – da Sass das meines Wissens nach nicht kann) könnte das Leben hier einfacher machen.
Anstatt also zu schreiben
Man könnte schreiben
Das Plugin kann erkennen, was zwischen
{}benötigt wird.Ich dachte das Gleiche, aber dann fiel mir ein, wie viele
!criticalund!non-criticales in den Quelldateien geben würde, und ich denke, das wäre ein ziemliches Durcheinander.Ich glaube nicht, dass die kritischen Teile typischerweise auf spezifischen Attributen/Werten liegen, sondern eher auf Selektorebene, also vielleicht so etwas wie das hier stattdessen
.header {color: red;
margin: 2em;
border: 1px solid #000;
}!critical
funktionieren könnte, obwohl ich kein großer Fan der Syntax bin.
Ich möchte auch das negative Gefühl gegenüber dem Begriff "fold" bekräftigen, da wir alle wissen, dass es ein sich bewegendes Ziel ist, das nicht wert ist, gejagt oder referenziert zu werden.
Der durchschnittliche Benutzer versteht, dass Websites geladen werden müssen, und da er dies bei vielen verschiedenen Geschwindigkeiten gewohnt ist (aufgrund der unterschiedlichen Geräte, die zur Internetnutzung verwendet werden), verlässt die Seite bei einer durchschnittlichen Ladezeit seltener. Ich tue mich schwer zu verstehen, welchen tatsächlichen Nutzen diese Taktik hätte.
Ich werde das als sehr gefährliches Denken wiederholen. Es fühlt sich für mich wie eine defensive Selbstvalidierung an. Es fühlt sich an wie "Mach dir keine Sorgen um die Performance, die Leute verstehen, dass Seiten Zeit zum Laden brauchen, egal was ich gerade tue, es ist in Ordnung." Und Sie werden dadurch bestätigt, dass Sie weiterhin ein Geschäft führen.
Es gibt jedoch auch einen alternativen Weg: Kümmere dich um die Performance, lerne neue Dinge, um Websites schneller zu machen, ernte die Belohnungen der Geschwindigkeit.
Ich verstehe Ihre Sorge. Ich meine nicht "Mach dir keine Sorgen um die Performance". Ich meine, opfern Sie nicht die Integrität Ihres Codes für einen winzigen Effizienz- und Punkteschub. Die Kosten überwiegen in den meisten Fällen den Nutzen, es sei denn, Sie haben bereits eine ineffiziente Website. Wenn Sie eine signifikante Geschwindigkeitssteigerung erzielen, gibt es wahrscheinlich etwas anderes, das falsch ist.
Guter Artikel, Ben! Es ist aufregend zu sehen, wie eines meiner Plugins für clevere Dinge verwendet wird, an die ich nie gedacht hätte.
Wirklich begeistert von der Idee von kritischen und nicht-kritischen im Gegensatz zu "above the fold".
Dies ist eine wunderbare Erklärung von kritischem CSS, die das "above the fold"-Performance-Monster anspricht, das wir alle ignoriert haben. Manchmal scheint all dies ein wenig wie das Bauen von hervorragenden Pflastern zu sein, während die Ursachen unserer Wunden ignoriert werden.
Aber für den Moment bin ich überzeugt. Tatsächlich arbeite ich gerade an einer Website-Überarbeitung mit einigen dieser Techniken und werde über die Ergebnisse berichten. Wir werden Inline-CSS auf inhaltsreichen Seiten rendern, die laut Analytics auch die ersten Anlaufstellen sind. Die Komponenten der Seite werden dem Compiler sagen, welches CSS benötigt wird. Wir experimentieren auch damit, das am häufigsten geteilte CSS der Website asynchron in ein stringifiziertes localStorage-Objekt zu laden, was es einzelnen Komponenten auch ermöglichen könnte, ihr CSS dort zu platzieren. Es ist eine seltsame Art, unsere fünf Megabyte pro Ursprung localStorage zu nutzen. Haben Sie ähnliche Techniken ausprobiert? Sind Post-Processing-Optimierungstechniken so stabil?
Entschuldigung, siehe meinen Kommentar unten
loadCSSscheint eine unnötige Verdoppelung von Informationen zu sein, d.h. der Dateiname, und benötigt eine Erweiterung für jedes Attribut, das Sie vielleicht auf Ihrem Link wünschen. Als Null-Annäherung (die ich nur kurz in FF und Chrome getestet habe), wie wäre es,class="stylesheet deferred"auf Ihr noscript zu setzen und in etwa so vorzugehen:localStorage zu verwenden ist etwas, von dem ich weiß, dass Scott Jehl und Filament Group es während ihrer Pre-loadCSS-Forschung untersucht haben – https://gist.github.com/scottjehl/87176715419617ae6994
Sie könnten auch an https://github.com/filamentgroup/enhance interessiert sein, das ihren Workflow für das asynchrone Laden von JavaScript auf qualifizierte Weise veranschaulicht
Ich sehe das nicht als "eingehendes CSS". Der Punkt der Trennung von Stil und Inhalt ist die Klarheit des Workflows für den Entwickler. Und in diesem Fall, wenn ich richtig verstanden habe, sieht der Entwickler kein Inline-CSS. Der Entwickler markiert einfach einige Dinge als kritisch, und das war's, der Automat erledigt den Rest.
Guter Artikel und interessante Diskussion. Ich habe ein paar Punkte hinzuzufügen (ich habe eines der im Artikel genannten Tools geschrieben)
Ja, es gibt keinen "fold", aber lassen Sie sich davon nicht beirren. Wir versuchen nur, einen leicht definierbaren Haltepunkt zu finden, mit dem wir automatisch sortieren können, was als kritisches CSS klassifiziert wird und was nicht. Obwohl ich die Denkweise verstehe, was manuell als kritisch bezeichnet werden soll, ist es meiner Meinung nach, wie Chris Coyier sagte – einfach nicht wartbar. Möchten Sie wirklich all Ihr CSS und HTML überarbeiten, sobald sich eines davon ändert? Oder finden Sie es in Ordnung, dass Ihre Website versehentlich ungestylten Inhalt anzeigt, bevor der Rest Ihres CSS greift?
Jeder Benutzer und jedes Gerät zeigt beim ersten Laden eine unterschiedliche Menge an Pixeln ("the fold") an – aber wir müssen uns hier nicht zu sehr darauf konzentrieren. Alles, was wir tun wollen, ist sicherzustellen, dass wir beim Laden zumindest alles Sichtbare auf dem Bildschirm laden, und idealerweise so wenig wie möglich sonst. Wenn Sie sich wirklich gegen die Verwendung eines "fold"-Haltepunkts aussprechen – setzen Sie einfach einen lächerlich großen Haltepunkt (9999px) für eines dieser Tools, und Sie werden trotzdem den Vorteil haben, alles CSS, das auf der aktuellen Seite nicht verwendet wird, abzuschneiden. Ihre Seite wird trotzdem viel schneller gerendert.
Jemand erwähnte, dass er 50 % seines CSS (als verbleibendes kritisches CSS) mit diesen Techniken einsparen könne. Ich habe inzwischen kritische Pfad-CSS für eine recht große Anzahl von Anfragen über die Online-Version meines Tools generiert, und im Durchschnitt beträgt die Einsparung eher 90 %. Offensichtlich hängt es davon ab, wie DRY Ihr CSS ist und wie groß Ihre Website ist, aber für jede große Website gibt es definitiv mehr als 50 % Einsparpotenzial (in Bezug auf die CSS-Dateigröße). (Dazu noch: Ob Sie 50 % oder 90 % sparen – wenn das vollständige CSS für Ihre Website kleiner als ca. 14 KB minifiziert ist, dann würde ich mich wirklich nicht mit kritischem Pfad-CSS abmühen… machen Sie einfach Ihr vollständiges CSS inline, und Sie werden die gleiche Performance-Verbesserung erzielen).
Was die Erschwerung unserer Arbeit durch solche Techniken angeht... Ich denke, dank der Community, die wir im Web haben, muss es nicht so schwer sein. Wenn Sie einen Task-Runner wie Grunt oder Gulp verwenden, richten Sie einfach eines der im Beitrag genannten Tools in Ihrem Build ein, lassen Sie es automatisch kritische Pfad-CSS für beliebige Seiten generieren, stellen Sie in Ihrer Template-Sprache ein, ob eine kritische Pfad-CSS-Datei für die Seite existiert – geben Sie sie dann einfach in einem Style-Tag aus! Ich habe mein Tool so geschrieben, dass es diese Aufgabe vollständig automatisiert, sodass Sie es nur einmal einrichten und nie wieder zurückblicken müssen. Ich werde ein Tutorial über jeden Schritt schreiben, den Sie dazu benötigen, vielleicht finden das einige Leute hilfreich.
Was die Art und Weise betrifft, wie wir derzeit CSS an unsere Benutzer liefern und gleichzeitig eine gute Performance beibehalten... Ich freue mich auch auf HTTP2 und darauf, dass der Browser/Server einige dieser Dinge für uns übernimmt. Aber wenn das passiert, können Sie sicher sein, dass wir neue Wege finden werden, um noch ein bisschen mehr Performance aus unseren Websites herauszuholen. :)
Versuche, meinen Gravatar zum Laufen zu bringen. :)
Jemand erwähnte, dass CSS, das für Benutzerinteraktionen benötigt wird, in das kritische CSS einbezogen werden soll. Ich rate dringend davon ab. Die Aufgabe des kritischen Pfad-CSS ist es, dem Browser zu ermöglichen, die Seite so schnell wie möglich zu rendern. Dinge in den kritischen Pfad einzubeziehen, die nicht Teil dieses ersten Renderns sind, ist... kontraproduktiv. Konzentrieren Sie sich stattdessen auf die allgemeine Seitenladeoptimierung, damit Ihr vollständiges CSS (und vielleicht benötigtes JS) so schnell wie möglich geladen werden kann.
Ich würde sogar argumentieren, dass Dinge wie Icon-Fonts idealerweise nicht Teil des kritischen Pfad-CSS sein sollten. Wenn Sie das weiterverfolgen möchten, entfernen Sie solche Regeln aus Ihrem CSS, bevor Sie es an ein Tool wie Penthouse übergeben, und erzielen Sie noch bessere Leistung. Ich erwäge, Ihnen die Übergabe einer "Blacklist" von Selektoren zu ermöglichen, die Sie aus dem kritischen Pfad-CSS ausschließen möchten...
Ich glaube, Sie meinen mich. Ich meinte das Gegenteil: kritisches CSS sollte CSS für Benutzerinteraktionen **ausschließen**. Dies ist wahrscheinlich das sicherste CSS zum Ausschließen, da es nicht von einer beliebigen Viewporthöhe abhängt, sondern davon, dass die Leute keine blitzschnellen Interaktionen mit der Seite haben.
Wäre es nicht erstaunlich, wenn es eine Art Node (oder ähnliche) Magie gäbe, um Eigenschaften mit einer
!criticalDeklaration à la!importantzu extrahierenDas wäre ziemlich bada55.
Das ist eine sehr schlechte Praxis und eine noch schlechtere Empfehlung von Google. Wir fanden einen Kunden, der seine externen Blätter anders bereitstellte und dasselbe erreichte. Dies verletzt alle Prinzipien von sauberem HTML und ist ein Albtraum für Entwickler und Zugänglichkeit.
Finden Sie eine bessere Methode oder empfehlen Sie keine. Inline-CSS verletzt alles, wofür CSS gedacht ist.
Es ist inline im HTML-Dokument, innerhalb eines Style-Tags, nicht auf einzelnen Elementen. Immer noch getrennt vom Inhalt.
Ich frage mich oft, warum ich, wenn ich einen Beitrag auf dieser Seite abonniert habe, oft Antworten sehe, die direkt auf jemanden anderen bezogen sein sollen… als völlig neue Antwort gepostet werden. Dann erhalte ich eine E-Mail, die mich über etwas informiert, auf das ich antworten möchte, und ich sehe diesen Kommentar nicht auf der Website Minuten, nachdem er hinzugefügt wurde. Sie sollten sich das vielleicht mal ansehen, Chris… denn jetzt verstehe ich, warum Antworten möglicherweise nicht richtig geordnet erscheinen.
Auf jeden Fall wollte ich nur sagen… es scheint, dass es für einige Leser hilfreich sein könnte, den Unterschied zwischen eingebetteten und Inline-Stilen zu lernen. Es gibt einen Unterschied.
Ich nenne das auch Troll-Bullshit. Wenn Sie ein Nörgler sein wollen, tun Sie es entweder mit Daten und Fakten zur Untermauerung, oder tun Sie es auf Ihrem eigenen Blog.
Warum Leute darauf bestehen, Dinge wie "Prinzipien sauberen HTML" zu sagen, ist mir ein Rätsel. Manchmal müssen Regeln gebrochen werden, um andere Ziele zu erreichen. Wenn Sie das Leben nach strengen Regeln leben, könnten Sie genauso gut ein Roboter sein. Menschen bewerten Situationen und können Regeln biegen, um den Umständen am besten gerecht zu werden.
Habe versucht, meinen Kommentar und den dazu zu finden
Welche Daten wünschen Sie sich von der CSS-Spezifikation und wie sie funktioniert? Vererbung ist die Grundlage von CSS und das wird mit dieser Methode gebrochen. Es gibt keinen guten Anwendungsfall dafür, außer in einigen CMS, und das nur, weil Sie keine Zeit haben, es zu korrigieren.
Und ich – ich mache CSS, seit es herauskam, und habe HTML von davor (ca. 1998) handcodiert. Ich mache seit 2004 Accessibility-Coding und arbeite seit 2005 mit SEO.
Es ist eine gute Idee, wenn Sie die Idee akzeptieren, dass das Einbetten von CSS in Ordnung ist. Ich tue das nicht, daher wird diese Art von Posten nur mehr Code-Albträume erzeugen, die ich Leute auffordern werde zu entfernen – besonders weil Sie die Page-Speed-Empfehlungen erfüllen können, ohne dies zu tun.
Man McGuyvert einen Website nur, wenn man es nicht besser weiß oder keine anderen Optionen hat. Sie haben andere Optionen, also gibt es keinen Grund für das McGuyvering.
PS Nichts Trolling daran, jemandem zu sagen, dass seine Idee schlecht ist. Aber leider scheint dies ein Blog nur für gleichgesinnte Geister zu sein.
Guter Artikel. Ich bin überrascht, dass hier niemand erwähnt hat, dass die willkürliche Bildschirmgröße für das kritische CSS zu einem FOUC (ungestyltes CSS!) führt. Als ich loadCSS auf meiner Website ausprobierte, war das Layout auf einem 24-Zoll-Display im unteren Fünftel kaputt. Wir wissen, was los ist, aber der durchschnittliche Benutzer könnte verwirrt sein, warum die Website nicht richtig lädt. Versucht, neu zu laden usw.
Treten das sonst niemand? Haben Sie alle einen gestylten Viewport auf PC-Monitorgrößen?
Nick, das ist das "fold"-Problem bei der Generierung von kritischem CSS – das Finden des Süßpunkts, wie viel CSS einzuschließen ist. Ich weiß, dass selbst mein Tool standardmäßig nicht genug CSS enthalten würde, um die Höhe eines 24-Zoll-Monitors richtig darzustellen – aber Sie können Ihre eigenen (größeren) Dimensionen an das Tool übergeben, um ein inklusiveres kritisches CSS zu generieren.
Theoretisch, wenn Sie auf dem Server die Viewport-Dimensionen des Benutzers kennen, könnten Sie spezifischere kritische CSS für verschiedene Dimensionen erstellen und ausliefern (klein, mittel, groß).
Hallo Nick. Es stimmt, dass es ein wenig Ausprobieren erfordert, um zu bestimmen, was auf allen Seiten Ihrer Website am besten funktioniert, und wie Jonas sagt, hilft das Testen gegen eine größere Ansicht sowie eine kleinere dabei.
HINWEIS für diejenigen, die es nicht zu wissen scheinen. Sie verursachen SEO-Probleme mit der Head-Technik (Code vs. Text-Verhältnis) und wenn jemand nicht vorsichtig ist, brechen Sie die CSS-Vererbung. Außerdem schaffen Sie einen Entwickler-Albtraum (da Sie den Code auf jeder Seite finden müssen) und ein zugänglicher Benutzer kann keine Stylesheets hinzufügen (wie er es normalerweise tut), weil der Browser keine vererbten Stile über Ihre Inline-Stile einfügen kann. Dies schafft weitaus mehr Probleme, als es löst, und diese Probleme können wieder einmal – ohne dies gelöst werden.
Da dieses Missverständnis mehr Probleme verursachen wird, als es hilft, begrabe ich das auch.
Dieser Beitrag schlägt keine Inline-Stile vor. Er schlägt vor, bestimmte Stile als kritisch zu markieren und sie in einen Style-Block im Head zu verschieben. Nichts am CSS bricht.
Dieses Muster ist schwer zu implementieren mit folgenden Dingen
Responsive / Media Query-basierte Webseiten
Web Components
Aktuell gängige Build-Tools
asynchrones CSS über Netzwerkanfragen wie Font-Face und/oder das Hauptlogo, was die Nutzung von Inline-data:url fördert, wenn die Schriftart, als Beispiel, als kritisch betrachtet wird
die Tatsache, dass SPDY oder neuere Netzwerkprotokolle parallele Importe lösen sollten, so dass es keinen Grund gibt, in Chunks zu splitten, da alles Gesplittete mit einer Anfrage heruntergeladen werden kann
neuer HTML-Link-Import
JS-Laufzeit hinzugefügte Stile für altmodische Skripte
Ich denke, insgesamt ist es für alle ein Gewinn, etwas länger auf ein vollständiges Erlebnis zu warten, anstatt Zeit mit Unter-Aufteilung zu verschwenden. 100 zusätzliche ms sind in der realen Welt so gut wie nichts, gehen Sie nicht zu manisch mit diesen Techniken um, es gibt immer noch ein Handy in irgendeinem Land, das 10 Sekunden zum Anzeigen braucht :P
Andrea,
Auch wenn diese spezielle Aufgabe in Zukunft einfacher werden wird, ist das kein Grund, uns nicht unser Bestes zu geben. Der Unterschied bei dieser Vorgehensweise beträgt keine 100 ms, sondern eher 1 Sekunde im Durchschnitt, je nachdem, womit man vergleicht und wie groß das CSS ist. Und das sind 1 Sekunde für Desktops mit Kabelverbindung.
Auf Mobilgeräten sind die Vorteile noch größer, da HTTP-Anfragen noch teurer sind. Wenn Sie es schaffen, alle HTTP-Anfragen aus Ihrem HEAD zu entfernen und Ihr kritisches CSS in das anfängliche Congestion Window zu packen (vollständige HTML-Größe < ca. 14,6 KB), dann sparen Sie höchstwahrscheinlich Sekunden bei Ihrer Renderstartzeit.
Warum so wenig Empathie für Menschen auf Handys in anderen Ländern? Wenn ihre Verbindungen schlecht sind, dann trifft sie schlechte Performance am härtesten. Wenn Ihre Website weniger Zeit zum Laden braucht, würden sie vielleicht erwägen, sie zu nutzen? ;)
–
Bezüglich Ihrer Liste
* Media Queries, Font-Face, Data-URLs… – All diese Dinge werden automatisch gehandhabt, zumindest in meinem Critical Path CSS Generator. Wenn es im CSS enthalten ist und "above the fold" auf der Seite verwendet wird, dann ist es Teil des kritischen CSS.
* Was die Schwierigkeit der Implementierung mit den aktuellen Build-Tools angeht – worauf beziehen Sie sich hier? Das Generieren des kritischen CSS sollte einfach sein, mit Grunt, Node, Gulp oder Ihrem eigenen Task-Runner… Sprechen Sie über die Automatisierung der Einrichtung, um das kritische CSS in Ihr HTML zu bekommen?
Eine ganze Sekunde Unterschied, auf einer Desktop-Kabelverbindung? Das ist viel und definitiv den Optimierungsaufwand wert.
Wie groß wäre das gesamte CSS dort, würden Sie sagen?
Mike
Es hängt von Ihrem Vergleich ab. Die HTTP-Anfrage(n) machen den größten Teil der Einsparung aus, die Sie für Ihre Startrenderzeit erzielen können – wenn Sie von praktisch jedem blockierenden >link< Stylesheet in Ihrem Head zu nur Inline-CSS einer vernünftig großen (>~20kb) Größe übergehen, sollten Sie eine Einsparung von mindestens etwa 1 Sekunde sehen (mehr, wenn Ihre HTTP-Anfrage(n) groß oder langsam sind). Bitte beachten Sie, dass dies erfordert, dass Sie keine anderen blockierenden Assets in Ihrem HEAD lassen, wie z.B. Javascript, sonst werden diese immer noch als Engpass vorhanden sein (und Sie werden überhaupt keine Einsparung sehen).
Der zweite große Einsparungspunkt
breakpointist die Reduzierung der Größe von Inline-CSS bis zu dem Punkt, an dem die vollständige HTML-Anfrage (einschließlich Ihres Inline-CSS) in das anfängliche Congestion Window passt. Aus diesem Grund werden Sie, wenn Sie das Inline-Setzen eines größeren (vollständigen) CSS mit dem Inline-Setzen eines kritischen CSS, das klein genug ist, um dies zu ermöglichen (vollständiges HTML <~14,6 KB minifiziert), vergleichen, wieder eine große Einsparung sehen, besonders auf Mobilgeräten (wie der Artikel erklärt). Ich habe keine genauen Zahlen für diesen Vergleich, aber es lohnt sich auf jeden Fall.Schließlich, wenn Sie nur die Größe des Inline-CSS reduzieren, aber ohne die oben genannten zwei Barrieren zu überschreiten… Dann besteht die Einsparung nur aus der geringeren Downloadzeit der kleineren HTML-Anfrage und der schnelleren Parsing- und Rendering-Zeit der CSS-Datei – da sie weniger Regeln hat. Ich habe versucht, einige Zahlen dazu zu bekommen, aber ich habe festgestellt, dass sie stark variieren, da sie stark von Antwort- und Downloadzeiten – serverseitigen Dingen – abhängen. Ich würde einfach vorschlagen, nicht nach Bytes in Ihrem Inline-CSS zu jagen, es sei denn, Sie können einen der oben genannten Punkte erreichen. Wenn nicht, konzentrieren Sie sich auf etwas anderes, wie das Komprimieren von Bildern oder das Optimieren Ihres Javascripts.
Danke Jonas, das ist sehr klar und hilft, die Ideen in die richtige Perspektive zu rücken.
Ich bin jetzt ziemlich neugierig, mit diesen Ideen zu spielen und die Ergebnisse zu vergleichen. :-)
Danke für diese tollen Tipps. Ich wurde von Google Page Speed Analytics immer wieder aufgefordert, solche Fehler zu beheben.
Toller Artikel.
Eine grammatikalische Anmerkung
"Sollten Ihre Partials sich nicht für diese Art der Strukturierung eignen..."
Ihr, nicht Sie.
HeadJS und korrekt implementiertes On-Demand-Loading. Ende der Geschichte.
cu, w0lf.
ps: natürlich hilft ein Asset-Queuing-System, wie es WP bereitstellt, auch sehr ;)
Ich glaube nicht, dass das Denken in kritischen und nicht-kritischen Modulen/Teilen eine praktikable Methode ist, um große, hochleistungsfähige Websites zu erstellen. In den meisten Fällen liegt das Problem darin, dass Sie viele Module und Komponenten für eine Website entwickelt haben und all diese Komponenten auf jedem Template verwendet werden können. Daher landen Sie selbst dann, wenn Sie in kritisch und nicht-kritisch denken, oft bei 30 KB+ kritischem CSS.
Es wäre besser, Ihr CSS und Ihr JS einfach in eine Basisdatei zu splitten, die das Hauptlayout inklusive des Grid-Systems, Header und Navigation sowie alle Template-Layouts enthält, und dann viele kleine zusätzliche Stylesheets und JS-Dateien für jede Komponente (jede Komponente kann ein oder mehrere Stylesheets/JS-Dateien haben) auf der anderen Seite. Diese Komponenten können dann geladen werden, wo sie benötigt werden. Mit dieser Technik haben Sie immer noch weniger blockierendes CSS und weniger ungenutztes CSS, aber es ist wesentlich entwicklerfreundlicher.
Der Nachteil ist, dass Sie möglicherweise mit vielen HTTP-Anfragen für CSS enden, was die Einsparungen durch das Herunterladen von weniger Bytes leicht übersteigen kann.
Dies kann durch ein cleveres Paketierungssystem gemildert werden (ich glaube, Facebook macht das). Natürlich erhöht das die Komplexität erneut. Irgendwann müssen Sie entscheiden, ob die Komplexität den Nutzen wert ist. Für Facebook oder Amazon ist das fast sicher; für eine kleine Unternehmenswebsite wahrscheinlich fast sicher nicht.
Die effizienteste Methode hängt von der Website ab. Wenn die Website auf allen (oder den meisten) Seiten ein ähnliches Design verwendet, ist es normalerweise besser, das CSS in einer Datei (oder wenigen Dateien) zu belassen. Wenn die Website sehr unterschiedliche Designs hat – sagen wir, eine "Portal"-Website wie Yahoo –, dann ist es möglicherweise besser, CSS in Module aufzuteilen.
Vieles davon wurde bereits vor langer Zeit (in Web-Zeit) von Steve Souders et al. behandelt. Das Einzige, was hier neu ist, ist die Automatisierung (oder Semi-Automatisierung) durch diese Tools, die Ihre Seite analysieren.
Ich verstehe den gewünschten Nutzen vollständig, bin mir aber nicht sicher, ob er in den meisten Fällen praktikabel ist. Wenn Ihre Kernstile (normalize, base, typography, navigation usw.) alle das Fundament für Ihr Modul- und Hilfs-CSS bilden – was bedeutet, dass letztere von ersteren für zumindest einen Teil ihrer Darstellung abhängig sind –, wäre es dann wirklich lohnenswert, diese Teile aus dem Kern-CSS für Module/Elemente im kritischen Pfad herauszuziehen? Ich werde es versuchen, aber die meisten kleinen bis mittelgroßen Projekte sehen möglicherweise nicht genug Einsparungen, um die Zeit zu rechtfertigen. In vielerlei Hinsicht fühlt es sich wie ein Rückschritt weg von Webstandards an Ihr Text zum Verlinken hier…. Was hat Zeldman oder jemand anderes dazu gesagt?
Wie wirkt sich dies auf das Browser-Caching aus?
Wenn wir diese Technik anwenden, erhöht sich das Gewicht nachfolgender Seiten, da wir zusätzliche Bytes an CSS laden, die sonst auf dieser ersten Seite geladen und dann gecached würden?
Ein ausgezeichneter Punkt. Page Speed Insights geht nur von einem einzigen Seitenaufruf ohne Caching aus. Mit der Zeit können sich diese zusätzlichen Bytes summieren. Auf einer großen Website bedeutet das auch eine höhere Bandbreitenrechnung.
Ich frage mich, ob Cookies hier helfen könnten? Im Grunde genommen, nach dem ersten Seitenaufruf, ein Cookie setzen. In Ihrer Website-Vorlage, wenn die Vorlage den Cookie sieht, dann hat sie bereits das CSS von einer vorherigen Seite (vorausgesetzt, die Inline-Stile sind auch Teil der größeren CSS-Datei). Sie müssten auch eine Möglichkeit haben, den "Cookie" zu invalidieren, vorausgesetzt, Ihr CSS ändert sich (was normalerweise über den Dateinamen geschieht).
Es stimmt, dass die gesamten kombinierten Bytes von HTML und CSS jeder Seite Ihrer Website mit dieser Technik größer wären, aber Sie könnten mehr kompensieren, indem Sie eines dieser wunderschönen 2x Retina-fähigen Bilder, die wir alle so sehr lieben, optimieren oder vielleicht sogar entfernen ;)
Dave, Sie könnten sich für https://github.com/filamentgroup/enhance interessieren, das einen Ansatz für nachfolgende Anfragen bietet
@ Ben: Danke für den Link, sieht nützlich aus. Gibt es etwas, woran Filament nicht beteiligt ist?!
Wer auch immer daran denkt, dies zu tun, sollte sicherstellen, dass die restlichen Grundlagen vorhanden sind: CSS/JS kombinieren und minifizieren, Bilder optimieren und skalieren, CDN usw.