HowTo: Langsame Webseiten beschleunigen und Google Page Speed verbessern

Es ist kein Geheimnis, dass die Geschwindigkeit von Webseiten Einfluss auf die Positionierung in den Suchmaschinen hat. Leser erfreuen sich an schnellen Webseiten, deren Seiten in Bruchteilen von Sekunden geladen werden, und das wird von Google, Bing & Co. honoriert. Daher wird im Netz nahezu gebetsartig gepredigt, die Webseiten möglichst schnell zu konfigurieren. Gar nicht so einfach, denn wurden einmal zu lange Ladezeiten diagnostiziert, beginnt die Suche in den Tiefen des Webservers und der Webanwendung. Gerade bei Redaktionssystemen wie Typo3 oder WordPress sind die potentiellen Leistungsbremsen vielfältig.

So häufig man Ratschläge über möglichst schnelle Ladezeiten lesen kann, so selten findet man konkrete Anleitungen, wie man eine Performance-Analyse und -Optimierung durchführt. Das ist wahrscheinlich darin geschuldet, dass die Beschleunigung von Webseiten ein sehr komplexes Unterfangen ist, welches ein tiefgreifendes technisches Know-How voraussetzt. In diesem Artikel wagen wir uns trotzdem an dieses Thema heran, was übrigens einen aktuellen Grund hat. Wie im Teaser-Bild zu sehen ist meldete Googles Webmaster Tools eine signifikant ansteigende Ladedauer von PC-Erfahrung.de, was es zu lösen gilt. Da nach den ersten Recherchen kein simpler Grund für das Verhalten zu finden war, begann die Suche nach der angezogenen Bremse, welche in diesem Artikel dokumentiert wird.

Vorweg die Kern-Punkte dieses Artikels:

• Performance-Analyse und -Optimierung von www.pc-erfahrung.de und des Webservers
• Auffinden von Leistungsbremsen und Aufzeigen von Verbesserungsmöglichkeiten
• Leistungsanalyse, Server-Monitoring, Langzeitanalyse
• Erklärung der Leistungsparameter in Googles Webmaster Tools und Analytics
• Verbessern des Page Speed Wertes

 Inhaltsverzeichnis

 1 Ausgangssituation: Serverumgebung und lange Ladezeit
 1.1 Das Problemkind: PC-Erfahrung.de mit Typo3 4.3
 1.2 Vorbildlich: die Forensoftware phpBB3 von www.pce-forum.de
 1.3 Weiteres Typo3-Web: www.meik-schmidt.de
 
 2 Performance Analyse und Erläuterung der Google Geschwindigkeits-Parameter
 
 3 Anleitung: Performance-Killer aufspüren
 
 4 Server-Kommunikation (blaue Phase)
 4.1 Ping-Zeiten kontrollieren und mit Konkurrenten vergleichen
 4.2 Download-Geschwindigkeit
 4.3 Server-Auslastung prüfen
 4.4 Webserver-Monitoring: Langzeitanalyse der Serverauslastung
 4.5 Defektes Netzwerkinterface, Netzwerkkabel oder Probleme beim Switch
 4.6 "Script Kiddies": Unerwünschte und automatisierte Zugriffe verhindern
 4.7 Bots aussperren mittels robots.txt
 4.8 mod_evasive: Denial of service Attacken verhindern
 
 5 Server-Antwortzeit beschleunigen (grüne Phase)
 5.1 Xdebug: langsame Programmabschnitte finden
 5.2 Datenbank-Optimierungen
 5.2.1 Slow-Query-Log aktivieren : Langsame Datenbankabfragen finden
 5.2.2 SQL Explain
 5.2.3 Dauer der Abfrage in PHPMyAdmin
 5.2.4 Temporäre Tabellen für optimierte Datenbankabfragen
 5.2.5 MySQL-Server-Statistiken
 5.2.6 mysqlanalyze : fehlerhafte Tabellen finden
 5.2.7 MySQL-Binärlog deaktivieren
 5.3 Seitencache (static file cache)
 5.4 Log-Dateien
 
 6 Download-Phase (Orange)
 6.1 Zu große Datenmenge
 6.2 Serverseitige Komprimierung (gzip, mod_deflate) aktivieren
 
 7 Rendering im Browser (rote Phase)
 7.1 Externe Skripte meiden
 7.2 Aufwendiges JavaScript oder Flash-Animationen
 7.3 Große, komplexe Layouts (bsp. große Tabellen)
 7.4 HTTP-Requests - Anzahl der herunterzuladenden Daten

1 Ausgangssituation: Serverumgebung und lange Ladezeit

Beginnen wir zum Einstieg mit der Serverumgebung. Insgesamt werden drei Webseiten auf einem Root-Server betrieben. Die Eckdaten des Webservers:

• Gentoo Linux Hardened Betriebssystem
• Intel Core 2 Duo E7400 @ 2.80GHz
• 4 GB RAM
• Software Raid-1 mit einer 80 GB S-ATA Festplatte
• Apache 2, MySQL 5.1, PHP 5.3

Am Tag des Anstiegs der Seitenlade-Geschwindigkeit werden für alle 3 Webseiten ca. 400.000 Seitenaufrufe (PIs) in den letzten vier Wochen gemessen. Die Hardware ist für die Menge der Seitenaufrufe mehr als ausreichend dimensioniert.

Bei den Installierten Webseiten handelt es sich um folgende Content Management Systeme bzw. Foren-Software

• Web 1 = Typo3 4.3 ~ 380.000 PIs
• Web 2 = Typo3 4.3 ~ 3.000 PIs
• Web 3 = PhpBB 3 ~ 15.000 PIs

Lange Rede, kurzer Sinn: die genannten Webseiten mit dieser Besucherauslastung laufen nun bereits seit Jahren problemlos und performant. Und dieses sogar bis vor kurzem auf einer noch älteren Hardware.

1.1 Das Problemkind: PC-Erfahrung.de mit Typo3 4.3

