Gösta Thomas' Blog

Hier geht es um die Pagespeed-Optimierung für Websites, die mit dem CMS CMSimple erstellt wurden. Die Pagespeed, also die Website-Geschwindigkeit, ist bei Google™ eines der etwa 200 Ranking-Kriterien. Gemeint sind die Ladezeit vom Server bis zum Besucher-Browser und die Zeit, die der Browser benötigt, um die Seite anzuzeigen. Viele Besucher warten höchstens eine oder zwei Sekunden, bis eine Seite angezeigt wird. Dauert es länger, wechseln sie zurück zu den Google-Suchergebnissen. Durch verschiedene Maßnahmen läßt sich die Pagespeed optimieren, so daß die Seiten beim Besucher schneller angezeigt werden. Die nachfolgend dargestellten Hinweise und Tipps gelten grundsätzlich für alle Webseiten, auch für handgemachte.

Für Seiten, die mit einem CMS erstellt wurden, sind oft einige Besonderheiten zu beachten. Abschnitte dieser Anleitung, die besonders CMSimple-Nutzer betreffen, habe ich mit gelb gekennzeichneten Überschriften versehen. Ich beschreibe die Pagespeed-Optimierung anhand des meistverwendenten Server-Programms Apache. Beachten Sie bitte, daß bestimmte technische Voraussetzungen erfüllt sein müssen, aber nicht in allen Webhosting-Tarifen vorhanden sind.

• ⇓ Elemente einsparen: nur benötigte Elemente an Browser senden
• ⇓ CSS- und Javascript-Dateien jeweils zusammenfassen
• ⇓ Für Layout-Grafiken die Zahl der Server-Anfragen verringern
• ⇓ CSS- und Javascript-Dateien minifizieren
• ⇓ Seiten-Elemente komprimiert an Browser ausliefern
• ⇓ Browsercache-Verhalten steuern je nach Dateityp
• ⇓ Original-Bilder der Kamera verkleinern und komprimieren
• ⇓ Aufrufe von CSS- und Javascript-Elementen richtig anordnen
• ⇓ Test mit Browser-Entwicklerwerkzeugen und Online-Tools
• ⇓ Kopfzeile  Expires: Thu, 19 Nov 1981 08:52:00 GMT ?

Elemente einsparen: nur benötigte Elemente an Browser senden:

Versuchen Sie, überflüssige Elemente einzusparen und gar nicht erst an die Browser Ihrer Besucher zu senden, also die Zahl der Anfragen an Ihren Server zu verringern. Wenn Ihnen schnelle Seiten wichtig sind, verzichten Sie außerdem auf Google Analytics, Google Webfonts, Adsense-Anzeigen, Fratzbuch-Plugins und dergleichen.

Was CMSimple-Nutzer anbelangt:

Bei überflüssigen Elementen kann es sich um Elemente handeln, die zum Umfang von CMSimple selbst gehören, oder um Plugin- oder Template-Elemente. Wenn Sie auf all' den JQuery-Schnickschnack verzichten können, setzen Sie in den Einstellungen -> CMS -> JQuery -> Autoload den Inhalt von "1" auf leer (kein Inhalt), und Sie sparen folgende Elemente ein (eingespartes Volumen zusammen 344 KB). Natürlich sind dann Plugins und Templates von der Stange, die JQuery voraussetzen, funktional eingeschränkt.

/plugins/jquery/lib/jquery_ui/jquery-ui-1.10.1.custom.min.js
/plugins/jquery/lib/jquery_ui/css/smoothness/jqueryui.css
/plugins/jquery/lib/jquery/jquery-1.10.1.min.js

Prüfen Sie außerdem alle verwendeten Plugins, ob wirklich alle Server-Anfragen erforderlich sind. Falls Sie das Plugin RealBlog verwenden, ist zB der Kalender für Sie als Admin entbehrlich. Dann brauchen Sie das Verzeichnis /plugins/realblog/jscalendar/ samt aller Inhalte gar nicht erst hochzuladen und sparen ein Volumen von 231 KB ein. Und Ihre Besucher, die den Kalender ohnehin nicht zu Gesicht kriegen, ersparen sich das Runterladen dieser Dateien:

/plugins/realblog/jscalendar/calendar.js
/plugins/realblog/jscalendar/lang/calendar-de.js
/plugins/realblog/jscalendar/calendar-setup.js
/plugins/realblog/jscalendar/calendar-system.css

