php-homepage.com

Kein Widerspruch in sich - Performance mit Joomla

Nach dem letzten Anstieg der Besucherzahlen auf unseren kommerziellen Projekten, habe ich mich mit dem optimieren der bestehenden Joomla Webseiten beschäftigt, statt wieder Geld in ein weiteres Server Upgrade zu stecken.

Zwar bringen größere Besucherzahlen und die dadurch höhere Serverlast auch Mehreinnahmen,
aber man will ja die Früchte seiner Arbeit nicht großteils zum Hoster durchreichen:-) Und nicht nur der ökonomische Aspekt kommt hier zum tragen, man will den Besuchern ja keine Ladezeiten von 5 Sekunden und mehr zumuten.
(Ich persönlich schließe eine Seite, die nicht binnen 2-4 Sekunden zu rendern beginnt, und sei das Thema noch so interessant)
Stichwort:

Bounce Rate

Angeblich ja einer der unzähligen Rankingfaktoren von Google, und da ich ja grundsätzlich ein bequemer Mensch bin, schlage ich nur allzugern zwei Fliegen mit einer Klappe:-)

1) Optimierung von Joomla

Ein ausführliches Thema, zu dem es schon genügend Artikel, Blogbeiträge und Meinungen gibt.
Ich finde jedoch, dass es etwas mehr bedarf, als nur 2 Buttons im Joomla backend zu drücken um das Optimum aus Joomla herauszuholen. (Gzip und Cache, dazu findet man zu Hauf diverse Meinungen.

Ich habe aufgrund der Erfahrungen mit recht gut frequentierten Seiten (eine satte Million Pageviews im Monat Mai,
verteilt auf die drei größten domains (rein organischer Traffik) gemerkt,
dass Gzip den Server mehr beanspruchen kann, als es im Endeffekt bringt.
Auch beim Joomla Cache muss man eine Menge berücksichtigen.

Ich möchte nun die teils veralteten Informationen, die sich so über Google finden, mit aktuellen Erfahrungen vergleichen. Die Statistiken hierzu muß ich erst grafisch aufbereiten und mit Erklärungen versehen.

1.1) Joomla aufräumen

Der erste und wichtigste Schritt, wenn es sich um ein bereits bestehendes System handelt!
Hier kann sich wahrscheinlich jeder an die Nase greifen, der ein Joomla Projekt zumindest schon über wenige Jahre laufen hat,
und erfahrungsgemäß den Großteil der Zeit in Content und SEO investiert. Diese Tatsache gilt, denke ich, auch für jedes andere CMS.

Man installiert Plugins, testet neue Funktionen, baut Module ein, zwei sidebars, eine sidebar, Werbung hier, Formulare da und selten werden die "Reste" restlos entfernt.
Die Folgen brauchen nicht weiter erläutert werden...

Auf einer unserer Domains, war z.B. ein Plugin, das für eine "verflossene" Contentmanagerin
eingerichtet und mit ihr vergessen wurde.
Oder ein veraltetes Plugin, das noch unter PHP Version <5.3 entstanden ist,
und nun in der aktualisierten Version mit PHP7 ganze 0,8 Sekunden schneller arbeitet.

1.2) Log Files checken

Beim vorsorglichen backub einer Joomla-Seite im Zuge der Aufräumarbeiten
bin ich zufällig auf dieses Problem gestoßen:

die Datei "error.php" im Verzeichnis /logs/ umfasst 3,2GB, Ja Gigabyte!
Die Gesamte Domain mit >12.000 Fotos und Grafiken inklusiver generierter Thumbnails beansprucht gerade einmal 2,6GB!
Da darf man sich nicht wundern, wenn ein backub script mit Fehlern (timout, Scriptlaufzeit, Speichermangel,..) abbricht:-)

Üblicherweise sind Logfiles nur wenige KB groß und die Einträge in diese
kosten den Server sogut wie keine Ressourcen. Nimmt dies aber überhand, wie im beschriebenen Fall,
Muss man der Ursache auf den Grund gehen!

In diesem Fall war die "error.php" voll mit missglückten Login-Versuchen.
Die Ursache sind irgendwelche Möchtegern-Hacker,
die versuchen über primitive Scripte ins Joomla backend zu kommen.
(Man kann die Standard Login-URL von Joomla ins Leere leiten.
Die Mitarbeiter, die ins backend müssen, bekommen dann eine eigene URL.)

Zum Thema Joomla Sicherheit ein anderes mal:-)

2) Gzip oder deflate

Ohne groß ins Detail zu gehen, auf vielen einschlägigen Joomla Seiten wird vorgeschlagen, gzip zu aktivieren,
grundsätzlich liefert der Server dadurch komprimierte Dateien zum rendern an den browser des clients.
Klingt gut, da hier weniger Bandbreite beansprucht und die Seite schneller geladen wird.
Der Pferdefuß liegt hier im Detail: Da wir mit Joomla+ Extensions schon eine Menge Code vom Apache+PHP Container berechnen müssen, bevor eine Seite ausgeliefert wird,
laden wir dem Server noch mehr Last auf.
Wenn er jetzt den Browser fragt, ob er komprimierte Inhalte verarbeiten kann,
gzippt Joomla die Inhalte und schickt sie dem Browser.

