Suche
Suche Menü

Apache Feintuning – Schnellere Ladezeiten für Ihre Webseite

Die Ausgangslage

Ein aktuelles Projekt, welches in den nächsten Tagen online geht, setzt dabei auf unser Hauseigenes „AMFramework“, dem auf PHP basierenden Entwicklungsframework mit Inline-Editing Content-Management Funktionalitäten. Darüber hinaus handelt es sich bei dem neuen Projekt um eine lebendige, sehr Bilder-lastige Seite, bei der locker mal einige MB an bereits komprimierten Bildern in die Leitung geschickt werden. Daher reagierte die Seite manchmal langsam. Ziel war also die performance der Webseite zu erhöhen, vor allem die „page loading time“.

Wie bekomme ich bei diesem Daten Mix aus vielen Bildern und Javascript trotzdem schnelle Ladezeiten und ein geringes Datenvolumen hin?

Eine mögliche Lösung ist dabei eigentlich ganz einfach mit Apache 2 „Bordmitteln“ zu realisieren!

Dojos „Shrinksafe“ Tool für kompaktes js & CSS

Nun aber zu den Pain-Points: Da ein Großteil der Inline-CMS Funktionalitäten auf Dojo basieren und somit als JS-Library immer geladen und eingebunden werden müssen, entstehen an dieser Stelle beträchtliche Datenpakete, die sich durch die Leitung quälen. Dojo wird bereits in mehreren Layern ausgeliefert, um immer nur die Funktionen zu laden, die auch benötigt werden. Darüber hinaus sind alle JS und CSS Dateien mit Dojos „Shrinksafe“ Tool „Minified“ worde. Seitens der Anwendung konnte also kein weiteres Sparpotenzial realisiert werden.

Apache Direktiven erhöhen Performance & Geschwindigkeit

An dieser Stelle tritt die Analyse mit Googles tollem „Page Speed“ Plugin für Firebug in Aktion. Einige Analysen später gelangte ich mit folgenden Apache Direktiven zu einem bemerkenswerten Erfolg. Der Aufwand ist dabei minimal.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript text/javascript
</IfModule>

Mit ISPConfig: Diese Anweisungen kopiert man einfach in das „Apache Direktiven“ Feld im „Optionen“ Reiter der jeweiligen Seite und wartet eine Minute, bis die Einstellungen übernommen wurden.
Ohne ISPConfig: Entsprechend in die vhost Config Datei unter /etc/apache2/sites-available/NAME.vhost einfügen und den Indianer neustarten oder die Configs refreshen. (NAME = Adresse des vhosts)

Lösung: Cache & komprimierte Übertragung (mod_deflate)

Was bewirken diese simplen Einstellungen?

Zweierlei: Einerseits werden die angegebenen Dateitypen mit einem „Expires“ Header versehen, so dass Browser, dies dieses zulassen, die Daten zwischenspeichern (=cachen) und nicht erneut abrufen brauchen. Hierbei werden alle Daten einen Monat lang zwischengespeichert und danach ein mal neu abgerufen. Sofern sich etwas verändert hat, werden die Dateien natürlich neu abgerufen.

Die zweite Funktion aktiviert die komprimierte Übertragung von allen möglichen Dateitypen. Hier gäbe es als Alternative noch mod_gzip, welcher allerdings von Hand nachinstalliert werden muss, während mod_deflate standardmäßig mit installiert ist. Sollte sich nichts tun, könnte es sein, dass die entsprechenden Apache-Module nicht aktiviert sind.

Dafür einfach mal per SSH / Shell auf dem Server anmelden und folgende Befehle absetzen:

a2enmod deflate
a2enmod expires

Hier aber mal die Ergebnisse von unserer neuen AMFramework Installation:

Als Gast auf der Seite („Standardseite“ mit einigen Bildern):

  • vorher: ~480kb
  • mit Änderungen: ~140kb (beim ersten Laden, danach alles direkt aus dem Cache!)

