Wie wir schnelle Websites bauen: ein Praxisleitfaden zu den Core Web Vitals

Eine langsame Website verliert Menschen, bevor sie überhaupt die Chance bekommt, zu überzeugen. Jemand tippt auf einem Android-Mittelklassehandy über eine schwankende Verbindung auf Ihren Link, wartet, sieht das Layout hin und her springen, tippt auf eine Schaltfläche, die eine halbe Sekunde lang nichts tut, und geht wieder. Kein noch so cleverer Text übersteht dieses Erlebnis. Bei Innovation T behandeln wir Performance als Produktmerkmal, nicht als Aufräumaufgabe, und die Core Web Vitals sind die Sprache, die Google uns gibt, um sie zu messen.

Dies ist der Praxisleitfaden, den wir tatsächlich verwenden, wenn wir bauen. Er erklärt in einfachen Worten, was die Metriken bedeuten, und gibt Ihnen dann die konkreten Taktiken an die Hand, zu denen wir bei echten Projekten greifen.

Was die Metriken tatsächlich messen

Core Web Vitals sind drei nutzerzentrierte Metriken, plus eine Labormetrik, die Ihnen hilft, Probleme zu finden, bevor Ihre Nutzer es tun. Vergessen Sie einen Moment die Abkürzungen und denken Sie daran, was der Nutzer empfindet.

LCP (Largest Contentful Paint) beantwortet eine einfache Frage: Wie lange dauert es, bis das Hauptelement dieser Seite erscheint? Dieses "Hauptelement" ist in der Regel ein Hero-Bild, eine Überschrift oder ein großer Textblock. Wenn Ihr LCP bei 4 Sekunden liegt, starrt Ihr Besucher 4 Sekunden lang auf einen weitgehend leeren Bildschirm. Google betrachtet 2,5 Sekunden oder weniger als gut.

INP (Interaction to Next Paint) misst die Reaktionsfähigkeit. Wenn jemand tippt, klickt oder etwas eingibt, wie lange dauert es, bis die Seite sichtbar reagiert? INP hat die ältere Metrik First Input Delay abgelöst, weil es alle Interaktionen über den gesamten Besuch hinweg betrachtet, nicht nur die erste. Eine träge Schaltfläche, ein Menü, das eine Spur zu spät aufgeht, ein Formularfeld, das stockt: das ist schlechtes INP. Gut sind 200 Millisekunden oder weniger.

CLS (Cumulative Layout Shift) misst die visuelle Stabilität. Es ist der Ärger, einen Absatz zu lesen und ihn springen zu sehen, weil ein Bild oder eine Anzeige darüber geladen wurde, oder nach einer Schaltfläche zu greifen, die plötzlich unter dem Finger wegrutscht. Ein gutes CLS liegt bei 0,1 oder weniger.

TBT (Total Blocking Time) ist das Laborgegenstück zu INP. Es misst, wie lange der Haupt-Thread während des Seitenladens blockiert und nicht in der Lage war zu reagieren. Sie sehen TBT in Lighthouse und anderen Laborwerkzeugen. Ein hohes TBT sagt fast immer ein schlechtes INP im Feld voraus, deshalb nutzen wir es während der Entwicklung als Frühwarnung.

Das Muster ist hier entscheidend. Bei LCP geht es um das Laden, bei INP und TBT um die Interaktivität und bei CLS um die Stabilität. Der Großteil der Performance-Arbeit läuft darauf hinaus, weniger an den Browser zu senden und weniger Arbeit auf dem Haupt-Thread zu leisten. Alles Folgende ist eine Variante dieser beiden Ideen.

Bildstrategie: meist der größte Gewinn

Bilder sind auf den meisten Seiten das Schwerste, und das Hero-Bild ist häufig das LCP-Element, deshalb fangen wir hier an.