Der Grund für diesen Artikel ist die Webseite www.pc-erfahrung.de selbst. Die installierte Typo3-Version 4.3 vollrichtet seit Monaten problemlos ihren Dienst bis plötzlich und ohne eigenes Verschulden die durchschnittliche Seitenladezeit von ca. 0,3 auf über 1,2 Sekunden anstieg. In den Webmastertools stieg die Dauer zum Herunterladen einer Seite deutlich an und auch Googles Online Page Speed Insight gibt eine Server Antwortzeit von 1,2 Sekunden an. Diese Werte sind definitiv zu hoch. PC-Erfahrung.de ist von den drei installierten Webseiten die mit Abstand meist frequentierte Seite.

Google WMT: plötzlicher Anstieg der Seiten-Download-Zeit von 0,3 auf über 1,5 Sekunden

Merkwürdig: das Ausliefern des HTML-Dokuments dauert aber nur ca. 0,3 Sekunden.

Anders sieht es Page Speed Insight: auch hier meckert Google über eine zu lange Serverantwort-Zeit

 

1.2 Vorbildlich: die Forensoftware phpBB3 von www.pce-forum.de

Das Forum www.pce-forum.de basierend auf phpBB3 ist unter Performance-Aspekten sehr wahrscheinlich eine Vorzeige-Webseite: keine Werbung, sehr wenige externe Skripte und ein einfaches Layout. Daraus resultieren sehr gute Leistungswerte: die durchschnittliche Dauer zum Herunterladen einer Seite liegt bei ca. 0,23 Sekunden und Page Speed Insight bestätigt uns eine schnelle Serverantwortzeit. Aber auch bei diesem Web ist die Seitengeschwindigkeit leicht negativ. Zu erwähnen ist, dass das Forum gerade einmal 5% der Seitenaufrufe im Vergleich zur Hauptseite www.pc-erfahrung.de generiert.

Leichte Tendenz nach oben, aber weiterhin sehr schnell.

Page Speed bescheinigt eine Serverantwort-Zeit von unter 0,2 Sekunden. Perfekt.

Auch das Online Tool Page Speed Insight bestätigt die Werte vom Browser-Plugin.

 

1.3 Weiteres Typo3-Web: www.meik-schmidt.de

Sehr interessant ist die private Webseite www.meik-schmidt.de. Sie wird nur sehr wenig frequentiert (3000 Seitenaufrufe im Monat), basiert aber ebenfalls auf derselben Typo3-Installation wie www.pc-erfahrung.de. Sie eignet sich daher hervorragend zum Vergleich der Webseiten-Geschwindigkeit. Die erste Erkenntnis ist, dass Typo3 grundsätzlich hohe Anforderungen an den Webserver hat. Page Speed Insight bestätigt uns eine Serverantwortzeit von 0,21 Sekunden, also knapp über der geforderten Hürde von 0,2 Sekunden. Das Browser-Plugin zeigt einen höheren Wert: 584ms (0,584 Sekunden) braucht der Server, um das HTML auszuliefern. Das sind wesentlich höhere Werte als beispielsweise die Forensoftware.

Auch hier sind Download-Zeiten in den Webmastertools leicht ansteigend, aber weiterhin im akzeptablen Bereich.

Typo3 frisst Ressourcen, was man an dieser sehr kleinen Webseite sehen kann: die Antwortzeit liegt mit 0,5 Sekunden vergleichsweise hoch.

Page Speed Insight mahnt die Antwort-Zeit ebenfalls an, wobei die Messlatte von 0,2 Sekunden nur sehr knapp gerissen wurde.

 

2 Performance Analyse und Erläuterung der Google Geschwindigkeits-Parameter

Google hilft uns mit seinen detaillierten Daten und Analysen dabei, die Flaschenhälse einer langsamen Webseite ausfindig zu machen. Die Informationen von Google Analytics sind komplex und dieser Artikel soll dabei helfen, die wichtigen Leistungsinformationen ausfindig zu machen und diese zu verstehen. Grundlegend gibt es folgende Anlaufstellen, die der Webseiten-Besitzer aufsuchen sollte, wenn die Webseiten-Geschwindigkeit zu wünschen übrig lässt:

• Google Webmaster Tools
  Crawling => Crawling-Statistiken => Dauer des Herunterladens einer Seite (in Millisekunden)
• Google Analytics
  Verhalten => Website-Geschwindigkeit => Übersicht / Seiten-Timings / Nutzer-Timings
• Page Speed Insight von Google, Pingdom oder Pagespeed
  Online Tools, welche die Webseite auf ihre Geschwindigkeit prüfen
• Page Speed Browser Plugin für Chrome oder Firefox
  Ladegeschwindigkeit im Browser analysieren

Werfen wir zuerst einen Blick in die Statistiken von Analytics:

Google Analytics - Website-Geschwindigkeit Seiten-Timings	Karten-Overlay: hiermit lassen sich regionale Geschwindigkeitsunterschiede ausfindig machen
Einer der häufigsten Flaschenhälse ist die Serverantwortzeit. Sie besagt u.a. wie lange der Server für die Berechnung benötigt

Im Menüpunkt Website-Geschwindigkeit findet man viele Leistungsparameter einer Webseite, die ein tiefgreifendes technisches Verständnis erfordern. Der Weg vom Nutzer zum Webserver und zurück birgt viele potentielle Leistungsbremsen, so dass ein genauer Blick notwendig ist, um die Schwachstelle ausfindig zu machen.

Folgende Leistungsparameter aus Googles Analytics Tool helfen dabei, die Performance-Killer einzugrenzen:

In der trockenen Theorie sind die genannten Begriffe nicht wirklich eindeutig, so dass folgende Grafik den Zusammenhang verdeutlichen soll:

Sehr schön zu erkennen ist, dass die einzelnen Leistungsparameter kumulierte Werte sind. So ist beispielsweise die Seitenladezeit die Summe aller angegebenen Leistungsparameter. Liegt die Dauer der Seitenladezeit bei mehreren Sekunden und die Webseite ist inakzeptabel langsam, so beginnt die Suche nach dem Abschnitt, der am längsten benötigt. Aus der Grafik ergeben sich folgende zentralen Abschnitte:

