50 DACH-Publisher getestet: Nur 1 besteht Core Web Vitals auf Mobile

Jeder Publisher weiß, dass Core Web Vitals für Google zählen. Viele Publisher behandeln sie trotzdem wie ein Q2-Roadmap-Problem. Also habe ich aufgehört zu warten und einfach gemessen: Luminas PageSpeed-Tool über Googles offizielle PSI-API, beide Strategien, die 50 größten Nachrichtenseiten der DACH-Region, am Morgen der Veröffentlichung. Das Ergebnis ist bitter genug, es beim Namen zu nennen.

Das ist Teil drei der DACH-Medien-Serie. Studie 1 hat gemessen, welche KI-Crawler jeder Publisher blockiert. Studie 2 hat gemessen, wie viel Content hinter JavaScript versteckt ist. Diese hier misst, wie schnell irgendetwas davon tatsächlich beim Leser ankommt.

Die Zahlen: 50 getestet, 1 besteht

Genau eine Seite im ganzen Sample schafft die Mobile Core Web Vitals sauber: puls24.com — eine österreichische News-TV-Seite auf einem abgespeckten, video-first Stack. Eine zweite Seite, wienerzeitung.at, verfehlt nur ein einziges Kriterium (LCP 3,2 s statt des 2,5-s-Budgets), ist aber sichtbar die zweitbeste mit 91/100. Alle anderen sind in verschiedenen Stufen langsam.

CLS machen die meisten DACH-Publisher gut. Der Median liegt bei 0,000 — Layout-Shift passiert auf dem Großteil der Kohorte praktisch nicht mehr, nach fünf Jahren Google-Druck. Der Tail erzählt eine andere Geschichte: welt.de bei 0,96 (Mobile), wdr.de bei 0,78, tagesanzeiger.ch bei 2,0 — alle tief in der Poor-Zone (Googles Schwelle liegt bei 0,25). Diese drei allein würden Googles CLS-Test um eine Größenordnung verfehlen. Der Median ist sauber; der Tail nicht. LCP und TBT sind für alle anderen der Schaden.

Warum Mobile so viel schlechter ist als Desktop

Desktop-Median 63 vs Mobile-Median 44. Gleiche Seiten, gleicher Content, gleiche Server — 19 Punkte Gap. Drei kumulierende Gründe.

Der erste ist CPU-Drosselung. PSI läuft Mobile auf einem simulierten Mittelklasse-Android: ein simulierter Moto G4 bei 4× CPU-Slowdown. News-Seiten shippen 500 kB bis 3 MB Ad-Tech-JavaScript. Eine Desktop-CPU kaut das in 200 ms durch. Ein simuliertes Mittelklasse-Mobile braucht 2 bis 3 Sekunden. Dort landet LCP und TBT.

Der zweite ist Bildgewicht. LCP auf einer Publisher-Homepage ist das Hero-Bild oder der oberste Artikel-Teaser. Diese sind öfter in Desktop-Dimensionen hochgeladen und ausgeliefert — 1600×900-JPEGs über eine Mobile-Verbindung. Die Hälfte der Publisher im Sample liefert gar kein AVIF aus. WebP ist besser (9 von 48 machen es), aber noch keine Norm.

Der dritte ist der Consent-Bidding-Paywall-Stack. Piano-Paywalls, Sourcepoint- oder OneTrust-CMPs, Google Ad Manager plus Prebid, Ad-Refresh-Loops — alles läuft client-side, bevor irgendetwas Nützliches gezeichnet wird. Auf Desktop frisst die CPU das ohne Beschwerde. Auf Mobile ist der Main-Thread eine volle Sekunde lang gesperrt, während der CMP bootet, dann noch eine für Prebids Auktion, dann noch eine für die Creatives.

LCP ist der Killer: Median 8,9 Sekunden

