Performance Tuning in Joomla Teil 2: Grundeinstellungen

Im ersten Teil dieser Serie habe ich beschrieben, warum du die Leistung deiner Webseite sowohl aus philosophischen als auch aus praktischen Gründen optimieren solltest und wo du anfangen kannst. Dieser Beitrag war notwendigerweise ein wenig allgemein gehalten.

Im zweiten Teil dieser Serie werden wir in einige der grundlegenden Dinge eintauchen, die du in Joomla tun kannst, um eine anständige Leistung freizuschalten.

 Dies ist eine Übersetzung des Artikels «Joomla Performance Tuning Part II- Basic Settings» von Nicholas Dionysopoulos aus dem Joomla! Community Magazine 11/21 (Link zum Original)

Grundlegende Systemeinstellungen

Beim Aufbau einer Website sind wir so sehr mit dem Design und der Funktionalität beschäftigt, dass wir vergessen, dass einige sehr grundlegende und ziemlich einfache Systemeinstellungen einen massiven Einfluss auf die Leistung unserer Websites haben können. Ein paar einfache Einstellungen in der globalen Konfiguration vor der Auslieferung der Website und ein paar einfache Serverprüfungen können den entscheidenden Unterschied ausmachen.

Caching

Die meiste Zeit, die der Server einer Webseite braucht, hat mit dem Aufbau der Seite zu tun, die dem Besucher angezeigt werden soll. Joomla hat, im Gegensatz zu WordPress, ein eingebautes Caching-System. Ich habe das Gefühl, dass die Leute es nicht genug anerkennen, weil sie an die minderwertige Caching-Erfahrung in Joomla 1.0 und 1.5 gewöhnt waren. Das war vor 10 bis 15 Jahren.

Gehe zur globalen Konfiguration deiner Webseite und stelle das Caching auf "AN - Erweitertes Caching". Die Option "Progressives Caching" ist die bessere Umsetzung des in Joomla eingebauten Cachings und stellt sicher, dass die Ausgabe jeder Erweiterung, die zum Aufbau Ihrer Seite verwendet wird, einzeln zwischengespeichert wird. Wenn eine Anfrage eintrifft, wird die Seite, wann immer möglich, aus diesen Teilen des zwischengespeicherten Inhalts zusammengesetzt. Dies kann sogar dazu beitragen, Leistungseinbussen gegenüber eines fertigen, nicht optimierten Templates auszugleichen. Es wird auf jeden Fall dazu beitragen, dass deine öffentlich zugänglichen Seiten schneller werden - genau das, was für das Suchmaschinen-Ranking deiner Webseite am wichtigsten ist.

Was die Zwischenspeicherung im Backend betrifft, so können die meisten Websites mit der Dateizwischenspeicherung auskommen, deren Leistung mit der von Memcached oder Redis auf einem anständigen, kommerziellen, gemeinsam genutzten oder virtualisierten Host vergleichbar ist - mit viel weniger Speicherverbrauch und daher viel billiger im Betrieb. "Ketzerei!", rufen die eher technisch orientierten unter euch. Bis zu einem gewissen Grad stimme ich mit dieser Meinung überein. Wenn du eine wirklich grosse oder stark frequentierte Website hast, ist es sinnvoll, einen dedizierten Memcached- oder Redis-Server als Caching-Backend zu verwenden. Das wird schneller sein. Die Chancen stehen gut, dass du, wenn du dies liest, keine solchen Webseiten hast, sondern eine eher gewöhnliche Webseite beschleunigen willst. Sogar meine eigene Unternehmenswebsite fällt in diese Kategorie, obwohl wir monatlich mehrere hunderttausend Besucher haben. Das sollte dir einen Eindruck von der Grösse der Webseite vermitteln, die von der Zwischenspeicherung auf einem speziellen Cache-Server profitieren würde.

HTML-Komprimierung

Wenn es einen Wettbewerb um die am meisten übersehene Option in Joomla gäbe, würde die Gzip-Seitenkomprimierung den Sieg davontragen. Falls du es noch nicht getan hast, solltest du diese Funktion aktivieren.

Diese Option sorgt dafür, dass der HTML-Inhalt, der von Ihrer Webseite an den Browser gesendet wird, mit dem GZip-Algorithmus (auch "deflate" genannt) komprimiert wird. Dadurch wird die Gesamtgrösse der an den Client übertragenen Daten erheblich reduziert. Die Zeitersparnis bei der Datenübertragung hat erhebliche Auswirkungen auf die Leistung Ihrer Webseite.