• Blau = der Weg vom Nutzer zum Server und zurück. Probleme entstehen durch eine langsame Internetanbindung des Servers, aber auch der heimische DSL-Anschluss kann den Verbindungsaufbau bremsen. Auch eine Überlastung des Servers erhöhen die Antwortzeiten in diesem Abschnitt.
• Grün = dieser Abschnitt entspricht allen internen Server-Abläufen. Folgende typische Probleme verlangsamen diesen Abschnitt: langsame Datenbank-Abfragen, überlasteter Server, schlecht entwickelte PHP-Skripte, falsch konfigurierter Webserver oder unperformante MySQL-Einstellungen.
• Orange = der Download des fertigen HTML-Dokumentes. Bei Problemen ist eventuell die Datenmenge zu groß oder wie in Punkt Blau beschrieben die Netzwerkanbindung zu langsam.
• Rot = dieser Abschnitt entspricht dem Rendering im Browser. Langsame Zeiten in diesem deuten vor allem auf externe Faktoren (bsp. Werbung) oder zu aufwendige Applikationen (bsp. JQuery) hin.

Ausführliche Informationen zu diesem Thema findet man in der Google-Hilfe "Website-Geschwindigkeit interpretieren".

Den beschriebenen zeitlichen Ablauf des Seitenaufrufs kann man mit der Page Speed Browser-Erweiterung hervorragend nachvollziehen. Das Page Speed Plugin zeigt in chronologischer Reihenfolge an, welche Inhalte wann und wie schnell geladen werden. Daraus lassen sich vor allem erkennen, ob

• die Serverantwortzeit (Generierung des HTML-Dokuments) zu hoch ist
• zu viele HTTP-Requests (Bilder, CSS, JavaScript) den Seitenaufbau verlangsamen
• die Download-Zeiten, bsp. durch zu große Datenmengen, zu hoch sind
• externe Skripte (bsp. Werbung) für Verzögerungen sorgen
• ab welchem Zeitpunkt das DOM der Webseite vollständig geladen wurde

Wichtiger Hinweis: bei der Benutzung der Browser-Plugins muss man berücksichtigen, dass die heimische DSL-Anbindung der Flaschenhals sein kann. Daher sollte man zur Bestätigung der Ergebnisse einen Online-Anbieter oder einen anderen Standort zusätzlich zu Rate ziehen.

Die beiden beschriebenen Analyse-Tools Google Analytics und Page Speed sind nützliche Helfer, wenn es darum geht, bei einer bereits diagnostizierten langsamen Webseite die Handbremsen zu finden. Das setzt aber voraus, dass man ein Problem bereits festgestellt hat. Und wie tut man dies? Hierfür kann man ebenfalls das Page Speed Plugin verwenden, aber für den allgemeinen Blick gibt es ebenfalls die entsprechenden Tools. Ein regelmäßiger Blick in die Webmaster-Tools unter dem Punkt Crawling-Statistiken informiert uns, wenn das Herunterladen einer Webseite durch den Google-Crawler auffällig langsam wird. Dieser Wert sollte zwischen 0,5 und 1 Sekunde, im Optimalfall sogar unterhalb von 0,5 Sekunden liegen:

Eine weitere Möglichkeit ist das Online Tool Page Speed Insight von Google, welches einer Online-Variante der Browser Plugins entspricht. Google legt fest, dass die Serverantwort-Zeit unterhalb von 200ms/0,2Sekunden liegen soll, was in folgendem Beispiel nicht gegeben ist und als Verbesserungsvorschlag angepriesen wird:

Alternativ zu Googles Page Speed Insight kann man auch Pingdom oder Pagespeed nutzen. Ebenfalls nützliche Online-Geschwindigkeitstests.

3 Anleitung: Performance-Killer aufspüren

Nachdem wir in diesem Artikel auf die theoretischen Grundlagen eingegangen sind und die Serverumgebung vorgestellt haben, widmet sich dieser Abschnitt mit der Performance-Optimierung. Schritt-für-Schritt wird gezeigt, welche Bereiche man untersuchen sollte, um die ungewünschten Performance-Killer ausfindig zu machen. Hierbei hilft uns die oben gezeigte Grafik "Zeitlicher Ablauf eines Webseiten-Aufrufs", welche einen Seitenaufruf in vier wichtige Abschnitte unterteilt.

4 Server-Kommunikation (blaue Phase)

Beginnen wir mit Antwortzeit und der Netzwerkgeschwindigkeit des Servers. Dieser Teil bietet vergleichsweise wenig Optimierungsmöglichkeiten, da er stark von dem Provider bzw. der Anbindung des Rechenzentrums abhängig ist. Positiv aber ist, dass die Performance-Checks relativ schnell abgearbeitet sind.

4.1 Ping-Zeiten kontrollieren und mit Konkurrenten vergleichen

Relativ einfach lassen sich die Netzwerkanbindung und Reaktionszeit des Server messen, ohne weitere Applikationen wie den Apache oder der MySQL-Datenbank zu berücksichtigen. Ein simples PING zeigt uns, wie lange der Server benötigt, um eine einfache Anfrage zu beantworten. Sind die Antwortzeiten zu hoch, kann es an einer langsamen oder überlasteten Datenleitung zum Rechenzentrum des Providers liegen. Aber auch ein Hinweis auf einen überlasteten Server lässt sich daraus erschließen

Es wird empfohlen, die PING-Zeiten nicht nur von einer Seite aus zu testen. Optimalerweise setzt man die PINGs auch vom betroffenen Server aus ab, um die ausgehende Geschwindigkeit zu prüfen. Außerdem sollte man die PING-Zeiten über einen längeren Zeitraum (mehrere Minuten, siehe Parameter -t) und unterschiedlichen Tageszeiten analysieren.

