Neu gemessen und neu geschrieben am 17. September 2026
Die April-Fassung dieser Studie behauptete, nur 1 von 48 DACH-Medien bestehe die Core Web Vitals auf dem Smartphone. Das war aus zwei Gründen falsch. Erstens beruhte sie auf einem einzigen Lighthouse-Laborlauf pro Seite, die Core Web Vitals werden aber anhand von Felddaten echter Chrome-Nutzer bewertet. Zweitens lieferte die einzige Seite, die als bestanden galt, puls24.com, zu dem Zeitpunkt eine Cloudflare-Fehlerseite aus. Außerdem erklärte der April-Text die Werte mit Tech-Stack- und Werbe-Details, die gar nicht gemessen worden waren. Ich habe alle 50 Seiten mit Labor- und Felddaten neu gemessen, und das Ergebnis zeigt in die andere Richtung.
Die meisten großen Nachrichtenseiten in Deutschland, Österreich und der Schweiz bestehen die Core Web Vitals. Am 17. September 2026 erfüllten 36 der 47 messbaren Seiten auf dem Smartphone alle drei Grenzwerte, laut Chrome-UX-Report-Daten echter Nutzer. Die PageSpeed-Laborwerte erzählen etwas ganz anderes: Der Median-Score auf Mobilgeräten liegt bei 52, und nur eine Seite schafft 90.
Das ist die dritte Studie der DACH-Medien-Reihe. Studie 1 hat untersucht, welche KI-Crawler Verlage in der robots.txt sperren. Studie 2 hat gemessen, wie viel Inhalt erst nach JavaScript erscheint. Diese hier schaut sich an, wie schnell die Seiten sind, und warum die zwei Messarten dabei so weit auseinanderliegen.
Die Zahlen: 36 von 47 bestehen
47 DACH-Nachrichtenseiten, Labor- und Felddaten.
PageSpeed Insights für Mobilgeräte und Desktop, 50 Verlage. Drei lieferten meinem Skript keine funktionierende Seite (puls24.com, zeit.de, tagesanzeiger.ch). Bestanden heißt: Das 75. Perzentil der Origin erfüllt alle drei Core Web Vitals, also LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1.
Das Muster ist eindeutig: Echte Nutzer bekommen überwiegend schnelle Seiten, während ein gedrosselter Laborlauf derselben Startseite langsam aussieht. Die Seiten, die im Feld durchfallen, scheitern nicht an der Ladezeit. Keine verfehlt mobil den LCP. Sie scheitern an der Reaktionszeit (INP) oder an der Layout-Stabilität (CLS).
Labor-Score gegen Felddaten: Warum sie sich widersprechen
PageSpeed Insights zeigt auf einer Seite zwei Arten von Daten, und die messen Unterschiedliches.
Felddaten stammen aus dem Chrome UX Report (CrUX). Sie werden bei echten Chrome-Nutzern über die letzten 28 Tage gesammelt und als 75. Perzentil angegeben. Für diese Studie habe ich die Werte auf Origin-Ebene genommen, die alle Seiten einer Domain abdecken, nicht nur die Startseite. Googles Bewertung der Core Web Vitals beruht auf diesen Daten.
Labordaten stammen aus einem einzigen Lighthouse-Lauf. Für Mobilgeräte emuliert Lighthouse ein Mittelklasse-Smartphone mit gedrosselter CPU und langsamer 4G-Verbindung und lädt eine URL mit leerem Cache. Der Performance-Score (0 bis 100) wird nur aus diesem Lauf berechnet.
Bei Nachrichtenseiten liegen diese zwei Situationen weit auseinander. Viele Leser kommen mehrmals am Tag wieder, die Dateien sind also schon im Cache. Viele nutzen aktuelle Smartphones mit schneller Verbindung. Ein Laborlauf hat nichts davon, und eine gedrosselte CPU braucht lange für Skripte von Drittanbietern, bevor das größte Element angezeigt wird. So kommt br.de im Labor auf einen LCP von 39,5 Sekunden und beim 75. Perzentil der echten Besucher auf 1,3 Sekunden.
Keine der beiden Zahlen ist falsch. Der Laborwert hilft, Bremsen auf einer Seite zu finden und Änderungen vor dem Release zu vergleichen. Aber ein Laborscore von 35 heißt nicht, dass eine Seite die Core Web Vitals verfehlt, und 97 heißt nicht, dass sie besteht. derstandard.at hat den besten mobilen Laborscore der Stichprobe und fällt im Feld trotzdem durch, weil echte Nutzer zu viel Layout-Verschiebung sehen.
Wer durchfällt und woran
Elf Seiten fallen mobil bei den Core Web Vitals durch. Keine davon wegen des LCP.
- Sechs scheitern nur am INP: zdf.de (260 ms), 20min.ch (445 ms), faz.net (244 ms), stern.de (214 ms), tt.com (204 ms) und merkur.de (203 ms). Die letzten drei liegen knapp über der 200-ms-Grenze.
- Drei scheitern nur am CLS: nzz.ch (0,59), derstandard.at (0,20) und taz.de (0,14).
- Zwei scheitern an beidem: kleinezeitung.at (INP 239 ms, CLS 0,13) und sn.at (INP 244 ms, CLS 0,11).
Auf dem Desktop verschiebt sich das Bild zur Layout-Verschiebung. Dort verfehlen 15 Seiten den CLS-Grenzwert, darunter spiegel.de, handelsblatt.com und wdr.de mit 0,90. INP ist auf dem Desktop kaum ein Thema, nur 20min.ch liegt drüber. Zwei Seiten verfehlen den Desktop-LCP: handelsblatt.com mit 3,0 s und kleinezeitung.at mit 4,0 s.
Warum eine bestimmte Seite hohe INP- oder CLS-Werte hat, kann ich aus diesen Daten nicht ablesen. PageSpeed Insights ordnet Felddaten keinen Skripten oder Elementen zu. Dafür braucht ein Verlag eigenes Real-User-Monitoring oder einen genauen Blick auf seine Templates. Die Daten zeigen aber, wo man suchen sollte: bei diesen Seiten bei Interaktion und Layout, nicht beim ersten Laden.
Deutschland, Österreich und die Schweiz im Vergleich
| Land | Gemessene Seiten | CWV bestanden (mobil) | Median-Laborscore (mobil) |
|---|---|---|---|
| Deutschland | 24 | 19 | 53 |
| Österreich | 17 | 13 | 50 |
| Schweiz | 6 | 4 | 36 |
Die Quoten liegen nah beieinander: 79 % in Deutschland, 76 % in Österreich, 67 % in der Schweiz. Bei nur sechs gemessenen Schweizer Seiten sagt dieser Abstand wenig. Nach Art des Mediums bestehen mobil alle fünf Wirtschaftstitel, alle drei Tech-Seiten und sechs von sieben öffentlich-rechtlichen Sendern. Am schlechtesten schneiden Regionalzeitungen ab: nur eine von vier besteht.
Alle 47 Seiten
Mobile Werte, sortiert nach Laborscore. LCP, INP und CLS sind das 75. Perzentil der Origin laut CrUX.
| Seite | Labor | LCP | INP | CLS | CWV |
|---|---|---|---|---|---|
| derstandard.at | 97 | 1,0 s | 106 ms | 0,20 | ✗ |
| wienerzeitung.at | 83 | 1,1 s | 121 ms | 0,00 | ✓ |
| golem.de | 80 | 1,1 s | 119 ms | 0,03 | ✓ |
| heise.de | 77 | 1,6 s | 81 ms | 0,00 | ✓ |
| welt.de | 73 | 1,5 s | 195 ms | 0,05 | ✓ |
| wdr.de | 73 | 1,6 s | 101 ms | 0,00 | ✓ |
| wiwo.de | 73 | 1,4 s | 137 ms | 0,04 | ✓ |
| ndr.de | 67 | 1,3 s | 80 ms | 0,00 | ✓ |
| zdf.de | 66 | 1,8 s | 260 ms | 0,03 | ✗ |
| taz.de | 64 | 1,2 s | 104 ms | 0,14 | ✗ |
| heute.at | 62 | 1,0 s | 138 ms | 0,07 | ✓ |
| manager-magazin.de | 62 | 1,1 s | 128 ms | 0,01 | ✓ |
| t3n.de | 62 | 1,2 s | 116 ms | 0,07 | ✓ |
| watson.ch | 61 | 1,2 s | 118 ms | 0,10 | ✓ |
| srf.ch | 60 | 1,4 s | 113 ms | 0,04 | ✓ |
| nachrichten.at | 59 | 1,5 s | 139 ms | 0,01 | ✓ |
| focus.de | 58 | 1,2 s | 137 ms | 0,07 | ✓ |
| diepresse.com | 55 | 1,3 s | 112 ms | 0,02 | ✓ |
| news.at | 55 | 1,9 s | 96 ms | 0,01 | ✓ |
| orf.at | 55 | 0,8 s | 145 ms | 0,00 | ✓ |
| spiegel.de | 53 | 1,0 s | 133 ms | 0,01 | ✓ |
| handelsblatt.com | 53 | 1,2 s | 182 ms | 0,04 | ✓ |
| capital.de | 53 | 1,7 s | 164 ms | 0,03 | ✓ |
| oe24.at | 52 | 0,8 s | 90 ms | 0,03 | ✓ |
| merkur.de | 51 | 1,0 s | 203 ms | 0,06 | ✗ |
| kurier.at | 50 | 1,2 s | 163 ms | 0,04 | ✓ |
| tagesschau.de | 50 | 1,1 s | 95 ms | 0,02 | ✓ |
| profil.at | 48 | 1,5 s | 111 ms | 0,10 | ✓ |
| stern.de | 48 | 1,7 s | 214 ms | 0,03 | ✗ |
| fr.de | 48 | 1,0 s | 181 ms | 0,07 | ✓ |
| bild.de | 47 | 0,9 s | 136 ms | 0,04 | ✓ |
| br.de | 47 | 1,3 s | 96 ms | 0,09 | ✓ |
| trend.at | 44 | 1,3 s | 104 ms | 0,00 | ✓ |
| kleinezeitung.at | 38 | 2,4 s | 239 ms | 0,13 | ✗ |
| sn.at | 38 | 1,4 s | 244 ms | 0,11 | ✗ |
| blick.ch | 38 | 1,3 s | 140 ms | 0,08 | ✓ |
| krone.at | 35 | 1,4 s | 166 ms | 0,05 | ✓ |
| sueddeutsche.de | 34 | 1,4 s | 162 ms | 0,05 | ✓ |
| 20min.ch | 34 | 1,9 s | 445 ms | 0,08 | ✗ |
| falter.at | 33 | 1,6 s | 102 ms | 0,10 | ✓ |
| servustv.com | 33 | 1,9 s | 192 ms | 0,04 | ✓ |
| n-tv.de | 28 | 1,2 s | 167 ms | 0,05 | ✓ |
| tt.com | 27 | 2,0 s | 204 ms | 0,08 | ✗ |
| beobachter.ch | 25 | 1,4 s | 118 ms | 0,09 | ✓ |
| faz.net | 23 | 1,6 s | 244 ms | 0,06 | ✗ |
| tagesspiegel.de | 21 | 1,5 s | 168 ms | 0,10 | ✓ |
| nzz.ch | 9 | 1,8 s | 117 ms | 0,59 | ✗ |
Was Verlage konkret tun können
Wenn die meisten Seiten schon bestehen, ist die sinnvolle Frage, wie man dabei bleibt und wo das verbleibende Risiko liegt.
- Zuerst die Felddaten ansehen. Der Core-Web-Vitals-Bericht in der Search Console und der Feldbereich oben in PageSpeed Insights zeigen, was Google bewertet. Starte kein Performance-Projekt nur wegen eines Laborscores.
- INP auf Artikelseiten prüfen. Sechs der elf durchgefallenen Seiten verfehlen nur den INP. Lange Tasks bei Interaktionen entstehen durch Event-Handler, Consent-Dialoge, nachladende Werbung und schwere Skripte im Main Thread. Der Performance-Tab der Chrome DevTools zeigt, welche Tasks eine Interaktion blockieren.
- Platz für alles reservieren, was spät lädt. Werbung, Embeds, Cookie-Banner und „Mehr lesen“-Boxen, die Inhalt nach unten schieben, erzeugen CLS. Feste Slot-Größen und
min-heightfür Werbecontainer sind die übliche Lösung. - Desktop getrennt testen. 15 Seiten verfehlen auf dem Desktop den CLS-Grenzwert, mobil nur 5. Breitere Layouts mit mehr Werbeplätzen verhalten sich anders.
- Laborläufe zur Ursachensuche nutzen, nicht zur Benotung. Ein Lighthouse-Lauf zeigt renderblockierende Ressourcen, Main-Thread-Arbeit und das LCP-Element. Das ist beim Debuggen wertvoll, auch wenn der Score selbst nicht über die Bewertung entscheidet.
Spielt das fürs Ranking eine Rolle? Laut Google nutzen die Ranking-Systeme die Core Web Vitals, gute Werte garantieren aber keine Top-Platzierung, weil Relevanz vorgeht. Für eine Nachrichtenseite ist der stärkere Grund ohnehin die Leserschaft: Eine Seite, die springt, während jemand auf eine Überschrift tippen will, nervt, egal was Google damit macht.
Methodik
Die Liste umfasst dieselben 50 Verlage wie Studie 1 und Studie 2: 25 aus Deutschland, 18 aus Österreich und 7 aus der Schweiz, darunter Tageszeitungen, Boulevard, Regionalzeitungen, Magazine, öffentlich-rechtliche Sender, Wirtschafts- und Tech-Titel.
Am 17. September 2026 hat ein Skript zuerst jede Startseite mit einem normalen Browser-User-Agent abgerufen und Weiterleitungen verfolgt. Getestet wurden nur Seiten, die mit HTTP 200 antworteten, damit keine Fehlerseite als Ergebnis zählt. Drei fielen raus: puls24.com (keine Verbindung), zeit.de (403) und tagesanzeiger.ch (keine 200-Antwort). Für die übrigen 47 habe ich die PageSpeed-Insights-API über Luminas Worker für Mobilgeräte und Desktop aufgerufen, Lighthouse 13.4.1, Kategorie Performance.
Aus jeder Antwort habe ich die Labormetriken (Score, FCP, LCP, TBT, CLS, Speed Index) und die Felddaten der Origin (originLoadingExperience) gespeichert: 75. Perzentil und Kategorie für LCP, INP, CLS, FCP und TTFB. Alle 47 Seiten hatten für beide Strategien Origin-Felddaten. Eine Seite besteht, wenn LCP ≤ 2.500 ms, INP ≤ 200 ms und CLS ≤ 0,1 beim 75. Perzentil gilt. Das deckt sich mit der Gesamtbewertung von PageSpeed Insights: Genau die 36 bestandenen Seiten sind mobil als FAST eingestuft.
Jeder Laborwert ist ein einzelner Lauf und schwankt von Lauf zu Lauf. Die Felddaten sind ein rollierendes 28-Tage-Fenster und ändern sich langsam. Die rohen PSI-Antworten und das Auswertungsskript liegen bei der Studie, jede Zahl hier lässt sich also nachrechnen.
FAQ
Wo du anfängst
Fünf Schritte für einen Verlag, der wissen will, wo er steht.
Prüf deine Startseite mit Luminas PageSpeed-Tool oder PSI und schau zuerst auf den Feldbereich: LCP, INP und CLS beim 75. Perzentil, für die URL und für die ganze Origin.
PageSpeed-Tool →Der Core-Web-Vitals-Bericht in der Search Console gruppiert ähnliche URLs. So siehst du, ob Artikelseiten, Bildergalerien oder Liveticker das Problem sind.
Core-Web-Vitals-Leitfaden →Zeichne im Performance-Tab von Chrome eine Interaktion auf, etwa das Öffnen des Menüs oder das Akzeptieren des Consent-Banners, und such nach langen Tasks. Daher kommt der INP.
Main-Thread-Arbeit prüfen →Reservier festen Platz für Werbung, Embeds und Banner. 15 von 47 Seiten dieser Studie verfehlen den CLS am Desktop, dreimal so viele wie mobil.
Desktop-CLS prüfen →Felddaten bewegen sich in einem 28-Tage-Fenster. Ein monatlicher Check zeigt, ob eine Änderung echten Nutzern geholfen hat, und fängt Rückschritte durch neue Werbepartner oder Skripte ab.
PageSpeed-Tool →Vergleich deine Seite mit der DACH-Stichprobe
Luminas kostenloses PageSpeed-Tool führt denselben PageSpeed-Insights-Test aus, den ich hier genutzt habe, und zeigt Felddaten neben dem Laborscore. Eine URL, ohne Anmeldung.
PageSpeed-Tool starten →