• Liefern Sie moderne Formate aus. AVIF und WebP sind bei gleicher Qualität dramatisch kleiner als JPEG oder PNG. Wir liefern AVIF mit einem WebP-Fallback aus und greifen nur dann zu älteren Formaten, wenn wir wirklich müssen.
• Skalieren Sie Bilder auf ihre Anzeigegröße und liefern Sie responsive Varianten. Verwenden Sie srcset und sizes, damit ein Handy ein handygroßes Bild herunterlädt und nicht ein 2000 Pixel breites Desktop-Asset, das im Browser herunterskaliert wird.
• Legen Sie stets explizite width und height fest (oder ein CSS-aspect-ratio). Das reserviert den Platz, bevor das Bild lädt, und ist die mit Abstand wirksamste Lösung für CLS.
• Priorisieren Sie das LCP-Bild und laden Sie den Rest verzögert (lazy). Fügen Sie dem Hero fetchpriority="high" hinzu und allem unterhalb des sichtbaren Bereichs loading="lazy", damit Bilder außerhalb des Bildschirms während des kritischen ersten Renderings nicht um Bandbreite konkurrieren.
• Erwägen Sie einen Preload-Hinweis für das Hero-Bild, damit der Browser mit dem Abruf beginnt, bevor er das CSS fertig geparst hat.

Das Hero-Bild richtig hinzubekommen, drückt den LCP oft schon allein unter die Marke von 2,5 Sekunden. Dieselbe Disziplin gilt für Video: Verwenden Sie ein Poster-Bild und spielen Sie auf Mobilgeräten niemals automatisch ein schweres Hintergrundvideo ab.

Schriftladen: Schluss mit unsichtbarem Text

Web-Schriften sind ein stiller LCP- und CLS-Killer. Eine Seite wartet auf eine benutzerdefinierte Schrift, zeigt nichts an (oder zeigt Ersatztext, der dann umbricht), und der Nutzer zahlt dafür.

• Fügen Sie font-display: swap hinzu, damit Text sofort in einer Ersatzschrift gerendert wird und zur Web-Schrift wechselt, sobald diese eintrifft. Nutzer können lesen, während die Schrift lädt.
• Hosten Sie Ihre Schriften selbst, statt sie von einem Dritten zu beziehen. Das entfernt eine zusätzliche Verbindung und gibt Ihnen die Kontrolle über das Caching.
• Laden Sie die ein oder zwei kritischen Schriftdateien vorab (preload), damit sie früh heruntergeladen werden.
• Erstellen Sie ein Subset der Schriften mit den Zeichen und Schnitten, die Sie tatsächlich verwenden. Jeden Schnitt einer Familie auszuliefern, während Sie zwei nutzen, ist reine Verschwendung.
• Wählen Sie eine Ersatzschrift mit ähnlichen Metriken oder stimmen Sie sie mit size-adjust ab, damit der Wechsel keinen sichtbaren Umbruch verursacht. Das schützt CLS.

JavaScript auf dem Haupt-Thread reduzieren

JavaScript ist der Ort, an dem gutes INP und TBT zugrunde gehen. Jedes Skript, das der Browser parsen, kompilieren und ausführen muss, blockiert den Haupt-Thread, und solange dieser Thread beschäftigt ist, kann er nicht auf Eingaben reagieren. Dies ist der schwierigste und wertvollste Bereich, den es richtig zu machen gilt.

• Liefern Sie weniger aus. Prüfen Sie Ihr Bundle und entfernen Sie Abhängigkeiten, die Sie nicht brauchen. Eine Datumsbibliothek, ein riesiges UI-Kit für eine einzige Komponente, drei sich überschneidende Hilfsbibliotheken: das summiert sich schnell.
• Teilen Sie den Code auf (Code-Splitting) und laden Sie verzögert. Laden Sie das JavaScript für eine Route oder eine Komponente nur dann, wenn es benötigt wird, nicht alles im Voraus. Ein modales Fenster, das sich per Klick öffnet, muss nicht im initialen Bundle stecken.
• Verzögern Sie unkritische Skripte. Analyse-Werkzeuge, Chat-Widgets und Marketing-Tags sollten laden, nachdem die Seite interaktiv ist, und nicht mit ihr konkurrieren. Verwenden Sie defer oder laden Sie sie im Leerlauf (on idle).
• Zerlegen Sie lange Aufgaben. Jede Aufgabe über 50 Millisekunden blockiert die Interaktion. Stückeln Sie schwere Arbeit und geben Sie die Kontrolle an den Haupt-Thread zurück, damit der Browser zwischen den Stücken auf Eingaben reagieren kann.
• Bevorzugen Sie die Plattform. Vieles, wofür Menschen Bibliotheken installieren (Formularvalidierung, einfache Animation, Datumsformatierung), erledigt der Browser inzwischen nativ. Wir bauen Seiten mit hoher Conversion und weniger Code, ein Thema, das wir in unserem Leitfaden zur Anatomie einer Landingpage mit hoher Conversion behandeln.