Hinweis: langsame DSL-Anbindung ausschließen!
Computer-Spieler kennen das Problem von hohen PING-Zeiten aufgrund einer schlechten DSL-Anbindung. Aus diesem Grund sollte man die PING-Zeiten im Optimalfall von mehreren Standorten aus prüfen. Hohe Ping-Zeiten können nämlich durch die heimische DSL-Anbindung entstehen.

Durch eine Konkurrenzanalyse erkennt man schnell, ob hier ein Performance-Killer vorliegt. In unserem Beispiel kann dies ausgeschlossen werden. Zwar ist PC-Erfahrung.de der langsamste Server, aber die Unterschiede liegen bei ca. 10-20ms, was 0,01 bis 0,02 Sekunden entspricht:

PING zu www.ard.de: 10ms
PING zu www.heise.de: 22ms
PING zu www.chip.de: 8ms
PING zu www.pc-erfahrung.de: 29ms

4.2 Download-Geschwindigkeit

Theoretisch könnte es sein, dass die Download- bzw. Upload-Geschwindigkeit des Webservers zu langsam ist, weil beispielsweise zu viele Webseiten an einer Internet-Leitung angeschlossen sind. Diese Problemstelle kann man ausschließen, wenn größere Daten von dem Webserver in einer angemessenen Zeit heruntergeladen werden können.

In folgendem Beispiel wurde eine Datei vom dem Webserver auf den PC heruntergeladen. Die durchschnittliche Übertragungsgeschwindigkeit betrug 3,79 MB pro Sekunde, was absolut ausreichend ist. Dass nicht der Webserver, sondern die heimische DSL-Verbindung der limitierende Faktor ist, zeigt der Download, der vom Webserver selbst gestartet wurde. Wer sich per SSH auf seinen Root-Server einloggen kann, der kann mittels wget eine Datei von einem anderen Server herunterladen. Der Server von PC-Erfahrung.de hat eine SDSL-Leitung und bietet bis zu 6 MB pro Sekunde.

Auch an dieser Stelle sei erwähnt, dass man die eigene DSL-Anbindung als potentiellen Flaschenhals prüfen muss. Bei langsamen Download-Raten sollte der Test von einem anderen Standort wiederholt werden, bei dem hohe Download-Raten gewährleistet sind.

4.3 Server-Auslastung prüfen

Denial of service (DoS) Attacken, abgestürzte Anwendungen oder ressourcenhungrige Programme können dafür sorgen, dass der Server bis an sein Maximum belastet wird. Daher empfiehlt es sich, kurz die Auslastung zu überprüfen. Im späteren Verlauf dieses Artikels zeigen wir im Detail, welche Komponenten eines Webservers besonders belastet werden.

Folgendes Beispiel zeigt, dass der Webserver mit einer Linux Load unterhalb von 1 nicht überlastet ist. Da es sich hierbei um eine Dual-Core-CPU handelt, darf die Linux Load den Wert nicht überschreiten.

Hinweis
Erweiterte Informationen zum Thema Performance-Analyse unter Linux findet man in folgendem Artikel: Linux Systemauslastung auswerten.

4.4 Webserver-Monitoring: Langzeitanalyse der Serverauslastung

Wer den Verdacht hat, dass der Server überlastet ist oder teilweise ausfällt, dem sei ein Monitoring-Tool wie munin empfohlen. Hierdurch lassen sich langfristige Analysen zur Server-Auslastung durchführen, indem über einen langen Zeitraum bis zu mehreren Jahren wichtige Systeminformationen gesammelt werden. Eine ausführliche Anleitung zu diesem Thema findet man in dem Artikel Webserver-Monitoring und Performance-Analyse mit Munin.

4.5 Defektes Netzwerkinterface, Netzwerkkabel oder Probleme beim Switch

Auffällig auf dem Webserver waren die relativ vielen verworfenen TCP-/UDP-Pakete. Im Vergleich zu anderen Webservern, wo dieser Wert gegen Null tangiert, deutet der hohe "dropped"-Wert auf eventuelle Probleme bei der internen Netzwerkanbindung hin. Dies könnte eine defekte Netzwerkkarte, eine Fehlkonfiguration, defektes LAN-Kabel oder ein Problem beim Netzwerk-Switch sein. Wer ebenfalls einen hohen Wert bei sich entdeckt, sollte die Ursachenforschung starten.

4.6 "Script Kiddies": Unerwünschte und automatisierte Zugriffe verhindern

Auch ein Blick in die Logdateien bzw. Zugriffsstatistik bringt manchmal sehr interessante Erkenntnisse mit sich, was man am Beispiel PC-Erfahrung.de sehen kann und für die es keine allgemein geltenden Regeln gibt. Nachdem mit dem Linux-Befehl top die aktiven Prozesse beobachtet wurden, poppte in regelmäßigen Abständen der Prozess awstats.pl hoch. Hierbei handelt es sich um das Statistik-Tool Awstats, welches die Webserver-Logs analysiert und daraus Zugriffstatistiken generiert (weitere Informationen hier). Die Statistiken waren auf PC-Erfahrung.de für jedermann frei zugänglich.

Awstats - Zugriffe aus China, USA und dem Rest der Welt erzeugen unnötige Serverlast
1000 Aufrufe innerhalb 30 Minuten

Problematisch wurde es, nachdem Crawler und Bots aus aller Welt diese Statistik intervallmäßig ausgelesen und dadurch die Last auf dem Server erhöht haben. Awstats speichert seine Statistiken in sehr großen Textdateien, die vor allem die Festplatten-Aktivität stark erhöht, wenn die Statistik aufgerufen wird. Ca. 1000 Aufrufe innerhalb einer halben Stunde durch Bots konnten gezählt werden.

Daraufhin wurde die Statistik entfernt und tatsächlich sank die Linux Load von ca. 0,5 auf unter 0,2. Auch in den Webmastertools sank die Dauer zum Herunterladen eines Dokuments um ca. 0,3 Sekunden, wobei nicht eindeutig bewiesen werden konnte, dass die schnellere Ladezeit damit zusammenhängt, da zeitgleich der nächste Punkt "Bots aussperren" durchgeführt wurde.

