Bilder, Schriften, Skripte — die drei größten Performance-Killer

Wenn wir eine langsame Website analysieren, finden wir fast immer dieselben drei Ursachen: unoptimierte Bilder, zu viele Webfonts und unnötige JavaScript-Skripte. Diese drei Performance-Killer sind für 80 bis 90 Prozent aller Ladezeit-Probleme verantwortlich. Die gute Nachricht: Alle drei lassen sich mit überschaubarem Aufwand beheben. Hier kommt die Anleitung.

Killer 1: Unoptimierte Bilder

Der mit Abstand häufigste Performance-Killer. Typische Symptome:

• Die Hero-Bilder sind 2-5 Megabyte groß
• Bilder werden als JPEG oder PNG ausgeliefert, obwohl WebP eine bessere Option wäre
• Alle Bilder laden auf einmal beim Seitenaufruf (kein Lazy-Loading)
• Mobile-Besucher bekommen die gleichen großen Bilder wie Desktop-Besucher

Die Konsequenzen sind messbar: Ein einziges unoptimiertes Hero-Bild kann einen Lighthouse-Wert von 90 auf 50 drücken. Bei mobilen Besuchern mit langsamer Verbindung wird aus einer Sekunde Ladezeit schnell eine fünf-Sekunden-Zumutung.

Was Sie tun können:

1. WebP statt JPEG/PNG: WebP ist ein modernes Bildformat, das bei gleicher Qualität 30-50% kleiner ist. Praktisch alle aktuellen Browser unterstützen es. Tools wie Squoosh, TinyPNG oder Shortpixel konvertieren kostenlos.

1. Passende Bildgrößen: Ein Hero-Bild muss nicht 4000 Pixel breit sein. 1920 Pixel reichen für alle aktuellen Desktops. Für Mobile liefern Sie 800 Pixel. Das nennt sich „responsive images" und ist HTML-Standard seit Jahren.

1. Lazy-Loading: Bilder, die nicht im sofort sichtbaren Bereich sind, sollten erst geladen werden, wenn der Besucher hinscrollt. Das Attribut `loading="lazy"` im ``-Tag macht genau das.

1. Figur statt Hero-Video: Wenn Sie ein Fullscreen-Hero-Video haben, ersetzen Sie es durch ein statisches Bild. Videos sind praktisch immer ein Performance-Desaster — selbst gut optimierte laden 5-10 MB.

Realer Gewinn: In unseren Projekten bringt Bild-Optimierung typischerweise 20-40 Punkte in Lighthouse.

Killer 2: Zu viele Webfonts (oder zu schwere)

Der zweithäufigste Killer. Moderne Websites verwenden gerne Webfonts — also Schriftarten, die über das Internet geladen werden statt auf dem Gerät des Nutzers installiert zu sein. Das sieht schöner aus als Arial, kostet aber Performance.

Typische Font-Probleme:

• Drei oder mehr Font-Familien parallel geladen
• Jeweils mehrere Gewichte pro Familie (Regular, Bold, Light, Medium, Italic, etc.)
• Fonts werden von Google Fonts geladen (zusätzlicher DNS-Lookup, Datenschutz-Problem)
• Fonts sind nicht in WOFF2 (modernes, kompaktes Format), sondern in älteren Formaten

Eine typische Font-Überladung kann 300-800 KB an zusätzlichem Traffic verursachen — und zwar genau am Anfang des Seitenaufrufs, wenn jede Millisekunde zählt.

Was Sie tun können:

1. Maximal zwei Font-Familien: Eine für Überschriften, eine für Fließtext. Das reicht für 99% aller Firmenwebsites.

1. Nur die benötigten Gewichte laden: Wenn Sie nur Regular und Bold verwenden, laden Sie nicht Light, Medium, ExtraBold und Italic mit.

1. WOFF2 statt WOFF oder TTF: WOFF2 ist etwa 30% kleiner als WOFF und wird von allen modernen Browsern unterstützt.

1. Fonts lokal einbinden, nicht von Google: Laden Sie die Font-Dateien auf Ihren eigenen Server. Das spart den DNS-Lookup zu Google-Servern und löst gleichzeitig das Datenschutz-Problem.

1. font-display: optional oder swap: Mit der CSS-Eigenschaft `font-display` kontrollieren Sie, wie der Browser mit noch nicht geladenen Fonts umgeht. `optional` ist die performanteste Wahl, `swap` bringt Fallback-Fonts beim ersten Render.

Realer Gewinn: Sauberes Font-Management bringt in unseren Projekten typischerweise 5-15 Lighthouse-Punkte.

