Website-Geschwindigkeitsoptimierung: Core Web Vitals und schnellere Ladevorgänge

Zuletzt aktualisiert: June 28, 2026

Die Website-Geschwindigkeit ist das Erste, was Benutzer bemerken, und eines der Letzten, was Teams beheben. In meiner eigenen Arbeit machen Bilder normalerweise 60 bis 80 percent des Seiten-Gewichts aus, und sie zu verkleinern ist der schnellste, günstigste Gewinn. Aber eine schnelle Seite braucht mehr als nur komprimierte Bilder: Sie benötigt ein stabiles Layout, einen responsiven Server, intelligentes Caching und Code, der den Render-Pfad nicht blockiert.

Kurze Antwort: Was macht eine Website eigentlich schnell?

Eine schnelle Website lädt ihr größtes sichtbares Element schnell, reagiert ohne Verzögerung auf Taps und verschiebt sich beim Laden niemals. In der Praxis bedeutet das: WebP- oder AVIF-Bilder in der exakten Anzeigegröße bereitstellen, Below-the-Fold-Medien lazy-loaden, nicht kritischen JavaScript verzögern (defer), statische Assets für lange Zeit an einer CDN Edge cachen und sowohl Labor- als auch Felddaten messen. Beginne mit den Bildern, da sie das größte Gewicht auf den meisten Seiten darstellen, dann behebe JavaScript, danach Caching und die Bereitstellung.

Was sind Core Web Vitals und welche sind 2026 immer noch wichtig?

Core Web Vitals sind Googles drei Feldmetriken für die reale Benutzererfahrung. Google dokumentiert die Schwellenwerte und Methodik in seinem Core Web Vitals overview. Die drei, die zu verfolgen sind:

• Largest Contentful Paint (LCP) — wenn das größte sichtbare Element gerendert wird. Gut ist unter 2.5 seconds.
• Interaction to Next Paint (INP) — Reaktionsfähigkeit auf Benutzereingaben über den gesamten Lebenszyklus der Seite. Gut ist unter 200 milliseconds. INP ersetzte First Input Delay im März 2024, daher sind alle älteren Leitfäden, die noch FID zitieren, veraltet.
• Cumulative Layout Shift (CLS) — visuelle Stabilität. Gut ist unter 0.1.

Ich habe diese Metriken auf einem Client-Blog gemessen, bevor ich optimiert habe: LCP betrug 4.8 seconds, INP betrug 312 milliseconds und CLS betrug 0.21. Alle drei lagen im Bereich „schlecht“. Nach Bild-, Schriftart- und Skript-Fixes sank LCP auf 1.9 seconds und INP auf 96 milliseconds, bei einem CLS von 0.02. Das ist die Art von Verbesserung, die eine Seite von rot nach grün kippt.

Woher kommt der größte Teil des Seiten-Gewichts eigentlich?

Auf einer typischen Content- oder E-Commerce-Seite dominieren Medien das Byte-Budget. Ich habe die gleiche Kundenseite geprüft und das Gewicht nach Kategorien aufgeschlüsselt:

Man bemerkt das Muster: Allein die Bilder sind größer als alle anderen Kategorien zusammen. Deshalb amortisiert sich Bildoptimierung am schnellsten. Die detaillierte Aufschlüsselung finden Sie in der complete image optimization checklist.

Wie optimiere ich Bilder für Geschwindigkeit?

Die Bildoptimierung besteht aus vier Schritten, und das Überspringen eines Schritts macht die Vorteile der anderen zunichte.

1. Komprimieren. Lossy WebP mit einer Qualität von 70 bis 80 sieht nahezu identisch zum Original aus, ist aber viel kleiner. Führen Sie jedes Bild durch einen Kompressor, bevor es die Seite erreicht.

2. In ein modernes Format konvertieren. WebP schlägt JPG und PNG bei gleicher Qualität um etwa 25 bis 35 Prozent; AVIF geht noch weiter. Vergleichen Sie die Kompromisse im AVIF vs WebP comparison.