Wenn Sie zumindest PHP-Grundkenntnisse besitzen, löschen Sie aus der Datei /plugins/realblog/index.php alles, was den Kalender (Date Picker settings) betrifft. Vorsichtige können den entsprechenden Code zunächst auf Kommentar setzen und erst nach Test endgültig entfernen.

Wenn Sie eine vorgefertigte Seiten-Vorlage (CMSimple-Bezeichnung: Template) verwenden, achten Sie darauf, daß sie möglichst ohne externe Elemente wie zB Google Webfonts auskommt, die von Ihren Besuchern zusätzlich heruntergeladen werden müßten und dadurch Ihre Seiten langsamer macht. Verwenden Sie nur die üblichen Schriften, die auf den Systemen Ihrer Besucher schon vorhanden sind wie zB die Schriftenfamilie Verdana, Geneva, Arial, Helvetica, sans-serif.

CSS- und Javascript-Dateien jeweils zusammenfassen:

Versuchen Sie, möglichst mehrere CSS- und Javascript-Dateien jeweils zusammenzufassen, um die Zahl der Server-Anfragen zu verringern.

CMSimple-Besonderheiten:

Standardmäßig muß der Besucher einer CMSimple-Website mehrere CSS-Dateien runterladen:

/css/core.css
/templates/(template-name)/stylesheet.css
/plugins/jquery/lib/jquery_ui/css/smoothness/jqueryui.css

Hinzu kommen die CSS-Dateien für die verwendeten Zusatz-Plugins. In meinem Fall (verwendete Plugins: RealBlog und Comments) waren dies:

/plugins/comments/css/stylesheet.css
/plugins/realblog/css/stylesheet.css
/plugins/realblog/jscalendar/calendar-system.css

Das waren insgesamt sechs Server-Anfragen nur für CSS-Dateien. Die beiden Stylesheet-Dateien jqueryui.css und calendar-system.css hatte ich schon zuvor entsorgt, wie im vorigen Abschnitt beschrieben. Da waren es noch vier CSS-Dateien: immer noch zu viele: Um die Zahl der Server-Anfragen weiter zu verringern, habe ich dann diese drei Stylesheet-Dateien in einer einzigen zusammengefaßt:

/templates/(template-name)/stylesheet.css
/plugins/comments/css/stylesheet.css
/plugins/realblog/css/stylesheet.css

Genauer gesagt: ich habe die CSS-Regeln aus den beiden Plugin-Stylesheet-Dateien kopiert und am Ende meiner Template-Stylesheet-Datei eingefügt, so daß die beiden Plugin-Stylesheet-Dateien überflüssig wurden. Damit habe ich für meine Besucher weitere zwei Server-Anfragen eingespart, insgesamt gibt es für meine CMSimple-Website nur noch diese zwei CSS-Dateien (das erinnert mich an das schöne deutsche Volkslied über die Zehn kleinen Negerlein):

/css/core.css
/templates/(template-name)/stylesheet.css

Bei dieser Gelegenheit habe ich aus beiden verbliebenen CSS-Dateien (core.css und stylesheet.css) auch alle überflüssigen Kommentare, Leerzeilen und Leerzeichen entfernt, um Platz einzusparen. Beim Testen mit den Browser-Entwicklerwerkzeugen werden die CSS-Regeln schließlich trotzdem schön übersichtlich angezeigt.

Da ich inzwischen (Juni 2018) die Blog-Kommentare deaktiviert habe (nur acht echte Kommentare in drei Jahren, aber viel zeitraubender Spam), brauche ich das Plugin Comments nicht mehr und habe deswegen die CSS-Regeln für Comments wieder aus der Stylesheet-Datei meines Templates entfernt.

Für Javascript-Dateien (hier aus Platzgründen nicht näher erläutert) gilt entsprechendes wie für CSS-Dateien.

Für Layout-Grafiken die Zahl der Server-Anfragen verringern:

Zum Webseiten-Layout gehören meist Flaggen, Symbole, Pfeile, Farbverläufe und sonstiger Zierrat. Oft erfolgt für jede dieser Grafik-Dateien eine eigene Server-Anfrage. Zu viele Server-Anfragen erhöhen aber die Ladezeit und verlangsamen den Aufbau der Seite im Browser Ihrer Besucher. Für Layout-Grafiken gibt es zwei Verfahren, die Anzahl der Server-Anfragen zu verringern und damit Ihre Seiten schneller zu machen:

• Mehrere Grafiken in einer Sprite-Datei zusammenfassen und über CSS-Regeln getrennt in Webseiten einbetten. Siehe meinen Blogartikel CSS-Sprites erstellen: Info, Anleitung, Tipps
• Grafiken base64-verschlüsselt in den HTML- oder CSS-Quelltext einbinden. Siehe meinen Blogartikel Base64-kodierte Bilder als CSS-Regel einbetten