Wird die Webseite dadurch nicht verlangsamt? Nein, eigentlich nicht. Die von Joomla erzeugten HTML-Seiten sind nur wenige Dutzend Kilobytes gross. Es dauert einen Bruchteil einer Millisekunde, um sie auf etwa ein Drittel bis die Hälfte dieser Grösse zu komprimieren. Bei den typischen Übertragungsgeschwindigkeiten zwischen einem Host und Ihren Besuchern bedeutet dies einen Zeitgewinn von ein paar Millisekunden. Du gewinnst zwei bis drei Grössenordnungen mehr Zeit als du in diesem Fall verlieren kannst.

JavaScript- und CSS-Komprimierung

Viele Vorlagen und Plugins von Drittanbietern geben vor, Zeit zu sparen, indem sie Ihre statischen Dateien (JavaScript und CSS) während des Betriebs komprimieren. Ich empfehle dringend, diese Funktionen nicht zu verwenden. Die Komprimierung der statischen Dateien spart zwar Übertragungszeit, führt aber zu einem Netto-Leistungsverlust.

Der Grund für dieses kontraintuitive Ergebnis liegt in der Art und Weise, wie Server statische und dynamische Inhalte ausliefern. Ein richtig eingerichteter Webserver speichert häufig verwendete statische Inhalte im Zwischenspeicher. Ausserdem nutzt er fortschrittliche Funktionen des Betriebssystems wie die Speicherzuordnung von Dateien https://httpd.apache.org/docs/2.4/mod/core.html#enablemmap . Dies führt zu einer sehr schnellen Bereitstellung statischer Inhalte.

Wenn du ein PHP-Skript zur Komprimierung der statischen Dateien verwendest, muss der Webserver die Anfrage an die ausführbare PHP-Datei weiterleiten. Im besten Fall (PHP FastCGI Process Manager a.k.a. PHP-FPM, mit einem ausreichend grossen Pool an Prozessen und aktiviertem PHP OPcache) vergeudet dies immer noch einige Zeit mit der Kommunikation zwischen den Prozessen und dem Zurücksetzen des PHP-Parsers. Das Skript muss als unverändert bestätigt werden, seine vorkompilierte Binärdarstellung muss geladen und interpretiert werden, die statische Datei muss geöffnet, ihr Inhalt komprimiert und an Apache gesendet werden, um sie an den Client zu liefern. All dies dauert Dutzende von Millisekunden. Wenn du nicht gerade eine mehrere hundert Kilobyte grosse Datei komprimierst, ist der Zeitverlust weitaus grösser - und zwar um eine bis zwei Grössenordnungen! - als der Zeitgewinn durch die Bereitstellung einer kleineren, komprimierten Datei. Es ist also ein Nettoverlust.

Ich empfehle dringend, dies über den Webserver selbst zu tun. Wenn du Apache verwendest, kannst du Sie folgendes zu deiner htaccess-Datei hinzufügen:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript image/svg+xml
</IfModule>
<IfModule mod_gzip.c>
mod_gzip_on Ja
mod_gzip_dechunk Ja
mod_gzip_keep_workfiles Nein
mod_gzip_can_negotiate Ja
mod_gzip_add_header_count Ja
mod_gzip_send_vary Ja
mod_gzip_min_http 1000
mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 512000
mod_gzip_maximale_Grösse_im Speicher 60000
mod_gzip_handle_methods GET
mod_gzip_item_include Datei \.(html?|txt|css|js|php|pl|xml|rb|py|svg|scgz)$
mod_gzip_item_include mime ^text/plain$
mod_gzip_item_include mime ^text/xml$
mod_gzip_item_inkludieren mime ^text/css$
mod_gzip_item_include mime ^application/xml$
mod_gzip_item_include mime ^anwendung/xhtml+xml$
mod_gzip_item_include mime ^anwendung/rss+xml$
mod_gzip_item_include mime ^anwendung/javascript$
mod_gzip_item_include mime ^anwendung/x-javascript$
mod_gzip_item_include mime ^image/svg+xml$
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include handler ^server-status$
mod_gzip_item_einschliessen-Handler ^server-info$
mod_gzip_item_include-Handler ^application/x-httpd-php
mod_gzip_item_exclude mime ^image/.*
</IfModule>

