- Critical CSS ist die Extraktion von nur dem minimalen CSS, das zum Rendern des „zunächst sichtbaren Bereichs (above the fold)“ einer Seite erforderlich ist; wird es inline in HTML eingebunden, verbessern sich Core Web Vitals wie FCP (First Contentful Paint)
- Durch das Inline-Einfügen in den
<head> von HTML kann der Browser Inhalte schnell rendern, ohne auf das vollständige Stylesheet warten zu müssen
- Vorteile sind unter anderem eine schnellere wahrgenommene Ladegeschwindigkeit, bessere Lighthouse-Werte sowie Verbesserungen bei SEO und UX
- Nicht essenzielles CSS kann am Ende von
<body> per <link> geladen oder per JavaScript verzögert geladen werden, um die Performance weiter zu optimieren
- Beachten Sie, dass Benutzer den Pfad zu CSS-Links und Asset-Referenzen selbst anpassen müssen
Critical CSS Generator
- Critical CSS Generator ist ein Tool, das nur den unbedingt benötigten minimalen CSS-Code aus einer Webseite extrahiert, sodass eine auf den Einsatzzweck optimierte CSS-Extraktion möglich ist
- Critical CSS sind die minimalen CSS-Regeln, die zum Stylen des zunächst sichtbaren Bereichs einer Seite erforderlich sind
- Dieser Ansatz hilft dabei, Performance und Core Web Vitals (wie FCP) zu verbessern, da der Browser nicht auf das Laden aller Stylesheets warten muss und die Hauptinhalte sofort anzeigen kann
Warum sollte man es verwenden?
- Schneller wahrnehmbare initiale Ladezeit
- Verbesserte Lighthouse-Werte
- Bessere SEO und Nutzererfahrung
🔧 Anwendung
Schritt 1: Critical CSS inline einbinden
Schritt 2: Nicht essenzielles CSS verzögert laden (Standardmethode)
Schritt 3 (optional): Asynchrones Laden von Styles per JavaScript
- Nach Abschluss des Seitenladens wird per JavaScript nicht essenzielles CSS dynamisch geladen
- Kann die Performance bei langsamer Netzwerkgeschwindigkeit verbessern
- Alle
<link>-Tags für nicht essenzielles CSS müssen aus dem bestehenden <head> entfernt werden
window.addEventListener("DOMContentLoaded", function () {
console.log("✅ Page loaded, now loading non-critical stylesheets...");
let stylesheets = [
// "/css/vendors.min.css",
// "/css/style.min.css",
];
let loadedCount = 0;
function checkAllStylesLoaded() {
loadedCount++;
if (loadedCount === stylesheets.length) {
console.log("✅ All non-critical stylesheets loaded...");
}
}
stylesheets.forEach(function (href) {
var link = document.createElement("link");
link.rel = "stylesheet";
link.href = href;
link.onload = checkAllStylesLoaded;
link.onerror = () => console.warn(`Failed to load stylesheet: ${href}`);
document.head.appendChild(link);
});
});
1 Kommentare
Hacker-News-Kommentare
Wäre cool, wenn auch Responsive Design unterstützt würde. Ich habe am Ende immer wieder Stylesheets manuell angepasst, weil das Deduplizieren von responsive Critical Styles schwierig ist. Da die Größe von Critical CSS wichtig ist, wäre auch eine Option gut, Dinge wie CSS-Variablen downzukompilieren. Und den Rat, das
<link>-Tag für nicht-kritisches CSS direkt vor</body>zu platzieren, würde ich nicht empfehlen. CSS sollte so schnell wie möglich ankommen; so verzögert man die Erkennung von CSS und damit auch den Download. Stattdessen würde ich eine Kombination aus preload und noscript empfehlen:<link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'"><noscript><link rel="stylesheet" href="styles.css"></noscript>Ich frage mich, ob diese Methode mit JS-Code in preload nicht durch CSP blockiert wird, wenn unsafe-inline nicht erlaubt ist.
Ich möchte CSS nicht über JS-Hacks laden. Beim Anwenden eines Stylesheets kann für die ganze Seite eine Neuberechnung von Layout/Styles ausgelöst werden. Browser holen sich Stylesheets auch dann schnell, wenn sie erst weiter unten auf der Seite stehen.
Einen ähnlichen Effekt kann man auch nur mit dem prefetch-Attribut, HTTP-Header-Hints und einem CDN erreichen. Man muss Critical CSS nicht unbedingt ständig neu builden. Wenn man ein CDN wie CF richtig nutzt, ist es extrem schnell.
Klingt plausibel. Ich plane auch, so eine Option einzubauen. Ich habe statt „before body“ die Option „DOMCONTENTLOADED“ ausprobiert, und selbst auf alten Smartphones oder in langsamen Netzwerken funktioniert das für UX und Lighthouse ausreichend gut.
Stimme der Forderung nach Responsive-Unterstützung voll zu.
Meiner Meinung nach riecht das nach verfrühter Optimierung. Das ist vielleicht wertvoll, wenn CSS extrem komplex ist oder viele Ressourcen geladen werden, aber in den meisten Fällen ist es effizienter, CSS, HTML und JS sauber zu schreiben, und dieser Ansatz ist dann unnötig oder sogar kontraproduktiv.
Sehr nützlich. Ich arbeite als Freelancer oft an WordPress-Websites, bei denen CSS/JS nach mehreren Entwicklern oder Agenturen völlig chaotisch geworden ist. So ein Tool würde ich wirklich gern ausprobieren.
Je komplexer das CSS ist oder je mehr Ressourcen es gibt, desto kleiner wird eher der Nettoeffekt der Optimierung. Hier geht es um RTT-Latency-Optimierung, und je größer das Critical CSS wird, desto höher werden die Optimierungskosten und desto geringer der Nettogewinn.
Vor 12 Jahren hätte ich für so ein Tool bezahlt. Damals hatten wir riesige Mengen über Jahre angesammelten CSS, und es war schwer zu erkennen, welche Regeln kritisch sind.
Für viele Sites ist das sicher verfrühte Optimierung. Aber bei klicksensiblen Sites wie News/Medien ist „sofortiges“ Laden der Seite extrem wichtig. Schon ab etwas über 1 Sekunde steigen Absprungrate und sinken Werbeeinnahmen. HuffPost hat diese Optimierung schon vor 10 Jahren ausprobiert.
Wenn ich mir den aktuellen Zustand der Frontend-Entwicklung ansehe, wirkt das wirklich übertrieben. Tools wie Lighthouse bringen Leute dazu, sich auf Optimierung für bedeutungslose Zahlen zu versteifen. Das Ergebnis ist mehr Build-Komplexität, obwohl echte Nutzer den Unterschied nicht einmal merken, während die Entwicklung unbequemer wird. Gleichzeitig sehe ich ständig Sites mit ganz grundlegenden Fehlern bei UI oder State-Management. Frustrierend.
Sauberes css, html und js ist zwar die Antwort, aber manchmal übernimmt man eben ein chaotisches Projekt oder benutzt ein Template, und selbst wenn man alles selbst entwickelt, kann sich das Design verheddern.
Für mich ist die Art, wie CSS geladen wird, ein Punkt, den man schon in der ersten Entwicklungsphase zwingend berücksichtigen muss. Unsere Website verlor oft Clients wegen schlechter Page-Speed-Test-Werte. Da Performance in SEO einfließt, ist das enorm wichtig. Ich habe die Seitenoptimierung neu entworfen, um bei Google Lighthouse 100 Punkte zu erreichen. Die Reihenfolge und Art des Ladens von css/js muss man von Anfang an planen, damit man später weniger nacharbeiten muss. Wir haben CSS oberhalb und unterhalb des Folds getrennt und passend inline eingebunden, und JS unterhalb des Folds wird gar nicht evaluiert, bis gescrollt wird. Alles, was Lighthouse vorgeschlagen hat, haben wir übernommen. Das alte System lud auf jeder Seite das komplette Website-CSS (3–4 MB), bei JS war es noch schlimmer. Das lag daran, dass anfangs keine Optimierungsarchitektur vorgesehen war. Wir nutzen dieses System noch, deshalb kann ich den Namen nicht nennen, aber intern sorgt es weiter für Probleme. Wenn Performance das Ziel ist, gibt es meiner Meinung nach keine verfrühte Optimierung. Man muss alles von Anfang an bedenken. Dadurch erreichen wir bei allen Clients einschließlich Mobilgeräten 100 Punkte Performance und haben auch gegenüber Wettbewerbern einen Vorteil. Ich habe dieses Tool auf meiner Site ausprobiert, aber es gab keinen Effekt, weil praktisch nichts mehr zu optimieren war.
Bei meiner mit dem Astro-Framework gebauten Seite sind es HTML 27.52KB (komprimiert 6.1KB), JS unter 10KB und Critical CSS 57KB (komprimiert 7KB). Ähnliche Sites liegen bei 100KB bis 1MB. Wenn man sauber baut, ist es auch ohne Inline-CSS/JS mit Resource Hints schnell genug. Mit nginx + HTTP/2 + Edge Cache sind 100/100 Performance auch ohne Critical CSS/Inline-JS möglich. Zusätzliche 7KB pro Seite wirken nicht gerade effizient. Architektonisch sind SPA/Edge Caching viel sinnvoller, schneller und umweltfreundlicher. Es gibt keinen Grund, unnötig schweres HTML wie bei Elementor zu übertragen. Mobile Geräte haben begrenzten Akku, warum also unnötige Daten schicken?
Netter Trick, aber in einer Welt, in der CDN und HTTP/2 ohnehin weit verbreitet sind, verschwendet diese Optimierung am Ende nur Bandbreite. Benchmark-Zahlen werden leicht besser, in der Praxis sind es vielleicht 10–20 ms.
Critical CSS auf jeder Seite einzubetten ist nicht unbedingt die richtige Antwort. Man kann es selektiv nur beim ersten Besuch (ohne Cache) oder auf der Einstiegsseite einer Session einsetzen, um unnötigen Data Bloat zu vermeiden.
Auf Wunsch eines Kunden habe ich nach einem Tool zum Extrahieren von Critical CSS gesucht, aber keines hatte die Funktionen, die ich wollte. Deshalb teile ich jetzt meine eigene Lösung mit Puppeteer. Man kann angeben, wie lange nach dem Laden der Seite gewartet werden soll. Ich habe auch kostenpflichtige Dienste ausprobiert, war aber unzufrieden und habe mir das Geld zurückerstatten lassen. Feedback ist willkommen, und im Moment ist es kostenlos offen verfügbar.
Mich würde interessieren, ob bestehende Tools wie das Paket penthouse das Problem waren.
Wenn man eine Site ohne CSS eingibt, gibt es einen Fehler.
Ist der Code offen verfügbar? Ich würde es auch gern als Vite-/Astro-Plugin verwenden.
Ich würde gern wissen, ob es eine UI-Version von penthouse ist. Viele Einstellungen wirken sehr ähnlich.
Diese Methode hat eher den gegenteiligen Effekt. Es kommt zu einem sehr konsistenten FOUC (kurzes Aufblitzen ohne angewendete Styles). Wenn sich das Layout mittendrin verändert, ist das für Nutzer, die gerade schon irgendwo klicken, eine große Unannehmlichkeit. Das ist nicht nur ein ästhetisches Problem, sondern ein echtes Usability-Problem.
Ich habe nach Einsatz dieser Methode zwar auch einige Styles angepasst, konnte aber am Ende trotzdem auf CLS (Cumulative Layout Shift) 0 optimieren. Bei kleinem Budget und Templates mit vielen Libraries war das sehr nützlich.
Ist nicht genau das ursprüngliche Ziel, FOUC zu vermeiden, ohne CSS-Network-Requests zu blockieren?
Dieser Ansatz ist vor allem unter der Annahme sinnvoll, dass beim ersten Seitenaufruf überhaupt kein CSS-Cache vorhanden ist. In der Praxis gibt es Trade-offs zwischen dem Verhältnis neuer zu wiederkehrenden Nutzern, CSS-Cache-Einstellungen, CDN, 103 Early Hints, Critical CSS/initial congestion window und verschiedenen anderen Faktoren.
Bei Performance-Messungen auf localhost war der Einfluss von CSS praktisch nicht vorhanden. Selbst wenn man CSS komplett entfernt, verbessert sich die Zeit um weniger als 7 ms, und selbst das liegt noch im Bereich des Messfehlers.
Als ich dieses Tool auf meiner Site verwendet habe, wurden sogar Debugging-Elemente in das CSS extrahiert, die eigentlich gar nicht nötig waren. Zum Beispiel wurde
body::afterfür ein Grid-Overlay der Site einfach mit ins CSS aufgenommen. (Ich hatte das vergessen und es dadurch jetzt erst bemerkt.)Ich bevorzuge eine Art, HTML zu schreiben, bei der der Inhalt auch ohne CSS gut verständlich ist. So kann man verhindern, dass die Dokumentstruktur von vornherein zu komplex wird.
Die Idee selbst ist frisch, deshalb habe ich sie auf meiner persönlichen Site ausprobiert, aber in der penthouse-Bibliothek trat ein CSS-Auslassungsfehler auf:
{"error":true,"name":"Error","message":"css should not be empty" ...}