Website-Geschwindigkeit optimieren: Bilder, Fonts, Skripte
Warum eine Website langsam lädt, hat meist drei Ursachen: zu große Bilder, spät ladende Fonts und angesammelte Skripte Dritter. Was zuerst behoben wird.
rabbitclip-TeamVeröffentlicht: 5 Min. Lesezeit
Kurz gesagt
Eine langsam ladende Website hat selten eine einzige Ursache; meist ist es die Summe aus drei Quellen: Bilder, die größer sind als nötig, Fonts, die das Sichtbarwerden der Seite verzögern, und Skripte Dritter, die sich über die Zeit ansammeln. Werden alle drei zusammen angegangen, macht das einen spürbaren Unterschied; nur eine davon zu beheben reicht meist nicht.
Google misst Geschwindigkeit nicht mehr nur daran, wie schnell eine Seite erscheint, sondern auch daran, wie schnell der Bildschirm reagiert, sobald jemand auf eine Schaltfläche tippt. Diese Metrik heißt Interaction to Next Paint, kurz INP (web.dev, INP). Geschwindigkeit bedeutet also nicht mehr nur «Ist die Seite geladen», sondern «Lässt sich die Seite tatsächlich nutzen».
Dieser Beitrag nimmt sich die drei Quellen einzeln vor: Bilder, Fonts, Code Dritter. Zu jeder wird gezeigt, wo man ansetzt und was wirklich etwas bringt.
Warum Bilder die größte Last tragen
Der größte Teil des Gesamtgewichts einer Seite stammt meist aus Bildern. Man denke an die Produktgalerie eines Bodenbelag-Herstellers: Eine fünfzig Megabyte schwere Seite bedeutet, je nach Gerät und Verbindung des Besuchers, mehrere Sekunden Wartezeit. Dieses Gewicht verschwindet nicht, solange das Bild nicht in der richtigen Größe und im richtigen Format ausgeliefert wird.
Die Lösung besteht aus zwei Schritten. Erst wird das Bild auf die Größe zugeschnitten, in der es tatsächlich erscheint; ein Bild, das auf dem Handy vierhundert Pixel breit angezeigt wird, sollte nicht mit zweitausend Pixeln ausgeliefert werden. Dann wird das Format gewählt: AVIF und WebP erzeugen bei vergleichbarer Qualität deutlich kleinere Dateien als das ältere JPEG (web.dev, Optimize LCP). Ein Framework wie Next.js automatisiert das, sodass niemand mehrere Versionen von Hand vorbereiten muss.
Warum Fonts eine Seite verlangsamen
Ein eigener Font ist Teil der Markenidentität, verzögert aber falsch geladen das Sichtbarwerden der Seite. Blendet der Browser den Text aus, bis die Font-Datei heruntergeladen ist, sieht ein Besucher ein bis zwei Sekunden lang eine leere Fläche; dieser Effekt wird als «unsichtbarer Text-Flash» bezeichnet.
Die Einstellung font-display: swap beseitigt diese Wartezeit: Der Browser zeigt den Text sofort in einer Systemschrift und tauscht sie aus, sobald der eigene Font geladen ist (web.dev, Best practices for fonts). Die Buchungsseite einer Spa-Kette braucht oft nur zwei Schnittstärken, normal und fett, doch aus der Designdatei werden häufig fünf oder sechs unverändert auf die Live-Seite übernommen; jede zusätzliche Stärke ist ein eigener Download.
Warum Skripte Dritter die heimtückischste Last sind
Analysetools, Live-Chat-Fenster, Werbe-Pixel, Social-Media-Einbettungen: Jedes davon fügt der Seite eine externe JavaScript-Datei hinzu. Diese sammeln sich still an; eine Seite mit fünf oder sechs verschiedenen, über ein Jahr hinzugefügten Tools ist keine Seltenheit.
Das Problem ist, dass diese Skripte den Haupt-Thread des Browsers belegen; solange dieser Code läuft, kann der Browser nicht auf einen Klick reagieren, was INP direkt verschlechtert (web.dev, INP). Alle paar Monate die Liste der genutzten Tools durchzugehen und ein Analyse-Panel zu entfernen, das niemand mehr ansieht, oder ein Chat-Widget, das niemand mehr nutzt, kostet zehn Minuten und lohnt sich.
In welcher Reihenfolge man vorgeht
Alle drei Quellen müssen nicht gleichzeitig behoben werden; eine Reihenfolge macht die Arbeit leichter.
- Aktuellen Stand mit PageSpeed Insights oder der Search Console messen
- Die größten Bilder im ersten Bildschirmbereich auf die richtige Größe und das richtige Format bringen
- Zahl der Font-Stärken reduzieren, font-display: swap ergänzen
- Ungenutzte Skripte Dritter entfernen, den Rest nur bei Bedarf laden
- Nach der Änderung mit demselben Tool erneut messen
Ist Geschwindigkeit nur ein technisches Thema
Geschwindigkeit ist auch eine Marketingentscheidung, weil sie der erste Kontakt eines Besuchers mit der Seite ist. Lädt die Notdienstseite eines Stromerzeuger-Herstellers langsam, kehrt der Besucher zum Suchergebnis zurück und probiert die nächste Firma; dieser Verlust geschieht leise, ohne Beschwerde und ohne Absprungrate, die jemand liest.
Geschwindigkeitsarbeit ist kein einmaliges Projekt, sie gehört in die laufende Wartung. Dieselbe Disziplin gilt, sobald ein neues Tool eingebunden oder ein neues Bild hochgeladen wird.
Was Next.js 16 und React 19 bei der Geschwindigkeit ändern
Next.js 16 und React 19, 2026 längst Standard, treiben Server-Komponenten weiter voran: Der Großteil einer Seite wird auf dem Server vorbereitet und fertig an den Browser gesendet, wodurch die Menge an JavaScript sinkt, die der Browser herunterladen muss. Das ist eine architektonische Entscheidung, die INP unmittelbar verbessert.
Für den Produktkatalog eines Herstellers mit Hunderten Seiten ist der Unterschied konkret: In einem älteren React-Aufbau wird jede Seite im Browser neu gerendert, in der neueren Architektur kommt die Seite fertig an und der Browser übernimmt nur die interaktiven Teile, einen Filter, einen Warenkorb-Button. Bei der Abwägung eines solchen Umstiegs gehört dieser architektonische Unterschied ins Geschwindigkeitsbudget, nicht nur in die optische Auffrischung.
Warum serverseitiges Caching einen Unterschied macht
Eine Seite, die einmal erzeugt und für eine bestimmte Zeit im Cache gehalten wird, statt bei jedem Besuch neu aufgebaut zu werden, erreicht spätere Besucher deutlich schneller. Das ist ein Gewinn, der sich für jede Seite lohnt, deren Inhalt sich nicht oft ändert, eine Über-uns-Seite, eine Leistungsbeschreibung.
Ein Veranstaltungskalender auf der Seite eines Wirtschaftsverbands, der häufig aktualisiert wird, braucht eine kurze Cache-Dauer; eine statische Unternehmensseite kann stundenlang oder sogar tagelang dieselbe zwischengespeicherte Version ausliefern. Die richtige Dauer ergibt sich daraus, wie oft sich der Inhalt tatsächlich ändert.
Falsch eingerichtetes Caching bringt eigene Probleme mit sich: ein alter Preis, der nach einer Aktualisierung noch eine Weile zwischengespeichert bleibt und weiter angezeigt wird, zum Beispiel. Deshalb sollte von Anfang an geplant werden, wann und wie der Cache nach einer Aktualisierung geleert wird.
Bilder, Fonts und Skripte Dritter machen eine Seite zusammen betrachtet nicht nur schneller, sie reagiert auch schneller auf Klicks. In einem Erstgespräch erstellt rabbitclip einen Geschwindigkeitsbericht der aktuellen Seite, damit gemeinsam sichtbar wird, welche Quelle am meisten Last verursacht.
Häufige Fragen
Wo kann ich die Geschwindigkeit meiner Seite messen?
Google PageSpeed Insights und der Core-Web-Vitals-Bericht in der Search Console liefern getrennte Werte für Mobil und Desktop.
Funktioniert AVIF in jedem Browser?
Die meisten aktuellen Browser unterstützen es; eine Seite lässt sich so einrichten, dass sie AVIF liefert, wo es unterstützt wird, und automatisch auf WebP oder JPEG zurückfällt, wo nicht.
Wie viele Skripte Dritter sind zu viel?
Es gibt keine feste Zahl; jedes zusätzliche Skript kostet etwas, deshalb lohnt es sich, regelmäßig zu prüfen, ob jedes einzelne noch wirklich genutzt wird.
Zerstört font-display: swap die Optik der Markenschrift?
Nein, kurz zeigt sich lediglich eine Systemschrift, während der eigene Font lädt; die Markenschrift übernimmt kurz darauf.
Reicht der Umstieg auf Next.js 16 allein für die Geschwindigkeit?
Nein, der architektonische Wandel hilft spürbar, aber ohne Disziplin bei Bildern, Fonts und Skripten reicht er allein nicht aus.
