Website-Performance: 10 Maßnahmen die sofort wirken

Deine Website lädt in 4,2 Sekunden. Du weißt das, weil Google PageSpeed Insights dir gerade einen Score von 38 gegeben hat. Dein Wettbewerber lädt in 1,8 Sekunden. Sein Score ist 92. Und Google rankt ihn jetzt über dir, obwohl dein Content besser ist.

Die gute Nachricht: Die meisten Performance-Probleme haben einfache Lösungen. Du musst nicht deine ganze Seite neu bauen. In diesem Artikel gehe ich 10 konkrete Maßnahmen durch, die messbare Verbesserungen bringen — viele davon an einem einzigen Nachmittag.

Warum Performance zählt (jenseits von PageSpeed-Scores)

Erst mal die Zahlen:

• 1 Sekunde längere Ladezeit reduziert Conversions um 7% (Akamai, 2024)
• 53% der mobilen Nutzer verlassen eine Seite, die länger als 3 Sekunden lädt (Google)
• Core Web Vitals sind seit 2021 ein bestätigter Ranking-Faktor
• Eine schnelle Seite senkt die Absprungrate um durchschnittlich 20-35%

Performance ist keine Eitelkeitsmetrik. Sie hat direkten Einfluss auf deinen Umsatz. Wenn deine Seite 100.000 EUR pro Jahr generiert und eine Geschwindigkeitsverbesserung die Conversions um 7% steigert, sind das 7.000 EUR mehr Umsatz bei gleichem Traffic. Die Optimierungsarbeit rechnet sich innerhalb von Tagen.

Die Vorher/Nachher-Übersicht

Hier siehst du, was jede Maßnahme typischerweise bringt. Diese Zahlen stammen aus realen Projekten — deine Ergebnisse werden je nach Ausgangslage variieren, aber die relative Wirkung ist konsistent.

In Kombination können diese Maßnahmen eine Seite von einem PageSpeed-Score von 30-40 auf 85-95 bringen. Ich habe das auf meiner eigenen Seite gemacht — die Case Study kannst du hier lesen.

Die 10 Maßnahmen im Detail

1. Bildoptimierung — der größte Einzelgewinn

Bilder machen auf den meisten Websites 50-70% des Seitengewichts aus. Und die meisten davon werden in Formaten und Größen ausgeliefert, die extrem ineffizient sind.

Was du tun solltest:

• Alle Bilder nach WebP konvertieren (oder AVIF für Browser, die es unterstützen). WebP liefert 25-35% kleinere Dateien als JPEG bei gleicher Qualität.
• Responsive Images mit srcset ausliefern — ein 400px breiter Handybildschirm braucht kein 2000px-Bild.
• Explizite width- und height-Attribute setzen, um Layout-Shifts (CLS) zu vermeiden.
• Ein Tool wie Sharp, Squoosh oder die eingebaute Next.js Image-Komponente für automatische Optimierung nutzen.

In Next.js übernimmt die <Image>-Komponente das meiste automatisch. Wenn du WordPress nutzt, installiere ein Plugin wie ShortPixel oder Imagify.

2. Lazy Loading — nur laden, was der Nutzer sieht

Standardmäßig laden Browser jede Ressource auf der Seite, auch Bilder und Inhalte weit unterhalb des sichtbaren Bereichs. Lazy Loading verschiebt das Laden von Off-Screen-Inhalten, bis der Nutzer dorthin scrollt.

Was du tun solltest:

• loading="lazy" zu allen Bildern unterhalb des Folds hinzufügen
• Das Hero-Bild oder alles oberhalb des Folds NICHT lazy-loaden — das macht LCP schlechter
• Schwere Komponenten wie Karten, Chat-Widgets oder eingebettete Videos perIntersection Observer oder dynamische Imports lazy-loaden

Ein Tipp: Iframes lazy-loaden (wie YouTube-Embeds) spart massive Datenmengen. Ein einziger YouTube-Embed lädt über 800KB an Scripts. Nutze ein Facade-Pattern — zeig ein Thumbnail und lade den eigentlichen Player erst beim Klick.

3. Font-Optimierung — der unsichtbare Performance-Killer

Custom Fonts sind ein heimlicher Performance-Fresser. Jede Font-Datei ist 20-100KB groß, und die meisten Seiten laden 3-6 Varianten (Regular, Bold, Italic usw.). Das sind potenziell 600KB an Fonts, die dein Seiten-Rendering blockieren.

Was du tun solltest:

• Fonts selbst hosten statt von Google Fonts laden. Das eliminiert einen zusätzlichen DNS-Lookup und eine Verbindung.
• font-display: swap nutzen, damit Text sofort mit einem System-Font sichtbar ist und dann zum Custom Font wechselt.
• Fonts subsetten. Wenn du nur lateinische Zeichen nutzt, entferne die kyrillischen und griechischen Glyphen. Das kann die Dateigröße um 50-70% reduzieren.
• Font-Varianten begrenzen. Brauchst du wirklich Thin, Light, Regular, Medium, Semibold, Bold UND Extra-Bold? Meistens reichen 2-3 Gewichte.