Bedingtes Aktivieren schwerer WebGL- und Animationsbibliotheken

Hier trennt die Praxiserfahrung die guten Websites von den ruckelnden. Reiche Visuals, WebGL-Szenen und physikbasierte Animation sehen auf einem High-End-Laptop atemberaubend aus und verwandeln ein Budget-Handy in eine Diashow. Die Antwort ist nicht, sie zu entfernen, sondern sie bedingt auszuliefern.

• Führen Sie schweres WebGL nur aus, wenn eine echte GPU vorhanden ist. Bevor wir eine aufwendige 3D-Szene einbinden, erkennen wir den Rendering-Kontext und prüfen den gemeldeten Renderer. Bei einem Software-Renderer oder einem Gerät, das eine schnelle Fähigkeitsprüfung nicht besteht, weichen wir auf ein statisches Bild oder eine leichtgewichtige CSS-Version aus, anstatt auf eine vollständige WebGL-Schleife.
• Respektieren Sie den Nutzer. Berücksichtigen Sie die Media-Query prefers-reduced-motion und überspringen Sie nicht essenzielle Animationen für alle, die darum bitten. Überspringen Sie zudem schwere Effekte, wenn das Gerät wenige CPU-Kerne meldet oder der Save-Data-Hinweis aktiv ist.
• Verlagern Sie Animationen nach CSS, wo immer Sie können. CSS-Transformationen und Opazitätsanimationen laufen auf dem Compositor-Thread und sind günstig. Ein Hover-Effekt, ein Einblenden, ein dezentes Gleiten: das gehört in CSS, nicht in eine JavaScript-Animationsbibliothek, die auf dem Haupt-Thread läuft.
• Drosseln Sie Ihre Render-Schleife. Wenn Sie eine Animations-Frame-Schleife ausführen müssen, begrenzen Sie die Bildrate und pausieren Sie sie vollständig, wenn das Element aus dem Sichtbereich scrollt oder der Tab verborgen ist. Eine Schleife, die für ein Canvas außerhalb des Bildschirms mit voller Geschwindigkeit neu zeichnet, ist reine Verschwendung, die sich als schlechtes INP zeigt.
• Laden Sie die schwere Bibliothek erst, wenn der Effekt tatsächlich sichtbar ist. Verwenden Sie einen Intersection Observer, damit das WebGL- oder Animations-Bundle heruntergeladen wird, wenn der Nutzer in seine Nähe scrollt, und nicht beim initialen Laden.

Verzögertes Laden, Caching und CDN

Die letzte Schicht dreht sich darum, Arbeit nicht doppelt zu erledigen und nicht aus der Ferne auszuliefern.