Als Administrator auf der Seite (gleiche Seite):

  • vorher: ~1,3MB
  • mit Änderungen: ~450kb

Minimaler Aufwand – Maximaler Effekt

Mit einem Aufwand von nur knapp einer Minute kann hier das Datenvolumen um ein Vielfaches reduziert werden. Auch ohne Caching werden so 2/3 der vorher übertragenen Daten eingespart (Als Administrator knapp 1MB PRO Übertragung!). Daraus ergibt sich eine win/win Situation! Während der Besucher sehr verkürzte Ladezeiten erfährt, sparen wir auf Seiten des Servers an Rechenleistung und Traffic.

Schön wie einfach sparen sein kann, oder?

Wir machen auch ihre Webseite schneller!

Hat Ihre Webseite auch Performance Probleme? Das wirkt sich nicht nur auf die Benutzerzahlen aus, sonder mittlerweile auch auf das Ranking in den Suchmaschinen, wie z.B. Google. Die schlechte Performance Ihrer Seite merken Sie somit direkt im Geldbeutel. Außerdem kostet weniger Traffic natürlich weniger Geld = doppelt sparen.

Gerne machen wir eine kurze Analyse der Geschwindigkeit Ihrer Webseite und klären Sie über mögliches Potential zur Verbesserung der Performance auf. Ihre Besucher, Google & der Geldbeutel wird Ihnen dankbar sein.

3 Kommentare Schreibe einen Kommentar

  1. Hi,

    an sich ist es ein recht guter Beitrag, aus dem man sich so manches mitnehmen kann, jedoch muss ich bei einer These widersprechen.

    Du hast geschrieben: „Daraus ergibt sich eine win/win Situation! Während der Besucher sehr verkürzte Ladezeiten erfährt, sparen wir auf Seiten des Servers an Rechenleistung und Traffic.“

    Ist es nicht so, dass bei einer komprimierung der Daten mehr Rechenleistung benötigt wird? 😉

    Gruß
    Peter

    Antworten

    • Moin Peter,

      vielen Dank für dein Feedback, es klingt in der Tat ein wenig widersprüchlich, dass man Rechenzeit sparen kann, indem man eine Rechenzeit benötigende Operation durchführt. Wo man, meiner Meinung nach, Rechenzeiteinsparung erreichen kann, ist das Caching. Da man dadurch ja erreicht, dass die Komprimierung nur bei x von n Anfragen durchgeführt werden muss.

      Grundsätzlich aber zum Thema Rechenzeit:

      Klar verbraucht die Komprimierung Rechenzeit, allerdings sehe ich Rechenzeit in der heutigen IT Landschaft nicht als kritischen Faktor an. Alleine schon aktuelle Intel Desktop CPUs bringen genügend Leistung mit sich, um diverse Betriebssysteme parallel auszuführen.

      Bei Servern liegen zudem CPU Ressourcen im Regelfall eher brach, als dass diese voll ausgenutzt werden. Erst durch eine Reihe virtualisierten Systemen wird ein Server reell ausgelastet. Da gibt es eine ganze Reihe Studien und Literatur zu, die das zeigen. Auch wir betreiben diverse Systeme auf einem Hardware-Server und ich kann nicht behaupten, dass diese die Hardware ausnutzen.

      Es heißt immer so schön „It depends“ (=Es hängt von … ab), was auch hier zutrifft. Auf modernen Systemen ist Rechenze it meiner Meinung nach kein limitierender Faktor mehr. Bandbreite und Ladegeschwindigkeiten hingegen schon (limitierend in dem Sinne, dass der User und auch Suchmaschinen direkt davon beeinflusst werden). Kostenfaktoren sind auch eher die Bandbreite als Rechenzeit.

      ABER das ist natürlich abhängig davon, was die Hardware dadrunter zu bieten hat. In einer Cloud sollte man z.B. einfach mal vergleichen was der Kostenfaktor Rechenzeit VS. Bandbreite sagt.

      Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.