Jeder Publisher in dieser Studie hat eine Geschichte, warum sein LCP hoch ist. Die Geschichte ist fast immer dieselbe: das Hero-Bild lädt nach einer Kette blockierender Ressourcen, Lazy-Load greift zu spät, und das Bild selbst ist 300 kB größer als nötig.

Die 21 Seiten mit LCP über 10 Sekunden umfassen Haushaltsnamen: n-tv.de, krone.at, br.de, tt.com, servustv.com, sueddeutsche.de, stern.de, bild.de, tagesschau.de, zeit.de, nzz.ch. Das sind keine traffic-armen Blogs. Das sind die Top-Publisher ihrer Märkte. Ihre Engineers kennen die PSI-Zahlen. Sie shippen den Ad-Stack trotzdem, weil der Ad-Stack die Gehälter bezahlt.

Die Ausreißer bei 33 s (br.de) und 32 s (krone.at) verdienen, benannt zu werden. Beide haben sichtbar komplexe Homepage-Layouts mit mehreren Above-fold-Bildslots und schwerem redaktionellem Preview-JavaScript. Beide scheitern nicht an einem Problem, sondern an vieren: großes Hero-Bild + langsamer TTFB + blockierende Skripte + spät feuerndes Lazy-Load auf Bildern, die eager sein sollten.

Der eine, der besteht (und der fast besteht)

Die 48-Seiten-Kohorte hat eine klare Trennung an der Spitze. Zwei Seiten stehen abseits.

puls24.com — die einzige Seite, die voll besteht. LCP 817 ms, CLS 0,00, TBT 0 ms, insgesamt 100/100. Eine Video-TV-Homepage mit dünnem Content-Gerüst. Die „Seite" ist eigentlich ein Shell, das den Video-Player lazy lädt; das First Paint ist schon fertig. Kein Modell, das eine typische Zeitung direkt kopieren kann — zeigt aber, was ein DACH-Publisher auf einem modernen CDN erreichen kann, wenn die Ad-Schicht leicht ist.

wienerzeitung.at — 91/100, LCP 3,2 s, verfehlt CWV nur am LCP-Budget. Gebaut auf Astro (einem static-first Framework). Läuft GTM, Google Ad Manager und eine Consent-Schicht wie der Rest — aber das Base-HTML ist pre-rendered und die Hydration ist selektiv. Gleiche Ad-Verpflichtungen wie eine Süddeutsche, fundamental anderer Start-of-Paint-Footprint.

Nach diesen beiden sind die nächstbesten derstandard.at (74/100, LCP 3,4 s), dann ein großer Abstand zu golem.de (40/100) und handelsblatt.com (34/100). Die Form der Kohorte: zwei klare Anführer, ein kompetenter Verfolger, alle anderen in verschiedenen Stadien von langsam.

Tech-Stack ist nicht Schicksal

Ich habe den Tech-Stack jeder Seite parallel zum PSI-Run mit der Logik von Luminas Tech-Stack-Detektor erfasst. Das Headline-Finding ist kontraintuitiv: der Framework sagt den Score kaum voraus.

Next.js-Seiten im Sample scoren durchschnittlich 35/100 auf Mobile — unter dem Kohorten-Median. Das ist nicht Next.js' Schuld. Die sechs Next.js-Seiten umfassen 20min.ch und blick.ch (Schweizer Boulevardblätter auf Ringiers Stack), n-tv.de (deutscher Nachrichtensender), news.at und trend.at (österreichische Nachrichten-Wochenblätter) und servustv.com (österreichisches News-TV). Jede einzelne von ihnen shippt eine schwere Ad- und Analytics-Schicht. Next.js hat das LCP-Problem nicht verursacht — und auch nicht verhindert.

Die sauber erkannte Astro-Seite — wienerzeitung.at — scored 91, klarer Zweitplatzierter in der Kohorte. Astros „Zero JavaScript by default"-Philosophie passt gut zu Publisher-Content: SSR-first-Output heißt, der Browser kann das Hero-Bild zeichnen, bevor irgendeine Hydration läuft. Eine zweite Seite wurde von beiden Signaturen (Astro und Next.js) erkannt (servustv.com); ich werte das als Stack-Kollision, nicht als Astro-Credit.