Killer 3: Tracking- und Marketing-Skripte

Der dritte und oft übersehene Killer. Tracking- und Marketing-Tools bringen ihre eigenen JavaScript-Dateien mit, die bei jedem Seitenaufruf geladen und ausgeführt werden müssen. Typische Übeltäter:

• Google Analytics (Universal oder GA4): ~50-100 KB, blockiert oft den Main-Thread
• Google Tag Manager: Lädt weitere Skripte dynamisch nach
• Facebook Pixel: ~30-50 KB
• Hotjar oder Clarity: Session-Recording-Skripte, die jeden Klick tracken
• Cookie-Banner-Libraries: Viele bringen hunderte von KB mit
• Chat-Widgets: Livechat-Widgets wie Intercom oder Drift — oft 100-300 KB

Jedes dieser Tools kostet allein nicht viel. In Kombination laden sie aber schnell 500 KB bis 1 MB an zusätzlichem JavaScript — und blockieren den Browser während der Ausführung.

Was Sie tun können:

1. Tools auf Notwendigkeit prüfen: Nutzen Sie die Insights von Google Analytics tatsächlich, oder liegt es ungenutzt? Bei den meisten Mittelständlern ist die Antwort: ungenutzt. Dann raus damit.

1. Auf datenschutzfreundliche Alternativen wechseln: Plausible, Fathom oder Matomo (selbst gehostet) sind deutlich schlanker als Google Analytics und ohne Cookie-Banner einsetzbar.

1. Chat-Widgets nur bei Bedarf laden: Wenn Sie ein Chat-Widget brauchen, laden Sie es erst nach Nutzer-Interaktion (Click-to-Load-Prinzip), nicht automatisch beim Seitenaufruf.

1. Tag Manager kritisch prüfen: Google Tag Manager ist ein Werkzeug für Marketing-Teams mit mehreren Tracking-Tools. Wenn Sie nur ein Tool nutzen, ist der Tag Manager unnötiger Overhead.

Realer Gewinn: Das Entfernen von unnötigen Skripten bringt oft 10-30 Lighthouse-Punkte.

Wie Sie mit Browser-Devtools Killer identifizieren

Sie brauchen kein Entwickler-Wissen, um Performance-Probleme zu finden:

1. Chrome öffnen, Ihre Website laden
2. F12 drücken (Developer Tools öffnen)
3. Tab „Network" auswählen
4. „Disable cache" aktivieren
5. Seite neu laden (F5)
6. Sortieren Sie die Liste nach „Size"

Die größten Dateien stehen oben. Typisches Ergebnis einer nicht-optimierten Website:

• 3-8 Bilder über 500 KB
• 2-4 Font-Dateien über 100 KB
• 5-10 JavaScript-Dateien über 50 KB

Jede dieser Dateien ist ein potenzieller Performance-Killer. Die größten drei sind meistens die Hauptverantwortlichen.

Was wir bei unseren Builds standardmäßig optimieren

In unseren Festpreis-Paketen ist Performance-Optimierung kein Zusatzleistungspunkt, sondern Standard:

• Alle Bilder automatisch als WebP ausgeliefert, mit responsive sizes
• Lazy-Loading für alle below-the-fold-Bilder
• Maximal zwei Font-Familien, lokal eingebunden, in WOFF2
• Kein Google Analytics (stattdessen Umami, falls gewünscht)
• Kein Tag Manager
• Keine unnötigen Drittanbieter-Skripte
• JavaScript auf ein Minimum reduziert (statisches HTML braucht wenig)

Das Ergebnis: Lighthouse 90+ in allen Kategorien ohne zusätzliche Optimierungsrunden. Wir liefern diesen Zustand ab Tag eins — weil die drei Performance-Killer bei uns von Anfang an vermieden werden.

Wie viel Performance Sie durch Aufräumen gewinnen

Aus unseren Migrationsprojekten typische Verbesserungen:

• WordPress-Seite mit 25 Plugins → Saubere statische Seite: Lighthouse von 45 auf 95
• WordPress-Seite mit WP Rocket optimiert → Saubere statische Seite: Lighthouse von 75 auf 95
• Mittelmäßig optimierte WordPress-Seite → Aggressiv optimierte Version: Lighthouse von 60 auf 85

Die Größenordnung ist deutlich: Eine saubere technische Basis bringt mehr Performance-Gewinn als jedes Optimierungs-Projekt auf einer suboptimalen Basis. Wenn Sie vor der Entscheidung stehen „Bestehende Site optimieren oder neu bauen", ist oft der Neubau der bessere Weg — schneller, günstiger und mit besserem Ergebnis.