Eine Website kann noch so gut aussehen. Wenn beim Laden zuerst mehrere Sekunden lang nichts passiert, Buttons verzögert reagieren oder Inhalte plötzlich durch die Gegend springen, funktioniert sie trotzdem nicht besonders gut.

Ich beschäftige mich deshalb bei fast allen Webprojekten mit Performance und prüfe sowohl meine eigene Website als auch Kundenprojekte regelmäßig.

Dabei gibt es keine magische Einstellung, die jede Website plötzlich schnell macht. Eine schlanke Portfolio-Seite hat andere Voraussetzungen als eine WordPress-Website mit WooCommerce, vielen Funktionen und Schnittstellen.

Und ein grüner Kreis bei PageSpeed ist erfreulich.

Er ist aber nicht das eigentliche Ziel.

Die Website soll sich für echte Menschen schnell, stabil und zuverlässig anfühlen.

Erst messen, dann optimieren

Bevor ich irgendetwas ändere, teste ich die Website. Sonst weiß ich hinterher nicht, ob eine Maßnahme tatsächlich geholfen hat oder nur sehr beschäftigt aussah.

Dafür nutze ich hauptsächlich:

  • PageSpeed Insights für Performance-Tests und verfügbare Daten aus echten Seitenaufrufen

  • Lighthouse direkt im Browser für technische Hinweise und einzelne Tests

  • GTmetrix als zusätzliche Perspektive auf Ladeverlauf, Dateigrößen und Anfragen

Keines dieser Werkzeuge liefert allein die vollständige Wahrheit.

Ein einzelner Test ist immer eine Momentaufnahme und kann je nach Gerät, Verbindung und Testlauf unterschiedlich ausfallen. Felddaten zeigen dagegen, wie eine Website bei echten Besuchen über einen längeren Zeitraum funktioniert, stehen aber nicht immer für jede Seite zur Verfügung.

Deshalb schaue ich weniger auf die große Zahl oben und mehr auf die Hinweise darunter: Was lädt zu spät? Welche Datei blockiert? Warum verschiebt sich ein Element? Welche externen Dienste werden aufgerufen?

Erst dann wird optimiert.

Hosting ist die Grundlage

Wenn der Server schon lange braucht, um überhaupt zu antworten, wird auch das perfekt komprimierte Bild die Website nicht retten.

Welches Hosting das richtige ist, hängt stark vom Projekt ab und bleibt am Ende jedem selbst überlassen. Wichtig ist vor allem eine vernünftige technische Grundlage. Bei WordPress würde ich auf schnellen SSD- oder NVMe-Speicher, eine aktuelle PHP-Version, SSL, regelmäßige Backups, Sicherheitsmaßnahmen und ausreichend Ressourcen für das jeweilige Projekt achten.

Alles darüber hinaus hängt von Anforderungen und Budget ab. Managed Hosting, Staging-Umgebungen, automatische Deployments, zusätzliche Sicherheitsfunktionen oder eine besonders komfortable Infrastruktur sind praktisch, aber nicht für jede Website notwendig.

Für viele meiner WordPress-Projekte nutze ich Raidboxes, weil dort vieles bereits auf WordPress abgestimmt ist. Transparenzhalber: Ich bin Raidboxes Silver Partnerin. Das heißt aber nicht, dass jedes Projekt dort liegen muss. Andere Anbieter und Systeme können je nach Anforderungen genauso sinnvoll sein.

Meine eigene Website läuft beispielsweise auf Vercel und damit auf einer völlig anderen Infrastruktur.

Ein CDN würde ich vor allem dann stärker berücksichtigen, wenn eine Website international genutzt wird oder viele größere Assets ausgeliefert werden. Liegt die Zielgruppe hauptsächlich in Österreich oder Deutschland und der Server ebenfalls in Europa, muss man nicht automatisch noch eine weitere Schicht dazwischenbauen.

Am Ende ist weniger wichtig, welcher Name auf der Hosting-Rechnung steht. Die technische Grundlage muss zum Projekt passen.

Bilder sind häufig der größte Hebel

Gerade auf Portfolio-, Fotografie- und Projektseiten gehören Bilder schnell zu den größten Dateien.

Ein Foto direkt aus der Kamera hochzuladen und anschließend im Browser auf 600 Pixel Breite anzeigen zu lassen, funktioniert technisch.

Sinnvoll ist es nicht.

Ich achte vor allem auf vier Dinge:

  1. Passende Abmessungen: Bilder nicht wesentlich größer ausliefern, als sie tatsächlich angezeigt werden.

  2. Komprimierung: Dateigröße reduzieren, ohne sichtbare Qualität unnötig zu verlieren.

  3. Moderne Formate: WebP und AVIF können gegenüber älteren Formaten deutlich kleinere Dateien ermöglichen.

  4. Responsive Images: Ein Smartphone braucht nicht dasselbe riesige Bild wie ein großer Desktop-Bildschirm.

WordPress erstellt normalerweise mehrere Bildgrößen und kann über srcset eine passende Variante ausliefern. Voraussetzung ist natürlich, dass Theme oder Page Builder diese Möglichkeiten auch sinnvoll nutzen.

Das wichtigste Bild im sichtbaren Bereich sollte nicht erst gemütlich irgendwann nachkommen.

Lazy Loading ist also sinnvoll, wenn es an der richtigen Stelle eingesetzt wird. Das wichtigste Bild einer Seite gehört meistens nicht dazu.

Schriften, Plugins, Add-ons und externe Dienste

Auch viele kleine Dinge summieren sich.

Bei Webfonts lade ich nur die Schnitte und Zeichensätze, die tatsächlich gebraucht werden, und hoste Schriften in der Regel lokal. Bei Icons bevorzuge ich einzelne SVGs statt einer kompletten Bibliothek.

Für drei Pfeile, ein Menü-Symbol und ein Instagram-Icon muss nicht vorsorglich die halbe Geschichte der visuellen Kommunikation geladen werden.

Bei WordPress gilt dasselbe für Plugins.

Die Anzahl allein sagt wenig über die Performance aus. Ein einziges schweres Plugin kann mehr zusätzliche Arbeit verursachen als mehrere kleine Erweiterungen. Problematisch wird es beispielsweise, wenn Plugins auf jeder Seite unnötige CSS- und JavaScript-Dateien laden, viele Datenbankabfragen ausführen oder ständig externe Dienste kontaktieren.

Deshalb frage ich mich vor allem:

  • Brauche ich diese Funktion wirklich?

  • Lädt sie auch dort Ressourcen, wo sie gar nicht verwendet wird?

  • Gibt es bereits etwas anderes im System, das dasselbe macht?

Das bedeutet nicht, alles selbst programmieren zu müssen. Aber für jede Kleinigkeit ein Plugin zu installieren und anschließend ein weiteres Plugin zu brauchen, das die Folgen optimiert, ist vielleicht nicht der eleganteste Weg.

Dasselbe gilt für externe Dienste.

Videos, Karten, Tracking, Social-Media-Feeds und Chat-Funktionen können sinnvoll sein. Jede zusätzliche Verbindung kostet aber Zeit und schafft eine weitere Abhängigkeit.

Ein YouTube-Video kann beispielsweise zunächst als Vorschaubild erscheinen und erst nach einem Klick geladen werden. Eine Karte muss nicht zwangsläufig auf jeder Unterseite eingebettet sein.

Weniger externe Dienste helfen häufig nicht nur der Performance, sondern auch Wartung und Datenschutz.

CSS und JavaScript: nicht blind optimieren

Minifizierung kann Dateien verkleinern. Sie ist aber selten der erste Hebel, den ich anfasse.

Wichtiger ist, dass möglichst nur das geladen und ausgeführt wird, was eine Seite tatsächlich braucht. Große globale Skripte, ungenutztes CSS oder unnötig aufwendige Animationen können wesentlich mehr ausmachen als ein paar Leerzeichen im Code.

Auch Optionen wie defer, async oder „JavaScript verzögert laden“ würde ich nicht einfach gesammelt einschalten und auf das Beste hoffen.

Gerade bei WordPress funktioniert danach gerne plötzlich irgendein Menü, Formular oder Slider nicht mehr.

Nach Änderungen teste ich deshalb nicht nur PageSpeed, sondern die Website selbst: Navigation, Formulare, Animationen, mobile Ansichten und bei Shops natürlich auch Warenkorb und Checkout.

99 Punkte sind wenig hilfreich, wenn das Kontaktformular nicht mehr absendet.

Die Core Web Vitals kurz erklärt

Google fasst einen Teil der wahrgenommenen Website-Performance in drei Core Web Vitals zusammen:

  • LCP – Largest Contentful Paint: Wie schnell erscheint der wichtigste große Inhalt?

  • INP – Interaction to Next Paint: Wie schnell reagiert die Seite auf eine Interaktion?

  • CLS – Cumulative Layout Shift: Wie stark verschieben sich Inhalte unerwartet während der Nutzung?

Als gute Orientierung gelten derzeit:

  • LCP: maximal 2,5 Sekunden

  • INP: maximal 200 Millisekunden

  • CLS: maximal 0,1

Ein einzelner Lighthouse-Test hilft vor allem bei der Fehlersuche. Daten aus echten Seitenaufrufen geben dagegen ein besseres Bild davon, wie die Website unter realen Bedingungen funktioniert.

Meine Reihenfolge für eine schnellere Website

Wenn eine Website langsam ist, würde ich nicht als Erstes fünf Optimierungsplugins installieren.

Ich gehe lieber ungefähr so vor:

  1. Website mit PageSpeed Insights oder Lighthouse testen

  2. große Bilder und das wichtigste sichtbare Element prüfen

  3. Hosting, Serverantwort und Caching kontrollieren

  4. Schriften und externe Dienste untersuchen

  5. Plugins und unnötige Funktionen prüfen

  6. CSS und JavaScript erst danach genauer optimieren

  7. erneut messen und vor allem testen, ob noch alles funktioniert

Performance ist keine einmalige Aufgabe. Inhalte kommen dazu, Plugins werden aktualisiert und neue Funktionen eingebaut.

Deshalb lohnt es sich, eine Website gelegentlich wieder zu prüfen und nicht erst dann, wenn sie sich anfühlt, als würde sie über ein sehr langes Verlängerungskabel geladen.

Eine gute Website darf schön sein. Sie muss aber auch funktionieren.