So, wie findet Ihr die aktuelle Ladezeit des Digidiary? Gestern – und auch schon in den letzten Tagen – fiel mir auf, dass es mittlerweile unerträglich lahmte. Wer hier mitdiskutiert, hat ja einen Grund, mehrere Sekunden zu warten, bis sich endlich was zeigt. Aber spontane Besucher? Eher nicht…
WordPress-Blogs haben allgemein die Unart, im Lauf der Zeit immer voluminöser und lahmer zu werden: man bindet dieses und jenes Feature ein, probiert Zusatzmodule aus, erweitert die Style-Datei (mit den möglichen Formatierungen), klatscht GoogleAds und interaktive Web2.0-Gimmicks dran – und merkt in der zunehmende Betriebsblindheit gar nicht, dass das Blog kaum noch in akzeptabler Zeit auftaucht.
Testen, testen, testen…
Also machte ich mich gestern dran, das zu ändern. Ein Test mit einer statischen Seite (meine Homepage) zeigte, dass der Server an sich recht schnell ist – es musste also am Blog und seinen vielfältigen Einzelteilen liegen, die ja erst beim Aufrufen zusammen gesetzt werden. Aber WELCHE Teile waren nun der Grund der Langsamkeit?
Nach einem allgemeinen Ladezeit-Test nutzte ich das sehr gute Tool von Uptrends, das eine genaue Übersicht über sämtliche Objekte im Blog und deren Ladezeit erstellt. Noch genauer und zudem mit sehr hilfreichen Empfehlungen für die „Optimierung“ ist der Web Page Speep Report auf WebSiteOptimisation.com.
Reduzieren, Optimieren, Komprimieren
Angefangen hab‘ ich dann mit dem Entfernen von allem, was mir momentan entbehrlich erschien: das Twitter-Fenster flog raus, die „letzten Kommentare“ hab‘ ich gekürzt, ebenso die Zahl der Postings auf der Startseite, die ich dann auch noch mit „weiter lesen“-Umbrüchen auf mehrere Seiten verteilte. Auch die Social Bookmarks mussten dran glauben, denn ich hab‘ schon länger bemerkt, dass die kaum mal jemand nutzt.
Dann besichtigte ich die CSS-Datei (style.css) und entfernte Formate, die längst nicht mehr genutzt wurden, verkleinerte Hintergrundbilder oder entfernte sie ganz (für die Kambodscha-Rubrik gabs z.B. ein riesiges Header-Bild, das IMMER mit den Styles vorgeladen wurde, auch wenn keiner einen der alten Kambodscha-Artikel liest).
Sodann ergänzte ich die Maßangaben (Breite/Höhe) auch kleinster Grafik-Dateien – auch das spart Ladezeit, wenn auch nicht viel. Überhaupt bringts erst die Masse verschiedenster Verbesserungen, wobei mir zuletzt noch ein „großer Sprung nach vorne“ gelang, als ich mich in das Thema „Datenkompression“ vertiefte. Die meisten Webserver bieten „GZip-Komprimierung“ an, was bedeutet, dass z.B. HTML-Seiten, CSS-Dateien und Javascripte komprimiert zum Browser übertragen werden. So lassen sich mehr als die Hälfte der Daten einsparen – man muss es nur anweisen!
Leider gibt es für WordPress keine eingebaute Möglichkeit, einfach „alles komprimieren, was geht“ anzuweisen. Ich forschte also weiter in der Welt der Plugins und Beschleunigungstipps und kam vom Hölzchen aufs Stöckchen. Mittlerweile war ich voll in der Technik versackt, fasziniert vom Reich der algorithmischen Möglichkeiten, die „Welt“ zumindest auf Code-Basis unabweisbar zu beherrschen – wow! Stunde um Stunde verging, ich lernte ‚was über Caching, verschiedene serverseitige Komprimierungen, entsprechende Methoden in PHP, Änderungen in der .htaccess-Datei und wie ich den Server meines Providers checke: was darf ich da und was nicht?
Wieder einmal merkte ich, dass aus mir auch ein richtiger Nerd hätte werden können: so ein Sonderling, der mit den Bits und Bytes tanzt und seine Adrenalin-Schübe bei jedem Testlauf des gerade bearbeiteten Programms bekommt. Hach, was für ein Erfolgsgefühl, wenn das Testtool dann in fast allen Bereichen GRÜN anzeigt und seinen Kommentar mit „Congratulations!“ beginnt!
Die kleine, aber sichere Lösung
Faktisch hab‘ ich es dann vorsichtshalber bei zwei Zeilen in der .htaccess belassen:
php_flag zlib.output_compression on
php_value zlib.output_compression_level 5
und für die Komprimierung der Style-Datei das Plugin CSS-Kompress genutzt. Alles andere hätte deutlich mehr Studium erfordert: ich weiß gerne, was ich tue, wenn ich was ausprobiere – und schließlich will ich das Diary nicht versehentlich „zerschießen“.
Natürlich geht noch MEHR
Als nächstes könnte ich noch diverse kleine Grafiken (Twitter, das Auge-Icon, RSS-Icon, etc.) zu einer zusammen fassen und dann per CSS-Positionierung Ausschnitte davon als Hintergründe nutzen. Das würde auch wieder einige Bilder-Ladevorgänge ersparen.
Weiter denke ich dran, die Gravatar-Unterstützung wieder zu entfernen und lieber die Namen der Kommentierer prägnant links neben den Kommentar zu stellen. Denn wie ich an den langen Diskussionen der letzten Wochen sah, nutzt HIER kaum jemand Gravatare. Und die Einbindung ist so nachlässig programmiert, dass das immerselbe graue Platzhalterbildchen nicht etwa als EIN Bild kommt, sondern zigmal mit unterschiedlichen Namen!
Dann könnte ich mich noch ins Thema „Caching“ einarbeiten, mit Datenbank-Optimierungstools experimentieren, die CSS-Dateien „händisch“ besser packen, und – das kommt sicher – das Blog auf PHP5/MySQL5 umstellen, mit denen ein aktuelles WordPress schneller läuft.
Ach ja: wenn man erstmal unter die Haube gekrochen ist, kommt man nur schwer wieder hoch… .:-)
Diesem Blog per E-Mail folgen…
Diskussion
Kommentare abonnieren (RSS)
9 Kommentare zu „Blog-Ladezeiten verbessern: ein Nachmittag als Nerd“.