4.7 Bots aussperren mittels robots.txt

Nicht nur Google und Bing durchsuchen das World Wide Web, sondern noch zahlreiche weitere Bots. Jeder dieser Bots verursacht Last auf dem Server, da Seitenaufrufe generiert werden, die dem Webseiten-Betreiber aber in keinster Weise nutzen. So ist es beispielsweise bei SEO-Agenturen Mode geworden, einen eigenen Bot auf das Web loszulassen, um etwaige Konkurrenzanalysen durchzuführen.

Um diesen unerwünschten Bots entgegenzuwirken, kann man die robots.txt Datei ergänzen, um die entsprechenden Bots auszusperren. Natürlich in der Hoffnung, dass sich die Bots auch daran halten.

Eine Beispielliste findet man in der robots.txt von PC-Erfahrung.de:
https://www.pc-erfahrung.de/robots.txt

4.8 mod_evasive: Denial of service Attacken verhindern

Wer ein ernsthaftes Problem mit DoS-Attacken hat, welche die gesamte Webseite aufgrund massiver Webseiten-Aufrufe lahm legen, dem sei die Apache-Extension mod_evasive ans Herz gelegt. Dieses Modul erkennt, wenn zu viele Aufrufe von einer bestimmten IP-Adresse stammen und blockiert diese für einen bestimmten Zeitraum. Somit lassen sich DoS-Attacken in den meisten Fällen sehr gut abwehren.

Quelle: http://wiki.apache.org/httpd/DoS

5 Server-Antwortzeit beschleunigen (grüne Phase)

Wie in der obigen Grafik zu sehen beschreibt die grüne Phase die Dauer zwischen Anfrage und Antwort des Webservers. D.h. die Anfrage ist über die Internetanbindung beim Webserver eingetroffen und dieser beginnt nun die Bearbeitung, um das fertige HTML-Dokument an den Client auszuliefern. Diese Phase ist bei langsamen Webseiten in der Regel der Flaschenhals, denn zwischen Anfrage und Auslieferung des HTML-Dokumentes befindet sich der Kern einer jeden Webseite bzw. Web-Anwendung. Beginnend bei den Datenbank-Abfragen über die eigentliche PHP-Programmierung bis hin zu den schwerfälligen Redaktionssystemen wie Typo3 inklusive seiner Erweiterungen: die potentiellen Leistungsbremsen sind vielfältig und man muss Schritt für Schritt seine Webanwendung analysieren.

1. Schritt: die Dauer der Auslieferung des HTML-Dokumentes reduzieren

Das Hauptziel ist es, die Server-Antwortzeit zu reduzieren. Dazu eignet sich das Page Speed Plugin als perfektes Hilfsmittel, indem man die Auslieferungszeit des HTML-Dokumentes analysiert. Bei langsamen CMS-Systemen wie Typo3, unperformanten Datenbankabfragen oder einer komplexen Programmierung ist benötigt der Server zu lange, um das fertige HTML-Dokument auszuliefern.

5.1 Xdebug: langsame Programmabschnitte finden

Bevor man sich in den Tiefen einer Webanwendung verliert, ist es ratsam, sich ein Debugging-Tool zur Performance-Analyse zu installieren. Ein so genannter PHP-Profiler analysiert, welche Programmabschnitte bzw. welcher Funktionsaufruf besonders viel Zeit beanspruchen und somit für Verzögerungen sorgen. In folgendem Beispiel erkennt man anhand der Timeline, dass im rot markierten Bereich ein besonders langsamer Abschnitt mit einer Dauer von ca. 2,25 Sekunden vorliegt, den es zu optimieren gilt.

Xdebug ermöglich das Finden langsamer Programmabschnitte

Xdebug hilft uns also, die Flaschenhälse zu finden, um diese anschließend zu optimieren. Eine ausführliche Anleitung zu diesem Thema findet man in unserer Anleitung: PHP Performance Analyse mit xdebug.

5.2 Datenbank-Optimierungen

In der Regel sind es vor allem langsame Datenbankabfragen und weniger komplexe Funktionsaufrufe, die die Webanwendung bremsen. Vor allem bei großen Datenbanken findet man demzufolge die meisten Hebel zur Optimierung der Webseiten-Geschwindigkeit. Eine detaillierte Anleitung würde den Rahmen dieses Artikels sprengen, so dass erfolgversprechende Maßnahmen kurz angesprochen werden:

5.2.1 Slow-Query-Log aktivieren: Langsame Datenbankabfragen finden

Im MySQL-Server lässt sich eine Zeit-Schwelle definieren, ab welcher eine Datenbankabfrage als langsam eingestuft und in einer Log-Datei mitprotokolliert wird. Diese Option hilft ähnlich wie bei Xdebug langsame Datenbankabfragen zu finden, so dass diese beschleunigt werden können.

5.2.2 SQL Explain

Stellt man das Wort EXPLAIN vor einem SQL-Statement an, gibt MySQL Informationen über die jeweilige Datenbankabfrage aus und hilft, unperformante Datenbank-Abfragen zu finden. Dies ist vor allem bei der Verwendung bzw. Nicht-Verwendung von Tabellen-Indizes von großer Bedeutung. Eine genaue Beschreibung zur Verwendung findet man in unserem Artikel MySQL - Abfragen optimieren.

5.2.3 Dauer der Abfrage in PHPMyAdmin

Nachdem man eine langsame Datenbankabfrage identifiziert hat, lässt sich mittels PHPMyAdmin hervorragend die Performance-Optimierung durchführen. Dazu kopiert man die SQL-Abfrage in das SQL-Eingabefenster und entfernt anschließend die verdächtigen Teile der SQL-Abfrage. Die Leistungsbremsen sind in der Regel im WHERE-, ORDER BY- oder JOIN-Abschnitt zu finden. Entfernt man diese Abschnitte, lässt sich schnell ein Vorher-/Nachher-Ergebnis feststellen.