Für CMSimple-Nutzer gilt:

Wenn Sie ein vorgefertigtes Template von der Stange nutzen, prüfen Sie, ob dort mehrere einzelne Layout-Grafiken verwendet werden, die vielleicht in einer CSS-Sprite-Datei zusammengefaßt oder per base64-Technik eingebunden werden könnten.

CSS- und Javascript-Dateien minifizieren:

Der nächste Schritt ist die Minifizierung (zumindest) von CSS- und Javascript-Dateien. Mit diesem Begriff ist gemeint, alle überflüssigen Kommentare, Zeilenumbrüche, Leerzeilen und Leerzeichen zu entfernen, weil schon damit viel Platz und somit Download-Volumen eingespart wird. Minifizierte CSS- und Javascript-Dateien sind Voraussetzung für die anschließende Komprimierung. Die Minifizierung läßt sich händisch oder über eine geeignete Browser-Erweiterung oder über ein Online-Programm erledigen.

Wer die Minifizierung händisch durchführt, macht sich das Leben leicht, indem er einen passenden Editor mit Syntax-Hervorhebung für CSS- und JS-Code wie zB SynWrite, Notepad++ oder PSPad verwendet (alle drei Windows-Programme sind kostenlos erhältlich). SynWrite und Notepad++ habe ich ausführlich getestet: hier geht's zum SynWrite-Test und dort zum Notepad++-Test. Aktualisierung am 14.07.2019: Für SynWrite gibt es auch zwei Erweiterungen, die auf Knopfdruck minifizieren: CSS Minifier und JS Minifier.

Geeignete Online-Werkzeuge zur Minifizierung sind für Stylesheet-Dateien zB der CSS-Compressor (auf Deutsch ) und für Javascript-Dateien der JS-Compressor (auf Englisch). Beide Werkzeuge sind ohne Speicherung von Cookies nutzbar.

Tipp für CMSimple-Nutzer:

Stylesheet-Dateien mit dem Online-Editor im Admin-Bereich zu minifizieren ist wenig vergnüglich und außerdem fehleranfällig. Bei händischer Minifizierung kopieren Sie sich am Besten alle CSS-Regeln einer Stylesheet-Datei über die Zwischenablage in einen geeigneten Editor mit Syntax-Hervorhebung, führen dort die Änderungen durch und kopieren dann den geänderten Zustand zurück in den CMSimple-eigenen Editor (Speichern und Testen nicht vergessen). Wenn Sie lieber eine Browser-Erweiterung oder ein Online-Programm nutzen wollen, gehen Sie entsprechend vor.

Seiten-Elemente komprimiert an den Browser ausliefern:

Es gibt unter dem Server-Programm Apache verschiedene alternative Methoden, um Seiten-Elemente komprimiert an die anfordernden Browser auszuliefern (Übersicht):

1. Komprimierung mit DEFLATE ...

... für dynamisch erzeugte und statische Elemente. Voraussetzung: Das Modul mod_deflate muß beim Webhoster verfügbar sein (nicht überall gegeben). Folgende Regel ist in der Datei .htaccess erforderlich:

#--- Server-Komprimierung DEFLATE für Typen: -----
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css
text/javascript application/x-javascript text/plain
# diese Regel muss in einer einzigen Zeile stehen!
# ggf. weitere Datei-Typen ergänzen!
</IfModule>

Dateitypen für Bilder (jpeg, gif, png) gehören hier nicht rein, da Bilder dieser Typen über ihr Format ohnehin komprimiert sind.

Info: Apache-Dokumentation mod_deflate auf Deutsch

CMSimple-Besonderheiten sind mir nicht bekannt. Ich kann's auch nicht testen, weil in meinem Webhosting-Tarif das Apache-Modul mod_deflate nicht verfügbar ist.

2. Komprimierung über PHP-Codeschnippsel ...

... für dynamisch erzeugte und statische HTML-/PHP-Seiten. Voraussetzungen: PHP-ZLib Support ist enabled (ist meistens gegeben, siehe <?php phpinfo(); ?>). Bei manchen Webhostern ist das die einzige Möglichkeit zur Komprimierung auf dem Server. Auch reine HTML-Seiten müssen PHP-geparst werden können (das ist bei den meisten Webhostern über die Datei .htaccess einstellbar).

