Blogoptimierung – woher kommt der Speed – Teil 1
13. Dezember 2009 | Von Kim Hübel | Kategorie: Web 2.0Oftmals wundert man sich, warum die eigenen Webseiten so lange brauchen, bis sie geladen sind, dabei ist es häufig gar nicht so schwer, ein Blog mit ein wenig Lade-Geschwindigkeit zu pushen. Dieser Artikel soll euch anhand vieler einzelner Beispiele zeigen, wie ihr die Gesamtladezeit eures Blogs oder generell eurer Website verbessern könnt. In dieser mehrteiligen Serie wenden wir uns also dem weiten Thema der Geschwindigkeitsoptimierung zu. Steigen wir also gleich ein in den ersten Teil und behandeln das Thema
Auftrennung in statischen und dynamischen Content
Eine moderne Website besteht im Grunde aus zwei verschiedenen Inhaltstypen: Statischen Inhalten – das sind sich nicht permanent verändernde Inhalte wie z.B. Grafiken, die zum Theme gehören, Javascripte, Style-Sheet-Dateien – und dynamischen Inhalten – die PHP-Dateien, die ihre Ausgabe aus Datenbanken etc. generieren. Um einen ersten Geschwindigkeitsvorteil zu gewinnen, sollte man diese Inhalte auf getrennten logischen Servern lagern. Das bedeutet, dass man für die statischen Inhalte eine eigene Subdomain (wie z.B. static.technikel.de) anlegt und die statischen Elemente dort in einer logischen Verzeichnisstruktur unterbringt. Der Trick liegt in Folgendem begründet:
Viele Browser wie z.B. die beiden Marktführer Internet-Explorer von Microsoft und der Firefox-Browser aus dem Hause Mozilla lassen nur eine beschränkte Anzahl an parallelen Verbindungen pro Server zu. Beim Internet-Explorer sind dies per Default 8, beim Firefox sogar nur 6 parallele Kontakte. Das bedeutet, dass pro Server parallel jeweils auch nur eine geringe Anzahl an Elementen der Website geladen werden kann. Durch die Auslagerung der statischen Inhalte auf eine eigene Subdomain ist es hier möglich, die Anzahl der Verbindungen zu erhöhen, ohne, dass der Benutzer hiervon irgendwas mitbekommt oder selbst eingreifen muss.
Was hier im Kleinen mit einer einzelnen Subdomain für die statischen Inhalte ausreicht, wird im Großen bei Websites mit richtig viel Traffic sogar noch dahingehend optimiert, dass man die Grafikdateien z.B. nicht nur auf einer einzelnen Subdomain verteilt, sondern gleich einen ganzen Pool an Servern nutzt. Häufig findet auch die Verwendung sogenannter Content Delivery Networks (CDNs) statt, was wiederum bedeutet, dass hier ganze Cluster hochperformanter Server bei externen Dienstleistern wie z.B. Amazon ihren Dienst tun. Preislich sind hier der Fantasie keinerlei Grenzen gesetzt.
Doch wir wollen mit den Füßen auf dem Boden bleiben und beglücken uns zunächst mit einer einzelnen Subdomain, die uns die statischen Inhalte liefert. Diese wird, sofern der Server dies unterstützt, auf die Verwendung der GZIP-Komprimierung getrimmt, was ich im konkreten Beispiel mittels einer einfachen .htaccess-Datei vornehme:
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl|jpg|gif|png)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
Gleichen Block verwende ich übrigens auch bei der eigentlichen Domain, die das Blog ausliefert, daher ist diese Block etwas generell und allumfassend gehalten, damit ich ihn nur entsprechend auf einen neuen Server kopieren brauche.
Der nächste Schritt wäre entsprechend, die statischen Teile aus dem Theme auf die statische Domain zu legen und das Theme im WordPress entsprechend anzupassen, damit die Stylesheet-Dateien wie auch die Grafiken in Zukunft von der neuen statischen Subdomain geladen werden. Wichtig ist auch, in den Stylesheet-Dateien die Grafik-Links für die Hintergrund-Grafiken etc. anzupassen, damit die Grafiken auch von der neuen Subdomain geladen werden.
Sind diese Schritte getan, haben wir bereits eine erste Maßnahme ergriffen, die Ladezeiten unseres Webprojektes zu minimieren.
Lesetipps im WWW
- WordPress: Ladezeiten verbessern durch Auslagerung von CSS/Bildern (CDN Light)
- Mit Amazon AWS, Google App Engine & Co. Applikationen auslagern
- Blog-Ladezeiten Optimieren – Teil 1
Moin Kim,
ich möchte beiden Punkten nicht widersprechen – besonders der erste Punkt hat seine Berechtigung. Allerdings zum zweiten Punkt möchte ich einen Zusatz geben:
Durch die GZIP-Komprimierung des Inhalts wird der Inhalt gerade bei langsameren Verbindungen zwar schneller übertragen aber gerade shared hosting bzw. kleine vServer etc. haben dabei ein anderes Problem: Du erreichst dabei deutlich erhöhte Ladezeiten (vor allem in Peak-Zeiten, wo viele Besucher online sind), da der Server mit dem komprimieren der Daten überfordert ist. Die First-Byte-Time, also die Zeit vom eintreffen der Anforderung beim Server bis zur Ankunft des ersten Byte beim Client, steigt in dem Moment signifikant. Der zweite Punkt ist, dass gerade moderne Browser z.T. anfangen Javascript und CSS umzusetzen sobald sie es bekommen. Das wiederum wird bei einer GZIP-Komprimierung deutlich erschwert, da die Daten erst dekomprimiert werden muss.
Dazu lässt sich aber leider keine allgemeine Aussage pro / contra GZIP treffen. Ich habe bei mir im Blog jegliche Kompression deaktiviert und damit eine Verbesserung der Ladezeit von über 2000ms = 2s erzielt. (Auf dem alten Server vor dem Umzug vor einigen Tagen)
Man sollte also beide Varianten austesten und die für sich und seine Hardware bzw. Zielgruppe (Online-Gamer => Hohe Bandbreite) am Besten geeignete Lösung nehmen.
Cheers,
antwortenKnut
Hallo Knut,
danke für deinen wertvollen Kommentar. Ich selbst habe den Punkt mit der GZIP-Komprimierung noch nicht wirklich so 100% durchtesten können, ob es wirklich zu solchen Effekten kommt. Bisher habe ich die Komprimierung immer auf recht gut ausgestatteten Maschinen, auf denen ich “weitestgehend alleine” war mit dem Webangebot eingesetzt und dabei eigentlich keine Nachteile spüren können, aber die von dir genannten Punkte sind durchaus interessant und mal den ein oder anderen Test wert.
Generell muss ich dir recht geben, dass gerade bei Serveroptimierungen immer auch die Zielanwendung ins Auge gefasst werden sollte: Was in einem Fall vielleicht gut ist, kann im anderen Fall komplett ins Gegenteil umschlagen.
Habe auch gerade gemerkt, dass ich noch kein Subscribe-to-Comments-Plugin installiert hatte
Das habe ich jetzt auch mal noch nachgeholt hier.
antwortenMoin Kim,
ich denke mal da wird in Zukunft noch der eine oder andere Kommentar kommen. Gerade im Bereich der Web-Technologie habe ich ja durch meine Arbeit doch ein wenig Ahnung. Habe den Blog erstmal abonniert und schaue mal was hier so kommt. (Ja und ich geb’s zu. Der Kommentar ist eigentlich nur dafür da die Kommentare via E-Mail zu bekommen
)
Cheers,
antwortenKnut
Von GZIP bin ich mometan auch abgekommen, irgendwie konnte ich das nachvollziehen das der Server überfordert war. Allerdings war das noch bei einem kleinen Hosting Angebot. Inzwischen läuft meine Seite auch wieder auf einem eigenen Server, evtl. werde ich das dort nochmal in Angriff nehmen und kann dann gern hier berichten.
antworten[...] wir uns im 1. Teil dieser Reihe mit dem Thema “Auftrennung in statischen und dynamischen Content” beschäftigt haben, möchten wir heute dem dynamisch erzeugten Content speziell bei [...]
antwortenSehr schöner Blog und sehr schönes Tutorial. Wird natürlich auf Deinen Kommentar hin aufgenommen
antworten[...] + Blogoptimierung – woher kommt der Speed – Teil 1 [...]
antworten[...] Kim Hübel behandelte die gleiche Thematik, wie ich soeben per pingback und tweet feststellte. Auch dort gibt es einen mehrteiligen Beitrag zum Thema – Hingehen, Lesen! [...]
antworten[...] – Blogoptimierung Woher kommt der Speed – Teil 1 – Auch bei Kim gibt es gute Tipps zur Optimierung. Er greift unter anderem das Thema Trennung des dynamischen und statischen Contents auf. [...]
antwortenAlso es gibt aber auch moderne Website die ohne diese Aufspaltung auskommen, sogar ohne Datenbank, ich nenne da mal Simple, ich fand das immer ganz gut. Vorteil wordpress sind aber viel mehr Anwendungsmöglichkeiten.
antworten@jan:
Das Problem liegt da, Jan, wo du Wartungsfreundlichkeit und fachliche Unkenntnis kombinieren möchtest. Da kommst du mit Web-Projekten, die auf reinen HTML-Seiten nicht mehr weiter… Es fängt ja schon an, wenn ein Unkundiger mehr als eine HTML-Seite gleichzeitig im synchronen Look halten soll. Das fällt denen genau so schwer, wie nicht auf irgendwelche SEO-Profis rein zu fallen, die glauben, mit ihrem Vodoo und breit gestreuter Kommentierung in diversen Blogs ein Linkbuilding betreiben zu können.
antwortenRT @KimHuebel: Blogoptimierung – woher kommt der Speed – Teil 1 http://bit.ly/5fAITu
antworten[...] Dieser Eintrag wurde auf Twitter von Mark Max Henckel erwähnt. Mark Max Henckel sagte: RT @KimHuebel: Blogoptimierung – woher kommt der Speed – Teil 1 http://bit.ly/5fAITu [...]
antworten