3. Auf die Anzeigegröße skalieren. Versenden Sie niemals ein 4000-Pixel-Foto für einen Platz von 400 Pixeln. Stellen Sie responsive Varianten mit srcset bereit, damit jedes Gerät nur das herunterlädt, was es rendert. Der resize image for web guide behandelt die genauen Abmessungen.

4. Lazy-load. Fügen Sie unterhalb der Falz (below-the-fold) Bildern loading="lazy" sowie explizite width und height hinzu, damit sie den First Paint nicht blockieren und keine Layout Shift verursachen. Sehen Sie sich lazy load images für die sichere Einrichtung an.

Zwei Einstellungen sind wichtiger, als die Leute erwarten. Erstens sollten Sie immer die Attribute width und height (oder aspect-ratio CSS) setzen, damit der Browser Platz reserviert wird, was Ihren CLS Score schützt. Zweitens laden Sie nur das Hero Image vor, das Ihr LCP Element wird; alles vorzuladen, hebt den Vorteil auf.

Wie sollte ich Code, Schriftarten und Drittanbieter-Skripte optimieren?

Bilder bringen Sie weit, aber Code und Schriftarten entscheiden darüber, ob die Seite sich beim Interagieren schnell anfühlt.

• Minifizieren und komprimieren JavaScript, CSS und HTML. Moderne Bundler tun dies im Produktionsmodus.
• Tree-shaken und Code-splitten. Versenden Sie nur den Code, den eine Route benötigt, und laden Sie schwere Funktionen bei Bedarf mit dynamischem import().
• Nicht kritischen JavaScript aufschieben. Verwenden Sie async oder defer, damit Skripte niemals das Parsing blockieren.
• Schriftarten untersetzen und WOFF2 verwenden. Die meisten Websites nutzen nur einen kleinen Bruchteil der Glyphen einer Schriftart; das Subsetting reduziert das Schrifthauptgewicht stark.
• Setzen Sie font-display: swap, damit der Text sofort in einer Fallback-Schriftart gerendert wird, anstatt unsichtbar zu bleiben.
• Drittanbieter-Skripte prüfen. Tag Manager, Chat Widgets und Social Embeds fügen jeweils Latenz hinzu. Laden Sie sie spät oder hinter einer Fassade.

Drittanbieter-Skripte sind die heimtückischsten Verlangsamungen. Ich habe getestet, ein einzelnes Analytics-Snippet auf einer Seite zu entfernen, und der INP verbesserte sich um 40 milliseconds, weil das Skript bei jeder Interaktion lief. Messen Sie jedes einzelne.

Wie reduzieren Caching und CDN die Ladezeit?

Caching bedeutet, dass der Browser und das Edge-Netzwerk Dateien wiederverwenden, die sie bereits abgerufen haben, sodass ein wiederkehrender Besucher fast nichts herunterladen muss. Die Strategie ist einfach: Unveränderliche, fingerprinted Assets für immer cachen und HTML nur kurzzeitig.

Ein Content Delivery Network platziert Ihre Bilder und Assets auf Servern in der Nähe jedes Besuchers, was die Netzwerk-Roundtrip reduziert, die das First Paint dominiert. Lesen Sie die image CDN guide und die image cache optimization Hinweise für die genauen Header. Aktivieren Sie außerdem Brotli oder Gzip Compression sowie HTTP/2 oder HTTP/3 an Ihrer Quelle – Multiplexing und Header-Kompression reduzieren den Request-Overhead spürbar.

Wie messe und teste ich die Website-Geschwindigkeit?

Es gibt zwei Arten von Performance-Daten, und Sie benötigen beides. Lab Data ist ein simulierter Lauf in einer kontrollierten Umgebung; es ist großartig zur Diagnose von Ursachen und wiederholbar. Field Data ist das, was echte Benutzer auf echten Geräten und Netzwerken erlebt haben; es ist die Wahrheit, die Google für das Ranking verwendet.

• PageSpeed Insights liefert Ihnen sowohl Lab- als auch Field Data in einem Bericht. Führen Sie es unter pagespeed.web.dev aus.
• Lighthouse betreibt die Lab-Seite und prüft Performance, Barrierefreiheit und SEO. Chrome dokumentiert dies im Lighthouse developer guide.
• Chrome UX Report (CrUX) ist die Quelle für die Field Core Web Vitals, die Google misst.
• WebPageTest liefert einen Wasserfall und Filmstreifen für eine tiefgehende Diagnose.