Bei selbsterstellten Seiten (also ohne ein CMS zu verwenden) wird ganz am Anfang jeder HTML-/PHP-Seite vor dem HTML-Code dieses kleine PHP-Codeschnippsel eingefügt:
<?php ob_start("ob_gzhandler"); ?>

Für CMSimple-Nutzer: Da alle am Server generierten Seiten über ein und dieselbe Datei /index.php ausgeliefert werden, reicht es aus, den PHP-Codeschnippsel ein einziges mal einzubauen: in der Datei /index.php zu Beginn in der 1. Zeile:
<?php ob_start("ob_gzhandler"); ?>

3. Vorab-Komprimierung mit GZIP ...

... (nur) für statische (CSS- und Javascript-) Dateien: Auf dem Server werden zwei Versionen parallel bereit gehalten: eine komprimierte Version im gz-Format und eine unkomprimierte Version. Das ist die schnellste Methode, weil die Komprimierung dann nicht bei jeder Serveranfrage erneut durchgeführt werden muß und die dafür benötigte Rechenzeit eingespart wird. Voraussetzungen: a) Ein GZIP-fähiges Programm auf dem heimischen Rechner (zB 7-Zip, kostenlos). b) Die Module mod_headers und mod_rewrite müssen beim Webhoster verfügbar sein (inzwischen fast überall gegeben). Wichtig bei zwei bereit gehaltenen Versionen ist auch die HTTP-header-Ausgabe Vary: Accept-Encoding (siehe hier). Folgende Regeln sind in der Datei .htaccess erforderlich:

#--- Vorab-Komprimierung GZIP für css|js: --------
<IfModule mod_headers.c>
<FilesMatch ".css.gz$">
  ForceType text/css
  Header set Content-Encoding: gzip
  Header append Vary Accept-Encoding
</FilesMatch>
<FilesMatch ".js.gz$">
  ForceType text/javascript
  Header set Content-Encoding: gzip
  Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_URI} .(css|js)$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ /$1.gz [L]

Server und Client regeln dann unter sich, welche Version (die komprimierte im gz-Format oder die unkomprimierte) an den Client (Browser) gesendet wird. Der Vollständigkeit halber: An der Referenzierung von CSS- und JS-Dateien in den HTML-Kopfdaten muß nichts geändert werden, oder, anders ausgedrückt: die komprimierten gz-Versionen werden dort nicht erwähnt.

Für CMSimple-Nutzer gilt:

Von allen CSS-Dateien wird lokal zusätzlich mit 7-Zip eine komprimierte Version erzeugt und im gleichen Verzeichnis abgelegt wie die unkomprimierte Version. Wer, wie oben beschrieben, seine CSS-Dateien auf zwei verringert hat, für den sieht's dann so aus:

/css/core.css
/css/core.css.gz
/templates/(template-name)/stylesheet.css
/templates/(template-name)/stylesheet.css.gz

Anschließend werden diese vier Dateien und die ergänzte .htaccess-Datei mit einem FTP-Programm auf den Server hochgeladen.

Einziger Nachteil für CMSimple-Nutzer ist dann der, daß die CSS-Dateien nicht mehr (wie vielleicht gewohnt) online im Admin-Bereich geändert werden können (denn nach einer solchen Änderung hätte die unkomprimierte Version einen anderen Inhalt als die komprimierte Version). Aber mal ehrlich: wie oft ändert man eine vorhandene CSS-Datei? Das kommt doch nur recht selten vor. Wenn es vorkommt, ändert man zuerst lokal auf dem heimischen Rechner die unkomprimierte Version, erzeugt zusätzlich die komprimierte Version und lädt beide zusammen auf den Server hoch. Außerdem ist es viel übersichtlicher und deshalb angenehmer, CSS-Regeln in einem dafür geeigneten Editor wie zB SynWrite oder Notepad++ (beide im vorigen Abschnitt schon erwähnt) zu ändern oder zu ergänzen als mit dem CMSimple-Online-Editor.

Für Javascript-Dateien (hier aus Platzgründen nicht näher erläutert) gilt entsprechendes wie für CSS-Dateien.

4. Server-Komprimierung mit GZIP ...

... für dynamisch erzeugte und statische Elemente. Voraussetzung: Das Modul mod_gzip müßte beim Webhoster verfügbar sein, das ist aber nur höchst selten gegeben, denn mod_gzip ist ein extern entwickeltes Modul für die Apache-Version 1.3. In neueren Apache-Versionen (aktuell ist die Versionsreihe 2.*) ist mod_gzip nicht lauffähig, stattdessen wird hier das Standard-Modul mod_deflate verwendet. Für das Modul mod_gzip, sofern verfügbar, wären in der Datei .htaccess folgende Regeln erforderlich:

#--- Server-Komprimierung GZIP für Endungen: -----
<IfModule mod_gzip.c>
mod_gzip_on yes
mod_gzip_static_suffix .gz
mod_gzip_can_negotiate yes
AddEncoding gzip .gz
mod_gzip_item_include file .(html|htm|php)$
# ggf. weitere Datei-Endungen ergänzen!
mod_gzip_item_exclude mime ^image/.*
mod_gzip_dechunk yes
</IfModule>

Info: Dokumentation mod_gzip auf Deutsch

CMSimple-Besonderheiten sind mir nicht bekannt. Ich kann's auch nicht testen, weil in meinem Webhosting-Tarif das externe Apache-Modul mod_gzip nicht verfügbar ist.

Bild 1: Developer Tools in Chromium-gestützten Browsern:

Browsercache-Verhalten steuern je nach Dateityp:

Mit der Steuerung des Browsercache-Verhaltens (auf Englisch Leverage Browser Caching) wird festgelegt, wie lange ein Element aus dem Browsercache des Besuchers geholt wird, ohne erneut vom Server runtergeladen zu werden. Eine Seite, deren Elemente überwiegend aus dem Browsercache des Besuchers geholt werden, wird bei wiederholten Besuchen natürlich erheblich schneller angezeigt.

Unter dem Server-Programm Apache gibt es zwei alternative Methoden, um den Browser-Cache zu steuern und damit ein Verfallsdatum festzulegen: entweder mit Regeln, die das Modul mod_expires verwenden, oder mit Regeln, die das Modul mod_headers nutzen (hier nicht beschrieben). In diesem Blog-Artikel beschreibe ich aus Platzgründen nur die Regeln mit mod_expires. Für PHP-Seiten und HTML-Seiten (sofern PHP-geparst) läßt sich das Browsercache-Verhalten auch über ein paar Zeilen PHP-Code am Anfang jeder Seite steuern (diese Methode wird für CMSimple benötigt, siehe unten).

Mit dem Modul mod_expires wird das Cache-Verhalten in der Datei .htaccess für jeden Dateityp (Mime type) in einer ExpiresByType-Regel festgelegt. Eine ExpiresByType-Regel enthält den Dateityp, für den sie gilt, sowie in Hochkommata die Zeitangabe ab einem bestimmten Zeitpunkt. Als Zeitpunkt kann man entweder mit dem Schlüsselwörtern modification plus das letzte Änderungsdatum auf dem Server oder mit den Schlüsselwörtern access plus den ersten Zugriff eines Besuchers angeben. Meist wird die besucher-individuelle access plus - Methode verwendet. Die server-orientierte modification plus - Angabe kommt für Elemente in Frage, die sich nur ganz selten ändern, zB CSS-Dateien. Hinter dem plus gibt man dann eine Zahl in arabischen Ziffern und eine Zeiteinheit auf Englisch (nicht auf Arabisch ;-)) an. Gebräuchlich sind seconds, minutes, hours, days, weeks, months, years in Einzahl oder Mehrzahl. Man kann auch mehrere Zeiteinheiten kombinieren. Beispiele (zuerst die Standard-Regel für "vergessene" Dateitypen):

ExpiresDefault "access plus 2 days"
ExpiresByType text/html "access plus 6 hours"
ExpiresByType text/css "modification plus 10 years"
ExpiresByType image/png "access plus 1 year 1 second"

Bitte beachten Sie: Bei der Zeitangabe modification plus (irgendwas) gilt als Änderungsdatum auch das erneute Hochladen einer Datei, die gar nicht geändert wurde. Dadurch würde die 10-Jahres-Frist wie im Beispiel neu beginnen. Zur Zeitangabe access plus (irgendwas): Wenn man ein neues Bild anstelle des alten Bildes anzeigen will, sollte man mitnichten die Zeitangabe access plus 1 year verringern (das beträfe dann ja alle Bilder und nicht nur dieses spezielle eine), sondern dieses eine Bild umbenennen (Beispiel: vorher: bild.jpg, nachher: bild-v2.jpg). Alternativ kann man für das geänderte Bild den Bildnamen beibehalten, jedoch bei der Einbindung einen Parameter anhängen (Beispiel: vorher: href="/favicon.ico", nachher: href="/favicon.ico?v=2").

Eine Alternative zur modification plus - Angabe wäre die ETag-Lösung (hier nicht beschrieben).