Datenbank-Optimierungen lassen sich mit PHPMyAdmin hervorragend nachverfolgen

5.2.4 Temporäre Tabellen für optimierte Datenbankabfragen

Optimale Datenbank-Abfragen sind das A und O einer schnellen Webseite, aber selbst die effektivsten Datenbankabfragen sind oftmals nicht schnell genug, da die Tabellengröße zu groß oder die Abfrage an sich zu komplex (bsp. viele JOINS) ist. Wer also einen großen Datenbestand vorhält (bsp. ein Online-Shop-Betreiber) und Informationen über mehrere Tabellen vorhält, die mit aufwendigen Order By- und Where-Statements verbunden sind, der sollte sich Gedanken über temporäre Zwischentabellen machen. Hierbei wird eine zusätzliche Tabelle aufgebaut, die das Ergebnis der ursprünglichen Tabelle vorhält bzw. die Abfrage vereinfacht. Diese temporäre Tabelle kann in regelmäßigen Abständen (in einem Nachtlauf) aktualisiert werden.

5.2.5 MySQL-Server-Statistiken

Eine weitere, aber weitaus komplexere Hilfestellung bieten die MySQL-Serverstatistiken. Hier wertet MySQL sämtliche Datenbankabfragen aus und bietet Vorschläge im Bezug auf die Programmierung und der Konfiguration des MySQL-Servers selbst. Wer Indizes bei Tabellen falsch einsetzt oder diese sogar vergessen hat, dem wird MySQL einen hohen Wert bei "Handler read next" haben, da MySQL die gesamte Tabelle scannen muss anstatt auf den Index zuzugreifen.

5.2.6 mysqlanalyze: fehlerhafte Tabellen finden

Theoretisch ist es möglich, dass eine Caching-Tabelle eines Redaktionssystems wie Typo3 defekt ist und nicht das Zwischenspeichern verhindert. Mit mysqlanalyze lässt sich schnell herausfinden, ob alle MySQL-Tabellen einwandfrei funktionieren.
Weitere Informationen findet man hier: http://dev.mysql.com/doc/refman/5.1/de/mysqlcheck.html

5.2.7 MySQL-Binärlog deaktivieren

Standardmäßig loggt MySQL jede Transaktion mit. Das kann gerade bei langsamen Festplatten zu Leistungseinbußen führen. Ein weiterer negativer Nebeneffekt ist, dass der Festplatten-Speicherplatz unnötig verbraucht wird, so dass man das MySQL-Binärlog deaktivieren sollte.
Weitere Informationen findet man in unserem Artikel MySQL Binary-Log

Hinweis
Weiterführende Informationen zur Optimierung von Datenbankabfragen findet man in unseren Artikeln:

MySQL - Abfragen optimieren und slow-query auffinden

PHP Performance Analyse mit xdebug

MySQL Binary-Log - Erklärung, Deaktivieren und Löschen

5.3 Seitencache (static file cache)

Zu Beginn der Internet-Ära war das Erstellen einer Webseite rudimentär: man startete einen Text-Editor, bearbeitete eine HTML-Datei und erstellte das HTML nach Vorgabe von www.selfhtml.org in Eigenregie. Die Performance ist überragend, da keine Berechnungen durch ein Content Management System entstehen. Es ist aber auch klar, dass gerade bei größeren und dynamischen Seiten ein Redaktionssystem eine Grundvoraussetzung darstellt, um die gewünschte Flexibilität und Administrierbarkeit zu erreichen. Das Ergebnis: Content Management Systeme verlangsamen den Seitenaufbau, da das zu liefernde HTML-Dokument bei jedem Seitenaufruf neu berechnet wird, obwohl sich in der Zwischenzeit keine Änderungen ergeben haben.

Wenn also alle Optimierungsmaßnahmen umgesetzt wurden und die Webseite weiterhin langsam agiert, ist ein so genannter Seitencache empfehlenswert, der eine dynamischen PHP-Seite wieder in ein statisches HTML-Dokument verwandelt. Der Trick hierbei ist, dass die jeweilige Seite einmal berechnet wird und anschließend das fertige HTML-Dokument in der Datenbank abgelegt wird. Beim nächsten Aufruf wird nur noch das bereits vorberechnete HTML-Dokument ausgegeben. Die komplexen Berechnungen, Datenbankabfragen usw. entfallen.

Die Einführung eines Seiten-Caches ist die wohl effektivste Methode,
um die Geschwindigkeit einer Webseite zu beschleunigen

Ein Seitencache bringt einen enormen Leistungsschub mit sich und bietet die größten Erfolgschancen bei der Beschleunigung einer Webseite. Die Last auf dem Webserver wird drastisch reduziert, da nur noch sehr wenige Festplattenzugriffe (bsp. durch die Datenbank) entstehen und die CPU (Berechnung der PHP-Skripte) sich anderen Dingen widmen kann. Der Nachteil eines Seitencaches ist der erhöhte Aufwand durch den Administrator oder Entwickler, der dafür sorgen muss, dass der Seitencache neu erstellt wird, wenn Änderungen vorgenommen werden. Der Aufwand aber lohnt sich: in oben genanntem Beispiel konnte nach Einführung des Seitencaches die Dauer des Herunterladens einer Seite von ca. 2,0 auf 0,5 Sekunden drastisch reduziert werden. Einen solch großen Sprung erreicht man mit einfachen Optimierungen nicht ansatzweise.

Wie aktiviert man aber einen solchen Seitencache? Dies ist abhängig von der verwendeten Webapplikation wie Typo3 oder Wordpress und der vorhandenen Erweiterungen. Hierfür muss man in den einschlägigen Foren recherchieren und nach Begriffen wie "static file cache" oder "site cache" suchen. Wer kein CMS einsetzt und ein eigens entwickeltes PHP-Web betreibt, dem sei die Output Buffering Control Functions von PHP ans Herz gelegt. Auf relativ einfache Weise (ob_start, ob_end_flush) wird die gesamte Ausgabe von PHP "aufgezeichnet", so dass man diese am Ende in die Datenbank speichern kann.