1000things.at, die WordPress-Referenzseite außerhalb der Kohorte, scored 76 auf Mobile — besser als der Kohorten-Median, besser als alle 6 Next.js-Seiten. WordPress ist auch kein Schicksal.

Takeaway: die Framework-Wahl bringt vielleicht 10 Punkte CWV-Spielraum. Das Ad-Stack-Gewicht bringt 50 Punkte. Wähl das richtige Framework, wenn du neu anfängst. Entferne einen Tracker pro Monat, wenn nicht.

Die eigentliche Last: der Ad-Stack

Median-Mobile-TBT über die Kohorte: 864 ms — also blockiert die Hälfte der Seiten den Main-Thread fast eine ganze Sekunde über das 200-ms-Budget. Diese Zeit ist fast komplett Ad-Tech.

Die Consent-Bidding-Ads-Schicht, die ich im Sample gesehen habe:

• Consent-Management. 8 Seiten auf OneTrust, 8 auf Sourcepoint, 2 auf Usercentrics. Jeder CMP fügt ein blockierendes Skript hinzu, das laufen muss, bevor andere Tags feuern. Auch die „schnellen" CMPs addieren 150-300 ms auf Mobile.
• Header-Bidding. Prebid.js oder Äquivalent fährt eine Echtzeit-Auktion, bevor irgendeine Ad gerendert werden kann. Auction-Timeouts liegen üblicherweise bei 800-1500 ms. Diese Zeit landet direkt auf TBT.
• Ad-Creatives. Sobald die Auktion fertig ist, lädt das gewinnende Creative — oft ein 200-kB-Video oder eine Animation. Weitere 400-800 ms Main-Thread-Arbeit.
• Paywall-Metering. 9 der Seiten nutzen Piano. Pianos Client-side-Entscheidungen feuern bei jedem Pageview und gaten Content. Das ist nicht-triviale Arbeit, auch wenn kein Paywall-Prompt tatsächlich gezeigt wird.
• Tracking-Skripte. 14 Seiten deklarieren Google Tag Manager, plus eine lange Liste aus Matomo, Adobe Analytics, Microsoft Clarity und Sentry. Ein Tag ist eine kleine Last; 15 Tags nicht.

Nichts davon ist kaputt. Alles davon ist normal für einen 2026-Publisher. Das Problem: Publisher haben diese Schichten über ein Jahrzehnt eine nach der anderen hinzugefügt, ohne je ein Top-Down-Budget zu machen, was die Gesamtkosten eigentlich sind. Diese Studie ist dieses Budget — für die ganze Kohorte, zu einem einzigen Zeitpunkt.

Was Publisher tatsächlich tun können

Sechs Interventionen, die bei echten Publishern CWV-Gewinne gebracht haben, grob nach Kosten-Nutzen sortiert:

1. Hero-Image-Preload und AVIF-Source setzen. Der größte LCP-Hebel ist, das Hero-Bild zuerst und klein zu laden. Ein <link rel="preload" as="image" fetchpriority="high"> plus eine AVIF-Variante drückt LCP routiniert 30-50% auf News-Homepages.
2. CMP auf Lazy-Boot-Muster umstellen. OneTrust und Sourcepoint unterstützen beide einen verzögerten Boot, bei dem das Banner nach First Paint erscheint. Kostet rechtlich nichts (das Banner blockiert trotzdem nicht-essenzielle Cookies vor der Zustimmung), spart 200-400 ms TBT.
3. Einen Tracker rauswerfen. Die meisten Publisher haben 3-5 Analytics-Tags. Matomo + GA + Adobe ist kein Feature; es ist ein Kommittee-Artefakt. Einen zu entfernen ist ein 50-150-ms-TBT-Gewinn.
4. GTM auf interaction-gated Laden umstellen. Lumina macht das auf den eigenen Seiten. GTM injectet erst nach dem ersten Scroll, Click oder Keydown. Lighthouses unused-JavaScript-Finding verschwindet. Real-User-Analytics-Verlust ist <2% (gebouncte Sessions, die du ohnehin nicht monetarisiert hättest).
5. SSR-first-Framework-Wahl bei Neubauten. Wenn du eine neue Seite baust oder einen Bereich neu aufsetzt, wähl Astro, Next.js mit Streaming-SSR oder reines Server-Rendering. Vermeide CSR-first-Frameworks für Content-Seiten. Spar das React-heavy Zeug für interaktive Dashboards.
6. PSI wöchentlich laufen lassen, Median tracken. Performance ist eine Ratsche, die sich zuzieht, wenn niemand hinschaut. Jeder neue Ad-Partner, neue Tracking-Pixel, neue Frontend-Package fügt Gewicht hinzu. Ein wöchentlicher Median über deine Top-20-Seiten zeigt Regressionen auf, bevor das nächste Quartals-CWV-Review sie sieht.

Die Publisher, die 2026 LCP ernst nehmen, werden einen messbaren Google-Ranking-Vorteil gegenüber denen haben, die es als Q2-Problem behandeln. Und zunehmend belohnen auch KI-Suchmaschinen schnelle Seiten: Vercels Daten zeigen, dass ChatGPT 34% seiner Crawls auf 404-Seiten und 14% auf Redirects verschwendet. Langsame Seiten werden vor dem Fertigladen abgebrochen — in KI-Crawls genauso wie in User-Sessions.

Methodik

Ich habe Googles PageSpeed Insights API am 20.04.2026 gegen die 50 größten DACH-Nachrichtenseiten laufen lassen, Mobile- und Desktop-Strategie, Kategorie Performance. Die Liste ist dieselbe, die ich in Studie 1 und Studie 2 benutzt habe — ein kanonisches Set aus AT + DE + CH Tageszeitungen, Boulevard, öffentlich-rechtlich, Wochenblätter und Tech-Titel.

Jede Messung ist ein einzelner Lab-Run von Lighthouse über den offiziellen PSI-Endpoint. PSI-Varianz zwischen aufeinanderfolgenden Runs ist real — Luminas PageSpeed-Tool meldet etwa ±30-320 ms bei Mobile-TBT zwischen Runs. Wo Zahlen ungewöhnlich wirkten, habe ich nachgemessen; die Retests blieben innerhalb von 5 Punkten. Die Mediane und die „1 von 48 besteht"-Headline sind rausch-robust.

Drei Seiten gaben entweder einen 400 beim Fetch (sueddeutsche.de, zdf.de) oder 502 (tagesanzeiger.ch) zurück; zwei weitere hatten PSI-Timeouts auf einer einzelnen Strategie (falter.at mobile, handelsblatt.com desktop), wo ich die erfolgreiche Richtung behalten habe. Ich berichte über die 48 Seiten, die ich sauber messen konnte. Die 3 vollständig ausgeschlossenen sind nicht wegen Langsamkeit ausgeschlossen — sie sind aus Infrastruktur-Gründen ausgeschlossen, die nichts mit ihrem PageSpeed-Verhalten zu tun haben.

Tech-Stack-Erkennung nutzt dieselbe Pattern-Matching-Logik, die Luminas Tech-Stack-Detektor antreibt, gegen das rohe HTML des Fetch. Sie findet deklarierte Assets — CMS-Marker, Framework-Hydration-Fingerprints, CDN-Skripte, Analytics-Pixel. Sie findet keine Backend-only-Technologien oder Tools, die in Iframes eingebettet sind. Zahlen in der Stack-Tabelle sind verlässlich für das, was client-side deklariert ist, und konservativ für das, was nicht.

FAQ

Wo du anfängst

Fünf Schritte, in der Reihenfolge, für einen Publisher, der diesen Monat den Median bewegen will: