Eine langsame Website hat selten nur eine Ursache. Vielleicht antwortet der Server zu spät. Vielleicht ist das Titelbild mehrere Megabyte groß. Vielleicht erzeugt WordPress bei jedem Seitenaufruf hunderte Datenbankabfragen. Vielleicht wartet der Browser auf externe Schriften, Werbenetzwerke oder JavaScript. Vielleicht funktioniert das alles schnell – und nur der sichtbare Seitenaufbau fühlt sich langsam an.
Genau deshalb führt die häufigste Performance-Empfehlung oft in die falsche Richtung:
„Installiere einfach ein Cache-Plugin.“
Caching kann enorm helfen. Es löst aber kein 8-Megabyte-Bild, keinen überlasteten Server, keinen langsamen Drittanbieter und kein JavaScript, das den Browser überfordert.
Wer eine Website wirklich schneller machen möchte, sollte deshalb nicht zuerst optimieren. Er sollte zuerst herausfinden, wo die Zeit verloren geht.
„Langsam“ kann mehrere Dinge bedeuten
Wenn jemand sagt, eine Website sei langsam, kann damit Unterschiedliches gemeint sein.
Vielleicht dauert es lange, bis überhaupt etwas passiert.
Vielleicht erscheint der erste Inhalt schnell, aber der Rest der Seite baut sich minutenlang auf.
Vielleicht sieht alles fertig aus, reagiert aber noch nicht auf Eingaben.
Vielleicht springen Bilder und Texte während des Ladens plötzlich an andere Positionen.
Oder die öffentliche Website ist schnell, während WordPress im Administrationsbereich beinahe unbenutzbar wird.
Diese Probleme haben unterschiedliche Ursachen.
Deshalb ist „Wie schnell lädt die Website?“ eigentlich bereits eine zu einfache Frage.
Besser ist:
Welcher Teil des Ladevorgangs ist langsam?
Ein Webseitenaufruf besteht aus mehreren Phasen
Beim Öffnen einer Website passieren mehrere Dinge hintereinander und teilweise gleichzeitig.
Vereinfacht:
Domain aufrufen
↓
DNS-Auflösung
↓
Verbindung zum Server
↓
HTTPS-Verbindung
↓
Server verarbeitet Anfrage
↓
HTML wird übertragen
↓
Browser analysiert HTML
↓
CSS, Bilder, Schriften und JavaScript werden geladen
↓
Browser berechnet das Layout
↓
Seite wird sichtbar und benutzbarAn nahezu jeder dieser Stellen kann Zeit verloren gehen.
Das erklärt, warum zwei Websites mit demselben Hosting völlig unterschiedlich schnell wirken können.
Mehr zum gesamten Ablauf findest du in Wie funktioniert eine Website?.
Servergeschwindigkeit ist nur ein Teil der Performance
Der Server muss eine Anfrage zunächst beantworten.
Bei einer statischen HTML-Datei kann das ausgesprochen schnell gehen.
Bei einer dynamischen WordPress-Seite muss der Server dagegen möglicherweise:
PHP starten,
WordPress laden,
Plugins ausführen,
Datenbankabfragen durchführen,
Theme-Dateien verarbeiten
und daraus HTML erzeugen.
Erst danach beginnt der Browser mit seiner eigentlichen Arbeit.
Wenn diese serverseitige Verarbeitung bereits sehr lange dauert, kann der Browser nichts daran ändern.
Umgekehrt kann der Server blitzschnell antworten, während anschließend riesige Bilder und JavaScript-Dateien den sichtbaren Seitenaufbau verzögern.
Backend-Performance und Frontend-Performance sind deshalb getrennte Probleme.
Die erste wichtige Zeit entsteht vor dem ersten Byte
Bevor der Browser überhaupt HTML erhält, muss der Server die Anfrage bearbeiten.
Ist diese Phase langsam, kann die Seite gefühlt „stehen“, obwohl noch gar nichts sichtbar geladen wird.
Mögliche Ursachen sind:
überlastetes Hosting,
langsame PHP-Verarbeitung,
langsame Datenbankabfragen,
externe API-Anfragen,
fehlendes serverseitiges Caching,
sehr komplexer Anwendungscode.
Bei WordPress ist diese Phase besonders interessant, weil eine ungecachte Seite dynamisch erzeugt werden kann.
Ein schneller Browser kann einen langsamen Server hier nicht kompensieren.
Shared Hosting muss nicht der Schuldige sein
Wenn eine WordPress-Seite langsam ist, fällt der Verdacht häufig sofort auf das Hosting.
Manchmal stimmt das.
Ein schlecht ausgelastetes oder stark begrenztes Hostingpaket kann Performanceprobleme verursachen.
Aber Shared Hosting ist nicht automatisch langsam.
Ein guter Hoster kann WordPress hervorragend optimieren.
Umgekehrt kann eine Website auf einem leistungsfähigen VPS langsam reagieren, wenn:
PHP falsch konfiguriert ist,
die Datenbank schlecht arbeitet,
Plugins ineffizienten Code ausführen,
Caching fehlt.
Deshalb sollte ein Serverwechsel erst erfolgen, wenn tatsächlich Hinweise darauf bestehen, dass die Infrastruktur der Engpass ist.
Die Hostingmodelle vergleichen wir in Shared Hosting, VPS oder eigener Server?.
Mehr CPU löst nicht jedes Problem
Angenommen, ein Plugin führt bei jedem Seitenaufruf eine unnötig komplexe Datenbankabfrage aus.
Ein schnellerer Prozessor kann diese Abfrage möglicherweise schneller berechnen.
Das Problem bleibt trotzdem bestehen.
Mehr Hardware kann Ineffizienz überdecken.
Das ist manchmal wirtschaftlich sinnvoll.
Aber Optimierung bedeutet zunächst herauszufinden, ob zusätzliche Ressourcen oder besserer Code die richtige Lösung sind.
Man sollte deshalb unterscheiden:
Der Server ist zu klein.
und
Die Anwendung nutzt den Server schlecht.
Beide Fälle können dieselben Symptome erzeugen.
Arbeitsspeicher kann ebenfalls zum Engpass werden
WordPress, PHP, Datenbanken, Caching-Systeme und andere Dienste benötigen Arbeitsspeicher.
Ist zu wenig RAM vorhanden, kann ein Server Prozesse beenden oder Daten auf langsameren Speicher auslagern.
Das kann die Reaktionszeit deutlich verschlechtern.
Auf einem VPS lässt sich die Ressourcennutzung häufig direkt beobachten.
Bei Shared Hosting arbeitet der Anbieter dagegen oftmals mit Account- und Prozesslimits.
Auch dort kann eine Website an Grenzen stoßen, selbst wenn man keinen direkten Zugriff auf die gesamte Serverauslastung besitzt.
Datenbanken können WordPress ausbremsen
WordPress speichert einen erheblichen Teil seiner Inhalte und Einstellungen in einer Datenbank.
Bei einem Seitenaufruf können zahlreiche Abfragen entstehen.
Zum Beispiel:
Welcher Beitrag wurde angefordert?
Welche Kategorien besitzt er?
Welche Einstellungen gelten?
Welche Menüs sollen angezeigt werden?
Welche Plugin-Daten werden benötigt?
Bei einer sauberen Installation ist das normalerweise kein Problem.
Schwierig wird es, wenn Erweiterungen ineffiziente Abfragen erzeugen oder Tabellen sehr groß werden.
Dann kann ein einzelner Seitenaufruf unnötig viel Datenbankarbeit verursachen.
Eine große Datenbank ist nicht automatisch langsam
Auch hier gilt: Größe allein reicht als Diagnose nicht.
Eine Datenbank mit mehreren Gigabyte kann hervorragend funktionieren.
Eine wesentlich kleinere Datenbank kann aufgrund ungünstiger Abfragen langsam sein.
Relevant sind beispielsweise:
welche Tabellen verwendet werden,
welche Abfragen ausgeführt werden,
ob passende Indizes vorhanden sind,
wie viele Daten durchsucht werden,
wie häufig dieselben Informationen erneut abgefragt werden.
„Datenbank optimieren“ sollte deshalb nicht bedeuten, wahllos Tabellen zu löschen.
Zuerst muss klar sein, welches Problem überhaupt existiert.
WordPress-Plugins können Performance kosten
Plugins erweitern WordPress und können dabei unterschiedlich viel Arbeit erzeugen.
Ein Plugin kann nur im Backend eine kleine zusätzliche Einstellung bereitstellen.
Ein anderes Plugin kann bei jedem Seitenaufruf:
Datenbankabfragen durchführen,
JavaScript laden,
CSS einbinden,
externe APIs kontaktieren,
Cookies setzen,
Hintergrundprozesse starten.
Die Zahl der Plugins allein sagt deshalb wenig.
Wie wir bereits in WordPress-Plugins verstehen gesehen haben, können 25 kleine Erweiterungen weniger problematisch sein als ein einzelnes sehr umfangreiches Plugin.
Besonders problematisch sind Funktionen, die überall geladen werden
Angenommen, ein Formular wird ausschließlich auf der Kontaktseite verwendet.
Das zugehörige Plugin lädt aber auf jeder einzelnen Seite:
CSS,
JavaScript,
externe Bibliotheken.
Dann zahlen sämtliche Besucher den Performancepreis für eine Funktion, die auf ihrer aktuellen Seite gar nicht benötigt wird.
Dasselbe kann passieren mit:
Slidern,
Galerien,
Shop-Funktionen,
Karten,
Popups,
Analysewerkzeugen.
Gute Performance bedeutet deshalb auch, Ressourcen möglichst nur dort zu laden, wo sie tatsächlich gebraucht werden.
Themes beeinflussen die Ladezeit stärker, als man denkt
Ein Theme bestimmt nicht nur die Optik.
Es kann zahlreiche Ressourcen mitbringen:
Stylesheets,
JavaScript,
Webfonts,
Iconsets,
Animationen,
Sliderbibliotheken,
Layoutfunktionen.
Ein sehr umfangreiches Mehrzweck-Theme kann Funktionen für dutzende Websitearten enthalten.
Die eigene Website verwendet vielleicht nur einen kleinen Teil davon.
Das Theme muss deshalb nicht automatisch schlecht sein. Aber bei der Auswahl lohnt sich die Frage:
Wie viel Technik wird für meine tatsächliche Gestaltung benötigt?
Mehr dazu findest du in WordPress-Themes verstehen.
Page Builder können zusätzliche Ebenen erzeugen
Visuelle Page Builder machen komplexe Layouts sehr einfach.
Dafür erzeugen sie möglicherweise zusätzliche:
HTML-Strukturen,
CSS-Regeln,
JavaScript,
Wrapper-Elemente,
Datenbankinformationen.
Wie relevant das ist, hängt stark vom jeweiligen Builder und der konkreten Seite ab.
Ein Page Builder ist nicht automatisch langsam.
Aber je komplexer ein Layoutsystem wird, desto wichtiger ist es, die Auswirkungen auf Performance mitzudenken.
Ein einfacher Artikel benötigt normalerweise keine dutzenden verschachtelten Layoutcontainer.
Bilder sind häufig der größte Datenblock
Bei vielen Websites sind Bilder für den größten Teil der übertragenen Daten verantwortlich.
Eine typische Kamera oder ein modernes Smartphone erzeugt Fotos mit mehreren Megabyte Dateigröße und sehr hoher Auflösung.
Für ein Bild, das auf einer Website maximal 1.200 Pixel breit dargestellt wird, ist ein 6.000-Pixel-Original häufig unnötig.
Wird es trotzdem ausgeliefert, muss der Besucher Daten übertragen, die er gar nicht sehen kann.
Das ist besonders auf Mobilgeräten und langsameren Verbindungen problematisch.
Ein Bild kann schön aussehen und trotzdem viel zu groß sein
Bildoptimierung bedeutet nicht, Fotos sichtbar kaputtzukomprimieren.
Moderne Formate und sinnvolle Kompression können die Dateigröße stark reduzieren, ohne dass der Unterschied für normale Besucher auffällt.
Entscheidend sind unter anderem:
Abmessungen,
Dateiformat,
Kompressionsgrad,
Motiv,
Transparenz,
Verwendungszweck.
Ein Logo stellt andere Anforderungen als ein großes Foto.
Wie man Bilder passend vorbereitet, behandeln wir in Bilder für Websites optimieren.
Responsive Images vermeiden unnötige Datenübertragung
Ein Smartphone benötigt normalerweise kein Bild in derselben Auflösung wie ein großer Desktop-Bildschirm.
Moderne Webseiten können deshalb mehrere Bildgrößen bereitstellen.
Der Browser wählt anschließend abhängig von Display und Layout eine passende Variante.
WordPress unterstützt solche Mechanismen bereits.
Das funktioniert allerdings nur sinnvoll, wenn die Ausgangsbilder und das Theme entsprechend eingesetzt werden.
Ein gigantisches Original als einzige verfügbare Variante bleibt gigantisch.
Lazy Loading verschiebt Arbeit nach hinten
Nicht jedes Bild muss geladen werden, bevor der Besucher überhaupt den oberen Bereich einer Seite sieht.
Bilder weit unten im Artikel können erst dann geladen werden, wenn sie näher in den sichtbaren Bereich kommen.
Dieses Verfahren wird als Lazy Loading bezeichnet.
Dadurch konzentrieren sich Netzwerk und Browser zunächst auf die Inhalte, die tatsächlich unmittelbar benötigt werden.
Lazy Loading kann sehr hilfreich sein.
Es sollte aber nicht blind auf jedes Element angewandt werden.
Das zentrale Bild im oberen sichtbaren Bereich sollte beispielsweise nicht unnötig spät angefordert werden.
JavaScript kann den Browser beschäftigen
JavaScript ermöglicht interaktive Websites.
Es kann:
Menüs öffnen,
Formulare prüfen,
Inhalte nachladen,
Slider bewegen,
Shops aktualisieren,
Analyse durchführen.
Aber JavaScript muss heruntergeladen und anschließend vom Browser verarbeitet werden.
Je mehr Code vorhanden ist, desto mehr Arbeit entsteht.
Besonders auf älteren Smartphones kann umfangreiches JavaScript deutlich stärker auffallen als auf einem schnellen Desktopcomputer.
Eine Seite kann deshalb auf dem eigenen Büro-PC hervorragend wirken und bei einem Besucher trotzdem träge reagieren.
Dateigröße und Rechenaufwand sind zwei verschiedene Dinge
Eine kleine JavaScript-Datei kann sehr aufwendige Berechnungen durchführen.
Eine größere Datei kann dagegen nur einmal geladen und anschließend kaum aktiv sein.
Performance lässt sich deshalb nicht ausschließlich anhand von Kilobyte beurteilen.
Relevant ist:
Wie viel wird übertragen?
Wann wird es geladen?
Wann wird es ausgeführt?
Wie lange blockiert es andere Aufgaben?
Diese Unterschiede werden bei moderner Performanceanalyse immer wichtiger.
Zu viele externe Dienste erhöhen die Abhängigkeit
Viele Websites laden Bestandteile nicht vom eigenen Server.
Zum Beispiel:
Schriftarten,
Analytics,
Werbung,
Videos,
Karten,
Chat-Funktionen,
Social-Media-Widgets,
Consent-Systeme,
Tracking-Pixel.
Jeder zusätzliche Anbieter bringt eine weitere Netzwerkverbindung und potenziell zusätzliche Dateien mit.
Ein externer Dienst kann außerdem langsam reagieren oder komplett ausfallen.
Dann kann eine ansonsten schnelle Website plötzlich warten.
Drittanbieter sollten einen klaren Nutzen haben
Ein einzelner externer Dienst ist normalerweise kein Drama.
Problematisch wird die Summe.
Ein Analysewerkzeug.
Ein Werbenetzwerk.
Drei Marketingtracker.
Ein Chat.
Ein Videoplayer.
Ein Social-Media-Widget.
Ein externes Schriftensystem.
Ein A/B-Test.
Plötzlich kommuniziert eine einzelne Seite mit dutzenden fremden Domains.
Jeder Dienst sollte deshalb dieselbe Frage beantworten wie ein WordPress-Plugin:
Brauchen wir ihn wirklich?
Webfonts können den sichtbaren Aufbau beeinflussen
Websites können Schriftarten über das Internet laden.
Das erlaubt eine sehr flexible Gestaltung.
Gleichzeitig muss der Browser die Schriftdateien erhalten, bevor bestimmte Texte genau in dieser Schrift dargestellt werden können.
Je nach Konfiguration kann Text deshalb:
vorübergehend in einer Ersatzschrift erscheinen,
kurz unsichtbar bleiben
oder beim Wechsel der Schrift seine Größe verändern.
Die beste Lösung ist nicht automatisch, ausschließlich Systemschriften zu verwenden.
Aber Typografie und Performance sollten gemeinsam betrachtet werden.
CSS kann ebenfalls zum Engpass werden
CSS beschreibt die Darstellung der Website.
Bei komplexen Themes und Page Buildern können sehr große Stylesheets entstehen.
Der Browser muss diese Regeln herunterladen und auswerten.
Problematisch kann außerdem CSS sein, das für die Darstellung des ersten sichtbaren Bereichs benötigt wird, aber erst spät verfügbar ist.
Deshalb beschäftigen sich Performanceoptimierungen unter anderem damit, kritische Styles möglichst früh bereitzustellen.
Für normale Website-Betreiber ist weniger wichtig, jede Optimierungstechnik selbst umzusetzen.
Wichtiger ist zu verstehen, dass auch Designcode Ladezeit kostet.
Der obere sichtbare Bereich ist besonders wichtig
Besucher warten nicht darauf, dass technisch jedes letzte Pixel geladen ist.
Sie beurteilen vor allem:
Wann sehe ich etwas Sinnvolles?
Wenn Überschrift und Hauptinhalt schnell erscheinen, wirkt eine Website oft deutlich schneller.
Wenn zunächst mehrere Sekunden ein leerer Bildschirm angezeigt wird, wirkt sie langsam – selbst wenn anschließend alles auf einmal erscheint.
Performance ist deshalb nicht nur eine technische Gesamtzeit.
Sie ist auch Wahrnehmung.
Core Web Vitals versuchen Nutzererfahrung messbar zu machen
Moderne Performancebewertung betrachtet deshalb nicht nur, wann der letzte Netzwerkrequest beendet wurde.
Interessant sind auch Fragen wie:
Wann erscheint der wichtigste sichtbare Inhalt?
Wie schnell reagiert die Seite auf Benutzereingaben?
Bleibt das Layout während des Ladens stabil?
Diese Aspekte werden unter anderem über die Core Web Vitals betrachtet.
Für Website-Betreiber ist das zugrunde liegende Prinzip wichtiger als einzelne Grenzwerte:
Eine gute Website sollte schnell sichtbar, schnell benutzbar und visuell stabil sein.
Layout-Verschiebungen wirken besonders störend
Vielleicht kennst du die Situation:
Du möchtest auf einen Link tippen.
Im letzten Moment erscheint oberhalb ein Bild oder eine Werbung.
Der gesamte Inhalt springt nach unten.
Du klickst auf etwas völlig anderes.
Solche Layout-Verschiebungen entstehen häufig, wenn der Browser vor dem Laden nicht weiß, wie viel Platz ein später eintreffendes Element benötigt.
Bei Bildern lässt sich beispielsweise bereits vorher Raum reservieren.
Dadurch bleibt das Layout stabil, während die Datei geladen wird.
Anzeigen und dynamische Einblendungen können Layout destabilisieren
Auch:
Cookie-Banner,
Werbeflächen,
Newsletterboxen,
extern nachgeladene Widgets
können Seiten nachträglich verschieben.
Das ist nicht nur optisch störend.
Es beeinflusst Bedienbarkeit.
Gute Performance bedeutet deshalb nicht nur weniger Datenübertragung, sondern auch einen vorhersehbaren Seitenaufbau.
Ein CDN kann Netzwerkwege verkürzen
Ein Content Delivery Network, kurz CDN, kann Dateien an verschiedenen geografischen Standorten zwischenspeichern.
Ein Besucher in Australien muss bestimmte Ressourcen dann möglicherweise nicht vom Ursprungsserver in Europa laden.
Dadurch können Netzwerkwege kürzer werden.
CDNs können außerdem zusätzliche Funktionen für:
Caching,
Sicherheit,
Kompression
und Traffic-Verteilung
bieten.
Ein CDN ist trotzdem kein Pflichtbestandteil jeder Website.
Ein CDN repariert keine schlechte Website
Eine 8-Megabyte-Bilddatei bleibt auch über ein CDN groß.
Ein langsames Datenbankproblem wird durch einen CDN-Edge-Server nicht automatisch behoben.
Schlecht programmiertes JavaScript bleibt schlecht programmiert.
Ein CDN ist deshalb eine Optimierungsebene.
Es sollte eingesetzt werden, wenn das Problem dazu passt.
Nicht weil jede Performanceanleitung das Wort CDN enthält.
Caching kann die Serverarbeit drastisch reduzieren
Caching gehört zu den wirkungsvollsten Werkzeugen bei dynamischen Websites.
Ohne Cache kann WordPress für jeden Besucher erneut:
PHP ausführen,
Plugins laden,
Datenbank abfragen,
Templates verarbeiten,
HTML erzeugen.
Wenn sich der Inhalt nicht verändert hat, ist diese Arbeit häufig redundant.
Ein Seiten-Cache kann das bereits erzeugte HTML speichern und beim nächsten Aufruf direkt ausliefern.
Vereinfacht:
ohne Cache
Besucher
↓
WordPress
↓
Datenbank
↓
HTMLmit Cache:
Besucher
↓
fertiges HTMLDas kann einen erheblichen Unterschied machen.
Caching funktioniert auf mehreren Ebenen
Es gibt nicht „den Cache“.
Zwischenspeicherung kann beispielsweise stattfinden:
im Browser,
im Webserver,
in WordPress,
für Datenbankergebnisse,
bei einem Reverse Proxy,
in einem CDN.
Jede Ebene erfüllt eine andere Aufgabe.
Deshalb können mehrere Cache-Systeme sinnvoll zusammenspielen.
Mehr dazu behandeln wir als Nächstes ausführlich in Caching einfach erklärt.
Zu viel Caching kann Probleme verstecken
Caching erzeugt auch typische Fehlerbilder.
Du änderst einen Artikel.
Die alte Version erscheint weiterhin.
Ein CSS-Fehler ist längst behoben, wird aber im Browser noch angezeigt.
Eine Seite funktioniert für eingeloggte Benutzer anders als für Besucher.
Dann wird oft pauschal gesagt:
„Lösch mal den Cache.“
Das kann funktionieren.
Besser ist trotzdem zu wissen, welcher Cache gemeint ist.
Browser-Cache?
WordPress-Cache?
CDN?
Server-Cache?
Je besser die Ebenen verstanden werden, desto leichter wird die Fehlersuche.
Kompression reduziert die Übertragungsmenge
Textdateien wie HTML, CSS und JavaScript lassen sich häufig sehr gut komprimieren.
Der Server kann sie komprimiert übertragen und der Browser entpackt sie anschließend.
Dadurch müssen weniger Daten durch das Netzwerk geschickt werden.
Bei bereits stark komprimierten Bild- und Videoformaten fällt der Nutzen dagegen anders aus.
Kompression ist heute eine normale Optimierungsebene moderner Webserver.
Sie ersetzt aber ebenfalls keine saubere Seitenarchitektur.
HTTP-Verbindungen sind heute effizienter als früher
Ältere Performance-Ratschläge empfehlen häufig, möglichst jede einzelne Datei zusammenzuführen, weil jede zusätzliche Anfrage sehr teuer sei.
Moderne Webprotokolle können zahlreiche Ressourcen wesentlich effizienter übertragen als frühere Generationen.
Dadurch haben sich manche historische Optimierungsregeln relativiert.
Das bedeutet nicht, dass beliebig viele Dateien kostenlos wären.
Aber Performance sollte nicht mit zehn Jahre alten Pauschalregeln optimiert werden.
Messwerte sind wichtiger als Tradition.
DNS kann ebenfalls Zeit kosten
Bevor der Browser einen neuen Host kontaktieren kann, muss gegebenenfalls dessen Adresse über DNS ermittelt werden.
Bei einer Website mit vielen externen Diensten entstehen dadurch zusätzliche Auflösungen.
Das ist einer von mehreren Gründen, warum eine hohe Zahl fremder Domains problematisch sein kann.
Für die eigene Hauptdomain ist DNS normalerweise nur ein kleiner Teil des gesamten Seitenaufrufs.
Ein grundsätzlich falsch konfiguriertes DNS kann allerdings natürlich die Erreichbarkeit beeinträchtigen.
Die Grundlagen findest du in Was ist DNS?.
HTTPS kostet ebenfalls etwas Arbeit – und gehört trotzdem dazu
Bei einer HTTPS-Verbindung müssen Browser und Server eine verschlüsselte Verbindung aufbauen.
Das benötigt zusätzliche Kommunikation und Rechenarbeit.
Moderne Protokolle und Systeme sind jedoch auf diesen Einsatz ausgelegt.
HTTPS aus Performancegründen wegzulassen wäre keine sinnvolle Optimierung.
Sicherheit und Performance sollten gemeinsam geplant werden.
Wie HTTPS funktioniert, behandeln wir in SSL und HTTPS verständlich erklärt.
Entfernung beeinflusst die Netzwerklatenz
Ein Server kann extrem leistungsfähig sein und trotzdem weit entfernt stehen.
Daten benötigen Zeit, um Netzwerke zu durchqueren.
Für eine österreichische Zielgruppe kann ein europäischer Server deshalb andere Latenzen erzeugen als ein System am anderen Ende der Welt.
Das bedeutet nicht, dass Hosting zwingend im Heimatland stehen muss.
Aber geografische Entfernung ist einer von mehreren Performancefaktoren.
CDNs können diesen Effekt für bestimmte Ressourcen reduzieren.
Mobilfunk verändert die Wahrnehmung
Eine Website sollte nicht nur über die schnelle Büro-Glasfaserleitung getestet werden.
Viele Besucher nutzen:
Mobilfunk,
überlastete WLAN-Netze,
ältere Smartphones,
Energiesparmodi.
Eine Seite mit 15 Megabyte Daten kann auf einem modernen Desktop unauffällig wirken.
Unter schlechteren Bedingungen wird das Problem deutlich sichtbar.
Gute Performance bedeutet deshalb, nicht nur für ideale Testbedingungen zu bauen.
Das Gerät des Besuchers zählt ebenfalls
Server und Netzwerk sind nur ein Teil.
Der Browser muss:
HTML parsen,
CSS verarbeiten,
JavaScript ausführen,
Layout berechnen,
Bilder dekodieren,
Seite zeichnen.
Auf leistungsfähigen Geräten geschieht das sehr schnell.
Auf älteren Smartphones kann dieselbe Seite wesentlich mehr Zeit benötigen.
Insbesondere JavaScript-lastige Websites sollten deshalb nicht ausschließlich auf High-End-Geräten beurteilt werden.
Das WordPress-Backend kann aus ganz anderen Gründen langsam sein
Eine Website kann für Besucher schnell sein, während /wp-admin/ träge reagiert.
Das ist nicht ungewöhnlich.
Öffentliche Seiten profitieren möglicherweise von umfangreichem Caching.
Im Backend müssen dagegen dynamische Daten verarbeitet werden.
Plugins können außerdem:
Dashboard-Widgets laden,
externe Lizenzserver kontaktieren,
Tabellen berechnen,
Statistiken auswerten,
Cron-Aufgaben ausführen.
Eine Backend-Performanceanalyse sollte deshalb separat erfolgen.
WP-Cron kann Hintergrundarbeit auslösen
WordPress besitzt ein System für geplante Aufgaben.
Plugins können darüber beispielsweise:
Backups starten,
E-Mails senden,
Daten synchronisieren,
temporäre Daten löschen.
Bei kleinen Websites funktioniert dies oft völlig unauffällig.
Bei umfangreichen Installationen können sehr viele geplante Aufgaben entstehen.
Wenn einzelne Prozesse lange laufen oder sich Fehler aufstauen, kann das zu Performanceproblemen beitragen.
Auch hier gilt: Erst messen, dann optimieren.
Externe API-Aufrufe können das Backend blockieren
Manche Plugins kontaktieren externe Systeme.
Zum Beispiel:
Lizenzserver,
Statistikdienste,
Updatequellen,
Cloud-Services.
Wenn ein solcher Dienst nur langsam antwortet und das Plugin synchron darauf wartet, kann eine WordPress-Seite oder Backend-Ansicht ebenfalls langsam werden.
Das ist ein gutes Beispiel dafür, warum nicht jedes Performanceproblem durch einen schnelleren eigenen Server gelöst wird.
Der Engpass liegt möglicherweise außerhalb der eigenen Infrastruktur.
Fehlerprotokolle können Hinweise liefern
Wenn eine Website langsam ist, lohnt sich ein Blick in technische Logs.
Dort können beispielsweise auftauchen:
PHP-Fehler,
Timeouts,
Datenbankprobleme,
Speichermangel,
fehlgeschlagene externe Verbindungen.
Logs beantworten nicht automatisch die gesamte Performancefrage.
Sie können aber zeigen, ob im Hintergrund ständig Fehler entstehen, die zusätzlich Ressourcen verbrauchen.
Eine saubere Website sollte Warnungen nicht jahrelang ignorieren.
Performance braucht Messwerkzeuge
Gefühl ist ein schlechter Benchmark.
Eine Website fühlt sich heute langsam an.
Nach dem Löschen eines Plugins wirkt sie schneller.
War sie tatsächlich schneller?
Vielleicht.
Vielleicht war nur das Netzwerk in diesem Moment besser.
Deshalb sollten Änderungen messbar verglichen werden.
Interessant sind unter anderem:
serverseitige Antwortzeiten,
übertragene Datenmenge,
Anzahl und Dauer von Netzwerkrequests,
JavaScript-Ausführung,
visuelle Ladephasen,
Datenbankabfragen.
Labordaten und echte Besucher beantworten unterschiedliche Fragen
Performance kann unter künstlich kontrollierten Bedingungen gemessen werden.
Das ist hervorragend, um Änderungen vergleichbar zu machen.
Echte Besucher verwenden jedoch:
andere Geräte,
andere Netzwerke,
andere Standorte,
andere Browser.
Deshalb können reale Nutzerdaten ein anderes Bild zeigen.
Beide Perspektiven sind wertvoll.
Laborwerte helfen bei reproduzierbaren Tests.
Felddaten zeigen, was tatsächlich draußen passiert.
Nicht jede Unterseite ist gleich schnell
Eine Startseite kann sehr komplex sein.
Ein normaler Artikel dagegen einfach.
Ein Shopprodukt lädt möglicherweise zusätzliche Skripte.
Der Checkout besitzt wiederum andere Funktionen.
Deshalb sollte nicht nur eine einzelne URL getestet und anschließend die gesamte Website beurteilt werden.
Sinnvoll sind typische Seitentypen:
Startseite,
Artikel,
Kategorie,
Landingpage,
Produktseite,
Checkout.
So lässt sich erkennen, ob das Problem systemweit oder nur bei bestimmten Templates auftritt.
Erst eine Ausgangsmessung, dann Veränderungen
Vor einer Optimierung sollte ein Ausgangszustand dokumentiert werden.
Sonst lässt sich später kaum beurteilen, was tatsächlich verbessert wurde.
Ein systematischer Ablauf könnte sein:
messen
↓
größtes Problem identifizieren
↓
eine Änderung durchführen
↓
erneut messen
↓
Ergebnis vergleichenDas ist langsamer als zehn Optimierungsplugins gleichzeitig zu installieren.
Aber erheblich aussagekräftiger.
Nicht zehn Dinge gleichzeitig verändern
Angenommen, du:
wechselst den Hoster,
installierst ein Cache-Plugin,
komprimierst Bilder,
entfernst drei Plugins,
wechselst das Theme.
Danach ist die Website schneller.
Warum?
Keine Ahnung.
Vielleicht war nur eine Maßnahme entscheidend.
Vielleicht verursachte eine andere sogar neue Probleme.
Performanceoptimierung wird deutlich verständlicher, wenn Änderungen kontrolliert erfolgen.
Beginne mit den größten Problemen
Ein 4,5-Megabyte-Hero-Bild ist ein offensichtlicher Kandidat.
Es wäre wenig sinnvoll, zunächst stundenlang eine 3-Kilobyte-CSS-Datei zu optimieren.
Das Pareto-Prinzip trifft bei Website-Performance häufig erstaunlich gut zu:
Einige wenige Ursachen erzeugen einen großen Teil der Verzögerung.
Deshalb sollte zuerst nach den großen Brocken gesucht werden.
Typische große Brocken sind schnell erkennbar
Häufig lohnt sich zunächst ein Blick auf:
sehr große Bilder,
extrem langsame Serverantworten,
riesige JavaScript-Pakete,
viele externe Dienste,
fehlendes Seiten-Caching,
einzelne langsame Plugins,
große Drittanbieter-Widgets.
Wenn dort ein klarer Engpass sichtbar ist, sollte er vor kleinen Mikrooptimierungen behandelt werden.
Performance und Funktion müssen gegeneinander abgewogen werden
Die schnellste Website wäre möglicherweise:
eine leere HTML-Datei.
Sie erfüllt allerdings keinen Zweck.
Performanceoptimierung bedeutet deshalb nicht, sämtliche Funktionen zu entfernen.
Ein Shop benötigt seinen Warenkorb.
Eine Videoseite benötigt Videos.
Ein Kartenportal benötigt Karten.
Die Frage lautet:
Ist der Performancepreis dieser Funktion ihrem Nutzen angemessen?
Das ist eine Produktentscheidung, keine reine Technikfrage.
Ein Video kann teuer sein und trotzdem sinnvoll
Ein Produktvideo kann mehrere Megabyte Daten und zusätzliches JavaScript benötigen.
Wenn es die Kaufentscheidung stark verbessert, kann das völlig gerechtfertigt sein.
Dann sollte man überlegen, wie es möglichst effizient eingebunden wird.
Performance darf nicht zum Selbstzweck werden.
Eine extrem schnelle Website, die ihre Aufgabe schlechter erfüllt, ist kein Erfolg.
Werbung verändert die Rechnung
Werbefinanzierte Websites besitzen ein besonderes Problem.
Werbung bringt Einnahmen.
Sie kann aber gleichzeitig:
zusätzliche Skripte,
externe Verbindungen,
Layout-Verschiebungen,
Tracking
und hohe Datenmengen erzeugen.
Einfach sämtliche Werbung zu entfernen würde die Performance verbessern, aber möglicherweise das Geschäftsmodell zerstören.
Hier muss optimiert werden, ohne die wirtschaftliche Funktion zu ignorieren.
Datenschutz und Performance können sich überschneiden
Weniger externe Tracker können:
weniger Datenübertragung,
weniger JavaScript,
weniger externe Verbindungen
und weniger Datenschutzkomplexität bedeuten.
Damit können Datenschutz und Performance teilweise dieselbe Richtung unterstützen.
Das bedeutet nicht, dass jeder externe Dienst schlecht ist.
Aber eine bewusste Auswahl kann mehrere Probleme gleichzeitig reduzieren.
Schnelle Websites sind leichter zu betreiben
Performanceoptimierung hat außerdem einen Wartungseffekt.
Eine Website mit:
überschaubarer Plugin-Struktur,
wenigen unnötigen Drittanbietern,
klarer Theme-Architektur,
optimierten Bildern,
funktionierendem Cache
ist häufig nicht nur schneller.
Sie ist auch einfacher zu verstehen und zu warten.
Performance und technische Einfachheit gehen häufig miteinander einher.
Die schnellste Lösung ist manchmal das Entfernen
Techniker denken bei Optimierung gerne an neue Werkzeuge.
Ein weiteres Plugin.
Ein CDN.
Ein Optimierungsdienst.
Eine neue Serverkomponente.
Oft ist die bessere Lösung:
etwas entfernen.
Ein nicht benötigtes Tracking-Skript.
Ein überflüssiges Plugin.
Eine unnötige Schrift.
Ein riesiger Slider.
Eine alte Integration.
Was nicht geladen wird, muss nicht optimiert werden.
Sollte man sofort den Hoster wechseln?
Nur wenn es gute Gründe gibt.
Ein Hostingwechsel ist sinnvoll, wenn Messungen zeigen, dass:
Serverantworten dauerhaft schlecht sind,
Ressourcenlimits regelmäßig erreicht werden,
die Plattform technisch nicht mehr passt,
notwendige Technologien fehlen,
der Anbieter unzuverlässig ist.
Wenn dagegen hauptsächlich 10-Megabyte-Bilder und externe Skripte das Problem verursachen, wird der Umzug wenig helfen.
Das Hosting sollte deshalb nicht zum universellen Sündenbock werden.
Sollte man sofort ein Performance-Plugin installieren?
Auch nicht automatisch.
Ein gutes Performance-Plugin kann viele nützliche Dinge erledigen:
Caching,
Kompression,
Dateioptimierung,
Lazy Loading.
Aber zwei oder drei überlappende Performanceplugins können sich gegenseitig behindern.
Zuerst sollte klar sein, welche Funktion benötigt wird.
Danach lässt sich ein passendes Werkzeug auswählen.
Was ist eine vernünftige Reihenfolge?
Für eine normale WordPress-Seite würde ich ungefähr so vorgehen.
Zuerst prüfen, ob die serverseitige Antwort grundsätzlich vernünftig ist.
Danach die größten übertragenen Dateien untersuchen.
Dann Bilder.
Danach JavaScript, CSS und externe Dienste.
Anschließend Caching und wiederholte Seitenaufrufe.
Parallel kontrollieren, ob einzelne Plugins oder Datenbankprozesse ungewöhnlich viel Arbeit erzeugen.
Dann erneut messen.
Das vermeidet blindes Herumoptimieren.
Nicht jeder Testwert muss perfekt sein
Performancewerkzeuge liefern gern Punktzahlen.
Das verleitet dazu, aus 94 unbedingt 100 machen zu wollen.
Dafür werden dann:
Funktionen entfernt,
komplizierte Hacks eingebaut,
Stunden Arbeit investiert.
Vielleicht merkt kein einziger Besucher einen Unterschied.
Ein Messwert ist ein Diagnosewerkzeug.
Er ist nicht das eigentliche Ziel.
Das Ziel ist eine Website, die sich für echte Besucher schnell und zuverlässig bedienen lässt.
Performance ist ein laufender Prozess
Eine Website kann heute schnell sein und in sechs Monaten langsam.
Inzwischen wurden vielleicht:
15 neue Plugins installiert,
100 Bilder hochgeladen,
ein Trackingdienst ergänzt,
ein neues Theme aktiviert,
Werbung eingebaut.
Performance sollte deshalb nicht nur einmal beim Relaunch betrachtet werden.
Sie gehört zur laufenden Wartung.
Veränderungen sollten beobachtet werden
Besonders interessant ist nicht nur:
Wie schnell ist meine Website heute?
sondern:
Wird sie langsam schlechter?
Wenn eine Kennzahl über Monate immer weiter abfällt, kann frühzeitig reagiert werden.
Das ist wesentlich angenehmer, als erst zu handeln, wenn Besucher sich beschweren.
Bei größeren Projekten kann Performance deshalb Teil des normalen Monitorings werden.
WordPress kann sehr schnell sein
WordPress besitzt manchmal den Ruf, grundsätzlich langsam zu sein.
Das greift zu kurz.
Ein schlankes WordPress mit:
gutem Hosting,
vernünftiger Datenbank,
funktionierendem Caching,
sauberem Theme,
sinnvollen Plugins,
optimierten Medien
kann sehr schnell reagieren.
WordPress macht allerdings sehr viel möglich.
Und genau dadurch kann man auch sehr viel zusätzliche Komplexität hineinbauen.
Die Plattform ist nicht automatisch der Engpass.
Die konkrete Umsetzung entscheidet.
Eine schnelle Website entsteht aus vielen kleinen Entscheidungen
Performance beginnt nicht erst beim Cache-Plugin.
Sie beginnt bereits bei:
Hostingwahl,
Themeauswahl,
Pluginarchitektur,
Bildgrößen,
Schriftarten,
externen Diensten,
Inhaltsgestaltung.
Je besser diese Entscheidungen von Anfang an getroffen werden, desto weniger muss später „repariert“ werden.
Performance ist deshalb auch Architektur.
Was du dir über langsame Websites merken solltest
Eine Website kann an sehr unterschiedlichen Stellen langsam werden.
Der Server kann lange für die Erzeugung der Seite brauchen.
WordPress und Plugins können unnötige Berechnungen und Datenbankabfragen erzeugen.
Bilder können zu groß sein.
JavaScript und CSS können den Browser beschäftigen.
Externe Dienste können zusätzliche Wartezeiten verursachen.
Netzwerk und Standort beeinflussen die Übertragung.
Der Browser und das Gerät müssen schließlich alles verarbeiten und darstellen.
Deshalb gibt es keine universelle Ein-Klick-Lösung.
Die wichtigste Performance-Regel lautet:
Erst messen, dann den größten Engpass beseitigen und anschließend erneut messen.
Das ist wesentlich zuverlässiger als wahllos Caches, CDNs und Optimierungsplugins übereinanderzustapeln.