Performance ist deshalb keine einzelne Zahl, sondern ein Zusammenspiel: Wie erleben echte Besucher die Seite? Wo liegen die technischen Ursachen? Und welche Ressourcen bremsen? Die neun Kriterien dieses Bereichs beantworten diese Fragen getrennt voneinander, weil jede Messart nur einen Teil der Wirklichkeit zeigt.
Auf einen Blick
- Geprüft werden Felddaten echter Besuche, kontrollierte Labormessungen für Mobil und Desktop, Ressourcengewicht, Bildauslieferung, Caching und Kompression, blockierende Ressourcen, responsive Darstellung sowie ein öffentlicher Technologie-Snapshot.
- Felddaten und Labordaten sind nicht austauschbar. Felddaten zeigen, wie reale Besuche verlaufen sind; Labordaten helfen, Ursachen reproduzierbar zu finden (web.dev: Tools zum Messen der Core Web Vitals).
- Laut dem im Januar 2026 veröffentlichten Web Almanac 2025 des HTTP Archive erreichten nur 48 % der Websites auf Mobilgeräten und 56 % auf Desktop gute Werte in allen drei Core Web Vitals (Datenbasis Juli 2025) (HTTP Archive: Web Almanac 2025, Performance).
- Gute Werte sind ein Qualitätsmerkmal, aber keine Ranking-Garantie (Google Search Central: Page Experience).
Warum Ladezeit und Technik geschäftlich relevant sind
Google beschreibt mit den Core Web Vitals drei Aspekte der Nutzererfahrung: wie schnell der Hauptinhalt erscheint (Largest Contentful Paint, LCP), wie schnell die Seite auf Eingaben reagiert (Interaction to Next Paint, INP) und wie stabil das Layout bleibt (Cumulative Layout Shift, CLS). Als gut gelten ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1 – jeweils gemessen am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. (web.dev: Web Vitals).
Google empfiehlt gute Core Web Vitals für den Erfolg in der Suche, stellt aber klar, dass gute Werte allein keine Top-Positionen garantieren; relevante Inhalte bleiben entscheidend (Google Search Central: Page Experience). Der geschäftliche Effekt zeigt sich vor allem bei den Menschen auf der Seite. Ray-Ban ließ Produktseiten per Prerendering vorab laden; Besucher vorgeladener Produktseiten wiesen auf Mobilgeräten eine etwa doppelt so hohe Conversion-Rate auf wie Besucher regulär ausgelieferter Seiten. Laut der Fallstudie aus dem Jahr 2025 wurde das per A/B-Test bestätigt, Angaben zu Stichprobe und Laufzeit fehlen allerdings (web.dev: Ray-Ban-Fallstudie). Beim Onlinehändler Trendyol führte eine etwa halbierte Reaktionszeit der Listenseiten (INP) in einem A/B-Test zu rund 1 % mehr Klicks auf Produktseiten pro Sitzung – ein messbarer, aber kleiner Effekt (web.dev: Trendyol-Fallstudie). Solche Fallstudien sind Einzelfälle, keine Prognose für jede Website.
Wie verbreitet Performance-Probleme sind, zeigt der Web Almanac des HTTP Archive: Auf Mobilgeräten erreichten 2025 nur 62 % der Websites einen guten LCP, 77 % einen guten INP und 81 % einen guten CLS. Der Ladevorgang des Hauptinhalts ist damit die häufigste Schwachstelle. Startseiten schneiden dabei schlechter ab als Unterseiten: Nur 45 % der mobilen Startseiten erreichten gute Core Web Vitals, gegenüber 56 % der mobilen Unterseiten (HTTP Archive: Web Almanac 2025, Performance). Einen anderen Ausschnitt zeigen die aktuellen Felddaten des Chrome User Experience Report, die Websites (Origins) statt einzelner Seiten zählen und sich deshalb nicht direkt mit dem Web Almanac vergleichen lassen: Im September 2026 hatten 55,9 % der rund 18,4 Millionen im Chrome User Experience Report erfassten Websites (Origins) gute Werte in allen drei Core Web Vitals; eine Aufteilung nach Gerätetyp weisen die Release Notes nicht aus (Chrome for Developers: CrUX Release Notes).
Feld- und Labordaten: zwei verschiedene Fragen
Bevor die einzelnen Kriterien folgen, lohnt sich ein Blick auf den wichtigsten methodischen Unterschied dieses Bereichs.
Felddaten stammen aus echten Besuchen, etwa aus dem Chrome User Experience Report (CrUX). Sie beantworten die Frage: Wie haben reale Menschen mit ihren Geräten und Verbindungen die Seite erlebt? Sie sind die Grundlage für die Bewertung der Core Web Vitals, liegen aber nur vor, wenn eine Seite oder Website genügend Besuche hat, und bilden einen zurückliegenden Zeitraum ab.
Labordaten entstehen in einem kontrollierten Test, etwa mit Lighthouse, unter festgelegten Bedingungen für Gerät und Netzwerk. Sie beantworten die Frage: Was passiert technisch beim Laden, und welche Ressource verursacht eine Verzögerung? Sie sind wiederholbar und ideal für die Fehlersuche, zeigen aber nicht, wie es echten Besuchern ergangen ist (web.dev: Tools zum Messen der Core Web Vitals).
Ein hoher Lighthouse-Wert bedeutet deshalb nicht automatisch, dass die Core Web Vitals im Feld gut sind – und umgekehrt. In unserer Auswertung bleiben beide Datenarten getrennt.
Prüfkriterien im Detail
Core Web Vitals Felddaten
Worum es geht. Ausgewertet werden aktuelle Felddaten zu LCP, INP und CLS für die geprüfte Adresse oder die gesamte Website, sofern öffentlich verfügbar.
Warum das wichtig ist. Nur Felddaten zeigen, wie Ihre Website bei Ihrem tatsächlichen Publikum funktioniert – mit dessen Geräten, Netzen und Nutzungsgewohnheiten. Die Schwellenwerte für „gut“ beziehen sich ausdrücklich auf das 75. Perzentil; drei von vier Seitenaufrufen sollen den Wert also erreichen (web.dev: Web Vitals).
So prüfen wir. Wir verwenden aktuelle, öffentlich verfügbare Felddaten und dokumentieren, ob sie sich auf eine einzelne Adresse oder die gesamte Website beziehen und welchen Zeitraum sie abdecken. Ein einzelner Labortest wird nie als Felddatum ausgegeben.
Typische Befunde.
- Gute Desktop-Werte, aber ein zu langsamer LCP auf Mobilgeräten.
- Ein schlechter INP durch umfangreiche Skripte, etwa für Tracking, Chat-Widgets oder Cookie-Banner.
- Ein erhöhter CLS durch nachladende Werbe- oder Bannerflächen.
Was Sie tun können. Beobachten Sie die Werte im Bericht „Core Web Vitals“ der Google Search Console oder in PageSpeed Insights und priorisieren Sie die Kennzahl, die den Schwellenwert am deutlichsten verfehlt. Prüfen Sie nach einer Optimierung über mehrere Wochen, ob sich die Felddaten tatsächlich verbessern.
Grenzen der Aussage. Felddaten sind eine Stichprobe realer Besuche. Fehlen sie, weil eine Website zu wenig Besuche hat, ist das kein schlechtes Ergebnis, sondern der Status „nicht geprüft“. Felddaten belegen keine Geschäftsergebnisse.
Mobile Labormessung
Worum es geht. Eine kontrollierte Messung simuliert ein typisches Smartphone mit gedrosselter Verbindung und zeichnet auf, wie die Seite lädt.
Warum das wichtig ist. Mobilgeräte haben meist weniger Rechenleistung und oft langsamere Verbindungen als Desktop-Rechner. Viele Engpässe – etwa ein zu großes Titelbild oder umfangreiches JavaScript – treten erst unter diesen Bedingungen deutlich hervor. Die Labormessung macht sie reproduzierbar sichtbar und zeigt, welche Ressource die Verzögerung verursacht (web.dev: LCP optimieren).
So prüfen wir. Werkzeug, Version, Datum, Geräte- und Netzwerkprofil sowie die getestete Adresse werden dokumentiert, damit ein späterer Vergleich unter denselben Bedingungen möglich ist.
Typische Befunde.
- Das Titelbild wird spät entdeckt, weil es erst per JavaScript oder CSS eingebunden wird.
- Schriftdateien oder Skripte verzögern die erste Darstellung.
- Der Hauptthread ist durch umfangreiche Skripte lange blockiert.
Was Sie tun können. Nutzen Sie den Labortest als Diagnosewerkzeug: Beheben Sie die größten Verursacher und messen Sie danach unter identischen Bedingungen erneut. Ergänzen Sie die Ergebnisse, sobald verfügbar, durch Felddaten.
Grenzen der Aussage. Ein Labortest bildet nicht ab, wie alle Geräte, Netze und Besucher die Seite erleben. Einzelne Läufe schwanken; Aussagen beruhen deshalb auf dokumentierten Bedingungen, nicht auf Kommastellen.
Desktop Labormessung
Worum es geht. Dieselbe kontrollierte Messung erfolgt mit einem Desktop-Profil.
Warum das wichtig ist. Viele Geschäftskunden recherchieren am Arbeitsplatz. Auch dort fallen langsame Serverantworten, schwere Skripte oder fehlerhafte Ladereihenfolgen auf. Der Desktop-Test hilft zudem, Ursachen von Geräteeinflüssen zu trennen: Ist eine Seite auch am Desktop langsam, liegt das Problem häufig beim Server oder bei der Auslieferung.
So prüfen wir. Wie bei der mobilen Messung werden Werkzeug, Version, Profil, Datum und Adresse dokumentiert.
Typische Befunde.
- Lange Serverantwortzeiten (Time to First Byte), etwa durch fehlendes Caching im CMS.
- Große Bibliotheken, die nur für einzelne Funktionen geladen werden.
- Gute Desktop-Werte, die über deutliche Mobilprobleme hinwegtäuschen.
Was Sie tun können. Vergleichen Sie Desktop- und Mobilergebnis direkt. Sind beide langsam, beginnen Sie bei Server und Caching; ist nur Mobil langsam, bei Bildgrößen, Skriptumfang und Rechenlast.
Grenzen der Aussage. Auch Desktop-Laborwerte sind keine realen Nutzerdaten und lassen sich nicht auf alle Seitentypen übertragen.
Asset-Gewicht & Ressourcenlast
Worum es geht. Erfasst wird, wie viele Daten eine Seite überträgt und welche Ressourcenarten dominieren: Bilder, JavaScript, CSS, Schriften oder Drittanbieter-Skripte.
Warum das wichtig ist. Jede Ressource muss übertragen, verarbeitet und gegebenenfalls ausgeführt werden. Besonders JavaScript belastet Mobilgeräte doppelt – beim Herunterladen und beim Ausführen. web.dev empfiehlt, unnötige Downloads zu vermeiden und die verbleibenden Ressourcen komprimiert zu übertragen (web.dev: Kodierung und Übertragung optimieren).
So prüfen wir. In einer Stichprobe wichtiger Seitentypen werden Übertragungsgröße und auffällige Ressourcenklassen erfasst und im Zusammenhang mit dem Ladeverhalten bewertet.
Typische Befunde.
- Bilder in Druckauflösung, die im Browser stark verkleinert dargestellt werden.
- Mehrere Tracking-, Chat- und Marketing-Skripte, die auf jeder Seite laden.
- Schriftfamilien mit vielen ungenutzten Schnitten.
Was Sie tun können. Prüfen Sie jedes Drittanbieter-Skript auf seinen tatsächlichen Nutzen, entfernen Sie ungenutzte Bibliotheken und laden Sie Funktionen nur auf den Seiten, die sie benötigen.
Grenzen der Aussage. Das Gewicht allein sagt nicht zuverlässig voraus, wie schnell sich eine Seite anfühlt. Ein großes, aber korrekt priorisiertes Bild kann unproblematisch sein; ein kleines, aber blockierendes Skript dagegen nicht.
Bild- & Media-Pipeline
Worum es geht. Geprüft wird, wie Bilder und Videos ausgeliefert werden: in welchen Formaten, in welchen Größen, mit responsiven Varianten, mit festen Abmessungen und mit welcher Ladepriorität.
Warum das wichtig ist. Meist ist ein Bild das größte sichtbare Element einer Seite und bestimmt damit den LCP: Laut Web Almanac 2025 war das auf 76 % der mobilen Seiten der Fall. Zugleich hatten 62 % der mobilen Seiten mindestens ein Bild ohne feste Abmessungen – eine häufige Ursache für verspringende Layouts (HTTP Archive: Web Almanac 2025, Performance). web.dev empfiehlt, das wichtigste Bild früh im HTML auffindbar zu machen und es nicht verzögert zu laden (web.dev: LCP optimieren).
So prüfen wir. Auf repräsentativen Seiten werden Bildformate, Abmessungen, responsive Varianten (srcset und sizes), verzögertes Laden und die Priorisierung des Hauptbildes untersucht.
Typische Befunde.
- Das Titelbild ist mit
loading="lazy"ausgezeichnet und wird dadurch zu spät geladen. - Smartphones erhalten dieselbe große Bilddatei wie Desktop-Bildschirme.
- Bilder ohne
width- undheight-Angaben verschieben beim Laden den Text.
Was Sie tun können. Liefern Sie Bilder in passender Größe und in modernen Formaten wie WebP oder AVIF aus, geben Sie feste Abmessungen an, laden Sie Bilder unterhalb des sichtbaren Bereichs verzögert und das wichtigste Bild bevorzugt. Viele CMS und Bild-CDNs übernehmen diese Schritte automatisch, wenn sie richtig konfiguriert sind.
Grenzen der Aussage. Eine gut eingerichtete Bildauslieferung beweist keine guten Felddaten, und nicht jeder Browser unterstützt jedes Format gleich.
Caching & Kompression
Worum es geht. Untersucht werden öffentliche Angaben zum Zwischenspeichern (Caching) und zur Komprimierung von Ressourcen, etwa die HTTP-Header Cache-Control und Content-Encoding.
Warum das wichtig ist. Caching sorgt dafür, dass Browser und Zwischenserver bereits geladene Dateien wiederverwenden, statt sie erneut anzufordern. Kompression verkleinert Textdateien wie HTML, CSS und JavaScript bei der Übertragung erheblich. Beides spart Ladezeit und Serverlast, besonders bei wiederkehrenden Besuchen (web.dev: HTTP-Cache). Gleichzeitig dürfen persönliche oder sensible Inhalte nicht in gemeinsam genutzten Zwischenspeichern landen (OWASP: Transport Layer Security Cheat Sheet).
So prüfen wir. Für ausgewählte HTML-Seiten und statische Dateien werden die relevanten Header erfasst und auf Plausibilität geprüft: Werden versionierte Dateien lange zwischengespeichert, wird HTML angemessen aktualisiert, sind Textressourcen komprimiert?
Typische Befunde.
- Statische Dateien ohne Cache-Angabe, die bei jedem Seitenaufruf neu geladen werden.
- Fehlende Komprimierung für CSS- oder JavaScript-Dateien.
- Sehr lange Cache-Dauern für Dateien ohne Versionierung, sodass Änderungen erst verzögert ankommen.
Was Sie tun können. Versehen Sie Dateinamen statischer Ressourcen mit einer Versionskennung und lassen Sie diese lange zwischenspeichern. Aktivieren Sie Brotli- oder Gzip-Kompression für Textressourcen und schließen Sie persönliche Inhalte ausdrücklich vom gemeinsamen Caching aus.
Grenzen der Aussage. Header zeigen die Absicht, nicht zwingend die Wirkung entlang des gesamten Übertragungswegs. Ob alle Zwischenspeicher korrekt arbeiten, lässt sich von außen nicht vollständig belegen.
Render-blockierende Ressourcen
Worum es geht. Gesucht wird nach CSS-, JavaScript- oder Schriftdateien, die der Browser laden muss, bevor er Inhalte darstellen kann.
Warum das wichtig ist. Solange blockierende Ressourcen fehlen, bleibt der Bildschirm leer oder unvollständig – auch wenn der eigentliche Inhalt längst übertragen ist. web.dev zählt es zu den wirksamsten Maßnahmen, die LCP-Ressource früh auffindbar zu machen und blockierende Abhängigkeiten zu reduzieren (web.dev: Die wirksamsten Optimierungen für Core Web Vitals).
So prüfen wir. Ressourcenabhängigkeiten werden mit Seiten- und Laborwerkzeugen analysiert. Dabei unterscheiden wir zwischen einer erkennbaren Abhängigkeit und einer tatsächlich gemessenen Verzögerung.
Typische Befunde.
- Mehrere große CSS-Dateien im Kopfbereich, von denen nur ein Bruchteil für den ersten Bildschirm nötig ist.
- Skripte ohne
deferoderasync, die die Darstellung anhalten. - Externe Schriften, die ohne Ausweichschrift geladen werden und Text zunächst unsichtbar lassen.
Was Sie tun können. Laden Sie nicht kritische Skripte verzögert, binden Sie für den ersten Bildschirm benötigtes CSS direkt ein und verwenden Sie für Schriften eine Ausweichdarstellung (font-display: swap). Prüfen Sie anschließend per Messung, ob sich die Darstellung tatsächlich beschleunigt hat.
Grenzen der Aussage. Eine statische Analyse belegt nicht, wie lange eine Ressource die Darstellung tatsächlich blockiert. Dafür sind Laufzeit- oder Labordaten nötig.
Responsive Auslieferung
Worum es geht. Geprüft wird, ob Inhalte, Bilder und Bedienelemente auf repräsentativen Bildschirmbreiten vollständig, lesbar und bedienbar sind.
Warum das wichtig ist. Google verwendet für Indexierung und Ranking vorrangig die mobile Version einer Website. Fehlen dort Inhalte, strukturierte Daten oder Bilder, die auf dem Desktop vorhanden sind, kennt Google sie unter Umständen nicht (Google Search Central: Mobile-First-Indexierung). Für Besucher bedeutet eine schwache mobile Darstellung schlicht, dass sie zentrale Informationen nicht finden.
So prüfen wir. Stichproben auf ausgewählten Bildschirmbreiten prüfen horizontales Scrollen, Reihenfolge und Vollständigkeit der Inhalte, Medien und grundlegende Bedienbarkeit. Das ist eine gezielte Sichtprüfung, kein vollständiges Gerätelabor.
Typische Befunde.
- Tabellen oder Bilder, die breiter als der Bildschirm sind.
- Inhalte, die auf Mobilgeräten ausgeblendet werden, um Platz zu sparen.
- Wichtige Aktionen, die erst nach langem Scrollen erreichbar sind.
Was Sie tun können. Stellen Sie sicher, dass die mobile Version dieselben Inhalte enthält wie die Desktop-Version. Testen Sie wichtige Seitentypen auf mehreren Breiten und mit echten Geräten.
Grenzen der Aussage. Ausgewählte Bildschirmbreiten decken nicht jedes Gerät, jedes Betriebssystem und jede Nutzungssituation ab.
Öffentlicher Technologie-Snapshot
Worum es geht. Dokumentiert werden öffentlich erkennbare Hinweise auf CMS, Framework, Hosting oder Auslieferung – und vor allem, ob die Inhalte bereits im ausgelieferten HTML stehen oder erst im Browser per JavaScript erzeugt werden.
Warum das wichtig ist. Der Snapshot liefert Kontext für Empfehlungen: Welche Optimierungen bietet das eingesetzte System bereits, und wo liegen typische Schwachstellen? Besonders wichtig ist die Frage der Darstellung. Google rendert JavaScript, empfiehlt aber weiterhin serverseitiges Rendering oder Pre-Rendering, weil nicht alle Bots JavaScript ausführen können (Google Search Central: JavaScript-SEO-Grundlagen). OpenAI, Anthropic und Perplexity dokumentieren nicht, ob ihre Crawler JavaScript ausführen; eine Messung von Vercel und MERJ aus dem Dezember 2024 fand bei deren Crawlern keine JavaScript-Ausführung (Vercel: The rise of the AI crawler). Inhalte, die erst im Browser entstehen, bleiben für diese Systeme möglicherweise unsichtbar. Mehr dazu im Beitrag KI-Crawler und KI-Agenten.
So prüfen wir. Beobachtet werden ausschließlich öffentlich sichtbare Signale im HTML und in den HTTP-Antworten. Schlussfolgerungen werden als Hinweise formuliert, nicht als gesicherte Aussagen über interne Systeme.
Typische Befunde.
- Ein fast leeres HTML-Gerüst, dessen Inhalt vollständig per JavaScript nachgeladen wird.
- Hinweise auf veraltete Bibliotheks- oder CMS-Versionen.
- Ein CMS, dessen eingebaute Bild- oder Cache-Optimierungen nicht aktiviert sind.
Was Sie tun können. Liefern Sie zentrale Inhalte – Texte, Überschriften, Links und strukturierte Daten – direkt im HTML aus, etwa durch serverseitiges Rendering oder statische Generierung. Halten Sie CMS, Erweiterungen und Bibliotheken aktuell.
Grenzen der Aussage. Öffentliche Hinweise belegen weder die Qualität des Quellcodes noch die interne Architektur oder die Sicherheit der Auslieferung.
Quellen
Die Aussagen auf dieser Seite stützen sich auf die folgenden Quellen, geordnet nach Herausgeber. Angaben von Anbietern beschreiben, was ein Unternehmen über sein eigenes System sagt; sie sind dafür die maßgebliche Quelle und können sich jederzeit ändern. Bei Gesetzen, Standards und technischen Referenzen nennen wir die geltende Fassung.
- Google definiert die Core Web Vitals und ihre Schwellenwerte, erklärt das Verhältnis von Feld- und Labordaten, gibt Optimierungshinweise und veröffentlicht mit dem Chrome UX Report monatlich aktuelle Felddaten; die Fallstudien auf web.dev dokumentieren einzelne Unternehmen.
- web.dev: Core Web Vitals workflows with Google tools
- Understanding page experience in Google Search results
- web.dev: Web Vitals
- web.dev-Fallstudie: How Ray-Ban doubled conversion rate … using the Speculation Rules API
- web.dev-Fallstudie: How Trendyol reduced INP by 50 %
- Chrome UX Report: Release notes (Datensatz September 2026)
- web.dev: Optimize Largest Contentful Paint
- web.dev: Optimize the encoding and transfer size of text-based assets
- web.dev: Prevent unnecessary network requests with the HTTP Cache
- web.dev: The most effective ways to improve Core Web Vitals
- Mobile site and mobile-first indexing best practices
- Understand JavaScript SEO basics
- Vercel
- Die Auswertung von Vercel und MERJ ist die jüngste uns bekannte veröffentlichte Messung außerhalb von Agentur-Tests, ob KI-Crawler JavaScript ausführen (Stand November 2026).
- HTTP Archive
- Der Web Almanac wertet jährlich Millionen Websites aus und liefert die Verteilung der Core-Web-Vitals-Werte nach Gerät und Seitentyp.
- OWASP Foundation
- Die OWASP Foundation beschreibt bewährte Verfahren für TLS und den Umgang mit sensiblen Inhalten in Zwischenspeichern.