Page Speed - Optimierung der Seitenladezeiten

· SEO-Tutorials

Die Seitenladezeit – im Fachjargon Page Speed – ist einer der wenigen Punkte in der Suchmaschinenoptimierung, bei denen sich niemand über die Richtung streitet. Google bezieht die Ladeerfahrung in die Bewertung mit ein, und unabhängig davon entscheidet sie darüber, ob jemand auf Ihrer Seite bleibt. Eine Seite, die auf dem Handy im Zug drei Sekunden weiß bleibt, verliert Besucher, bevor sie überhaupt etwas anbieten konnte.

Was sich in den letzten Jahren geändert hat, ist nicht die Bedeutung, sondern die Messgröße. „Wie lange lädt die Seite?“ ist keine sinnvolle Frage mehr, seit Seiten schrittweise aufgebaut und nachgeladen werden. Gemessen wird deshalb nicht mehr ein Zeitpunkt, sondern drei Aspekte der Nutzererfahrung.

Die Core Web Vitals

Seit 2020 fasst Google die aus seiner Sicht entscheidenden Werte unter dem Namen Core Web Vitals zusammen:

  • LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element im ersten Bildschirmbereich fertig gezeichnet ist – meist ein Titelbild oder ein großer Textblock. Bis 2,5 Sekunden gilt der Wert als gut, ab 4 Sekunden als schlecht.
  • INP (Interaction to Next Paint) misst, wie lange die Seite braucht, um auf einen Klick, Tap oder Tastendruck sichtbar zu reagieren. Bis 200 Millisekunden gut, ab 500 Millisekunden schlecht. INP hat im März 2024 den älteren First Input Delay (FID) abgelöst; wenn Sie in einer Dokumentation noch FID finden, ist sie älter als das.
  • CLS (Cumulative Layout Shift) misst, wie stark das Layout während des Ladens noch springt. Bis 0,1 gut, ab 0,25 schlecht.

Wie diese drei Werte im Einzelnen zustande kommen, steht im Wiki-Eintrag zu Page Speed. Für die Praxis genügt der Kern: LCP ist ein Ladeproblem, INP ein JavaScript-Problem und CLS fast immer ein Layout-Problem – drei verschiedene Ursachen, drei verschiedene Werkzeugkästen.

Felddaten und Labordaten auseinanderhalten

Das ist die häufigste Fehlerquelle bei der Bewertung, und sie kostet regelmäßig Wochen.

Labordaten entstehen bei einem einzelnen Testabruf unter definierten Bedingungen – das ist es, was Lighthouse, PageSpeed Insights im unteren Bereich und die meisten Speedtests liefern. Der Vorteil: Der Wert ist sofort da und reagiert unmittelbar auf jede Änderung. Der Nachteil: Er beschreibt einen simulierten Besuch auf einem simulierten Gerät, nicht Ihre Besucher.

Felddaten stammen aus dem Chrome User Experience Report (CrUX): tatsächliche Messwerte echter Nutzer, gesammelt über ein fortlaufendes Fenster der letzten 28 Tage. Diese Werte zählen für die Bewertung durch Google. Bewertet wird dabei das 75. Perzentil – erst wenn drei Viertel aller gemessenen Aufrufe unter dem Schwellenwert liegen, gilt die Seite als bestanden. Der Durchschnitt genügt also nicht, und ein einzelner guter Testlauf sagt gar nichts.

Daraus folgt eine unbequeme Eigenschaft: Nach einer Optimierung dauert es Wochen, bis sich die Felddaten bewegen, weil das Messfenster erst durchlaufen muss. Und Seiten mit wenig Verkehr haben überhaupt keine Felddaten; für sie bleibt nur die Laborbetrachtung.

Der bekannte Punktwert von 0 bis 100 in PageSpeed Insights ist übrigens ein reiner Laborwert und kein Google-Ranking. Er ist nützlich, um Fortschritt zu sehen, taugt aber nicht als Ziel. Eine Seite mit 78 Punkten und guten Felddaten ist besser dran als eine mit 96 Punkten und schlechten.

Womit Sie messen

  • PageSpeed Insights ist der naheliegende Einstieg, weil es beides zeigt: oben die Felddaten aus CrUX, darunter den Lighthouse-Lauf mit konkreten Empfehlungen.
  • Lighthouse in den Chrome DevTools liefert denselben Laborlauf lokal, auch für Seiten hinter einem Login oder auf einem Testsystem.
  • Der Core-Web-Vitals-Bericht in der Search Console zeigt, wie sich das Problem über die ganze Website verteilt, statt Seite für Seite. Wie Sie den Zugang einrichten, beschreibt ein eigenes Tutorial.
  • WebPageTest ist das Werkzeug für den zweiten Blick: Wasserfalldiagramm, Testläufe aus verschiedenen Regionen, Verbindungsprofile.

Zwei Empfehlungen aus älteren Fassungen dieses Beitrags sind hinfällig: Den Speedtest von Pingdom gibt es nicht mehr, und YSlow von Yahoo wird seit Jahren nicht mehr gepflegt. Die früheren Browser-Erweiterungen für PageSpeed sind in Lighthouse aufgegangen.

Bilder: der größte Hebel bei den wenigsten Zeilen

In den meisten Projekten ist das größte Element im Sichtbereich ein Bild – und damit sind Bilder der direkteste Weg, den LCP zu verbessern.