Weiterführende Links zum Thema Seitencache
- ob_start - Cache Your Website with PHP (in 1 minute)
- Output-Control-Funktionen @php.de
- Typo3 Seitencache - nc_staticfilecache
- Wordpress Caching Plugins

Eine abschließende Bemerkung zu PHP-Beschleunigern wie eAccelerator: hierbei handelt es sich Cache-Methoden für die Zwischenspeicherung oft genutzter PHP-Operationen. Hierbei handelt es sich aber nicht um den hier beschriebenen Seitencache.

5.4 Log-Dateien

Grundsätzlich ist die Kontrolle der Logdateien des Apache-Webservers, MySQL oder weiterer Systeminformationen zu empfehlen, um etwaige Fehler oder Auffälligkeiten zu finden. Aber nicht nur der Inhalt, sondern auch die Größe der Logdateien sollte man im Auge behalten, um unnötige Festplatten-Auslastung zu vermeiden. Bereits angesprochen wurde das MySQL-Bin-Log, welches alle Transaktionen mitloggt und den Webserver unnötig verlangsamt. Aber auch große Logstatistiken des Apaches werden oftmals übersehen. An dieser Stelle sei das Tool logrotate zu empfehlen, welches in vorgegeben Abständen die Logdateien leeren kann, so dass übergroße Logdateien verhindert werden.

6 Download-Phase (Orange)

Nachdem die Webseite angefordert, die Netzwerkkommunikation durchgeführt wurde und der Webserver das fertig berechnete HTML-Dokument zur Verfügung stellt, beginnt die Phase das Downloads durch den Client-Browser. Die Download-Phase bezieht sich vor allem auf die Dauer des Herunterladens des HTML-Dokumentes. Daher betragen die Werte wenige Millisekunden (0,1 bis 0,5 Sekunden). Aber auch hier lassen sich Probleme diagnostizieren, wenn beispielsweise das HTML-Dokument zu groß ist (schlechte und überladener HTML-Code) oder Netzwerkprobleme vorhanden sind.

6.1 Zu große Datenmenge

Die Regel ist einfach: je kleiner das HTML-Dokument, desto schneller der Download! Daher ist eine saubere HTML-Programmierung im XHTML-Stil in Verbindung mit CSS-Styleangaben eine Grundvoraussetzung für schlanke Webseiten. Wer beispielsweise einmal Webseiten mit Microsoft Frontpage oder OpenOffice erstellt hat, kennt das Problem eines aufgeblähten HTML-Codes. Damit unnötige HTML-Auszeichnungen nicht die Dateigröße in die Höhe treiben, ist eine strikte Umsetzung eines schlanken XHTML-Grundgerüstes und Layoutgestaltung mit CSS absolute Pflicht.

Als Daumenregel kann man sich merken, dass ein HTML-Dokument nicht größer als 100-200kb sein sollte. Dazu zählen keine Grafiken, CSS-Dateien, JavaScript-Dateien usw.

6.2 Serverseitige Komprimierung (gzip, mod_deflate) aktivieren

Als Anwender macht man es automatisch: große Dateien werden vor als ZIP, RAR oder sonstiges Format komprimiert, bevor diese über das Internet verschickt werden. Das spart Zeit beim Upload und Download. Dasselbe Prinzip nutzt die serverseitige Komprimierung auf dem Webserver. Wer einen Apache-Webserver betreibt, der sollte das mod_deflate.c (siehe Apache-Dokumentation hier) aktivieren. Dadurch werden Dateien wie HTML, XML oder CSS automatisch durch den Webserver komprimiert und im Browser des Nutzers wieder entpackt. Ziel ist es, die Download-Geschwindigkeit zu verbessern, indem die Datenmenge reduziert wird. Auch Google empfiehlt die Aktivierung der serverseitigen Komprimierung.

Sofern der Webserver mod_deflate.c unterstützt, kann die Komprimierung über die php.ini oder direkt in der Domain-Konfiguration aktiviert werden. Die erfolgreiche Konfiguration prüft man beispielsweise in Googles Page Speed.

 # vi /etc/apache2/vhosts.d/00_default_vhost.conf

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml
AddOutputFilterByType DEFLATE text/css text/javascript 		AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
AddOutputFilterByType DEFLATE application/javascript application/x-javascript
</IfModule>

7 Rendering im Browser (rote Phase)

Fassen wir es kurz zusammen, an welcher Stelle wir uns nun befinden: das HTML-Dokument, welches alle weiteren Informationen (Bilder, CSS, JavaScript usw.) enthält, hat den weiten Weg vom Webserver zum Client zurückgelegt und liegt nun zur weiteren Verarbeitung beim Nutzer. Nun beginnt der Browser mit der Verarbeitung und Darstellung des HTML-Dokuments. Er beginnt die benötigten Daten (Bilder, CSS, JS-Dateien usw.) nachzuladen, die Inhalte und das Layout darzustellen, die dynamischen JavaScript-Anwendungen zu verarbeiten und letztendlich die fertige Webseite auf dem jeweiligen Gerät darzustellen.

Dabei gibt es folgende Regeln zu berücksichtigen:

7.1 Externe Skripte vermeiden

Jede Einbindung eines externen Dokuments geht auf Kosten der Webseitengeschwindigkeit, da einerseits eine vollwertige HTTP-Anfrage an eine fremde Domain durchgeführt wird und andererseits diese Datei den gesamten Aufbau der Webseite blockieren kann. Grundsätzlich geht man bei externen die Abhängigkeit des externen Anbieters ein, wobei nicht geladene Bilder noch das geringste Problem darstellen. Vor allem eingebundene JavaScript-Dateien blockieren eine Webseite bis zum Timeout, sofern diese nicht erreichbar sind. Nicht ohne Grund ermahnt Google Page-Speed alle Webseiten-Administratoren, kein JavaScript "above the fold", sprich im sichtbaren bzw. oberen Bereich einzubinden:

Die externen Ressourcen häufen sich schnell zu einer großen Menge an. Als Beispiel sind...

• Display-Werbung,
• Google Adsense,
• Seitenstatistiken (Google Analytics),
• Frameworks wie jQuery,
• Amazon Advertiser API
• uvm.

... zu nennen. Auf der einen Seite sind diese Tools unabdingbar, andererseits wirken sie sich negativ auf die Webseiten-Geschwindigkeit aus, so dass man des Nutzung im Einzelfall prüfen muss. Folgende Maßnahmen werden empfohlen:

• Externe (JavaScript-)Dateien immer an das Ende einer Webseite, so dass der Seitenaufbau nicht blockiert wird und der User mit der Seite interagieren kann.
• JavaScript-Dateien wenn möglich auf die eigene Domain verlagern.
  Beispiel: anstelle <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script> sollte man die Bibliothek auf den eigenen Webspace hochladen und verwenden
• Wenn es unterstützt wird, sollte man Asynchrone Techniken nutzen

7.2 Aufwendiges JavaScript oder Flash-Animationen

Riesige animierte Werbegrafiken (bsp. Billboards), responsive Design oder Animationen sind nun einmal ressourcenhungriger als simpler Text auf weißem Hintergrund. Auch diesen Umstand sollte man berücksichtigen und daher wird empfohlen, die jeweilige Webseite mit einem altem Smartphone aufzurufen und die Geschwindigkeit "zu fühlen".

7.3 Große, komplexe Layouts (bsp. große Tabellen)

In der heutigen Zeit tummeln sich auch leistungsschwache Geräte wie Smartphones und Tablet-PCs unter den Client-Computern. Dies sollte man bei der Gestaltung einer Webseite berücksichtigen. Aufwendige JavaScript-Anwendungen, Flash-Animationen oder sehr große Seiteninhalte (bsp. große Tabellen wie auf der Grafikchiprangliste auf PC-Erfahrung.de) sorgen für zusätzliche Rechenlast auf dem PC. Wo moderne PCs keine Probleme haben, sind Smartphones oder alte PCs schnell überfordert und der Seitenaufruf verlangsamt sich.

Die obige Grafik aus Googles Analytics zeigt die durchschnittliche Seitenladezeit in unterschiedlichen Browsern. Hieraus lassen sich indirekt die Plattformen (PC, Smartphone usw.) auslesen. So lassen sich die hohen Werte im Chrome und Android Browser damit erklären, dass Smartphone-Anwender sehr lange warten müssen, bis die Seite komplett dargestellt wurde. Wo PC-Anwender 2-3 Sekunden warten müssen, sind es bei mobilen Anwendern 10-20 Sekunden!

7.4 HTTP-Requests - Anzahl der herunterzuladenen Daten

HTTP-Requests - Auszug aus dem Firebug-Plugin

Obwohl moderne Browser diverse Tricks kennen, um die Anzahl paralleler Verbindungen zur erhöhen, sollte man als Webseiten-Administrator die Anzahl der Grafiken bzw. Dateien möglichst gering halten. Hierbei gibt es folgende Möglichkeiten:

• Beim Webseiten-Design auf Grafiken verzichten. CSS ab Version 3 bietet hervorragende Möglichkeiten, runde Ecken, Farbverläufe und weitere Designelemente ohne Grafiken darzustellen.
• Mehrere CSS- und JavaScript-Dateien zusammenfassen. Lieber eine große Datei anstatt viele kleine.
• Verwendung von CSS-Sprites. Hierbei werden viele Grafiken zu einer großen Grafik zusammengefasst und dann mittels CSS sichtbar verschoben.
• Weitere Domain für Grafiken verwenden. Hierbei werden Grafiken von einer anderen Domain geladen. Dadurch wird die HTTP-Request-Beschränkung umgangen, da diese nur pro Domain gilt.

Fazit

Dieser Artikel ist sicherlich keine Anleitung mit detaillierten und tiefgreifenden Handlungsanweisungen. Vielmehr wurden viele Bereiche angesprochen, die zur Verbesserung der Website-Geschwindigkeit (Page Speed) beitragen. Webseiten-Betreiber sollten vor allem die unter Punkt 5 genannten Aspekte zum Thema Serverantwortzeit unter die Lupe die nehmen, da sich hier oftmals die Leistungsbremsen wiederfinden und die Erfolgschancen zur Beschleunigung der Webseite besonders hoch sind.

In unserem Fall konnte die Performance wieder in einen grünen und akzeptablen Bereich gedrückt werden. Welche Maßnahmen letztendlich dazu führten, lässt sich nicht eindeutig klären, da der sprunghafte Anstieg der Seitenladezeit einfach viel zu groß war. In der Regel liegen die Optimierungen unterhalb einer Sekunde. Nichtsdestotrotz sollen die durchgeführten Maßnahmen genannt werden, die für den Leistungszuwachs gesorgt haben:

• 5.2 Datenbank-Optimierungen: Es wurden einige selbstentwickelte Skripte überprüft, die fehlende Indizes aufwiesen
• 4.6 "Script Kiddies":: die AwStats-Statistiken wurden entfernt, so dass die Bot-Aufrufe reduziert wurden.
• 4.4 Webserver-Monitoring:: dies ist keine Maßnahme. Der Punkt soll angesprochen werden, um zu sagen, dass die Leistungsparameter des Servers absolut ausreichend sind.
• 4.7 Bots aussperren mittels robots.txt: es wurden einige bekannte Crawler ausgesperrt, um die Last zu verringern.
• 5.2.7 MySQL-Binärlog deaktivieren:
• Google Analytics Code: wurde gegen eine aktuelle Version ausgetauscht.
• Austausch Netzwerkkarte: aufgrund der hohen Anzahl der Dropped Packages wurde die Onboard-Netzwerkkarte durch eine dedizierte Netzwerkkarte ausgetauscht.

Seite zuletzt geändert am 22.05.2018 | Impressum | Datenschutzerklärung | Copyright © pc-erfahrung.de