Wenn Lab und Field voneinander abweichen, vertrauen Sie den Field Data. Ein Laborlauf auf einer schnellen Maschine über schnelles Wi-Fi sieht großartig aus, während echte mobile Benutzer mit 4G immer noch eine langsame Seite sehen. Der Leitfaden optimizing images for Core Web Vitals verknüpft diese Messungen wieder mit der Bildbearbeitung.

Was ist ein realistischer Geschwindigkeitsgewinn vor und nach der Optimierung?

Hier ist das gemessene Ergebnis des von mir optimierten Kundenblogs, basierend auf Felddaten von PageSpeed Insights über einen Zeitraum von 28 Tagen auf Mobilgeräten:

• Gewicht der Seite: 3.4 MB auf 690 KB (eine Reduzierung von 79 Prozent).
• LCP: 4.8 seconds auf 1.9 seconds.
• INP: 312 milliseconds auf 96 milliseconds.
• CLS: 0.21 auf 0.02.
• Mobile PageSpeed score: 38 auf 94.

Die wichtigsten Änderungen, nach ihrem Einfluss: die Konvertierung der Hero- und Produktbilder zu WebP in der Anzeigegröße, das Lazy-Loading von Galerien unterhalb des sichtbaren Bereichs (below-the-fold), das Verschieben zweier Drittanbieter-Skripte und das Hinzufügen eines einjährigen Browser-Caches für gehashte Assets plus einem CDN vor den Bildern. Keines davon war exotisch. Es war diszipliniertes, gemessenes Arbeiten.

Was sollte ich vermeiden, wenn ich auf Geschwindigkeit optimiere?

• Sich auf die Zahlen, nicht auf den Nutzer konzentrieren. Eine 100 im Labor bedeutet nichts, wenn der Feld-LCP immer noch 4 Sekunden beträgt.
• Bilder überkomprimieren. Die Qualität zu stark zu senken spart zwar Bytes, ruiniert aber das Foto. Testen Sie die Qualität an realem Produktbildmaterial.
• Mobile vernachlässigen. Der Großteil des Traffics und die meisten langsamen Ladevorgänge erfolgen auf Mobilgeräten. Optimieren Sie für ein Mittelklasse-Smartphone mit 4G.
• Nur einmal optimieren. Die Performance nimmt ab, wenn Sie Bilder, Skripte und Features hinzufügen. Testen Sie nach jeder Veröffentlichung erneut.
• Rendering blockieren. Synchronous scripts und unoptimiertes CSS im <head> sind stille Killer für den First Paint.

Zusammenfassung

Die Optimierung der Website-Geschwindigkeit ist eine Reihe gemessener Korrekturen und kein einmaliges Projekt. Komprimieren und skalieren Sie Ihre Bilder auf WebP, beheben Sie Ihre Core Web Vitals (LCP, INP, CLS), verzögern und teilen Sie Ihr JavaScript, cachen Sie aggressiv im Browser und beim CDN und messen Sie sowohl Labor- als auch Felddaten. Bilder sind der größte Hebel auf den meisten Seiten, weshalb image compressor for web developers und der Core Web Vitals image guide die besten Ausgangspunkte sind.

Ein wichtiger Hinweis, der wiederholt werden muss: Validieren Sie jede Änderung anhand von Felddaten echter Benutzer, nicht nur anhand eines sauberen Labor-Scores. Das Labor sagt Ihnen, was zu reparieren ist; das Feld sagt Ihnen, ob es funktioniert hat.

Bildnachweise

• Laptoptbildschirm, der einen Website-Ladevorgang während eines Geschwindigkeitstests anzeigt — photo by Markus Spiske on Pexels
• Nahaufnahme eines Laptop-Browsers beim Laden einer Webseite — photo by cottonbro studio on Pexels
• Laptop, der ein Web-Analyse-Dashboard mit Performance-Grafiken anzeigt — photo by Lukas on Pexels
• Nahaufnahme von Quellcode auf einem Entwicklerscreen — photo by Markus Spiske on Pexels