Dein Webserver kann statische Mediendateien viel schneller komprimieren. Er kann die komprimierten Dateien im Speicher zwischenspeichern, um sie beim nächsten Mal schneller ausliefern zu können.

Joomla 4 ermöglicht es dir, deine statischen Dateien im Voraus mit GZip zu komprimieren und die vorkomprimierten Dateien auszuliefern, anstatt sie bei Bedarf vom Webserver komprimieren zu lassen. Das funktioniert folgendermassen. Angenommen, du hast die JavaScript-Datei
media/com_example/js/something.min.js. Komprimiere sie mit GZip in
media/com_example/js/something.min.js.gz. Wenn ein Browser die Datei
media/com_example/js/something.min.js anfordert, prüft der Webserver seinen Accepts HTTP-Header, um festzustellen, ob er GZip-komprimierte Ressourcen unterstützt. Ist dies der Fall, wird die Datei
media/com_example/js/something.min.js.gz anstelle der normalen, unkomprimierten Datei
media/com_example/js/something.min.js geliefert.

Die Voraussetzung dafür ist, dass du die mit Joomla gelieferte Datei htaccess.txt in htaccess (mit einem Punkt davor) umbenennst. Alternativ, wenn du Ihre eigene htaccess-Datei verwaltest, stellest du sicher, dass der folgende Code in der Datei enthalten ist:

## Diese Direktiven sind nur aktiviert, wenn das Apache mod_headers Modul aktiviert ist.
## Dieser Abschnitt prüft, ob eine .gz-Datei existiert und wenn ja, wird sie
## direkt gestreamt oder auf gzip umgeschaltet.
## Wenn Ihre Seite nach der Aktivierung dieser Funktion seltsam aussieht und Sie sehen
## ERR_CONTENT_DECODING_FAILED in der Netzwerk-Registerkarte Ihrer Browser-Konsole,
## dann gzippt Ihr Server bereits css- und js-Dateien und Sie brauchen diesen
## Block in Ihrer htaccess aktivieren
<IfModule mod_headers.c>
# Serve gzip-komprimierte CSS-Dateien, wenn sie existieren
# und der Client gzip akzeptiert.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

# Serve gzip-komprimierte JS-Dateien, wenn sie existieren
# und der Client gzip akzeptiert.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve korrekte Inhaltstypen, und verhindern mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve korrekten Kodierungstyp.
Header append Content-Encoding gzip

# Proxies zwingen, gzipped zu cachen &
# nicht-gezippte css/js-Dateien separat zu cachen.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

Joomla 4 stellt die vorkomprimierten .gz-Dateien für alle statischen JavaScript- und CSS-Dateien in seiner Distribution zur Verfügung. Wenn du diesen htaccess-Trick aktivierst, wird deine Webseite mit minimalem Aufwand noch schneller. Fantastisch, nicht wahr?!

Zwischenspeicherung statischer Medien

Die Verringerung der Grösse statischer Medien durch Komprimierung ist die halbe Miete und ist vor allem für Erstbesucher wichtig. Wenn jemand Ihre Webseite erneut besucht, ist es sinnvoll, dass der Browser statische Medien aus dem Cache des Browsers bereitstellt, ohne das Netzwerk zu belasten. Wenn du Apache verwendest, kannst du den folgenden Code in deine htaccess-Datei einbauen:

<IfModule mod_expires.c>
# Verfallskontrolle einschalten
ExpiresActive On

# CSS und JS Verfall:
ExpiresByType text/css "jetzt plus 1 Jahr"
ExpiresByType anwendung/javascript "jetzt plus 1 Jahr"
ExpiresByType anwendung/x-javascript "jetzt plus 1 Jahr"

# Bilddateien Verfall: 1 Monat nach Anfrage
ExpiresByType image/bmp "jetzt plus 1 Jahr"
ExpiresByType image/gif "jetzt plus 1 Jahr"
ExpiresByType image/jpeg "jetzt plus 1 Monat"
ExpiresByType image/jp2 "jetzt plus 1 Monat"
ExpiresByType image/pipeg "jetzt plus 1 Monat"
ExpiresByType image/png "jetzt plus 1 Monat"
ExpiresByType image/svg+xml "jetzt plus 1 Monat"
ExpiresByType image/tiff "jetzt plus 1 Monat"
ExpiresByType image/vnd.microsoft.icon "jetzt plus 1 Monat"
ExpiresByType image/x-icon "jetzt plus 1 Monat"
ExpiresByType image/ico "jetzt plus 1 Monat"
ExpiresByType image/icon "jetzt plus 1 Monat"
ExpiresByType image/webp "jetzt plus 1 Monat"
ExpiresByType text/ico "jetzt plus 1 Monat"
ExpiresByType anwendung/ico "jetzt plus 1 Monat"
ExpiresByType image/vnd.wap.wbmp "jetzt plus 1 Monat"
ExpiresByType anwendung/vnd.wap.wbxml "jetzt plus 1 Monat"
ExpiresByType application/smil "jetzt plus 1 Monat"