Next.js hat eingebaute Font-Optimierung über next/font. Es hostet und subsettet Fonts automatisch. Falls du nicht auf Next.js bist, nutze google-webfonts-helper zum Download und Selbst-Hosten.

4. Bundle-Size-Reduktion — weniger JavaScript ausliefern

JavaScript ist die teuerste Ressource im Web. Anders als Bilder muss JS heruntergeladen, geparst, kompiliert UND ausgeführt werden. Eine 200KB JavaScript-Datei braucht mehr Verarbeitungszeit als ein 200KB-Bild.

Was du tun solltest:

• npx next build (oder das Äquivalent deines Frameworks) ausführen und die Bundle-Analyse prüfen. Die größten Chunks finden.
• Schwere Libraries durch leichtere Alternativen ersetzen: date-fnsstatt moment.js (80% kleiner), clsx statt classnames.
• Tree-Shaking-Probleme prüfen: import { debounce } from 'lodash-es' statt import _ from 'lodash'
• Ungenutzte Dependencies entfernen. npx depcheck ausführen, um Pakete zu finden, die installiert aber nie verwendet werden.

Ich habe erlebt, wie Seiten ihr JavaScript von 1,2MB auf 350KB reduziert haben, nur indem drei Libraries ersetzt und toter Code entfernt wurde. 70% Reduktion mit vielleicht 3 Stunden Arbeit.

5. CDN — Inhalte vom nächsten Edge-Server ausliefern

Ein CDN (Content Delivery Network) cached deine statischen Assets auf Servern weltweit. Wenn ein Nutzer in München deine Seite lädt, bekommt er die Dateien aus Frankfurt statt von deinem Origin-Server in Virginia.

Was du tun solltest:

• Wenn du auf Vercel, Netlify oderCloudflare Pages bist, hast du bereits ein CDN. Statische Assets werden standardmäßig vom Edge ausgeliefert.
• Bei klassischem Hosting Cloudflare (Free Tier reicht meistens) als Reverse Proxy vor deine Seite schalten.
• Achte auf korrekte Cache-Header — statische Assets sollten lange Cache-Zeiten (1 Jahr) mit Content-Hashing für Cache-Busting haben.

6. Core Web Vitals — das messen, was Google misst

Google misst drei Metriken: LCP (Largest Contentful Paint),INP (Interaction to Next Paint) und CLS (Cumulative Layout Shift). Diese beeinflussen direkt dein Suchranking.

LCP (sollte unter 2,5s sein): Meistens dein Hero-Bild oder die Headline. Optimiere das Bild, preloade es mit <link rel="preload"> und stell sicher, dass die Server-Antwort schnell ist.

INP (sollte unter 200ms sein): Misst, wie schnell die Seite auf Nutzer-Interaktionen reagiert. Reduziere Main-Thread-Blocking durch Aufteilen langer Tasks, Web Workers für schwere Berechnungen und Debouncing von Event-Handlern.

CLS (sollte unter 0,1 sein): Layout-Shifts passieren, wenn Elemente nach dem Laden ihre Größe oder Position ändern. Behebe das durch explizite Dimensionen auf Bildern und Embeds, font-display: optional bei Font-Swapping-Problemen, und reservierten Platz für dynamische Inhalte.

7. Caching-Header — nichts erneut laden, was sich nicht geändert hat

Korrektes Caching bedeutet, dass wiederkehrende Besucher deine Seite quasi sofort laden. Der Browser liefert Dateien aus dem lokalen Cache statt sie erneut herunterzuladen.

Was du tun solltest:

• Statische Assets (JS, CSS, Bilder mit Hashes): Cache-Control: public, max-age=31536000, immutable
• HTML-Seiten: Cache-Control: public, max-age=0, must-revalidate (damit Updates sofort live gehen)
• API-Antworten: stale-while-revalidate setzen für Daten, die sich nicht jede Sekunde ändern

8. Code Splitting — Seiten laden, nicht die ganze App

Ohne Code Splitting wird das gesamte JavaScript deiner Anwendung in eine (oder wenige) große Dateien gebündelt. Der Nutzer lädt Code für jede Seite herunter, auch wenn er nur die Startseite besucht.

Was du tun solltest:

• Next.js und moderne Frameworks machen route-basiertes Code Splitting automatisch. Jede Seite lädt nur ihren eigenen Code.
• Dynamische Imports für schwere Komponenten nutzen: const Chart = dynamic(() => import('./Chart'))
• Vendor-Code von Anwendungscode trennen, damit Browser-Caching besser greift — dein Code ändert sich oft, React nicht.

9. Server Components — weniger JavaScript zum Client

Wenn du React 18+ oder Next.js 13+ nutzt, sind Server Components ein Gamechanger. Sie rendern auf dem Server und schicken HTML zum Client — null JavaScript für diese Komponente erreicht den Browser.

Was du tun solltest:

• Standardmäßig Server Components nutzen. Nur 'use client'hinzufügen, wenn du Interaktivität brauchst (Click-Handler, State, Effects).
• Data-Fetching in Server Components verlagern — keine Loading-Spinner mehr für initiale Daten.
• Client Components als kleine Blatt-Knoten halten. Header und Footer brauchen nicht Client Components zu sein, nur weil sie einen Mobile-Menü-Toggle enthalten.

In einem meiner Projekte hat die Umstellung von 60% der Komponenten von Client auf Server das clientseitige JavaScript um 45% reduziert. Der LCP verbesserte sich um 1,2 Sekunden.

10. Datenbank-Optimierung — der Backend-Flaschenhals

Ein schönes, optimiertes Frontend bringt nichts, wenn der Server 3 Sekunden für die Antwort braucht. Langsame Datenbankabfragen sind das häufigste Backend-Performance-Problem.

Was du tun solltest:

• Indexe hinzufügen auf Spalten, nach denen du filterst, sortierst oder joinst. Eine unindexierte Abfrage auf 100.000 Zeilen dauert Sekunden; eine indexierte Millisekunden.
• Nur holen, was du brauchst. SELECT * holt jede Spalte. Wenn du nur Name und Email brauchst, hol Name und Email.
• N+1-Queries vermeiden. Wenn du 20 Produkte lädst und dann für jedes einzeln die Kategorie holst, sind das 21 Queries. Nutze einen JOIN oder Batch-Fetch.
• Teure Queries cachen. Wenn eine Abfrage 500ms dauert und die Daten sich einmal pro Stunde ändern, cache sie mit 5-Minuten-TTL.

Tools zum Messen der Performance

• Google PageSpeed Insights: Kostenlos, nutzt echte Nutzerdaten (CrUX) für Feld-Metriken und Lighthouse für Lab-Metriken.
• WebPageTest: Detaillierter als PageSpeed. Zeigt Waterfall-Charts, Filmstrip-Ansicht und erlaubt Tests von verschiedenen Standorten.
• Chrome DevTools Performance-Tab: Zum Tiefeintauchen in spezifische Probleme wie Long Tasks oder Layout-Shifts.
• Lighthouse CI: Performance-Tests in der CI/CD-Pipeline automatisieren. Regressionen fangen, bevor sie Produktion erreichen.

Wann du einen Profi brauchst

Maßnahmen 1-7 sind für jeden mit grundlegendem Web-Wissen machbar. Plugin installieren, Einstellungen anpassen, fertig. Maßnahmen 8-10 erfordern Entwickler-Skills — Code Splitting, Server Components und Datenbank-Optimierung bedeuten echte Code-Änderungen.

Wenn deine Seite unter 50 bei PageSpeed scored und du keinen Entwickler im Team hast, rechnet sich eine professionelle Website-Optimierung schnell. Ein typisches Projekt kostet 2.000-5.000 EUR und liefert Ergebnisse in 1-2 Wochen. Vergleich das mit dem Umsatz, den du jeden Tag mit einer langsamen Seite verlierst.

Du willst eine schnelle Einschätzung, wo deine Seite steht? Der kostenlose Website-Audit analysiert Performance, SEO und Conversion in einem Durchgang.

FAQ: Website-Performance

Was ist ein guter PageSpeed-Score?

90+ ist exzellent, 50-89 verbesserungswürdig, unter 50 schlecht. Für die meisten Business-Websites ist ein Ziel von 80+ auf Mobile realistisch und ausreichend. Desktop-Scores sind normalerweise 10-20 Punkte höher, weil Desktop-Geräte schneller sind.

Beeinflusst Performance wirklich SEO?

Ja. Core Web Vitals sind ein bestätigter Ranking-Faktor. Aber die Wirkung ist relativ — guter Content mit mittelmäßiger Performance schlägt immer noch mittelmäßigen Content mit perfekter Performance. Performance ist der Tiebreaker, nicht das Hauptkriterium.

Wie oft sollte ich die Performance prüfen?

Nach jedem Deployment, das das Frontend ändert. Richte Lighthouse CI in deiner Deployment-Pipeline ein, um Regressionen automatisch zu fangen. Mindestens ein manueller Check pro Monat.

Kann ich Performance verbessern, ohne den Tech-Stack zu wechseln?

Ja. Bildoptimierung, Caching, Font-Loading und CDN-Setup funktionieren auf jeder Plattform. WordPress, Shopify, Custom PHP — die Prinzipien sind die gleichen. Nur Server Components und erweitertes Code Splitting erfordern ein spezifisches Framework.

Wie viel schneller kann meine Seite realistisch werden?

Das hängt vom Ausgangspunkt ab. Eine WordPress-Seite mit nicht-optimierten Bildern, ohne Caching und mit 15 Plugins kann leicht von 5 Sekunden Ladezeit auf unter 2 Sekunden kommen. Eine moderne Next.js-Seite, die schon ordentlich ist, verbessert sich vielleicht von 2,5 auf 1,5 Sekunden. Je schlechter der Ausgangspunkt, desto größer die Gewinne durch Basis-Optimierungen.