Warum eine schnelle Website heute unverzichtbar ist

„Die Seite ist zu langsam“ ist ein Gefühl. Bevor man daran arbeiten kann, muss daraus eine Zahl werden, sonst optimiert man ins Blaue. Seit Google die Core Web Vitals eingeführt hat, gibt es dafür einen gemeinsamen Maßstab: drei Messwerte, die beschreiben, wie sich eine Seite für echte Menschen anfühlt. Dieser Artikel erklärt, was sie messen, woran es meistens hakt und welche Maßnahmen sich wirklich lohnen.

Schnell heißt heute messbar. Die Core Web Vitals fassen drei Aspekte zusammen: wie lange der wichtigste sichtbare Inhalt braucht, wie flott die Seite auf Eingaben reagiert und wie ruhig das Layout beim Laden bleibt. Bewertet werden alle drei an echten Seitenaufrufen, nicht an einem Testlauf im Labor.

Die Core Web Vitals bestehen aus drei Kennzahlen, und für jede gibt es eine klare Schwelle, ab der Google den Wert als „gut“ einstuft:

INP ist der jüngste der drei Werte: Er hat im März 2024 den früheren First Input Delay als Core Web Vital abgelöst. Der Grund war, dass der alte Wert nur die allererste Eingabe betrachtet hat – und von dieser nur die Verzögerung bis zum Beginn der Verarbeitung, nicht die Verarbeitung selbst. Fast jede Seite hat ihn deshalb bestanden, auch eine träge. INP bewertet dagegen, wie zügig die Seite über den ganzen Besuch hinweg auf Klicks, Tippen und Tastendrücke reagiert. Scrollen und Zoomen fließen ausdrücklich nicht ein.

Weil ein Durchschnitt die Ausreißer verschluckt. Das 75. Perzentil sagt: Drei von vier Seitenaufrufen waren mindestens so gut wie dieser Wert. Damit zählt nicht das schnellste Gerät im Büro, sondern die Erfahrung der großen Mehrheit – ältere Handys und schlechte Mobilverbindungen eingeschlossen.

Praktisch heißt das: Eine Seite kann auf dem Entwicklungsrechner blitzschnell wirken und trotzdem durchfallen. Wer eine belastbare Aussage über die eigene Website treffen will, braucht Daten aus echten Besuchen. Laborwerte sind gut zum Suchen von Ursachen, aber sie sind kein Beleg dafür, wie sich die Seite draußen bei Ihrer Kundschaft verhält.

Schneller, als die meisten Websites liefern. Die bekannteste Zahl dazu stammt von Google: 53 Prozent der Besuche werden voraussichtlich abgebrochen, wenn eine mobile Seite länger als drei Sekunden lädt. Veröffentlicht hat Google sie im September 2016, gestützt auf rund 3.700 mobile Websites, die ihre Daten freiwillig beigesteuert haben. Sie ist damit über zehn Jahre alt und beruht auf keiner Zufallsstichprobe – lesen Sie sie als Größenordnung, nicht als Messwert für Ihre Website.

Wir nennen die Zahl trotzdem, weil sie die Richtung richtig beschreibt: Auf dem Handy ist die Geduld kleiner als am Schreibtisch, und wer einmal weggeklickt hat, kommt selten zurück. Was wir bewusst nicht wiederholen, sind die beiden Klassiker aus jeder Performance-Präsentation: die Amazon-Anekdote über Millisekunden und Umsatz und die Faustregel, eine Sekunde Verzögerung koste einen zweistelligen Anteil der Abschlüsse. Für beide gibt es keine publizierte Studie mit nachvollziehbarer Methodik – für die Amazon-Zahl im besten Fall einen rund zwanzig Jahre alten Vortrag. Sie klingen gut und belegen nichts – und wenn wir Ihnen eine Investition empfehlen, dann nicht mit erfundenen Zahlen.

Ja, aber nicht als Hauptfaktor. Google empfiehlt Betreibern ausdrücklich, gute Core Web Vitals zu erreichen, und ordnet sie gemeinsam mit weiteren Aspekten der Seitenerfahrung dem zu, was die Ranking-Systeme belohnen sollen. Entscheidend bleibt aber der Inhalt: Google beschreibt die Seitenerfahrung als das, was den Ausschlag geben kann, wenn mehrere Ergebnisse ähnlich hilfreich sind.

Interessanter als das Ranking ist ohnehin, was nach dem Klick passiert. Wer aus der Suche kommt und erst einmal auf eine weiße Fläche schaut, ist wieder weg, bevor Ihr bestes Argument sichtbar wird. Geschwindigkeit ist deshalb weniger ein SEO-Trick als die Voraussetzung dafür, dass sich die Arbeit an Sichtbarkeit überhaupt auszahlt.

Fast immer aus vier Gründen, und die sind über Projekte hinweg erstaunlich gleich: zu große Bilder, zu viele Skripte von Dritten, schwerfällig eingebundene Schriften und ein Server, der zu spät antwortet. Die Reihenfolge wechselt von Fall zu Fall, die Liste selten.