Moderne Formate verwenden. AVIF und WebP liefern bei vergleichbarer Qualität deutlich kleinere Dateien als JPEG und PNG. Beide werden von allen aktuellen Browsern unterstützt; mit <picture> liefern Sie trotzdem einen Rückfall aus:

<picture>
  <source srcset="/bilder/hero.avif" type="image/avif">
  <source srcset="/bilder/hero.webp" type="image/webp">
  <img src="/bilder/hero.jpg" width="1600" height="900"
       alt="Werkhalle mit Montagelinie" fetchpriority="high">
</picture>

Drei Details an diesem Beispiel sind wichtiger, als sie aussehen. width und height reservieren den Platz, bevor die Datei da ist – das ist die wirksamste Einzelmaßnahme gegen CLS. fetchpriority="high" weist den Browser an, dieses Bild vorzuziehen; es gehört an das LCP-Bild und an kein anderes. Und das alt-Attribut beschreibt den Inhalt, wofür das Tutorial zum Alt-Attribut die Details liefert.

Lazy Loading, aber nicht überall. Bilder unterhalb des sichtbaren Bereichs lädt der Browser mit loading="lazy" erst, wenn sie gebraucht werden:

<img src="/bilder/detail-3.avif" width="800" height="600"
     alt="Nahaufnahme der Schweißnaht" loading="lazy" decoding="async">

Der klassische Fehler dabei: loading="lazy" auf dem Titelbild. Dann verzögert der Browser genau das Element, an dem der LCP gemessen wird, und der Wert wird schlechter statt besser. Faustregel: alles im ersten Bildschirmbereich normal laden, alles darunter lazy.

Passende Größen ausliefern. Ein 2400 Pixel breites Foto auf einem 390 Pixel breiten Handydisplay ist verschwendete Bandbreite. Mit srcset und sizes liefert der Browser die passende Variante aus.

JavaScript und CSS

INP ist praktisch immer ein JavaScript-Problem: Der Hauptthread des Browsers ist beschäftigt und kommt nicht dazu, auf die Eingabe zu reagieren. Die Ursachen liegen selten im eigenen Code, sondern in dem, was über die Jahre dazugekommen ist – Tag-Manager-Container, Chat-Widgets, Bewertungs-Einbindungen, A/B-Test-Werkzeuge, Consent-Banner.

Der ehrlichste Schritt ist deshalb eine Inventur: Welche dieser Einbindungen erfüllt heute noch einen Zweck? Was bleibt, lädt möglichst spät (defer), außerhalb des Hauptthreads oder erst auf Interaktion – ein Chat-Fenster muss nicht beim Seitenaufbau da sein.

Beim CSS geht es um das Gegenteil: Stylesheets blockieren das Rendering, solange sie nicht geladen sind. Reduzieren Sie, was im <head> steht, auf das, was für den sichtbaren Bereich nötig ist. Schriften laden Sie am besten selbst gehostet, mit font-display: swap und einem preload für den tatsächlich verwendeten Schnitt – nebenbei erspart Ihnen das die datenschutzrechtliche Diskussion über extern eingebundene Schriftdienste.

Server, Übertragung, Hosting

Alles bisher Genannte setzt an dem an, was der Browser tut. Ein Teil der Zeit vergeht aber, bevor überhaupt etwas ankommt.

Kompression. Textbasierte Ressourcen – HTML, CSS, JavaScript, SVG, JSON – gehören komprimiert ausgeliefert. Brotli ist dabei gzip überlegen und wird von allen aktuellen Browsern unterstützt. Bei den meisten Webservern ist es eine Konfigurationszeile.

HTTP/2 und HTTP/3. HTTP/3 setzt auf QUIC statt TCP auf und verhält sich deutlich robuster bei Paketverlust – also genau in Mobilfunknetzen. Die meisten CDNs und viele Hoster bieten es an, oft muss es nur eingeschaltet werden.

Caching. Statische Dateien mit langer Gültigkeit und einem Versionsstempel im Dateinamen auszuliefern, ist die einfachste Maßnahme mit dauerhafter Wirkung:

Cache-Control: public, max-age=31536000, immutable

Die Serverleistung selbst. Das passende Hosting wählen Sie nach dem System, das darauf laufen soll – nicht nach Speicherplatz oder Traffic-Volumen. Ausschlaggebend sind Rechenleistung, Datenbankgeschwindigkeit und die Antwortzeit des Servers. Für eine gewöhnliche Website mit einem Content-Management-System reicht ein solides Standardpaket. Ein Shopsystem wie Magento hat andere Ansprüche; welche das im Einzelnen sind, behandeln die SEO-Tipps für den Magento-Shop. Wo Umsatz an der Seite hängt, ist Sparen an dieser Stelle die teuerste Variante.

Wie Sie vorgehen

Messen Sie zuerst die Felddaten, nicht den Laborwert – sonst optimieren Sie an einem Problem, das Ihre Besucher gar nicht haben. Nehmen Sie sich dann die Vorlagen vor, nicht einzelne Seiten: Ein Shop hat drei bis fünf Seitentypen, und eine Korrektur an der Produktvorlage wirkt auf zehntausend URLs.

Und rechnen Sie mit Wochen, bis sich das im Bericht zeigt. Page Speed ist einer der Bausteine, die wir uns bei einer Suchmaschinenoptimierung früh ansehen, weil die Ergebnisse spät sichtbar werden – nicht, weil sie besonders spektakulär wären.