Ein (ziemlich vollständiger) Regelsatz in der Datei .htaccess könnte so aussehen:

#--- Cache-Verhalten festlegen je Typ: -----------
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 2 days"
ExpiresByType text/html "access plus 6 days"
# ExpiresByType text/html ... funkt nicht im CMSimple-Betrieb!
ExpiresByType text/css "modification plus 10 years"
ExpiresByType text/x-component "access plus 1 year"
ExpiresByType text/javascript "access plus 8 days"
ExpiresByType application/javascript "access plus 8 days"
ExpiresByType application/x-javascript "access plus 6 hours"
ExpiresByType application/json "access plus 1 year"
ExpiresByType application/xml "access plus 6 hours"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
# ggf. weitere ergänzen, überflüssige löschen
</IfModule>
<IfModule mod_headers.c>
Header unset ETag
Header unset Pragma
Header set Cache-Control "private, must-revalidate"
</IfModule>

Infos: Apache-Dokumentation mod_expires auf Deutsch , Erläuterung zur Angabe modification plus auf Englisch, PHP-Dokumentation Browsercache-Verhalten steuern auf Deutsch

Besonderheit für CMSimple-Nutzer:

Eine für den Dateityp HTML (Mime Type text/html) in der Datei .htaccess festgelegte ExpiresByType-Regel funktioniert nicht: eine Steuerung des Browsercache-Verhaltens für die eigentlichen CMS-Seiten ist damit also nicht möglich. Als Ersatz bietet sich für CMSimple-Nutzer die PHP-Code-Lösung an. Die Frage ist nur: in welche Datei kommt der entsprechende PHP-Code rein: Vielleicht in die /index.php ? Oder in die /cmsimple/cms.php ? Weder noch! Die PHP-Codezeilen zur Browsercache-Steuerung für den Dateityp HTML (Mime Type text/html) müssen in die Datei /templates/(template-name)/template.htm eingefügt werden, und zwar ganz am Ende. Da wäre ich selbst nie drauf gekommen, aber im CMSimple_XH-Forum gab's eine ausführliche Diskussion über Ladezeiten-Optimierung einschließlich der Lösung von cmb (die funktioniert leicht abgewandelt auch unter CMSimple 4.x).

Ich verwende die Lösung aus dem CMSimple_XH-Forum (etwas abgespeckt) am Ende meiner Datei template.htm für CMSimple 4.x :

</body>
</html>
<?php // Browser-Caching steuern für HTML-Seiten:
if (!$adm) {
$expire = 144 * 60 * 60; // alle Seiten: 6 Tage
$expires = gmdate('D, d M Y H:i:s', time() + $expire) . ' GMT';
header('Expires: ' . $expires);
}
?>

Das war's auch schon: funktioniert bestens :-) Und die restlichen Caching-Regeln in meiner .htaccess-Datei sind die gleichen wie oben angegeben (natürlich ohne die für CMSimple-Seiten unwirksame Regel ExpiresByType text/html "access plus 6 days").

Der Vollständigkeit halber sei hier noch erwähnt, daß es für das verwandte CMSimple_XH das Plugin CnC: Cache&Compress für CMSimple_XH gibt: JS- und CSS-Dateien werden minifiziert und komprimiert und in einem serverseitigen Cache zwischengespeichert. CMSimple_XH-Seiten werden auf dem Server GZip-komprimiert und nach ETag-Prüfung entweder vom Server runtergeladen oder aus dem Browser-Cache angezeigt. Ein echter Wolpertinger!

Ich weiß nicht, ob das Plugin CnC_XH auch unter CMSimple 4.x lauffähig ist. Wer die Unterschiede beider CMS genau kennt und zudem ausreichend gute (!) PHP-Kenntnisse hat, sollte die nötigen Änderungen selbst durchführen können. Der Aufwand für eine solche Plugin-Anpassung ist aber vermutlich größer als der für eine handgemachte Lösung.

Original-Bilder der Kamera verkleinern und komprimieren:

Original-Bilder sind bei hohen Auflösungen mehrere Megabyte groß (zB bei der Auflösung 4000 x 3000 px fünf oder mehr MB). Zur Anzeige auf Webseiten werden sie dann oft per CSS-Regel (oder früher: über HTML-Attribute) verkleinert dargestellt. Wenn Sie solche Monster-Bilder in Kunstdruck-Qualität auf Ihren Webseiten einbinden, werden das Download-Volumen unnötig vergrößert und die Ladezeit bis zur Anzeige der Webseite beim Besucher erheblich erhöht. Also: Keine hochauflösenden Bilder per CSS oder HTML "runterskalieren"! Denn fast alle Besucher erwarten, daß eine Seite spätestens nach ein oder zwei Sekunden vollständig auf dem Bildschirm angezeigt wird.

