Webserver-Performance optimieren (Teil 3): Antwortzeiten verkürzen

Heute wollen wir uns mit einem Kapitel beschäftigen, das häufig zu kurz kommt: Was können Sie tun, wenn Ihr Webserver zu lange braucht, um Anfragen überhaupt erst zu beantworten?

Flaschenhals Webserver?

Einen guten Hinweis auf langsame Webserver liefern dauerhaft hohe Werte bei der Time to First Byte (TTFB), also der Zeitspanne vom Seitenaufruf bis zum Empfang des ersten Datenpakets. Sie sollte möglichst unter 500 Millisekunden liegen, Google empfiehlt max. 200 Millisekunden. In Googles PageSpeed Insights wird der Wert bei den „Prüfungen“ (Audits) unter „Serverantwortzeiten“ (Server Response Times) angegeben. WebPageTest nennt den Wert „First Byte“ (die Messwerte weichen allerdings von denen von Google ab). 

Noch aussagekräftiger sind Wasserfallanalysen, wie sie WebPageTest und Pingdom bieten. Sie liefern für jede einzelne Anfrage Messwerte für wichtige Etappen des Ladeprozesses bis zum Empfang der ersten Daten, bei Pingdom z. B. Auskunft für DNS-Anfrage, SSL- Handshake, Verbindungsaufnahme (Connect), Senden und Warten. Hier gibt also ein besonders hoher Anteil der Wait-Zeiten (der gelbe Balken) an den Gesamtladezeiten von Ressourcen einen Hinweis auf Serverprobleme.

DNS-Auflösung beschleunigen

Diese Anzeige ist auch nützlich, um festzustellen, ob wirklich der eigene Webserver der Grund für lange Antwortzeiten ist. Das Problem könnte zum Beispiel auch in einer zu langsamen Auflösung des Domain-Namens liegen (der rosa Balken bei Pingdom). Aber Achtung: Die DNS-Antwort wird von Pingdom zwischengespeichert und fällt deshalb bei wiederholten Tests nicht mehr ins Gewicht. Ist der rosa Balken bei einem zweiten Test kürzer, heißt das also nicht, dass der DNS-Server diesmal schneller geantwortet hat. Bei Verzögerungen kann es sich lohnen, einen schnelleren DNS-Server zu testen, zum Beispiel den von Google (8.8.8.8 und 8.8.4.4) oder Cloudflare (1.1.1.1) oder ggf. einen Premium-DNS-Service. 

Server-Framework optimieren

Antwortet dagegen der eigene Webserver zu langsam, können ganz verschiedene Faktoren dafür verantwortlich sein. Neben den Hardware-Ressourcen sind das zum Beispiel Web Applikation Framework und Anwendungslogik, Datenbankabfragen oder Routing. Google empfiehlt daher, zunächst die Kernaufgaben des Servers bei der Ausgabe von Seiteninhalten zu identifizieren und zu messen, wie lange ihre Ausführung dauert. So können Sie sich auf die wichtigsten Performance-Killer konzentrieren.

Das Vorgehen bei der Optimierung wollen wir am Beispiel der populären Kombination Apache und WordPress illustrieren. Sowohl bei der Server-Konfiguration als auch beim CMS gibt es Stellschrauben, an denen Sie drehen können.

Auf jeden Fall empfehlenswert ist es, eine aktuelle PHP-Version zu verwenden – neuere Versionen sind erfahrungsgemäß schneller. Bei DomainFactory können Sie zudem zwischen einer Standard- und einer Light-Version mit weniger Modulen wählen, die beim Start geladen werden müssen.

Noch mehr Beschleunigungspotenzial bietet sich Ihnen, wenn Sie auf Ihrem Webserver HTTP/2 aktivieren können (Direktzugriff erforderlich). Der Nachfolger des Internet-Protokolls HTTP 1.1 kann dank Multiplexing (paralleles Laden aller Ressourcen über eine einzige TCP-Verbindung), Header-Komprimierung, Server Push und Ressourcen-Priorisierung die Performance erheblich verbessern. Voraussetzung für HTTP/2 ist eine aktive SSL-Verschlüsselung.

WordPress-Stellschrauben