Grundsätzlich sollte ja diese Vorgehensweise gewählt werden, ABER eben nicht,
wenn der Server ohnehin schon unter den Zugriffen ächzt. Dies hat zur Folge, dass im Endeffekt die Zeitspanne vom Aufruf bis zum anzeigen der Seite länger dauern kann,
als wenn man auf Gzip verzichtet.

mod_deflate als Alternative zu gzip?

Deflate funktioniert im Prinzip gleich wie Gzip, aber ohne (meist unnötigen) Overhead. Eine (modernere?) Alternative zu gzip und wird auch von Google (pagespeed) vorgeschlagen.
Aber Vorsicht, erstmal auf keinen fall beides benutzen und deflate hat auch Nachteile (das leidige Thema Browserkompatibiliät)
Meine Testreihen hierzu sind noch nicht abgeschlossen,
aber auf den ersten Blick konnte ich einiges an CPU Zeit mit dem Wechsel von gzip zu deflate sparen.
Dies wiederum verhält sich aber wieder von Server zu Server unterschiedlich.
Auch die Anweisungen in der .htaccess beanspruchen Kapazität und was sich schlussendlich bewährt, wird das Serverlog im Juli 2016 zeigen.
Die Grafik unten war ein Kurztest der Ladezeiten mit 2 Joomla Installationen.
mal ohne Komprimierung, mal mit Gzip und dann noch mit Deflate.
Aufgrund der Schwankungsbreite
(Serverauslastung während des Tests, Zuverlässigkeit der verwendeten Tools,...)
ist hier kein eindeutiger Trend zu erkennen.

Joomla mit Gzip und mod_deflate
Ein Auszug aus der Versuchsreihe gzip vs. deflate
mit zufälligen pages aus 2 Domains

Sobald ich mal Zeit und freie Serverkapazitäten habe,
werde ich eine neue Reihe mit mehr Messpunkten starten und versuchen,
ein zuverlässigeres Ergebnis zu erhalten.

August 2016
Fazit zu Gzip vs. Deflate:
In den von mir getesten Joomla-Projekten schneidet die Komprimierung mit mod_deflate über die .htaccess etwas besser ab als das über das Joomla backend aktivierte Gzip!
Da Gzip sowieso "veraltet" ist und angeblich auf vielen Servern nicht mehr eingesetzt wird,
lautet die Lösung als mod_deflate!
Also im Joomla backend Gzip ausschalten und die .htaccess von möglichen Gzip Anweisungen
z.B. <ifModule mod_gzip.c>...
befreien!

3) Joomla Cache

Richtig angewendet, bringt der Joomla Cache einiges an Geschwindigkeit und entlastet den Server.

Joomla Cache Plugin aktivieren

Joomla Cache Plugin
Cache Plugin aktivieren

Als ersten Schritt aktivieren wir die Joomla Erweiterung "System - Seitencache".
Ich persönlich schalte den Browser Cache nicht ein. (Browser-Cache benutzen)
Da der Traffic meiner Seiten hauptsächlich über Suchmaschinen kommt und somit dem großteil meiner Besucher keinen Nutzen bringt. Außerdem hat man als Webmaster keinen Einfluss über den Browsercache der einzelnen Besucher:-)
Die Seite würde aber bei mir lokal gecached werden, und ich will nicht dauernd meinen eigenen Browsercache leeren,
wenn ich etwas verändere.
Unter dem Tab erweitert, könnte man noch einzelne Seiten vom Cache ausnehmen, praktisch für Seiten, die sich laufend ändern.

Jetzt noch den Cache und die Art des Cachings im backend aktivieren

System/Konfiguration und dann den Tab "System" klicken.

erweitertes caching

der tooltip gibt Auskunft darüber, ob man "normales Caching" oder "erweitertes Caching" verwenden sollte.
In der Theorie zumindest, in der Praxis habe ich versucht herauszufinden, welche Variante nun besser geeignet wäre:

Erweiterter Systemcache: "schnellerer, größerer Systemcache, inklusive Modulcache" "Nicht für extrem große Seiten zu empfehlen"
Schnellerer, klingt gut, größer auch recht, Webspace haben wir genug, - aber was sind jetzt extrem große Seiten? unsere größten haben je 800-900 Seiten im Index (Artikel), mit insgesamt >6000 Bildern, jeder Menge Werbung
und 5000-6300 Besuchern pro Tag.

Das mit dem Modulcache kann ich bestätigen, beim Normalen Cache werden keine Module gecached.
Größe: Cache Ordner im zweistelligen MB-Bereich- kein spürbarer Unterschied zum normalen Caching;
Serverload auch kein Unterschied;