Bilder sind fast immer das Element, an dem der Largest Contentful Paint gemessen wird: laut HTTP Archive bei 76 Prozent der mobilen und 85 Prozent der Desktop-Seiten. Daraus folgt aber nicht, dass die Dateigröße auch die Ursache des Problems ist. Googles Auswertung echter Felddaten zeigt das Gegenteil: Bei den meisten Websites mit schlechtem Largest Contentful Paint entfallen weniger als zehn Prozent der Zeit auf das eigentliche Herunterladen des Bildes. Der weitaus größere Teil geht dafür drauf, dass der Server spät antwortet und der Browser erst spät erfährt, welches Bild er überhaupt laden soll. Ein Foto, das unverkleinert aus der Kamera in die Mediathek wandert, gehört trotzdem korrigiert – nur ist es selten der einzige Hebel. Prüfen Sie deshalb zuerst, wo die Zeit tatsächlich vergeht: bei der Serverantwort, beim verspäteten Anfordern des Bildes oder beim Übertragen. Was WebP und AVIF unterscheidet, steht im Glossar unter Bildkompression.

Meistens mehr, als ihr Nutzen hergibt. Jedes eingebundene Werkzeug – Analyse, Chat, Karten, Werbepixel, Schriftdienst – bringt eine eigene Verbindung, eigenen Code und eigene Wartezeit mit. Das summiert sich still, weil niemand ein Skript entfernt, das vor zwei Jahren für eine Kampagne eingebaut wurde. Eine ehrliche Inventur ist oft die billigste Optimierung, die es gibt: Was sich niemand mehr anschaut, kann weg.

Spürbar, weil beide den ersten sichtbaren Aufbau blockieren können. Der Browser hält Text zurück, bis die Schrift geladen ist, oder wartet auf ein Stylesheet, das er erst spät entdeckt. Wenige Schriftschnitte, selbst ausgeliefert, ein bewusst gewähltes Ladeverhalten und CSS, das nicht die halbe Website in jede einzelne Seite packt: Das bringt hier viel für vergleichsweise wenig Aufwand.

Der Server bestimmt, wann überhaupt etwas beim Browser ankommt. Diese Wartezeit heißt Time to First Byte; web.dev nennt dafür 0,8 Sekunden als guten Wert – kein Core Web Vital, aber ein verlässlicher Frühindikator. Ist dieser Wert hoch, hilft keine Bildoptimierung, weil das Problem vor dem ersten Byte liegt. Dann geht es um Caching, um die Datenbank oder schlicht um ein Hosting-Paket, das der Website gewachsen ist.

Mit zwei Arten von Daten. Felddaten stammen aus echten Besuchen und sagen, wie sich Ihre Seite tatsächlich verhält. Labordaten entstehen in einem simulierten Testlauf und sagen, woran es liegt. Für die Bewertung brauchen Sie die Felddaten, für die Reparatur die Labordaten – beide zusammen ergeben ein Bild.

Ein Labortest läuft unter festgelegten Bedingungen: gleiches Gerät, gleiche Verbindung, jedes Mal. Das macht ihn wiederholbar und damit gut geeignet, um zwei Stände derselben Seite zu vergleichen. Felddaten bilden dagegen die Wirklichkeit ab, mit allen alten Geräten und schlechten Verbindungen – und genau daraus entsteht das 75. Perzentil. Wer nur auf Labortests schaut, optimiert an einer Wirklichkeit vorbei, die es so nicht gibt. Ergänzend lohnt ein Blick auf den First Contentful Paint; web.dev nennt dafür 1,8 Sekunden als guten Wert.

In den meisten Projekten dieselben vier: Bilder in der Größe und im Format ausliefern, die die Seite wirklich braucht; Skripte von Dritten aussortieren; Schriften und CSS entschlacken; und dafür sorgen, dass der Server zügig antwortet. Große Umbauten kommen erst danach – wenn überhaupt.

Was auf dieser Liste bewusst fehlt, sind Wunderwerkzeuge. Ein Plugin, das „Performance“ verspricht, verschiebt in der Regel nur, wo das Problem entsteht, und macht die Ursache schwerer auffindbar. Wenn eine gewachsene Website an allen vier Punkten gleichzeitig scheitert, ist ein sauberer Neubau oft günstiger als jahrelanges Nachbessern. Das rechnen wir vorher durch, nicht danach.

Mehr, als es zunächst wirkt. Dieselben Entscheidungen, die eine Seite schnell machen – wenig Ballast, klare Struktur, keine überraschenden Layoutsprünge –, machen sie auch bedienbarer und leichter maschinell lesbar. Geschwindigkeit ist deshalb selten ein Projekt für sich.

Ein Layout, das beim Laden springt, trifft alle, aber Menschen mit motorischen Einschränkungen am härtesten: Sie treffen die Schaltfläche, die inzwischen woanders ist. Eine Seite, die ohne schwere Skripte auskommt, funktioniert auch bei schlechter Verbindung und auf älteren Geräten. Und Suchmaschinen wie Antwortmaschinen kommen mit schlankem, sauber strukturiertem HTML deutlich besser zurecht. Deshalb behandeln wir Performance nicht als Nachbesserung, sondern als Teil davon, wie eine Website überhaupt gebaut wird.