• Laden Sie Inhalte unterhalb des sichtbaren Bereichs verzögert: Bilder, Iframes, Einbettungen und schwere Komponenten. Der Browser bietet natives loading="lazy" für Bilder und Iframes, und ein Intersection Observer deckt alles andere ab.
• Cachen Sie aggressiv. Statische Assets mit inhaltsgehashten Dateinamen können ein Jahr lang gecacht werden, denn eine Änderung an der Datei ändert den Dateinamen. Setzen Sie dafür lange Cache-Control-Header und kürzere für HTML.
• Nutzen Sie ein CDN. Assets von einem Edge-Standort nahe bei Ihrem Nutzer auszuliefern, senkt die Latenz direkt, was dem LCP hilft. Ein CDN fängt außerdem Verkehrsspitzen ab und nimmt Last von Ihrem Ursprungsserver.
• Komprimieren Sie alles. Brotli für Textassets schlägt gzip und sollte auf Server- oder CDN-Ebene standardmäßig aktiviert sein.
• Verkürzen Sie die Server-Antwortzeit. Ein langsames erstes Byte vergiftet jede nachgelagerte Metrik. Cachen Sie gerenderte Seiten, wo Sie können, und halten Sie Datenbankarbeit vom kritischen Pfad fern. Wenn wir die APIs hinter diesen Seiten entwerfen, optimieren wir genau darauf, ein Thema, in das wir in APIs entwerfen, die Entwickler lieben tiefer einsteigen.

Die Performance-Checkliste

Dies ist die nummerierte Liste, die wir vor dem Launch durchgehen.

1. Bestätigen Sie das LCP-Element (in der Regel das Hero-Bild oder die Überschrift) und geben Sie ihm priorisiertes Laden.
2. Liefern Sie AVIF oder WebP aus, responsiv dimensioniert mit srcset und sizes.
3. Legen Sie explizite Abmessungen oder ein aspect-ratio auf jedem Bild und jeder Medieneinbettung fest, um Layout-Verschiebungen zu unterbinden.
4. Laden Sie jedes Bild, jeden Iframe und jede schwere Komponente unterhalb des sichtbaren Bereichs verzögert.
5. Hosten Sie Schriften selbst, erstellen Sie ein Subset, laden Sie die kritischen Dateien vorab und verwenden Sie font-display: swap.
6. Prüfen Sie das JavaScript-Bundle und entfernen oder ersetzen Sie schwere Abhängigkeiten.
7. Teilen Sie den Code nach Route auf und laden Sie Komponenten verzögert, die beim ersten Rendering nicht benötigt werden.
8. Verzögern Sie Analyse-, Chat- und Marketing-Skripte bis nach dem Erreichen der Interaktivität.
9. Zerlegen Sie jede Haupt-Thread-Aufgabe, die länger als 50 Millisekunden dauert, und geben Sie zwischen den Stücken die Kontrolle ab.
10. Aktivieren Sie WebGL erst nach einer Prüfung auf eine echte GPU, mit einem statischen Fallback für schwache Geräte.
11. Verlagern Sie Animationen auf CSS-Transformationen und Opazität und berücksichtigen Sie prefers-reduced-motion.
12. Drosseln und pausieren Sie Render-Schleifen, wenn sie außerhalb des Bildschirms sind oder der Tab verborgen ist.
13. Setzen Sie lange Cache-Header auf gehashte statische Assets und kürzere auf HTML.
14. Liefern Sie über ein CDN mit aktivierter Brotli-Komprimierung aus.
15. Messen Sie während der Entwicklung mit Laborwerkzeugen (Lighthouse, TBT) und validieren Sie nach dem Release mit Felddaten (echte LCP, INP, CLS).

Diesen letzten Punkt überspringen die Leute gern. Laborwerte sagen Ihnen, wo die Probleme liegen, aber nur Felddaten sagen Ihnen, was Ihre echten Nutzer auf ihren echten Geräten und Netzwerken erleben. Wir bauen für das Labor und verifizieren im Feld.

Schnelligkeit ist eine Design-Entscheidung, die Sie bewusst treffen, immer wieder, auf jeder Ebene. Machen Sie es gut, dann kümmern sich die Metriken um sich selbst, denn sie sind nichts weiter als Messungen einer Website, die den Menschen respektiert, der sie nutzt.

Wenn sich Ihre Website langsam anfühlt und Sie nicht sicher sind, wohin die Zeit verschwindet, ist das genau die Art von Problem, die wir mögen. Werfen Sie einen Blick auf unsere Leistungen oder nehmen Sie Kontakt auf, und wir helfen Ihnen, etwas Schnelles zu bauen.