# Ablauf von Schriftartendateien: 1 Woche nach Anforderung
ExpiresByType anwendung/vnd.ms-fontobject "jetzt plus 1 Woche"
ExpiresByType application/x-font-ttf "jetzt plus 1 Woche"
ExpiresByType anwendung/x-font-opentype "jetzt plus 1 Woche"
ExpiresByType application/x-font-woff "jetzt plus 1 Woche"
ExpiresByType font/woff2 "jetzt plus 1 Woche"
ExpiresByType image/svg+xml "jetzt plus 1 Woche"

# Ablauf von Audiodateien: 1 Monat nach Anfrage
ExpiresByType audio/ogg "jetzt plus 1 Monat"
ExpiresByType anwendung/ogg "jetzt plus 1 Monat"
ExpiresByType audio/basic "jetzt plus 1 Monat"
ExpiresByType audio/mid "jetzt plus 1 Monat"
ExpiresByType audio/midi "jetzt plus 1 Monat"
ExpiresByType audio/mpeg "jetzt plus 1 Monat"
ExpiresByType audio/mp3 "jetzt plus 1 Monat"
ExpiresByType audio/x-aiff "jetzt plus 1 Monat"
ExpiresByType audio/x-mpegurl "jetzt plus 1 Monat"
ExpiresByType audio/x-pn-realaudio "jetzt plus 1 Monat"
ExpiresByType audio/x-wav "jetzt plus 1 Monat"

# Ablauf von Filmdateien: 1 Monat nach Anfrage
ExpiresByType application/x-shockwave-flash "jetzt plus 1 Monat"
ExpiresByType x-world/x-vrml "jetzt plus 1 Monat"
ExpiresByType video/x-msvideo "jetzt plus 1 Monat"
ExpiresByType video/mpeg "jetzt plus 1 Monat"
ExpiresByType video/mp4 "jetzt plus 1 Monat"
ExpiresByType video/quicktime "jetzt plus 1 Monat"
ExpiresByType video/x-la-asf "jetzt plus 1 Monat"
ExpiresByType video/x-ms-asf "jetzt plus 1 Monat"
</IfModule>

Eine berechtigte Frage ist, was passiert, wenn du Joomla und/oder Erweiterungen von Drittanbietern aktualisierest. Die statischen Dateien - JavaScript, CSS, Bilder, ... - ändern sich im Rahmen der Aktualisierung. Wir wollen nicht, dass der Browser die alte Datei verwendet. Im besten Fall sieht die Seite dann komisch aus, im schlimmsten Fall ist sie für den Besucher nicht mehr zu gebrauchen. An dieser Stelle kommt die Medienversionierung mit Abfrageparametern ins Spiel. Wenn du den Quellcode deiner Webseite ansiehst, wirst du Zeilen wie diese finden:

<link href="/media/plg_system_webauthn/css/button.min.css?f15d039055248502c1a41bc99a31c0f3" rel="stylesheet">

Dieses ?f15d039055248502c1a41bc99a31c0f3 wird als Media Versioning Query bezeichnet. Das Zeug nach dem Fragezeichen spielt keine Rolle, solange es sich jedes Mal ändert, wenn sich die statische Datei ändert. Joomla - und korrekt geschriebene Erweiterungen von Drittanbietern - tun dies automatisch für CSS- und JavaScript-Dateien. Wenn du andere statische Inhalte wie Bilder, Videos usw. in deine Artikel aufnimmst, denke daran, eine Versionsabfrage hinzuzufügen. Etwas so Einfaches wie ?20211205111300 (ein Fragezeichen gefolgt von Jahr, Monat, Tag, Stunde, Minuten und Sekunden - die Zeit, zu der diese Abfrage geschrieben worden ist) ist mehr als ausreichend.