Sorgen Sie für eine geringere Dateigröße der Bilder auf Ihrem Server: Angenommen, die Originalbilder Ihrer Kamera haben eine Bildauflösung von 2560 x 1920, 3264 x 2448 oder 4000 x 3000 Pixeln, werden auf Ihrer Webseiten aber höchstens in der Abmessung 640 x 480 px angezeigt, dann verringern Sie vor dem Hochladen die Bildauflösung am heimischen Rechner auf 640 x 480 px. Bei dieser Gelegenheit können Sie auch gleich die EXIF-Daten entfernen (Datenschutz beginnt mit eigener Wachsamkeit). Löschkandidat ist auch eine eventuell eingebettete zusätzliche Miniaturansicht. Das JPG-Format sorgt zwar schon standardmäßig für komprimierte Bildspeicherung. Sie können die Kompression aber zusätzlich erhöhen (und damit den Speicherbedarf weiter verringern), indem Sie die Bildqualität absenken, zB auf 60% bis 80%.

Nach diesen Verarbeitungsschritten ist ein Bild dann nicht mehr 4 oder 5 Megabyte groß, sondern vielleicht nur noch 60 oder 70 Kilobyte, und zwar ohne merkliche Qualitätseinbußen am Bildschirm. Hierfür eignen sich einfache Bildbearbeitungsprogramme wie zB XnView (für Windows, privat kostenlos nutzbar, Sprache wählbar: auch Deutsch ). Die erweiterte Version XnView MP ist für die Systeme Windows, Mac OS und Linux verfügbar und kann für private Zwecke ebenfalls kostenlos genutzt werden. XnView und XnView MP unterstützen auch die Bildbearbeitung für mehrere Bilder im Stapelbetrieb.

Wenn Sie eine Bildergalerie mit kleinformatigen Vorschaubildern (zB in der Auflösung 160 * 120 px) anzeigen, verwenden Sie am Besten für jedes Bild zwei Bilddateien: die eine in der Auflösung 160 * 120 px für die Bildergalerie, die zweite in der Auflösung zB 640 * 480 px für die Großbild-Ansicht. Dann müssen vom Besucher nicht schon zur Anzeige in der Bildergalerie alle Bilder in höherer (nicht benötigter) Auflösung runtergeladen werden.

Aufrufe von CSS- und Javascript-Elementen richtig anordnen:

Auch die Reihenfolge, in der CSS- und Javascript-Dateien vom Server angefordert werden, entscheidet darüber, wie schnell eine Seite vom Browser bei leerem Cache angezeigt werden kann. Also: zuerst die Stylesheet-Datei laden und danach Javascripte!

Manchmal wird empfohlen, CSS-Regeln auf zwei externe CSS-Dateien aufzuteilen: demnach kommen in die erste nur diejenigen CSS-Regeln rein, die erforderlich sind, um eine Seite above the fold (also oben im sichtbaren Bereich) sofort richtig darzustellen, in die zweite alle restlichen Regeln. Davon halte ich gar nichts, solange eine einzige Stylesheet-Datei komprimiert kleiner als 10 KB ist. Und wo, bittesehr, ist angesichts von Dutzenden verschiedener Bildschirmgrößen der fold? Der ist doch auf jedem Gerät woanders.

Nicht selten liest man auch den Rat, above the fold-CSS-Regeln innerhalb des HTML-Codes der Seite zu platzieren. Früher war sowas streng verpönt, und nicht selten meckern genau darüber auch heute die gleichen Tools, die es zuvor empfohlen hatten.

Was allerdings sinnvoll sein kann: CSS-Regeln für HTML-Elemente, die nur auf einzelnen Seiten vorkommen, zB Formulare, in eine gesonderte Stylesheet-Datei auszulagern.

Wenn Laden und Ausführen eines Scriptes den Seitenaufbau verlangsamen, läßt sich die Script-Verarbeitung mit dem Schlüsselwort-Attribut defer im Script-Aufruf verzögern, bis die Seite vom Browser aufgebaut ist:
<script src="script_xyz.js" defer></script>

Info: SelfHTML-Dokumentation Script-Attribut defer auf Deutsch

Bild 2: GTmetrics Performance Report:

Test mit Browser-Entwicklerwerkzeugen und Online-Tools:

Das beste Test-Werkzeug, um die Website-Geschwindigkeit (Zahl der Server-Anfragen, Speichervolumen aller Elemente, Ladezeit der gesamten Seite, Komprimierung und Browsercache-Verhalten einzelner Elemente ...) zu prüfen, sind die Browser-eigenen Entwicklerwerkzeuge, Reiter Netzwerk. Die Entwicklerwerkzeuge sind meist zu erreichen über die Tasten F12 oder Strg+Umschalt+I (I wie Inspect). Umfangreiche Informationen, schön aufbereitet, bieten die Entwicklerwerkzeuge in den Chromium-gestützten Browsern Chrome, Opera 15+ (siehe Bild 1), Vivaldi, Yandex (und bald vielleicht auch Microsoft Edge;-)). Über den Reiter Audits gibt es zusätzliche Optimierungs-Hinweise, um das Ranking zu verbessern. Wer dem Google-Browser Chrome aus Datenschutzgründen mißtraut, kann ja Opera oder Vivaldi verwenden. Auch die Firefox-Entwicklerwerkzeuge lassen sich gut nutzen.

Und dann gibt es noch verschiedene Online-Tools, mit denen man die Website-Geschwindigkeit testen kann. Die haben zwar keine anderen Informationen zur Verfügung als der heimische Browser, zeigen diese Infos aber optisch anders aufbereitet an und liefern zusätzlich konkrete Hinweise zur Verbesserung. Manche Online-Tools wie GTmetrics oder Google Pagespeed Insights (PSI) bewerten eine Webseite nach bestimmten Kriterien und vergeben dafür Punkte. Bei der Nutzung solcher Punkte-Tools sollte man aber nicht vergessen: eine Seite mit 60 von 100 möglichen Punkten, die nur 10 Elemente mit einer Datenmenge von 100 KB benötigt, ist immer schneller als eine Seite mit zwar 100 Punkten, die aber 50 Elemente mit einem Speicher-Volumen von 3 MB umfaßt. Also schielen Sie nicht nur auf die erreichte Punktezahl!

Der Vorteil von GTmetrics ist, daß oben rechts die benötigte Ladezeit (Fully Loaded Time, Zugriff allerdings aus Vancouver, Kanada), die Summe des Download-Volumens (Total Page Size) und die Zahl der Serveranfragen (Requests) angezeigt werden, darunter erst die bewerteten Kriterien nach Punkten, getrennt nach Google PageSpeed Score und Yahoo YSlow Score (siehe Bild 2). Der YSlow-Tipp Use a Content Delivery Network (CDN), der bei Nichtbeachtung Punkte kostet, ist ein veralteter Tipp aus Zeiten, als Browser gleichzeitig nur zwei Elemente von der gleichen Domain runterladen konnten. Längst vorbei! Und wer ein CDN aus fremden Domains nutzt (zB Webfonts vom Google-Server einbindet), sollte wissen, daß er damit seine Webseiten verwanzt und laut DSGVO in seiner Datenschutzerklärung zumindest darauf aufmerksam machen muß.

Google Pagespeed Insights (PSI) ist seit Jahren eine Dauer-Baustelle, auf der sich ständig etwas ändert, so daß vergleichende Prüfungen einer Seite über längere Zeit kaum möglich sind. Derzeit in PSI aktuell sind Prüfergebnisse nach Lighthouse-Muster. Ich selbst fand die alte Version besser, auch weil die Tipps zur Optimierung übersichtlicher und verständlicher waren als derzeit.

Bild 3: Test mit Google PageSpeed Insights:

Kopfzeile Expires: Thu, 19 Nov 1981 08:52:00 GMT in Server-Antwort?

Gelegentlich sieht man in der HTTP-Response (Server-Antwort) einer Seite den header (die Kopfzeile) Cache-Control: private, must-revalidate (soll gecachet werden) und zugleich den header Expires: Thu, 19 Nov 1981 08:52:00 GMT. Damit wird die Seite vom Browser aber nicht gecachet, weil ihr Verfallsdatum 37 Jahre zurückliegt. So ein seltsames Datum trägt niemand von Hand ein, das ist vielmehr ein Fehler des verwendeten CMS oder eines seiner Plugins (siehe Funktion session_cache_limiter() im PHP-Handbuch). Mit ungenügenden PHP-Kenntnissen sucht man sich dumm und dusselig, also lieber gleich im Forum des verwendeten CMS nachfragen.

Kurzlink dieses Blogartikels zum Teilen: https://tinyurl.com/PageSpeed-Optim

veröffentlicht in kat_Webdesign, kat_CMSimple