Fazit zu Normaler(conservative) zu Erweiterter(progressive) Cache: Wer keine Module hat, die sich ständig ändern, ist wohl mit dem erweiterten Cache besser bedient.
Bleibt noch die Cache Dauer, wenigstens etwas was hier klar zu sein scheint:
Die Zeit, wann eine gecachte Seite aktualisiert/bzw. neu generiert wird. Standard ist 15 Minuten, ich setze hier auf 120 um in den peak-Zeiten den Server zu entlasten.
Der Wert ist stark abhängig vom Intervall, in welchem ihr eure Seite aktualisiert,
neuer Content ist davon sowieso nicht betroffen, nur geänderter.

Update August 2016:
Nun weiß ich auch was der tooltip beim progressiven caching "Nicht für extrem große Seiten zu empfehlen" bedeutet...
War nach der Umstellung auf Urlaub, die Seiten liefen sehr gut, aber nach einigen Tagen wurde ich vom Serveradministrator angeschrieben: "Zu hohe Schreiblast in den Cache-Verzeichnissen", also wieder auf conservative caching umgestellt und alles läuft bestens.
Zur Sicherheit habe ich auch die Cache Time auf 360 Minuten erhöht, da die Seiten ohnehin nur 2-3 mal /Woche upgedatet werden.

Und man kann/sollte den Cache bei Änderungen ja auch wieder leeren:

Cache bei Bedarf leeren

Ein letzter Punkt wäre hier noch zu erwähnen und auf obigen Screenshot zu sehen: "abgelaufenen Cache leeren"

Da abgelaufene Elemente sowieso überschrieben werden, weiß ich nicht wozu die Funktion gut sein soll.
Aber gut wer knapp mit Webspace ist, sollte das von Zeit zu Zeit mal machen, aber bedenken, dass der Prozess auch CPU-Last verursacht und eventuell die erlaubte execution time von PHP (Php-Laufzeit-Limit) überschreitet. (steht in der Warnung im tooltip)
Bei meinem Test hat sich danach im Cache Ordner nichts verändert.
Im Normalfall werdet ihr durch löschen alter Logeinträge wohl mehr Speicherplatz frei bekommen:-)

4) Google Pagespeed

Der ursprüngliche Ausgangspunkt für alle Optimierungen!

Und von mir absichtlich erst zum Schluss erwähnt, da erst die oben aufgeführten Maßnahmen ergriffen werden sollten.

Wenn man diese Tools auch nicht 100% wörtlich nehmen sollte... Die Domain hier mit fast allen pages hat 98% Pagespeed, (mein eigenes "CMS", mehr Hobbyprojekt als Werkzeug für den Produktiveinsatz)
Die erwähnten Joomla-Projekte erzielen 90-96%.(besser gehts nicht, der Rest kommt von unbeeinflussbaren Faktoren wie
Werbung, shopsystem, Statistik usw.
100% Pagespeed erreicht man mit den optimierten flat file CMSes ohne Werbung usw.
Unbedingt erreichen muss man die 100% nicht, aber ein Wert über 80-85% sollte angestrebt werden.

Auf die einzelnen Pagespeed bzw. Yslow -Faktoren werde ich gesondert eingehen, der Aufwand hierfür kann recht groß sein
und das eigentliche Thema war ja (Server)Performance mit Joomla.

Aktuell habe ich mich mit dem Opcache in PHP7 beschäftigt und halte diese Art von (Bytecode)Caching für eine sehr gute Lösung!

Opcache mit PHP7 ein riesiger Performancegewinn!

Seit PHP Version 5.5 gibt es die die Möglichkeit Opcache zu nutzen.
Aktuell laufen unsere Projekte auf PHP7 und mir ist aufgefallen, dass manche eine gravierende Performancesteigerung erfahren haben. Dies liegt zum einen an der Version 7 von PHP und zum anderen am Opcache, der nur auf manchen Hostern standardmäßig aktiviert ist. So hatten wir auf einem Vserver mit Plesk 12 nach der Umstellung zu PHP 7 den Opchache automatisch aktiviert. Bei einem anderen Hoster musste ich dies erst mittels .htaccess und php.ini händisch machen. Nun laufen auch diese Seiten um weitere 30% schneller.

Welche Vorgehensweise gewählt werden muss, hängt einerseits vom Hoster bzw. den Servereinstellungen ab, andererseits muss man abwägen, ob diese zusätzliche Caching-Methode überhaupt einen Vorteil bringt.
Bei meinem eigenen "CMS" hier auf php-homepage bringt der Opcache keinen messbaren Geschwindigkeitszuwachs, bei den größeren Joomla-Seiten aber rund 30% schnellere Ladezeiten!
Ich teste noch die verschiedenen Kombinationen aus Joomla Cache und Opcache und werde dann für jedes Projekt individuell entscheiden.