Blog Performance – Die Übertragungsgeschwindigkeit eines WordPress Blogs verbessern
Nachdem ich gestern geschrieben hatte, wie man die Performance seines Blogs messen kann gibt es hier noch einen Tipp, wie man seine Übertragungsgeschwindigkeit um einiges steigern kann. Dazu ist auch kein großer Voodoo nötig, den ab WordPress 2.5 ist dieses Feature schon eingebaut aber nur standardmäßig nicht aktiviert.
Ich hatte anfangs um meine Performance auf der Webseite zu steigern das Plugin WP Super Cache installiert.
Aber so eine richtige Performancesteigerung konnte ich damit aber nicht feststellen. Im Grunde macht das Plugin auch nichts anderes als die dynamischen WordPress Seiten statisch zu cachen. Das Problem ist aber selten beim Webserver zu suchen. Die CPU Performance ist in den meisten fällen vollkommend ausreichend um die dynamischen Seiten zu erstellen. Vielmehr bremst das zu übertragende Datenvolumen die Webseite aus und verlangsamt damit den Seitenaufbau.
Die Lösung ist eigentlich ganz einfach. Anstatt die Webseiten zu cachen ist es viel sinnvoller die Seiten zu komprimieren und dabei die Größe der Seite zu minimieren. Um das zu erreichen muss man nur die index.php im WordPress root Verzeichnis anpassen. Aber Vorsicht, nicht verwechseln mit der index.php aus dem Theme!
define(’WP_USE_THEMES’, true);suchen und folgende 2 Zeilen einsetzen, damit es am Ende dann so aussieht:
ini_set(’session.use_trans_sid’, false);
if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], ‘gzip’))
ob_start(”ob_gzhandler”); else ob_start();
define(’WP_USE_THEMES’, true);Das war es dann auch schon. Jetzt kann man das ganze testen und staunen. Ein toller Nebeneffekt ist, dass man dadurch viel weniger Traffic hat. Das ist besonders für diejenigen interessant die nur ein begrenztes Volumen zur Verfügung haben 
Ausserdem habe ich jetzt auch keine Probleme mehr mit Plugins, die sich nicht mit dem cache verstanden haben.
Wer aber jetzt denkt cool, dann benutze ich die Komprimierung und zusätzlich den Cache um an Traumwerte zu gelangen, den muss ich leider enttäuschen. Die Komprimierung und der Cache mögen sich gar nicht. Man muss sich also entscheiden welche Methode die beste Performance für seinen Blog bringt.
Für mich steht die Entscheidung fest: “Komprimierung statt Cache“. Probiert es einfach mal aus. Die Änderungen sind leicht durchzuführen und wem des Ergebnis nicht gefällt der kann es ja auch genauso schnell wieder abstellen.
Das sehe ich komplett anders. GZip bringt meiner Meinung nach nicht wirklich viel, da die Leitungen heutzutage fett genug sind. WP-Cache bringt Dir auch nicht wirklich etwas wenn Du keine Last auf dem Server hast. Wenn Du dann aber mal einen Peak hast und plötzlich in wenigen Minuten mehrere tausend Besucher auf Dein Blog zugreifen, dann wirst Du sehen wie WP-Cache abgeht. Ohne Last wirst Du keinen signifikanten Unterschied feststellen.
Hi Paddy,
Meine jetzige Erfahrung zeigt aber das bei mir im Moment Gzip viel mehr bringt als jeder Cache. Sollte es sich dann doch mal zeigen, das Gzip nichts mehr bringt werde ich mir dann wieder in Betracht ziehen es mal wieder mit einem Cache zu probieren. Ob Gzip oder Cache auf jeden Fall sollte man eins von beiden Einsetzen, denn in der Standardinstallation kommt man Performance mäßig nicht sehr weit.
von den tausend Zugriffen auf einmal bin ich noch ein
bisschenein stück weit entfernt. Vielleicht sollte ich auch mal was über Uschi Blum schreibenViele Grüße
Thomas
Hallo hombertho,
ein komprimiertes html kann in bestimmten Fällen auch das Gegenteilige bewirken. Wenn eine komprimierte Seite im Browser angeflogen kommt, muss erst decodiert werden. Man sollte sich nicht auf die Performance der Clients im WWW verlassen. Hier hilft eine Seitencache sicherlich mehr :wink:
Hi thovei,
vielen Dank für deinen Beitrag. Das stimmt, wenn der Client schwachbrüstig ist, dann wird es wieder langsamer. Ich habe es aber auf mehreren Clients und selbst auf dem Iphone getestet und da lief es mit Komprimierung eindeutig schneller als mit Cache. Leider muß man immer egal was man wählt Einschränkungen in kauf nehmen. Im Moment fahre ich mit der Komprimierung ganz gut. Kann aber auch sein, dass beim weiteren wachsen des Blogs dann Komprimierung eher von Nachteil ist und der Cache wieder mehr Vorteile bietet. Spätestens dann, wenn sich die Beschwerden einer langsamen Seite lauter werden
Viele Grüße
Thomas
Ich bemerke das bei mir… wenn ich mit dem “lahmen” Netbook Blogs besuche, dauert es doch länger als bei anderen Rechnern. Also hat wohl der Client nicht genug Dampf…
Wenn der jetzt noch entzippen muss, oh oh…
Aber auf jeden Fall ein Ansatz, der jeder mal für sich überdenken kann.
Ich persönlich habe eine spürbare Performance-Verbesserung, seitdem PHP mit eAccelerator läuft!
Hi Marc,
danke für den Hinweis. Das werde ich mir auf jeden Fall noch einmal genauer ansehen. Vor allem das mit dem eAccelerator. Ich wollte es gerade mal für Debian kompilieren aber leider zickt die Installation wieder mal rum. Wenn ein bisschen mehr Zeit ist werde ich das Thema aber noch einmal anpacken
Viele Grüße
Thomas
Ich glaube bei mir muss ich mir auch noch einmal die Konfiguration von eA. ansehen. Wenn der apache neu gestartet ist, sind die Antwortzeiten irgendwie nochmals besser. Scheint an einer Stelle ein Engpass zu sein…
Zwar alles nichts dramatisches, aber wir geben uns ja erst mit dem Optimum zufrieden
@Marc: Nur Optimum ist optimal :-D. Wenn ich mein neues Theme dann am start hab, dann werde ich mich noch einmal genauer mit dem Thema eA befassen. Ich habe ja auch noch die Hoffnung, dass mit dem neuen Theme alles schneller läuft
Ich habe letztes WE mein Theme auf einer Testdomain mit *leeren* Sitebars gehabt… war ein Unterschied wie Tag und Nacht.
Bei Gelegenheit werde ich also mal schauen, was wirklich in der Siebar sein sollte und was unter schnick-schnack fällt…
wie kann ich den prüfen ob es zu problemem mit gzip und wp-cache (wp-super cache) kommt? hab momentan mal beides im einsatz und kann bisher keine probleme entdecken. bin mir leider nicht wirklich schlüssig was mehr bringt.
@Marc:Haha noch 4 Monaten Antworte ich dir mal, aber der Kommentar scheint unter gegangen zu sein. Aber da ich jeden Kommentar beantworte kriegst du dennoch eine
Wie ist dein Test verlaufen. Leider ist wirklich vieles in der Sidebar Schnick Schnack und vieles wird glaube ich nicht einmal beachtet.
@Markus: Ob es Probleme gibt kannst du nur prüfen, indem du mal alle Browser durchtestest. Aber wenn schon keine Fehlermeldungen auftauchen, dann schein es doch ganz gut zu laufen. Wenn du Wissen willst ob es was bringt, dann kannst du das mithilfe den online Tools http://tools.pingdom.com/ Da wird genau aufgeschlüsselt wie lange welches Element zum laden braucht. Einmal aktivieren und ein paar mal durchlaufen lassen und einmal Deaktivieren und ein paar mal durchlaufen lassen. Wichtig ist, dass du die Tests mehrfach machst, da es immer zu anderen Werten wegen allgemeinen Schwankungen kommt.
@hombertho danke^^ hab jetzt mal einige mal das teil rennen lassen. hier mal paar ergebnisse.
1.76 seconds (ohne gzip / mit chache)
2.38 seconds (mit gzip / mit chache)
2.03 seconds (mit gzip / mit chache)
3.51 seconds (mit gzip / ohne chache)
1.85 seconds (mit gzip / mit chache)
1.63 seconds (ohne gzip / mit chache)
werde das mal weiter zu verschiedenen zeiten testen. bisher sieht es so aus das ich ohne gzip besser fahre.
@Markus: Das sind ja auf jeden Fall schon mal sehr gute Werte. Gzip muss eben nicht immer von Vorteil sein. Daher auch ruhig ausschalten, wenn es dann eher die Seite bremmst
habs erstmal aufgegeben mit gzip. ich komm auch leider nicht wirklich zu genauen testergebnissen.
@Markus: Hast du schon meinen vierten Teil von der Artikelserie gelesen. Wenn du bei gzip keine Verbesserung bekommst, dann lieber weglassen.
Hallo hombertho,
ich hatte die Tage imense Probleme mit diversen WP-Cachen – sei es Hypercache, Supercache, DB-Cace, DB-Cache-Reloaded usw. – teilweise lief aufgrund zweier Blogs die Serverlast immens in die Höhe.
Ich teste mal Deine Methode – scheint aber auf dem ersten Blick sehr gut zu laufen, schauen wir mal.
Gruß Tobias
@Tobias: Cache wird bei mir immer noch nicht eingesetzt. Mit meinen Methoden klappt es mit der Beschleunigung ganz gut und wenn mal ein Besucheransturm ankommt, denn ist bis jetzt mein Server auch noch nicht in die Knie gegangen.
Hallo Thomas, hast Du das Ganze schon mal mit den neuen Augen in den WMTs angesehen (Website-Leistung)? Unter diesem Aspekt bin ich gerade dabei einiges auszuprobieren und überlege auch, ob dies hier noch eine Möglichkeit sein könnte. Deine Artikelreihe ist natürlich auch sehr hilfreich
@Tanja: Meinst du in dem neuen Google Webmaster Feature? Ja da scheinen die Werte im Moment sehr zu schwanken und komischerweise werde ich sogar schlechter als besser. Mittlerweile habe ich ja seit diesem Artikel auf einen Cache namen W3 im Einsatz und bin auch sehr zufrieden damit. Laut pingdom Tool lädt meine Seite innerhalb von weniger als 6 Sekunden. Ein paar bremser habe ich noch drin, aber leider kann ich mich nicht von allem trennen.
Ja genau die meine ich
@Tanja: Da fehlen mir leider die Vergleichswerte. In der Zwischenzeit haben sich meine Besucher und die gelesenen Seiten auch mehr als vervierfacht.
Ich bin gerade runter auf 3,4 Sekunden in den WMTs mit ein paar kleinen Tunings. Vor 10 Tagen waren es noch 4,8 Sekunden.
Wobei ich denke, dass WordPress selbst auch schon eine lahme Krücke ist.
Auf dem Server auf dem mein Shop läuft (der ist da so gut wie ganz alleine drauf), erreicht der Shop sage und schreibe 0,8 Sekunden und der WordPress Blog dahinter klebt irgendwo bei 3,x… Und so ein Shop ist nicht gerade klein…
@Tanja: Wow da kann ich nicht mithalten. Im Moment zeigt mir das Tool an, dass meine Seite 8 Sekunden braucht und damit 80% langsamer ist als andere Webseiten. Dabei habe ich schon einiges optimiert. Der größte Teil macht jetzt noch die Bilder aus. Aber die mächte ich nicht komplett von meinem Blog verbannen. Ich hoffe das in der neuen WordPress Version 2.9 auch standardmäßig etwas an der Performance Schraube gedreht wird.
Man darf sich deswegen wirklich nicht verrückt machen
Und bei WordPress ist sicherlich noch einiges im Core rauszuholen, wie schon mein Vergleich zeigt. Da wären gut noch mal 2,5 bis 3 Sekunden gut zu machen, damit wäre uns allen gedient