Bei WordPress beginnt die Performance-Optimierung schon bei der Auswahl des verwendeten Themes. Unnötige Funktionen sollten abgeschaltet oder von vornherein gar nicht enthalten sein. Auch Plugins können WordPress-Seiten sowohl verlangsamen als auch beschleunigen – hier kommt es auf eine sinnvolle Auswahl an. Dabei ist es besser, sich vorab gründlich zu informieren, als Plugins testweise zu installieren und dann wieder zu verbannen. Weil nämlich viele Plugins bei der Standard-Deinstallation nicht vollständig entfernt werden, können sie auch postum noch die Performance beeinträchtigen.

Überflüssige Anfragen können Sie reduzieren, indem Sie in WordPress Pingbacks und Trackbacks (Link-Benachrichtigungen aus anderen Blogs) deaktivieren. Zudem ist es sinnvoll, die Anzahl angezeigter Posts pro Seite begrenzen – insbesondere bei hochfrequentierten Diskussionsseiten.

Caching aktivieren

Die mit Abstand populärste Empfehlung aber ist das Caching. Und das mit Recht: Wenn Inhalte direkt aus dem Cache geladen werden, spart das gerade bei komplexen Seiten oder zu langsamen Datenbankabfragen viel Zeit. Zudem benötigt der Server dann weniger Ressourcen, was ebenfalls der Performance zugutekommt. 

Grundsätzlich können Seiten auf dem Webserver oder auf Client-Seite, d. h. im Browser der Besucher oder auf Proxy-Cache-Servern zwischen Webserver und Endgerät, zwischengespeichert werden. Aktivieren Sie am besten beides. Eine dritte Caching-Option sind sogenannte Reverse-Proxy-Caches, wie sie von Content Delivery Networks bereitgestellt werden (dazu unten mehr). 

Serverseitiges Caching

Für serverseitiges Caching brauchen Sie viel Arbeitsspeicher. Setzen Sie dafür das PHP Memory Limit (in der php.ini) so hoch wie möglich, wenn möglich mindestens 256M, besser 512M. PHP-Anwendungen können durch die Aktivierung (bzw. Installation) von APCu (APC User Cache) und OPcache beschleunigt werden. Apache bietet für das Caching die Module mod_cache sowie mod_disk_cache und/oder mod_mem_cache an. PHP- und Apache-Caching sind aber im Hosting-Kontext oft nicht konfigurierbar. Mit beidem kann es zudem Kompatibilitätsprobleme beim gleichseitigen Einsatz von CMS-Caching geben.Deshalb ist für WordPress-Sites eher der Einsatz von Caching-Plugins zu empfehlen. Diese speichern die dynamisch generierten Webseiten als fertige statische Inhalte wahlweise auf Festplatte oder im Arbeitsspeicher und liefern sie beim Aufruf aus. Populäre Caching-Plugins für WordPress sind unter anderem WP Super Cache, W3 Total Cache beide (kostenlos) oder WP Rocket (Premium). 

Clientseitiges Caching 

Clientseitiges Caching durch Browser und auch Proxy-Caches kontrollieren Sie über die HTTP-Header der ausgelieferten Webseiten. „Expires“- und/oder „Cache-Control“-Header sagen dem Client, ob und wie lange eine Seite ohne erneute Validierung zwischengespeichert werden soll, also als „fresh“ gilt. Bei Apache werden diese Header über die Module mod_expires und mod_headers erzeugt.Die Steuerung der Caching-Header kann per .htaccess-Datei oder auch per PHP erfolgen. Wir werden in einem separaten Beitrag ausführlicher auf dieses Thema eingehen. Die oben genannten Plugins W3 Total Cache und WP Rocket (nicht aber Super Cache) können ohne htaccess-Modifikation ebenfalls das Browser-Caching nutzen.

Datenbank bereinigen 

Die WordPress-Datenbank enthält nicht nur sämtliche Textinhalte in Beiträgen, Seiten und Kommentaren, sondern auch Einstellungen, Benutzerinformationen und die Daten von Plugins (zum Beispiel Produktinfos von Online-Shops). Sämtliche Transaktionen hinterlassen in der MySQL-Datenbank ihre Spuren. Die Datenbank wird fragmentiert; durch Updates, deinstallierte Plugins, gelöschte Beiträge oder Revisionen von Beiträgen entstehen nicht genutzter Speicher (Überhang) und nutzloser Datenmüll, der Abrufvorgänge behindern kann. Es ist daher ratsam, die Datenbank regelmäßig zu bereinigen, zum Beispiel mit Hilfe von phpMyAdmin oder WP Rocket.