HTTPS und HSTS

Es ist ein weit verbreiteter Irrglaube, dass HTTPS etwas mit der Sicherheit Ihrer Webseite zu tun hat, dass es teuer und langsam ist und dass du es nicht wirklich brauchst, es sei denn, du betreibst E-Commerce oder ähnliches. Ein weiterer Irrglaube ist, dass deine Webseite dadurch langsamer wird.

Diese Mythen haben ihren Ursprung in den späten 1990er Jahren. Seit über zwei Jahrzehnten sind sie offenkundig falsch.

Heutzutage ist HTTPS so gut wie obligatorisch. Wenn du kein HTTPS verwendest, erscheint auf deiner Webseite eine grosse, rote Warnung, die deine Besucher darauf hinweist, dass sie unsicher ist, was die Besucher abschreckt. Sie wird von den Suchmaschinen abgestraft. Du solltest HTTPS verwenden, und sei es nur, um diese beiden Probleme zu lösen. Du musst nicht einmal das Sparschwein aufbrechen. TLS-Zertifikate sind jetzt dank Let's Encrypt kostenlos. Die meisten Hosting-Kontrollpanels ermöglichen Let's Encrypt, d. h. du kannst dein via deinem Hosting-Kontrollpanel buchstäblich ein kostenloses TLS-Zertifikat ausstellen und installieren lassen und es auch automatisch erneuern. Der Wartungsaufwand für dich ist gleich null. HTTPS ist ausserdem superschnell, da jede moderne CPU, die in den letzten zehn Jahren auf den Markt gekommen ist, über Hardware-Beschleunigung für die verwendeten kryptografischen Operationen verfügt.

Wenn du schon dabei bist, denke auch daran, "HTTPS für die gesamte Webseite erzwingen" in deiner globalen Konfiguration einzustellen. Dies stellt sicher, dass deine Joomla-Webseite ausschliesslich über HTTPS ausgeliefert wird, was die Anmeldungen sicherer macht. Sobald du das getan hast und du dich vergewissert hast, dass HTTPS auf deiner Seite funktioniert, füge das Folgende zur htaccess hinzu:

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>

Damit wird eine Funktion namens HSTS (HTTP Strict Transport Security) aktiviert. Kurz gesagt, dein Browser wird angewiesen, niemals zu versuchen, eine Verbindung zur HTTP-Version Ihrer Webseite herzustellen, unabhängig davon, was ein Besucher ihm sagt. Da dies auf der Browserseite geschieht, wird ein Besucher, der deinen Domänennamen in die Adressleiste ohne das Präfix https:// eingibt oder auf einen Link mit dem Präfix http:// klickt, immer zur HTTPS-Version Ihrer Webseite gelangen, ohne zuerst die HTTP-Version besuchen zu müssen und von Joomla umgeleitet zu werden. Dies ist viel schneller, vor allem bei Verbindungen mit hoher Latenz, wie z.B. bei mobilem oder Satelliten-Internet.

Eine weitere Optimierung, die du vornehmen kannst, ist die Aufnahme deiner Webseite in die HSTS-Preload-Liste. Während HSTS erst nach dem ersten Besuch Ihrer Webseite funktioniert, bedeutet die Aufnahme Ihrer Webseite in die HSTS-Preload-Liste, dass der Browser bereits vor dem ersten Besuch deiner Webseite weiss, dass sie HSTS verwendet. Daher wird der Browser nie versuchen, sie über einfaches HTTP zu laden. Auch dies ist eine Zeitersparnis für Verbindungen mit hoher Latenz, einfach und kostenlos. Was gibt es daran nicht zu lieben?

HTTP/2-Server-Push

Wenn ich in der Vergangenheit darüber gesprochen habe, wie man Joomla schneller machen kann, habe ich den Leuten immer gesagt, wie man HTTP/2 Server Push aktiviert, um Webseiten schneller zu machen. Die Entwickler von Google Chrome haben jedoch bereits vorgeschlagen, die Unterstützung dafür zu entfernen und erklärt, dass es für das HTTP/3-Protokoll sowieso nicht implementiert wird. Daher ist mein derzeitiger Rat, sich nicht damit zu befassen.

Dies ist der zweite Teil einer fünfteiligen Serie. Im Teil 3 geht es um Statische Medienoptimierung Hier geht es zur Fortsetzung dieser Serie.