Render-blocking requests in Lighthouse: so behebst du sie

Schaden render-blocking Requests meinem Score?

Lighthouse listet im Insight „Render-blocking requests“ („Requests are blocking the page's initial render, which may delay LCP“ – vor Lighthouse 13: „Eliminate render-blocking resources“) jedes Stylesheet und Skript auf, auf das deine Seite vor dem ersten Paint gewartet hat. Der Insight fließt nicht in deinen Score ein. Aber solange die Seite auf ihr CSS und ihre Skripte wartet, bleibt sie weiß. Das verzögert FCP und LCP, besonders auf dem Smartphone. Bereinige und bündle dein CSS und lade Skripte per defer.

Was prüft der Insight „Render-blocking requests“?

Lighthouses Beschreibung lautet: „Requests are blocking the page's initial render, which may delay LCP. Deferring or inlining can move these network requests out of the critical path.“ Inlining ist nicht die Lösung: siehe unten. Die Tabelle hat drei Spalten: URL, Transfer Size und Duration. Transfer Size ist die komprimierte Datei, wie sie übertragen wurde. Duration ist Lighthouses Schätzung, wie lange der Request auf einem langsamen Smartphone dauert – inklusive einer neuen Verbindung zu einer anderen Domain.

Beim Laden einer Seite markiert Chrome jeden Request als render-blocking oder nicht und schreibt das in seinen Trace. Lighthouse liest den Trace aus und listet jeden Request im Main Frame auf, den Chrome als blockierend markiert hat und der vor dem ersten Paint abgeschlossen war. In der Praxis sind das die Stylesheets und synchronen Skripte im <head> sowie die Dateien, die sie per @import nachladen. Ein Stylesheet im Body zählt nur bei Chromes höchster Priorität, ein Skript bei hoher Priorität. Nach dem ersten Bild sinkt die Priorität beider ab und Lighthouse überspringt sie. Es gibt keinen Schwellenwert: Schon eine gelistete Datei reicht, damit der Insight fehlschlägt.

Manche Dateien tauchen hier nie auf, selbst wenn sie die Seite verlangsamen: Async-Skripte, Dateien, die ein Skript nachträglich einfügt (gtm.js, gtag.js), Inline-Styles und -Skripte, alles in einem iframe sowie Fonts.

Der Insight auf einer WooCommerce-Produktseite, Lighthouse 13.5.0, simuliertes Throttling wie in PageSpeed Insights.

Was macht eine Datei render-blocking?

Render-blocking bedeutet: Der Browser rendert nichts, bis diese Datei da ist. Jedes Stylesheet im <head> muss ankommen und jedes synchrone Skript dort muss heruntergeladen und ausgeführt werden.

• Ein Skript nach einem Stylesheet wartet auf dieses Stylesheet. Chrome führt ein synchrones Skript erst aus, wenn das CSS darüber da ist. Und der Parser wartet auf das Skript. Beide Dateien können parallel herunterladen, trotzdem zahlst du zuerst für das CSS und dann für das Skript.
• Ein @import startet spät. Chromes Preload-Scanner findet jeden Link im HTML sofort. Ein @import in einer CSS-Datei findet er aber erst, wenn diese Datei geladen ist. Auf der Produktseite unten startete das importierte Theme-Stylesheet bei 1,28 s – gegenüber 0,59 s bei einer Verlinkung direkt im HTML.
• Eine andere Domain kostet eine eigene Verbindung. Ein Stylesheet auf fonts.googleapis.com oder einem CDN braucht DNS, TCP und TLS, bevor sein erstes Byte ankommt.

Beeinflussen render-blocking Requests FCP und LCP?

Ich habe das auf einer WooCommerce-Produktseite mit neun Stylesheets und zwei Skripten im Head gemessen – auf einem Smartphone über Slow 4G. In der optimierten Version ist das CSS bereinigt und in einem einzigen Stylesheet mit 6,6 kB zusammengefasst, beide Skripte sind auf defer gesetzt. Einmal geladen sieht die Seite exakt gleich aus.

FCP

Das Original hatte seinen ersten Paint bei 2,12 s, die optimierte Version bei 1,39 s.

Beide Versionen bei 1,4 s auf dem gedrosselten Smartphone: Das Original ist noch weiß.

LCP

Der LCP kann nicht vor dem ersten Paint liegen. Hier ist das LCP-Element das Produktfoto, und auch das kann erst erscheinen, wenn das CSS da ist: Der LCP sank durch den Fix von 2,25 s auf 1,91 s. In einer LCP-Aufschlüsselung taucht diese Wartezeit als Element Render Delay auf. Lighthouse zeigt das nicht: Ist das LCP-Element ein Bild, schätzt Lighthouse die LCP-Ersparnis immer auf 0 ms. Deute das nicht als fehlenden Einfluss auf den LCP.

Wie viele Websites sind betroffen und kann man das ignorieren?

Fast alle. State of CWV prüft die Startseiten von 114.526 Websites mit CrUX-Daten: 92,8 % haben mindestens einen render-blocking Request, 91,2 % ein blockierendes Stylesheet und 62,5 % ein blockierendes Skript. Wenn vorhanden, liegt der Median bei 8 Requests und 110 kB. Jede fünfte Website hat mehr als 20. (State of CWV zählt Stylesheets und synchrone Skripte im Head – das deckt sich weitgehend mit Lighthouses Liste.)

Websites mit vielen blockierenden Requests schneiden im Feld schlechter ab. 84,0 % der Websites ohne solche Requests erreichen einen guten FCP auf Smartphones – gegenüber 54,1 % bei Websites mit mehr als 20. Doch der Server erklärt den Großteil dieses Einbruchs: Im selben Bereich verdoppelt sich die mediane TTFB von 538 ms auf 1.114 ms. Aufgeteilt nach Servergeschwindigkeit:

Websites mit gutem FCP auf Smartphones nach Anzahl der render-blocking Requests und Server-Antwortzeit. State of CWV, Oktober 2026, CrUX-p75 auf Smartphones, ein guter FCP liegt bei 1,8 s oder weniger.

• Schneller Server (TTFB unter 600 ms): 94 bis 97 % erreichen einen guten FCP, unabhängig von der Anzahl. Die Verzögerung bleibt trotzdem: Vom ersten Byte bis zum ersten Paint dauert es mit 21 oder mehr blockierenden Requests etwa 150 bis 200 ms länger als ohne.
• Langsamer Server (TTFB ab 900 ms): Der Anteil mit gutem FCP bricht von rund der Hälfte der Websites (47 bis 53 %) bei bis zu zwei blockierenden Requests auf 30 % bei 21 oder mehr ein. Bei einer TTFB ab 900 ms bleiben weniger als 0,9 s bis zum Grenzwert von 1,8 s für einen guten FCP. Jeder zusätzliche Request, auf den der Paint wartet, kann den FCP über die Schwelle drücken.

WordPress-Websites haben mehr davon: 57 % haben 16 oder mehr blockierende Requests (Median: 19, 163 kB). Bei gleicher Servergeschwindigkeit kostet das gegenüber ein bis fünf Requests auf einem schnellen Host 3 Prozentpunkte beim guten FCP – und rund 10 Prozentpunkte auf einem langsamen.

Das ist eine Korrelation, aber sie gibt die Reihenfolge vor: Bei einer langsamen TTFB optimierst du zuerst den Server. Auf einem schnellen Server lohnt es sich trotzdem, die 150 bis 200 ms mitzunehmen, wenn es dein eigenes CSS ist. Den Hinweis kannst du ignorieren, wenn:

• Lighthouse nur ein oder zwei kleine eigene Stylesheets auflistet, jedes unter etwa 15 kB;
• die gelistete Datei ein Consent-Tool, ein A/B-Testing-Snippet oder eine Plattform-Datei ist, die du nicht ändern kannst (siehe unten).

Wie erkennst du render-blocking Requests in deinen Felddaten?

Lighthouse lädt deine Seite einmal mit leerem Cache. Nach dem ersten Aufruf haben deine Besucher das CSS im Cache. Im Feld zeigen sich die Kosten daher vor allem bei der ersten Seite, die ein Besucher aufruft. Achte in CoreDash mobil auf zwei Dinge:

• FCP im Vergleich zur TTFB. Render-blocking Dateien kosten Zeit zwischen dem ersten Byte und dem ersten Paint. Ein Template, bei dem dieser Abstand größer ist als bei anderen, lädt mehr davon.
• LCP Render Delay. Halte nach Templates Ausschau, bei denen der Render Delay einen großen Teil des LCP ausmacht. Blockierendes CSS ist eine Ursache für diese Wartezeit. Die DevTools (nächster Abschnitt) zeigen, ob die Seite solches CSS enthält.

CrUX liefert dieselben Metriken als p75 für deinen Origin oder eine URL – verrät dir aber nicht, welches Template langsam ist.

CoreDash für einen Beispielshop, acme-pagespeed.com, mobil, p75: Die Produkt- und Kategorieseiten sind die langsamen.

Wie findest du die blockierenden Dateien in den DevTools?

Öffne die Seite in Chrome, wechsle ins Performance-Panel, stelle das Netzwerk auf Slow 4G sowie die CPU auf 4x Slowdown und zeichne einen Reload auf. Die Insights-Seitenleiste listet „Render-blocking requests“ auf. Klicke darauf, und die DevTools heben jeden blockierenden Request in der Network-Spur hervor.

Jeder Balken reicht vom Start des Requests bis zum Eintreffen seines letzten Bytes. Suche nach dem Request, der als letzter vor der FCP-Markierung endet: Auf genau diesen hat der Paint gewartet. Ein CSS-Request, der erst startet, wenn ein anderer endet, ist ein @import. Wenn nichts blockiert, meldet die Seitenleiste: „No render-blocking requests for this navigation“.

Wie behebst du render-blocking Requests?

Die URL in der Lighthouse-Tabelle verrät dir, woher jede Datei stammt. Das bestimmt, an welcher Stelle du ansetzen musst.

Eigenes CSS und eigene Skripte

Ziele in deinen eigenen Templates auf diesen Head ab: ein einziges kleines, bereinigtes Stylesheet und alle Skripte auf defer. Dann wartet der erste Paint nur noch auf diese eine Datei.

<link rel="stylesheet" href="/css/main.min.css">
<script src="/js/jquery.min.js" defer></script>
<script src="/js/gallery.min.js" defer></script>

Wie du dorthin kommst, erfährst du weiter unten ab CSS bereinigen und bündeln.

WordPress

Dateien unter /wp-content/plugins/ gehören zu einem Plugin, /wp-content/themes/ zu deinem Theme und /wp-includes/ zu WordPress selbst.

Wenn du keinen Code schreibst, nutze ein Optimierungs-Plugin mit diesen Einstellungen:

• Aktiviere das Deferring für Skripte: „Load JavaScript deferred“ in WP Rocket, „Defer JavaScript“ in Perfmatters, „Load JS Deferred“ in LiteSpeed Cache. Ein verzögertes Skript blockiert den ersten Paint nicht mehr. Bei jQuery ist Vorsicht geboten, siehe unten.
• Lass „Load CSS Asynchronously“ und Critical CSS deaktiviert – ganz egal, was der alte WordPress-Tipp unter diesem Insight über Plugins erzählt, die „critical assets inlinen“. Critical CSS funktioniert zwar, aber der Rest des CSS kommt erst nach dem ersten Paint an. Die Seite stylt sich dadurch zweimal um und springt oft. Was Inlining zusätzlich kostet, steht unter CSS bereinigen und bündeln.
• Lass „Remove Unused CSS“ deaktiviert („Generate UCSS“ in LiteSpeed Cache). Die Funktion generiert für jede URL ein eigenes CSS (WP Rocket packt es inline ins HTML) und behält nur die Regeln, die beim ersten Laden auf der Seite zu sehen sind. Ändert ein Skript später ein Element (ein geöffnetes Menü, einen Slider), fehlen oft die Styles. WP Rocket hat einen eigenen Guide für die Darstellungsfehler, die das erzeugt. Das bringt mehr Ärger als Nutzen: Bereinige und bündle die Stylesheets lieber selbst. Das macht mehr Arbeit, zahlt sich aber aus.

Viele Plugins laden ihr CSS auf jeder Seite – auch dort, wo sie gar nicht gebraucht werden: Contact Form 7 auf Seiten ohne Formular, WooCommerce außerhalb des Shops. Jedes Stylesheet, das WordPress ausgibt, hat eine ID wie contact-form-7-css. Der Teil vor -css ist das Handle, mit dem du es überall dort entfernst, wo es überflüssig ist:

add_action( 'wp_enqueue_scripts', function () {
  if ( ! is_page( 'contact' ) ) {
    wp_dequeue_style( 'contact-form-7' );
  }
}, 20 );

WooCommerce bietet für seine drei Stylesheets einen eigenen Filter: woocommerce_enqueue_styles. Für eigene Skripte kann WordPress ab Version 6.3 defer direkt hinzufügen:

wp_enqueue_script( 'acme-gallery', get_stylesheet_directory_uri() . '/js/gallery.min.js', array( 'jquery' ), '2.3.0', array( 'strategy' => 'defer' ) );

WordPress entfernt dieses defer ohne Warnung wieder, wenn ein abhängiges Skript noch blockiert oder danach ein Inline-Skript folgt. Prüfe deshalb den Script-Tag im Quelltext.

Setze jQuery nur mit einem Tool auf defer, das auch die inline platzierten jQuery(...)-Aufrufe abfängt. WordPress registriert jQuery ohne defer. Sobald etwas davon abhängt, blockiert es den Head. Fügst du defer manuell hinzu, bricht jeder Inline-Aufruf von jQuery(...) ab, der davor ausgeführt wird. „Load JavaScript deferred“ von WP Rocket verzögert jQuery und fängt diese Inline-Aufrufe ab. Perfmatters' „Defer JavaScript“ klammert jQuery aus, bis du „Include jQuery“ aktivierst. Klicke dich danach durch die Seite (Menü, Galerie, Warenkorb) und prüfe, ob noch alles funktioniert.

Ein Child-Theme, dessen style.css mit @import url("../storefront/style.css") beginnt, baut eine @import-Kette auf. Entferne diese Zeile und lade das übergeordnete Stylesheet stattdessen mit wp_enqueue_style.

Shopify

Apps binden ihre Dateien über App-Embeds ein (Onlineshop, Theme anpassen, App-Einbettungen). Die Skriptdatei eines Embeds lädt asynchron (außer sein Liquid-Code schreibt einen eigenen Script-Tag), sein Stylesheet blockiert. Deaktiviere Embeds, die du nicht brauchst. Und suche nach der Deinstallation einer App in theme.liquid und den Snippets nach übrig gebliebenem Code.

Themes laden ihr CSS über den Filter stylesheet_tag in theme.liquid, der einen blockierenden Link erzeugt. Für das eine Basis-Stylesheet ist das in Ordnung. Der Filter script_tag erzeugt ein Skript ohne defer – schreibe diesen Tag deshalb selbst:

<!-- blocks the first paint -->
{{ 'gallery.js' | asset_url | script_tag }}

<!-- doesn't -->
<script src="{{ 'gallery.js' | asset_url }}" defer></script>

Shopify sendet bereits 103 Early Hints für bis zu 10 render-blocking Dateien im Head. Diese Dateien starten also ohnehin früh. Was du beeinflussen kannst, ist ihre Anzahl und Größe. Rechne damit, dass das Stylesheet für den beschleunigten Checkout auf der Liste bleibt (siehe unten).

Next.js

Im App Router wird jeder CSS-Import zu einem Stylesheet-Link ganz oben im Head – und React rendert erst, wenn dieser geladen ist. Next.js fasst sie in wenigen Chunks zusammen. Die Lösung lautet daher: weniger CSS. Verlagere CSS, das nur einzelne Routen brauchen, aus dem globalen CSS in CSS Modules: Globales CSS aus dem Root-Layout landet auf jeder Route, ein CSS Module nur auf Routen, die es auch importieren. Mehr dazu unter wie Next.js seine CSS-Dateien baut.

Next.js lädt seine eigenen Skripte asynchron oder per defer. Ein blockierendes Skript auf einer Next.js-Website hat fast immer jemand manuell ins Layout eingefügt. Binde es stattdessen über next/script ein. Das lädt standardmäßig erst, wenn Next.js mit der Hydration der Seite begonnen hat:

import Script from 'next/script'

<Script src="https://example.com/widget.js" strategy="afterInteractive" />

Google Fonts und andere Domains

Der Link zu Google Fonts ist ein blockierendes Stylesheet auf fonts.googleapis.com, und die Schriftdateien stammen von einer zweiten Domain, fonts.gstatic.com. Lighthouse hat dieser 0,5 kB kleinen Datei die längste Duration zugewiesen: Es rechnet den neuen Verbindungsaufbau ein. Hoste die Schriften selbst und binde die @font-face-Regeln in dein eigenes Stylesheet ein – schon sind der Request und beide Verbindungen Geschichte. Unter Next.js übernimmt next/font das bereits automatisch.

Consent-Tools, A/B-Tests und andere Dateien, die du in Ruhe lässt

• Ein Consent-Tool mit Autoblocking (Cookiebot, OneTrusts OtAutoBlock, der Usercentrics-Autoblocker): Es muss vor jedem anderen Skript laufen, um es blockieren zu können. Es ist also absichtlich synchron. Die Alternative ist der manuelle Modus, in dem du jedes Cookie-Skript selbst auszeichnest. Ob sich dieser Aufwand lohnt, ist vor allem eine rechtliche Frage. Ein Preconnect zur Domain des Tools baut die Verbindung immerhin frühzeitig auf.
• Ein A/B-Testing-Snippet (Optimizely, AB Tasty, Convert): bewusst synchron, damit Besucher nicht kurz das Original aufblitzen sehen, bevor die Variante lädt. Entferne es, wenn kein Test aktiv ist.
• Shopifys content_for_header: Jedes Theme braucht diesen Tag und du kannst ihn nicht bearbeiten. In allen fünf für diesen Artikel geprüften Shops fügte er ein blockierendes Stylesheet für den beschleunigten Checkout hinzu: accelerated-checkout-backwards-compat.css. Lass es einfach stehen.

CSS bereinigen und bündeln

Beschränke das render-blocking CSS auf wenige Stylesheets, jedes komprimiert unter etwa 15 kB. 15 kB ist ungefähr das, was eine neue Verbindung im ersten Roundtrip liefert.

Sechs render-blocking Stylesheets über Slow 4G im Network-Panel der DevTools. Grün ist die Wartezeit auf das erste Byte – bei jeder Datei gleich. Blau ist der Download, der mit der Dateigröße wächst.

• Fasse die winzigen Dateien zusammen, die Theme und Plugins einfügen. Jedes Stylesheet wartet einen kompletten Roundtrip, bis sein erstes Byte eintrifft – über Slow 4G rund 0,6 s, völlig unabhängig von der Größe. Eine 0,3 kB kleine Datei zahlt diese volle Wartezeit für fast nichts.
• Kürze oder teile eine große Datei. Nach derselben Wartezeit war die 14-kB-Datei 0,4 s später geladen. Die 60-kB-Datei brauchte noch eine weitere Sekunde für den Download – und die Seite blieb weiß, bis sie da war.
• Entferne CSS-Regeln, die die Seite nicht nutzt. Der Coverage-Tab in den DevTools zeigt für jede Datei, wie viel CSS die Seite niemals verwendet. Bei der typischen Website sind das im Median 89 % (State of CWV, Chromes Coverage-Messung der Startseite).
• Pack nicht das gesamte CSS in eine einzige riesige Datei. Das gesamte CSS unbereinigt in einer einzigen 68-kB-Datei hatte seinen ersten Paint später als mit den neun separaten Dateien. Die große Datei teilte sich die Bandbreite mit den verzögerten Skripten und dem Hero-Bild, während bei neun Dateien die render-blocking Requests den Großteil der Bandbreite bekamen.
• Binde CSS nicht inline ein. Inline-CSS landet im HTML, und das HTML ist die erste Datei, die der Browser braucht: Alles andere wartet darauf. Inlining macht genau die Datei größer und langsamer, auf die alles wartet. Noch wichtiger: Der Browser kann das HTML meist nicht cachen. Jeder Seitenaufruf lädt dieses CSS also erneut herunter, während ein separates Stylesheet nach der ersten Seite im Cache liegt. Unter Websites mit einer TTFB unter 900 ms und ein bis fünf blockierenden Requests haben 95,9 % der Websites ohne Inline-CSS einen guten FCP – gegenüber 90,8 % bei denen, die mehr als 300 kB inline einbinden (State of CWV).
• Lagere „den Rest“ des CSS nicht zum späteren Nachladen aus. Der alte Trick mit media="print" funktioniert nur für CSS, das garantiert nie im ersten Viewport auftaucht. Das weißt du selten für jede Seite und jede Bildschirmgröße: Liegst du falsch, rendert die Seite zuerst komplett ungestylt.

Ersetze jedes @import

Gib jeder importierten Datei einen eigenen Link im HTML oder binde sie direkt in die übergeordnete Datei ein. Das Entfernen von @import auf der Produktseite zog den ersten Paint um 137 ms nach vorne, sobald die Skripte auf defer gesetzt waren. Solange die Skripte noch blockierten, brachte es 33 ms: jQuery traf etwa zeitgleich mit dem importierten Stylesheet ein, der Paint wartete also so oder so auf jQuery.

Skripte per defer laden

Füge jedem Skript im Head, das der erste Paint nicht zwingend braucht, ein defer hinzu. Modul-Skripte sind ohnehin schon deferred. async nimmt ein Skript zwar ebenfalls von der Liste, es kann aber trotzdem vor dem ersten Paint laufen und den Main Thread blockieren. defer ist daher der bessere Standard. Skripte machen heute den kleineren Teil dieses Insights aus: Beide Skripte auf defer zu setzen brachte 24 ms, weil das CSS ohnehin länger brauchte. Mehr dazu unter async vs. defer, Head- vs. Footer-JavaScript und 14 Methoden, JavaScript per defer zu laden.

Haupt-Stylesheet mit 103 Early Hints frühzeitig starten

Mit 103 Early Hints teilt der Server dem Browser mit, welche Dateien er abrufen soll, noch während der Server das HTML generiert. Sende einen Hint für dein Haupt-Stylesheet:

HTTP/2 103
link: </css/main.min.css>; rel=preload; as=style

Das lohnt sich, wenn dein Server Zeit braucht, um die Seite zu bauen. Das Stylesheet lädt währenddessen herunter. Der Gewinn entspricht also maximal der Rechenzeit deines Servers. Eine Seite aus dem CDN-Cache profitiert kaum. Cloudflare bietet dafür einen Schalter (Speed, Settings, Content Optimization) und generiert die Hints aus den Link-Headern deines Servers. Apache beherrscht H2EarlyHint ab Version 2.4.58.

Prüfe danach den LCP. Wenn das CSS früher da ist, starten auch die darin definierten Fonts früher: Auf der Produktseite nahm der 156 kB große Font-Awesome-Font dem Produktfoto Bandbreite weg, und der LCP trat später ein. Lighthouse behält die per Hint gemeldete Datei trotzdem auf seiner Liste, mit 0,0 KiB. Mehr zu 103 Early Hints und warum ein einfaches Preload eines ohnehin verlinkten Stylesheets nichts bringt.

Verzichte auf fetchpriority="low" bei Stylesheets

Ein häufiger Tipp lautet, CSS, das nicht für den ersten Viewport gebraucht wird, mit fetchpriority="low" zu versehen. Das ist ein Anti-Pattern. Im Head stuft Chrome dieses Stylesheet lediglich um eine Stufe herab – von höchster auf hohe Priorität – und wartet vor dem ersten Paint trotzdem darauf. Lighthouse entscheidet in seiner Simulation anhand der Priorität, was blockiert. Es behandelt die Datei deshalb so, als wäre sie gar nicht da: keine Duration und ein schnellerer simulierter FCP.

Ich habe das an vier Stylesheets getestet. Lighthouse senkte den FCP bei simulierter Drosselung von 2,0 s auf 1,60 s und steigerte den Score von 96 auf 97. In Chrome verschob sich der erste Paint von 2.122 ms auf 2.114 ms. Deine Besucher warten also genauso lange wie zuvor.

In dem Moment, den Lighthouse als FCP ausweist, zeigt Chrome immer noch einen weißen Bildschirm.

Wie prüfst du, ob der Fix funktioniert hat?

Lass Lighthouse mobil noch einmal laufen. Nach dem Fix stieg der Score von 96 auf 100 und der simulierte FCP sank von 2,0 s auf 1,1 s. Der Insight wechselte von Rot mit zwölf Dateien auf Orange mit einer einzigen: dem 6,6-kB-Stylesheet.

Lighthouse 13.5.0, mobil, simuliertes Throttling.

Miss dreimal und nimm den mittleren Wert: Auf derselben Seite wich der simulierte FCP zwischen den Durchläufen um 1,5 s ab.

CoreDash zeigt den FCP und den LCP Render Delay ab den nächsten Besuchen an. CrUX und Search Console bilden die letzten 28 Tage ab – zwei Wochen nach dem Fix stammt die Hälfte ihrer Daten also noch von der alten Seite.

Willst du wissen, ob blockierendes CSS deinen mobilen FCP oder LCP rot hält? In einer Core-Web-Vitals-Power-Hour schauen wir uns deine Felddaten und einen Trace deiner Seite gemeinsam an – und du weißt genau, welche Dateien du bereinigen, bündeln oder auf defer setzen musst.