So, wie findet Ihr die aktuelle Ladezeit des Digidiary? Gestern – und auch schon in den letzten Tagen – fiel mir auf, dass es mittlerweile unertr\u00e4glich lahmte. Wer hier mitdiskutiert, hat ja einen Grund, mehrere Sekunden zu warten, bis sich endlich was zeigt. Aber spontane Besucher? Eher nicht… <\/p>\n
WordPress-Blogs<\/strong> haben allgemein die Unart, im Lauf der Zeit immer volumin\u00f6ser und lahmer zu werden: man bindet dieses und jenes Feature ein, probiert Zusatzmodule aus, erweitert die Style-Datei (mit den m\u00f6glichen 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.<\/p>\n Also machte ich mich gestern dran, das zu \u00e4ndern. Ein Test mit einer statischen Seite (meine Homepage<\/a>) zeigte, dass der Server an sich recht schnell ist – es musste also am Blog und seinen vielf\u00e4ltigen Einzelteilen liegen, die ja erst beim Aufrufen zusammen gesetzt werden. Aber WELCHE Teile waren nun der Grund der Langsamkeit?<\/p>\n Nach einem allgemeinen Ladezeit-Test<\/a> nutzte ich das sehr gute Tool von Uptrends,<\/a> das eine genaue \u00dcbersicht \u00fcber s\u00e4mtliche Objekte im Blog und deren Ladezeit erstellt. Noch genauer und zudem mit sehr hilfreichen Empfehlungen f\u00fcr die „Optimierung“ ist der Web Page Speep Report auf WebSiteOptimisation.com.<\/a><\/p>\n 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\u00fcrzt, ebenso die Zahl der Postings auf der Startseite, die ich dann auch noch mit „weiter lesen“-Umbr\u00fcchen auf mehrere Seiten verteilte. Auch die Social Bookmarks mussten dran glauben, denn ich hab‘ schon l\u00e4nger bemerkt, dass die kaum mal jemand nutzt. <\/p>\n Dann besichtigte ich die CSS-Datei (style.css) und entfernte Formate, die l\u00e4ngst nicht mehr genutzt wurden, verkleinerte Hintergrundbilder oder entfernte sie ganz (f\u00fcr 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). <\/p>\n Sodann erg\u00e4nzte ich die Ma\u00dfangaben (Breite\/H\u00f6he) auch kleinster Grafik-Dateien – auch das spart Ladezeit, wenn auch nicht viel. \u00dcberhaupt bringts erst die Masse verschiedenster Verbesserungen, wobei mir zuletzt noch ein „gro\u00dfer 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 \u00fcbertragen werden. So lassen sich mehr als die H\u00e4lfte der Daten einsparen – man muss es nur anweisen!<\/p>\n Leider gibt es f\u00fcr WordPress keine eingebaute M\u00f6glichkeit, einfach „alles komprimieren, was geht“ anzuweisen. Ich forschte also weiter in der Welt der Plugins und Beschleunigungstipps und kam vom H\u00f6lzchen aufs St\u00f6ckchen. Mittlerweile war ich voll in der Technik versackt, fasziniert vom Reich der algorithmischen M\u00f6glichkeiten, die „Welt“ zumindest auf Code-Basis unabweisbar zu beherrschen – wow! Stunde um Stunde verging, ich lernte ‚was \u00fcber Caching, verschiedene serverseitige Komprimierungen, entsprechende Methoden in PHP, \u00c4nderungen in der .htaccess-Datei und wie ich den Server meines Providers checke: was darf ich da und was nicht?<\/p>\n Wieder einmal merkte ich, dass aus mir auch ein richtiger Nerd<\/a> h\u00e4tte werden k\u00f6nnen: so ein Sonderling, der mit den Bits und Bytes tanzt und seine Adrenalin-Sch\u00fcbe bei jedem Testlauf des gerade bearbeiteten Programms bekommt. Hach, was f\u00fcr ein Erfolgsgef\u00fchl, wenn das Testtool dann in fast allen Bereichen GR\u00dcN anzeigt und seinen Kommentar mit „Congratulations!“ beginnt! <\/p>\n Faktisch hab‘ ich es dann vorsichtshalber bei zwei Zeilen in der .htaccess<\/a> belassen:<\/p>\n php_flag zlib.output_compression on und f\u00fcr die Komprimierung der Style-Datei das Plugin CSS-Kompress<\/a> genutzt. Alles andere h\u00e4tte deutlich mehr Studium erfordert: ich wei\u00df gerne, was ich tue, wenn ich was ausprobiere – und schlie\u00dflich will ich das Diary nicht versehentlich „zerschie\u00dfen“. <\/p>\n Als n\u00e4chstes k\u00f6nnte ich noch diverse kleine Grafiken (Twitter, das Auge-Icon, RSS-Icon, etc.) zu einer zusammen fassen und dann per CSS-Positionierung<\/a> Ausschnitte davon als Hintergr\u00fcnde nutzen. Das w\u00fcrde auch wieder einige Bilder-Ladevorg\u00e4nge ersparen. <\/p>\n Weiter denke ich dran, die Gravatar-Unterst\u00fctzung wieder zu entfernen und lieber die Namen der Kommentierer pr\u00e4gnant 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\u00e4ssig programmiert, dass das immerselbe graue Platzhalterbildchen nicht etwa als EIN Bild kommt, sondern zigmal mit unterschiedlichen Namen!<\/p>\nTesten, testen, testen…<\/h2>\n
Reduzieren, Optimieren, Komprimieren<\/h2>\n
Die kleine, aber sichere L\u00f6sung<\/h2>\n
\nphp_value zlib.output_compression_level 5<\/p><\/blockquote>\nNat\u00fcrlich geht noch MEHR<\/h2>\n