Website-Performance-Optimierung bedeutet, dass Seiten schneller laden, schneller reagieren und beim Laden stabil bleiben. Google misst das Ergebnis mit drei Core Web Vitals: LCP innerhalb von 2,5 Sekunden, INP von höchstens 200 Millisekunden und CLS von höchstens 0,1. Laut HTTP Archive Web Almanac 2025 bestanden nur 48 % der mobilen Websites alle drei, die meisten Websites können also schneller werden. 2026 beheben sieben Schritte die meisten langsamen Websites. Schritt 1 sind Bilder, weil bei 76 % der mobilen Seiten ein Bild das LCP-Element ist. Schritt 2 ist JavaScript. Die übrigen Schritte betreffen Rendering, Caching, Fonts, blockierende Dateien und Monitoring. Eine Website mit Next.js erhält zum Beispiel Bildskalierung und selbst gehostete Fonts direkt mit. Messen Sie zuletzt mit Felddaten echter Nutzer, nicht nur mit einem Laborwert aus Lighthouse.
Warum ist Website-Performance 2026 wichtig?
Website-Performance ist gleichzeitig ein Rankingfaktor und ein Teil der Nutzererfahrung. Laut Google Search Central werden Core Web Vitals von den Ranking-Systemen von Google verwendet. Google betont aber auch, dass die Suche weiterhin die relevantesten Inhalte zeigt, selbst wenn die Nutzererfahrung auf der Seite schwach ist. Geschwindigkeit ist also ein Tiebreaker in der Suche, keine Abkürzung an gutem Inhalt vorbei. Für Besucher ist der Effekt direkter: Eine langsame Produktseite verliert im Mobilfunknetz die Aufmerksamkeit, bevor das erste Bild erscheint. Der HTTP Archive Web Almanac 2025 zeigt, wie verbreitet langsame Seiten noch sind: Nur 48 % der mobilen Websites bestanden 2025 alle drei Core Web Vitals. Mobil erreichten 62 % der Seiten einen guten LCP-Wert, auf dem Desktop waren es 74 %. In der Praxis verdient der mobile Wert die meiste Aufmerksamkeit. Google weist Mobil und Desktop getrennt aus, und Mobil ist meist der schwächere Wert.
Welche Grenzwerte gelten für die Core Web Vitals?
Google bewertet jede Kennzahl am 75. Perzentil echter Seitenaufrufe.
Schritt 1: Wie optimieren Sie Bilder für einen schnelleren LCP?
Bildoptimierung ist der erste Schritt, weil das größte Element auf den meisten Seiten ein Bild ist. Laut HTTP Archive Web Almanac 2025 haben 76 % der mobilen Seiten ein Bild als LCP-Element. Derselbe Bericht zeigt, dass etwa 16 % bis 17 % der Seiten ausgerechnet dieses LCP-Bild per Lazy Loading laden, ein Anteil, der seit 2024 unverändert ist. Lazy Loading verzögert dann genau die wichtigsten Pixel auf dem Bildschirm. Beginnen Sie mit modernen Formaten: Laut Next.js-Dokumentation sind AVIF-Dateien etwa 20 % kleiner als WebP, brauchen aber etwa 50 % länger für die Kodierung. Geben Sie außerdem immer Breite und Höhe an, damit der CLS niedrig bleibt. Nutzen Sie srcset, damit Smartphones nie Desktop-Bilder laden. Laden Sie zuletzt das Hero-Bild sofort mit hoher Fetch-Priorität und verwenden Sie Lazy Loading nur unterhalb des sichtbaren Bereichs. Eine mit Next.js gebaute Website erhält zum Beispiel Skalierung, moderne Formate und Lazy Loading direkt von der Image-Komponente.
Schritt 2: Wie reduzieren Sie JavaScript, um den INP zu verbessern?
Weniger JavaScript ist der wichtigste Hebel für INP, die Kennzahl für Reaktionsfähigkeit. INP hat First Input Delay am 12. März 2024 als Core Web Vital abgelöst. Laut Google gilt ein INP über 500 Millisekunden als schlecht. Jedes Script konkurriert um den Main Thread, deshalb wirken Klicks und Tippen bei schweren Bundles träge. Teilen Sie erstens den Code pro Route auf, damit Besucher nur das JavaScript der aktuellen Seite laden. Entfernen Sie zweitens ungenutzte Bibliotheken; ein Bundle-Analyzer zeigt die schwersten Abhängigkeiten. Verzögern Sie drittens nicht notwendige Drittanbieter-Scripts wie Chat-Widgets und Tag-Manager bis nach der ersten Interaktion. Teilen Sie zusätzlich lange Tasks in kleinere Stücke auf, damit der Browser zwischendurch auf Eingaben reagieren kann. In der Praxis rendert eine Website mit Next.js und React Server Components viel auf dem Server, sodass der Code der Server Components nicht im Browser-Bundle landet.
Schritt 3: Welche Rendering-Strategie ist am schnellsten: SSG, SSR oder ISR?
Static Site Generation (SSG) ist meist die schnellste Rendering-Strategie, weil das HTML schon existiert, bevor ein Besucher kommt. Ein CDN liefert eine statische Seite ohne jede Datenbankabfrage aus. Server-Side Rendering (SSR) erzeugt das HTML pro Anfrage und passt zu Seiten mit persönlichen oder ständig wechselnden Daten. Incremental Static Regeneration (ISR) liegt dazwischen: Seiten bleiben statisch, werden aber nach einem Intervall oder einer Inhaltsänderung erneuert. Ein Projekt mit Next.js kann alle drei Strategien pro Route kombinieren. Eine Marketingseite kann zum Beispiel statisch sein, ein Blog wird nach dem Veröffentlichen neu generiert und ein Kundendashboard rendert pro Anfrage. Eine Single Page Application, die alles im Browser rendert, ist für öffentliche Seiten oft die langsamste Option, weil Inhalte erst nach dem Ausführen von JavaScript erscheinen. Zusätzlich hilft vorgerendertes HTML Google und anderen Crawlern beim Lesen. Auch 2026 rendert das schnellste Setup den Großteil des HTML im Voraus, daher ist Schritt 3 eine Entscheidung pro Route und nicht pro Website.
Schritt 4: Wie richten Sie Caching und ein CDN ein?
Caching bedeutet, eine fertige Antwort zu speichern, damit Server und Netzwerk beim nächsten Mal weniger Arbeit haben. Schritt 4 baut auf Schritt 3 auf, weil sich eine statische Seite leicht cachen lässt. Geben Sie erstens statischen Dateien wie CSS, JavaScript und Bildern einen langen Browser-Cache. Dateien mit einem Content-Hash im Namen dürfen ein Jahr im Cache bleiben, weil jede neue Version einen neuen Namen bekommt. Schalten Sie zweitens ein CDN vor die Website, damit Besucher Dateien von einem Server in Amsterdam oder Frankfurt laden statt von einem weit entfernten Server. Cachen Sie drittens aufwendige Arbeit auf dem Server, etwa Datenbankabfragen, API-Antworten und gerenderte Seiten. Eine langsame Serverantwort verzögert jede andere Kennzahl, auch den LCP. In der Praxis ist die Antwortzeit des Servers bei WordPress-Websites mit vielen Plugins auch 2026 oft das versteckte Problem. Eine Website mit Next.js kann gerenderte Seiten und abgerufene Daten dagegen gezielt cachen. Prüfen Sie zuletzt die Cache-Header in den Chrome DevTools, denn ein falscher Header schaltet das Caching für die ganze Website ab.
Schritt 5: Wie laden Sie Webfonts ohne springenden Text?
Font-Optimierung ist Schritt 5, der Schritt, der verhindert, dass Text springt, sobald die endgültige Schrift eintrifft. Laut der web.dev-Dokumentation von Google entstehen Layout Shifts oft durch Fonts, die größer oder kleiner dargestellt werden als die Fallback-Schrift. Begrenzen Sie erstens die Zahl der Fontdateien. Zwei Familien mit je zwei oder drei Schnitten reichen zum Beispiel meistens aus. Nutzen Sie zweitens das WOFF2-Format und ein Subset mit nur den Zeichen, die die Website braucht. Laden Sie drittens die ein oder zwei Fonts für den oberen Seitenbereich per Preload. Setzen Sie zusätzlich font-display auf swap oder optional, damit Besucher den Text sofort lesen, statt auf einen Download zu warten. Ein variabler Font kann mehrere Schnittdateien durch eine einzige Datei ersetzen. Eine Website mit Next.js kann next/font nutzen, das Fonts selbst hostet und externe Netzwerkanfragen entfernt. Das Ergebnis: stabiler Text und eine Drittanbieter-Verbindung weniger.
Schritt 6: Wie entfernen Sie render-blockierende Ressourcen?
Eine render-blockierende Ressource ist eine CSS- oder JavaScript-Datei, die der Browser vor der ersten Darstellung laden muss. Nach den Fonts in Schritt 5 nimmt sich Schritt 6 das übrige CSS und die Scripts vor. Jede blockierende Datei kostet einen zusätzlichen Netzwerk-Roundtrip, und im Mobilfunknetz ist jeder Roundtrip spürbar. Binden Sie erstens das wenige kritische CSS für den oberen Seitenbereich inline ein und laden Sie den Rest ohne Blockade. Versehen Sie zweitens Scripts, die nicht vor der ersten Darstellung laufen müssen, mit defer oder async. Nutzen Sie drittens preconnect für die wenigen externen Domains, die die Seite wirklich braucht, etwa einen Zahlungsanbieter oder ein Bild-CDN. Ersetzen Sie zusätzlich schwere Embeds durch eine leichte Fassade. Ein YouTube-Embed von Google kann zum Beispiel zuerst ein statisches Vorschaubild zeigen und den vollständigen Player erst nach einem Klick laden. Ein kurzer Test mit Lighthouse in den Chrome DevTools zeigt die blockierenden Dateien und die Zeitersparnis pro Datei.
Schritt 7: Wie überwachen Sie die Website-Performance dauerhaft?
Dauerhaftes Monitoring ist Schritt 7, der letzte Schritt, weil eine schnelle Website wieder langsamer wird, sobald sich Funktionen, Plugins und Tracking-Scripts ansammeln. Google bietet dafür drei kostenlose Tools. Erstens kombiniert PageSpeed Insights Labordaten aus Lighthouse mit Felddaten echter Chrome-Nutzer aus den vergangenen 28 Tagen. Zweitens erhält, wer die Google Search Console nutzt, einen Core-Web-Vitals-Bericht, der langsame URLs nach Problemtyp gruppiert. Drittens misst die Open-Source-Bibliothek web-vitals echte Nutzerdaten im Browser, bereit für jedes Analytics-Tool. Laut Google meldet PageSpeed Insights das 75. Perzentil für Felddaten, also dasselbe Perzentil wie bei der Bewertung der Core Web Vitals. In der Praxis verhindert ein kurzer Performance-Check vor jedem Release die meisten Rückschritte. Ein Performance-Budget, zum Beispiel eine maximale JavaScript-Menge pro Seite, macht diesen Check objektiv.
Häufig gestellte Fragen
Brauchen Sie einen Lighthouse-Score von 100?
Nein, ein Lighthouse-Score von 100 ist nicht nötig. Core Web Vitals werden mit Felddaten echter Nutzer gemessen und nicht mit einem Laborwert. Lighthouse ist ein Labortest auf einem simulierten Gerät mit einer simulierten Verbindung. Vergleichen Sie zum Beispiel eine Seite mit einem Laborwert von 85 und guten Feldwerten mit einer Seite, die im Labor 100 erreicht. Hat die zweite Seite bei echten Nutzern einen schlechten INP, steht die erste Seite besser da. Schritt 1 ist deshalb der Blick auf die Felddaten mit PageSpeed Insights oder dem Core-Web-Vitals-Bericht in der Google Search Console. In der Praxis sollten Sie zuerst gute Feldwerte für LCP, INP und CLS anstreben, gemessen am 75. Perzentil der Seitenaufrufe. Laut Google Search Central wiegt Relevanz auch 2026 schwerer als die Nutzererfahrung auf der Seite, daher bleibt die Qualität der Inhalte die erste Priorität. Ein Laborwert bleibt als schneller Test vor jedem Release nützlich.
Ist Next.js schneller als WordPress?
Next.js ist nicht automatisch schneller als WordPress, aber das Framework macht ein schnelles Ergebnis leichter erreichbar. Die Geschwindigkeit von WordPress hängt von Hosting, Theme und Plugins ab, und laut W3Techs läuft WordPress im Oktober 2026 auf 39,7 % aller Websites. Erstens kann ein schlankes WordPress-Theme auf gutem Hosting mit Page-Caching alle drei Core Web Vitals bestehen. Zweitens kann ein schwerer Page-Builder mit vielen Plugins Probleme mit INP oder LCP bekommen. Ein React-Framework wie Next.js startet mit vorgerendertem HTML, automatischem Code-Splitting und eingebauter Bild- und Fontoptimierung, sodass viele Verbesserungen schon in der Basis stecken. Die Website von VirtuoLab läuft zum Beispiel selbst auf Next.js mit React Server Components. Der Nachteil ist die Inhaltspflege, denn eine Next.js-Website braucht meist ein Headless CMS, während WordPress einen Editor mitbringt. Schritt 1 jedes fairen Vergleichs ist die Messung von Felddaten für echte Seiten, nicht für eine Demoseite.
Sollten Sie eine bestehende Website optimieren oder neu bauen?
Eine bestehende Website zu optimieren ist die richtige Wahl, wenn die Basis solide ist und die Probleme klar umrissen sind. Typische Beispiele sind große Bilder, fehlendes Caching oder zu viele Scripts. Ein Neubau ist die bessere Investition, wenn ein altes Theme, ein schwerer Page-Builder oder veraltetes Hosting jede Verbesserung blockiert. Prüfen Sie zuerst die Felddaten in PageSpeed Insights für die 5 Seiten mit den meisten Besuchern. Schätzen Sie danach den Aufwand pro Ursache, die Lighthouse meldet. Betreffen die Korrekturen fast jedes Template, ist ein Neubau meist der planbarere Weg. Eine Website mit 8 Seiten auf einem modernen Theme braucht zum Beispiel vielleicht nur Korrekturen bei Bildern und Caching. Ein schwerer Page-Builder in jedem Template spricht eher für einen Neubau. VirtuoLab nennt 2026 für eine Unternehmenswebsite eine Orientierung von 2.000 € bis 8.000 €. Schritt 1 ist ein kostenloses Kennenlerngespräch mit VirtuoLab, danach folgt der genaue Preis.