Dateien per Gzip komprimieren 

Um die Dateigrößen Ihrer Webseite zu minimieren, sollten Sie Text- bzw. Code-Dateien komprimieren. Schalten Sie dafür die Gzip-Komprimierung auf dem Server ein. Bei Apache übernimmt dies entweder das Basismodul mod_deflate oder das Erweiterungsmodul mod_gzip. Sie aktivieren auch die Gzip-Komprimierung entweder per .htaccess oder mittels WordPress-Plugin, etwa mit den bereits erwähnten Caching-Plugins W3 Total Cache und WP Rocket. Auch hier noch mal der Hinweis, dass die Kompression von Website-Daten vor der Übertragung die TTFB erhöhen wird – trotzdem wird dadurch die Leistung Ihrer Website verbessert.

Bilder optimieren 

Bilder gehören aufgrund ihrer Dateigröße zu den Seitenelementen, die häufig das Laden verlangsamen. Genaueres verrät wieder die Wasserfallanalyse. Deshalb sollten Bilder vor dem Upload automatisch komprimiert werden. Spezielle Plugins wie Imagify oder das Plugin für TinyPNG/TinyJPG nutzen dafür externe Dienste, um Ihren Server zu entlasten. Ebenfalls nützlich ist die Technik des verzögerten Ladens: Mit „Lazy Loading“ werden zunächst nur die Inhalte geladen, die der Browser im aktuellen Viewport („above the fold“) anzeigen soll. Auch dafür stehen zahlreiche WordPress-Plugins bereit, zum Beispiel a3 Lazy Load, BJ Lazy Load oder Lazy Load sowie wieder WP Rocket.

An der Basis ansetzen: CDN nutzen

Wenn Optimierungsmaßnahmen keine ausreichenden Verbesserungen bringen, dürfte das Performance-Problem an der Serverleistung liegen. Je nach Hosting-Dienstleister und Tarif teilen sich oft viele Kunden die verfügbaren Hardware-Ressourcen (CPU und Arbeitsspeicher). Je mehr Traffic ihre Seiten bekommen, desto wahrscheinlicher werden Überlastungen und schlechte Reaktionszeiten.

In diesem Fall können Sie erwägen, Ihren Tarif oder gleich den Hoster zu wechseln. Bei hohen Anforderungen sollten Sie einen dedizierten Server in Betracht ziehen. Prüfen Sie sorgfältig verfügbare Angebote und gleichen Sie sie mit Ihren Anforderungen ab. Es gibt aber noch eine zweite Möglichkeit: die Nutzung eines Content Delivery Networks. Ein Content Delivery Network (oder Content Distribution Network), kurz CDN, ist ein Netz verteilter Server-Cluster, die aktuelle Kopien von Webseiten zwischenspeichern, um die Performance zu optimieren und auch bei Lastspitzen eine hohe Verfügbarkeit zu garantieren. 

Ein großer Vorteil – insbesondere bei internationalen Webpräsenzen – ist die räumliche Verteilung des Netzes: So werden bei Seitenaufrufen die gewünschten Inhalte nicht vom Webserver Ihres Hosters, sondern vom jeweils nächstgelegenen CDN-Knoten ausgeliefert und Netzwerklatenzen minimiert. 

Zum Beispiel nutzt Sucuri, die Website Security Suite von DomainFactory, ein globales Anycast-Netzwerk mit zehn Server-Clustern in den USA, Europa und Asien und zwei CDN-Edges in Australien und Brasilien. Die Serverkonfiguration ist auf hohe Leistung optimiert; auch das neue HTTP-Protokoll HTTP/2 wird unterstützt. Auch für nicht international aktive Website-Betreiber ist Sucuri interessant, weil das CDN vor allem auch umfangreiche Sicherheitsfunktionen bietet, darunter Malware-Überwachung und Bereinigung, Website Application Firewall, Intrusion Prevention System und Website-Backups.