PageSpeed 100/100. TYPO3 schneller machen, richtig viel schneller!

Diese Empfehlung dürften vermutlich viele beim ersten Test der Seite erhalten. Hier geht es einfach darum, anstelle von JPG oder PNG zum Beispiel das Format WebP, welches sich deutlich besser komprimieren lässt als andere Formate, und dabei die Bildqualität gut bleibt, zu verwenden Es gibt für TYPO3 eine sehr gute Extension die es erlaubt, alle vorhandenen Bilder weiterzunutzen. Technisch gesehen werden die bereits vorhandenen Bilder erneut ins WebP Format konvertiert.

Vorab sollte geprüft werden, ob die vorhandene ImageMagick oder GraphicsMagick Version auf dem Server Bilder zu WebP konvertieren kann. Das geht relativ leicht:

# Für GraphicsMagick
gm version | grep WebP

# Für ImageMagick
convert version | grep webp

Es sollte "Ja" oder eine Liste von Formaten ausgegeben werden, in denen WebP enthalten ist. Sofern diese Voraussetzung gegeben ist, lässt sich die Erweiterung mittels

composer require "plan2net/webp"

installieren.

Im Anschluss werden über das Install-Tool die "Processed Files" gelöscht. In der .htaccess wird dann im Rewrite Bereiche folgendes hinzugefügt:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_ACCEPT} image/webp
    RewriteCond %{DOCUMENT_ROOT}/$1.$3.webp -f
    RewriteRule ^((fileadmin)/.+)\.(png|jpg|jpeg)$ $1.$3.webp [L]
</IfModule>

<IfModule mod_headers.c>
    Header append Vary Accept env=REDIRECT_accept
</IfModule>

AddType image/webp .webp

Nachdem alle Caches geleert wurden sollten im Frontend die Bilder bereits als WebP ausgeliefert werden. Prüfen lässt sich das relativ einfach mit der Entwickler Konsole des Browsers:

Diese Empfehlung dürfte vermutlich die einfachste sein, sofern das JavaScript sauber ist und durch die Komprimierung keine Fehler auftreten. Je nach Projekt gibt es mehrere Möglichkeiten, das JavaScript zu komprimieren. Ich zeige hier zwei Möglichkeiten. Zusätzlich zum Komprimieren von JavaScript sollte auch gleich in Erwägung gezogen werden, alle Dateien zu einer einzigen Datei zusammenzuführen. Das kann dann je nach Projekt schon schwierig werden. Grundsätzlich ist das Einbinden einer einzigen Datei am Dokumentende die beste Strategie, aber oft auch die schwierigste. Von daher ist es ratsam, das Projekt schon von Beginn an so aufzubauen, damit man mit einer einzigen JavaScript Datei am Ende des Dokuments klarkommt. 

Komprimieren mit TYPO3

Dieser Schritt entfällt, da ich das JavaScript des Projektes Inline aus einem FE-Build nutze.  Wer keinen FE Build nutzt, verfährt wie folgt. Der folgende Code kann in das setup.typoscript des Projekts hinterlegt werden:

config {
  concatenateJs = 1
  compressJs = 1
}

Kann man einzelne Dateien nicht komprimieren oder zusammenführen lassen, gibt es auch eine Anweisung zum Deaktivieren der Datei:

page {
  includeJSFooterlibs {
    jsfile1 = EXT:template/Resources/Public/JS/file1.js
    jsFile2.excludeFromConcatenation = 1
  }
}

Tipp: Wenn man am Projekt arbeitet, ist es natürlich sinnvoll, die Komprimierung und Zusammenführung zu vermeiden, wenn man im TYPO3 Backend eingeloggt ist. Zusätzlich wäre also folgender Code-Block erforderlich:

[backend.user.isLoggedIn]
    config {
      concatenateJs = 0
      compressJs = 0
    }
[end]

Zusätzlich dazu kann in der LocalConfiguration.php Compression Level eingestellt werden. Hierzu benötigt man den folgenden Eintrag:

$GLOBALS['TYPO3_CONF_VARS']['FE']['compressionLevel'] = 9

Anschließend wird in der .htaccess die gzip-Komprimierung aktiviert:

<FilesMatch "\.js\.gzip$">
	AddType "text/javascript" .gzip
</FilesMatch>
<FilesMatch "\.css\.gzip$">
	AddType "text/css" .gzip
</FilesMatch>
AddEncoding gzip .gzip

Komprimieren mit einem FE Build

Ich nutze für das Zusammenführen und komprimieren einen FE-Build. Das sei jedem empfohlen, da man hier genau steuern kann, welche JS Dateien eingebunden werden sollen, und auch an welcher Position das stattfinden soll. Zudem kann man Map-Dateien erstellen lassen, um in der Entwickler-Konsole des Browsers sehen zu können, welcher Code aus dem JS zum Beispiel einen Fehler verursacht. In meinem FE-Build schaut das dann in etwa so aus:

var paths = {
    scriptsFooter: [
        './src/JavaScript/bootstrap-native-custom.js',
        './node_modules/simplelightbox/dist/simple-lightbox.js',
        './node_modules/lazysizes/plugins/unveilhooks/ls.unveilhooks.js',
        './src/JavaScript/cookie-consent.js',
        './src/JavaScript/prism.js',
        './src/JavaScript/lazysizes.js',
        './src/JavaScript/scripts.js',
    ],
    styles: [
        './src/Scss/style.scss'
    ],
    css: [
        './node_modules/drift-zoom/dist/drift-basic.css',
        '../../web/typo3conf/ext/ext/powermail/Resources/Public/Css/Basic.css',
        '../../web/typo3conf/ext/mindshape_cookie_hint/Resources/Public/Css/dark-top.css',
        './src/fonts/icons/css/animation.css',
        './src/fonts/icons/css/fa.css',
        './src/CSS/cookie_consent.css'
    ],
    rteStyles: [
        './src/Scss/rte.scss',
        './src/Scss/rte-colors.scss'

    ],
    destJS: '../../packages/basetemplate/Resources/Public/JavaScript/',
    destCSS: '../../packages/basetemplate/Resources/Public/css/'
};

gulp.task('scripts', function () {
    return gulp.src(paths.scriptsFooter, { allowEmpty: true })
        .pipe(concat('footer.js'))
        .pipe(gulp.dest(paths.destJS))
        .pipe(minify())
        .pipe(gulp.dest(paths.destJS));
});

Verwendet werden die Module gulp-concat und gulp-minify. Wie oben zu sehen ist, werden an dieser Stelle alle JS Dateien gezogen, die beim Projekt benötigt werden. An dieser Stelle werden übrigens auch alle JS Dateien aus den Extensions angegeben, sofern vorhanden.

Wenn das JavaScript dann mit dem FE-Build gebaut wurde, wird es via TypoScript in die Seite geladen, und zwar im Fußbereich der Seite:

page {
    includeJSFooter >
    includeJSFooterlibs >
    includeJS >
    includeJSLibs >

    includeJSFooterlibs {
        footer = EXT:basetemplate/Resources/Public/JavaScript/footer-min.js
        analytics = EXT:basetemplate/Resources/Public/JavaScript/analytics.js
        analytics.defer = 1
    }
}

Wie zu sehen ist, setze ich alle anderen Möglichkeiten zum Einbinden von JavaScript zurück. Ab diesem Schritt muss dann auch klar sein, dass nur noch das hier angegebene JavaScript geladen wird. Mit dem Beispiel von weiter oben lässt sich auch hier eine Condition erstellen, damit bei eingeloggtem Backend Benutzer nicht die minimierte Version des JavaScript geladen wird. Im Prinzip entfällt bei mir auch dieser Schritt, da ich das JavaScript später Inline nutzen werden. 

Im Wesentlichen entfällt auch dieser Schritt bei mir, da ich das CSS später Inline einbinden werde. Ansonsten gilt: Beim CSS kann man sich eigentlich ganz gut am JavaScript von oben orientieren. Der Task für den FE-Build schaut entsprechend wie folgt aus:

gulp.task('styles', function () {
    var scssStream = gulp.src(paths.styles, { allowEmpty: true })
        .pipe(sass({
            outputStyle: 'nested'
        }).on('error', sass.logError));

    var cssStream = gulp.src(paths.css, { allowEmpty: true });

    return merge(cssStream, scssStream)
        .pipe(sourcemaps.init())
        .pipe(concat('style.css'))
        .pipe(sourcemaps.write('./'))
        .pipe(gulp.dest(paths.destCSS))
        .pipe(rename({ suffix: '.min' }))
        .pipe(cleanCSS({compatibility: 'ie8'}))
        .pipe(gulp.dest(paths.destCSS));
});

Ich nutze hierfür gulp-sourcemaps, gulp-sass, gulp-rename, gulp-clean-css sowie merge-stream. Letzters wird benötigt, wenn nicht nur SCSS, sondern auch CSS im Build verwendet wird. Die Einbindung in das TYPO3 läuft dann wieder wie folgt:

page {
    includeCSS >
    includeCSS {
        screen = EXT:basetemplate/Resources/Public/css/style.css
        screen.media = screen
    }
}

Somit ist sichergestellt, dass nur CSS Dateien eingebunden werden, die wir tatsächlich einbinden wollen.

Hier kann es schon das erste Mal kritisch werden. Die Meldung "Darauf achten, dass der Text während der Webfont-Ladevorgänge sichtbar bleibt" an sich ist relativ einfach wegzubekommen. Allerdings wird dieser Posten später erneut aufschlagen, wenn die Fonts nicht grundlegend optimiert werden. Wie auf dem Bild zu sehen, werden einige Schriften verwendet. Das größte Problem bei diesem Projekt waren zum einen die Font (zusätzliche andere Fonts auf Unterseiten), sowie die FontAwesome Fonts. Hier wurden die zusätzlichen Fonts "Solid" und "Brands" genutzt. Diese Fonts sind letztlich dafür verantwortlich, dass auch das CSS relativ schnell groß wird. Und dieses Thema ist später sehr wichtig. Es wird nämlich ein möglichst kleines CSS benötigt.

• fontawesome.css > 72Kb
• brands.css > 1Kb
• solid.css > 1Kb
• fa-solid-900.woff2 > 78Kb
• fa-brands-400.woff2 > 77Kb
• fa-regular-400.woff2 > 13Kb
• Requests: 4

Addiert man nun alle Daten zusammen, ergibt das in Summe 242Kb und einige Requests die der Browser ausführen muss.

Aber von Anfang an, primär geht es erst mal um die Empfehlung  "Darauf achten, dass der Text während der Webfont-Ladevorgänge sichtbar bleibt". Die Fonts liegen alle lokal auf dem Projektserver und werden via CSS/SCSS eingebunden. Das sieht dann in etwa wie im folgenden aus:

@font-face {
    font-family: 'fa';
    src: url('/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.eot?49596511');
    src: url('/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.eot?49596511#iefix') format('embedded-opentype'),
    url('/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.woff2?49596511') format('woff2'),
    url('/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.woff?49596511') format('woff'),
    url('/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.ttf?49596511') format('truetype'),
    url('/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.svg?49596511#fa') format('svg');
    font-weight: normal;
    font-style: normal;
    font-display: swap;
}

Wichtig hier ist die Zeile font-display: swap;, diese muss hinzugefügt werden. Danach sollte die Empfehlung erledigt sein.

Wir rufen uns nun nochmal die 242Kb von oben in Erinnerung. Ziel ist es, die Menge an Daten zu drücken und weniger Requests zu erreichen. Im Falle von FontAwesome bin ich nach der Optimierung auf folgende Werte gekommen:

• fa.css > 3Kb
• fa.woff2 > 5Kb

Macht in der Summe 8 KB und am Ende nur ein Request. Schaffen lässt sich so etwas nur durch einen Kompromiss. Alles herauswerfen, was nicht benötigt wird. In diesem Projekt beschränkt sich die Verwendung von Icons auf 17 Stück. Mit dem Tool von Fontello lässt sich ein Custom Build der Icons zusammenstellen. Einfach alle Icons anklicken und die Daten ins Projekt übernehmen. 

Für den Bereich der normalen Schriften habe ich auch einen Kompromiss gemacht. Anstelle von vielen Schriften und vielen Schriftschnitten habe ich mich auf eine Schrift und zwei Schriftschnitten beschränkt. Der Weg zum Ziel ist also die Waage zwischen Design und technischer Funktionalität zu balancieren.

Das ist doch wieder etwas einfacher und sollte erledigt werden, wenn klar ist, welche Ressourcen wie Schriften oder externe Bibliotheken verwendet werden müssen. Bei externen Ressourcen sollte man sich aber auf jeden Fall immer folgendes Fragen: "Kann ich das auch lokal hosten?". Wann immer diese Frage mit "ja" beantwortet werden kann, sollte man Schriften und andere Sachen lokal hosten. 

Bei diesem Projekt geht es konkret um die letzten Font-Dateien, die nach den Kompromissen noch übrig sind. Diese Font-Dateien werden klassisch im CSS geladen. Nun sorgen wir dafür, dass der Browser die Dateien schon vorab lädt, und diese dann bereits zur Verfügung stehen, wenn das CSS geladen wird. Damit kann man auch prima "zuckende" Texte beheben. Außerdem wirkt sich dieser Punkt positiv auf "First Contentful Paint" aus den Labdaten aus. Der Preload der Dateien wird mit einem Meta-Tag im Head der Seite gemacht:

page {
    headerData {
        30 = TEXT
        30.value (
    <link rel="preload" href="/typo3conf/ext/basetemplate/Resources/Public/Fonts/open_sans/open-sans-v17-latin-300.woff2?49596511" as="font" type="font/woff2" crossorigin>
    <link rel="preload" href="/typo3conf/ext/basetemplate/Resources/Public/Fonts/open_sans/open-sans-v17-latin-600.woff2?49596511" as="font" type="font/woff2" crossorigin>
    <link rel="preload" href="/typo3conf/ext/basetemplate/Resources/Public/Fonts/fa.woff2?49596511" as="font" type="font/woff2" crossorigin>
        )
    }
}

Hier gibt es mehrere Möglichkeiten wie man ans Ziel kommen kann. Zum einen könnte man natürlich versuchen, das ganze mit besserer und schnellerer Hardware zu kompensieren. Oder man setzt am Webserver und an der Datenbank an und optimiert hier weiter (was sicher auch kein Fehler ist). Aber wenn es richtig schnell werden soll, ist ein einfaches HTML File noch immer die beste Möglichkeit. Deshalb heißt die Lösung hier: StaticFileCache. Diese Extension erstellt beim ersten Zugriff auf eine Seite ein fertiges HTML File, das später dann ausgeliefert wird. Das funktioniert natürlich nur, wenn die Seite selbst keine dynamischen Inhalte verwendet. Es sollte also darauf geachtet werden, dass möglichst viele Seiten gecacht werden können. Eine Seite, auf der zum Beispiel ein Powermail-Formular angelegt ist, kann so nicht gecacht werden. Die Installation und Konfiguration der Extension ist denkbar einfach. Die Installation wird mit 

composer require lochmueller/staticfilecache

erledigt. Danach wird die Extension aktiviert, und die .htaccess Datei wird bearbeitet. Am besten Direkt nach 

RewriteEngine On

wird folgender Block eingefügt:

### Begin: StaticFileCache (preparation) ####

# Document root configuration
RewriteRule .* - [E=SFC_ROOT:%{DOCUMENT_ROOT}]
# RewriteRule .* - [E=SFC_ROOT:%{DOCUMENT_ROOT}/t3site] # Example if your installation is installed in a directory
# NOTE: There are cases (apache versions and configuration) where DOCUMENT_ROOT do not exists. Please set the SFC_ROOT to the right directory without DOCUMENT_ROOT then!

# Cleanup URI
RewriteCond %{REQUEST_URI} ^.*$
RewriteRule .* - [E=SFC_URI:/%{REQUEST_URI}]
RewriteCond %{REQUEST_URI} ^/.*$
RewriteRule .* - [E=SFC_URI:%{REQUEST_URI}]
RewriteCond %{REQUEST_URI} ^/?$
RewriteRule .* - [E=SFC_URI:/]

# Cleanup HOST
RewriteCond %{HTTP_HOST} ^([^:]+)(:[0-9]+)?$
RewriteRule .* - [E=SFC_HOST:%1]

# Disable cache for EXT:solr indexing requests
RewriteCond %{HTTP:X-Tx-Solr-Iq} .+
RewriteRule .* - [E=SFC_HOST:invalid-host]

# Get scheme
RewriteRule .* - [E=SFC_PROTOCOL:http]
RewriteCond %{SERVER_PORT} ^443$ [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} https
RewriteRule .* - [E=SFC_PROTOCOL:https]

# Get port
RewriteRule .* - [E=SFC_PORT:80]
RewriteCond %{ENV:SFC_PROTOCOL} ^https$ [NC]
RewriteRule .* - [E=SFC_PORT:443]
RewriteCond %{SERVER_PORT} ^[0-9]+$
RewriteRule .* - [E=SFC_PORT:%{SERVER_PORT}]
RewriteCond %{HTTP:X-Forwarded-Port} ^[0-9]+$
RewriteRule .* - [E=SFC_PORT:%{HTTP:X-Forwarded-Port}]

# Full path for redirect
RewriteRule .* - [E=SFC_FULLPATH:typo3temp/tx_staticfilecache/%{ENV:SFC_PROTOCOL}_%{ENV:SFC_HOST}_%{ENV:SFC_PORT}%{ENV:SFC_URI}/index]

# Extension (Order: br, gzip, default)
RewriteRule .* - [E=SFC_EXT:]
RewriteCond %{HTTP:Accept-Encoding} br [NC]
RewriteRule .* - [E=SFC_EXT:.br]
RewriteCond %{ENV:SFC_ROOT}/%{ENV:SFC_FULLPATH}%{ENV:SFC_EXT} !-f
RewriteRule .* - [E=SFC_EXT:]
RewriteCond %{ENV:SFC_EXT} ^$
RewriteCond %{HTTP:Accept-Encoding} gzip [NC]
RewriteRule .* - [E=SFC_EXT:.gz]
RewriteCond %{ENV:SFC_EXT} ^\.gz$
RewriteCond %{ENV:SFC_ROOT}/%{ENV:SFC_FULLPATH}%{ENV:SFC_EXT} !-f
RewriteRule .* - [E=SFC_EXT:]

# Write Extension to SFC_FULLPATH
RewriteRule .* - [E=SFC_FULLPATH:%{ENV:SFC_FULLPATH}%{ENV:SFC_EXT}]

### Begin: StaticFileCache (main) ####

# We only redirect URI's without query strings
RewriteCond %{QUERY_STRING} ^$

# It only makes sense to do the other checks if a static file actually exists.
RewriteCond %{ENV:SFC_ROOT}/%{ENV:SFC_FULLPATH} -f

# NO frontend or backend user is logged in. Logged in users may see different
# information than anonymous users. But the anonymous version is cached. So
# don't show the anonymous version to logged in users.
RewriteCond %{HTTP_COOKIE} !staticfilecache [NC]

# We only redirect GET requests
RewriteCond %{REQUEST_METHOD} GET

# Rewrite the request to the static file.
RewriteRule .* %{ENV:SFC_ROOT}/%{ENV:SFC_FULLPATH} [L]

# Do not allow direct call the cache entries
RewriteCond %{ENV:SFC_URI} ^/typo3temp/tx_staticfilecache/.*
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule .* - [F,L]

# Handle application cache
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^.*\.sfc$ %{ENV:CWD}index.php?eID=sfc_manifest [QSA,L]

### Begin: StaticFileCache (options) ####

# Set proper content type and encoding for gzipped html.
<FilesMatch "\.gzip$">
   SetEnv no-gzip 1
   SetEnv no-brotli 1
   <IfModule mod_headers.c>
      Header set Content-Encoding gzip
   </IfModule>
</FilesMatch>
<FilesMatch "\.gz$">
   SetEnv no-gzip 1
   SetEnv no-brotli 1
   <IfModule mod_headers.c>
      Header set Content-Encoding gzip
   </IfModule>
</FilesMatch>
<FilesMatch "\.br$">
   SetEnv no-gzip 1
   SetEnv no-brotli 1
   <IfModule mod_headers.c>
      Header set Content-Encoding br
   </IfModule>
</FilesMatch>

# if there are same problems with ForceType, please try the AddType alternative
# Set proper content type gzipped html
<FilesMatch "\.gzip$">
   ForceType text/html
    AddType "text/html" .gzip
</FilesMatch>
<FilesMatch "\.js\.gzip$">
   ForceType text/javascript
    AddType "text/javascript" .gzip
</FilesMatch>
<FilesMatch "\.css\.gzip$">
   ForceType text/css
    AddType "text/css" .gzip
</FilesMatch>
<FilesMatch "\.xml\.gzip$">
   ForceType text/xml
    AddType "text/xml" .gzip
</FilesMatch>
<FilesMatch "\.rss\.gzip$">
   ForceType text/xml
   # AddType "text/xml" .gzip
</FilesMatch>
<FilesMatch "\.gz$">
   ForceType text/html
    AddType "text/html" .gz
</FilesMatch>
<FilesMatch "\.xml\.gz$">
   ForceType text/xml
    AddType "text/xml" .gz
</FilesMatch>
<FilesMatch "\.rss\.gz$">
   ForceType text/xml
   # AddType "text/xml" .gz
</FilesMatch>
<FilesMatch "\.br$">
   ForceType text/html
    AddType "text/html" .br
</FilesMatch>
<FilesMatch "\.xml\.br$">
   ForceType text/xml
   # AddType "text/xml" .br
</FilesMatch>
<FilesMatch "\.rss\.br$">
   ForceType text/xml
   # AddType "text/xml" .br
</FilesMatch>

# Avoid .br files being delivered with Content-Language: br headers
<IfModule mod_mime.c>
   RemoveLanguage .br
</IfModule>

### End: StaticFileCache ###

Anschließend muss noch der TYPO3 Cache geleert werden. Statische Seiten werden nur von gecacht, welche nicht schon von TYPO3 selbst gecacht wurden. Im groben und ganzen war es das auch schon. Anbei noch zwei Screens, einmal die Zeit ohne StaticFileCache und einmal mit. Wichtig: Der Browser-Cache muss jeweils deaktiviert sein, es soll ja die Seite getestet werden, und nicht wie schnell der Browser die Sachen aus dem eigenen Cache lädt :-)

Dieser Empfehlung kann man wieder recht gut folgen. Ich hatte bei diesem Projekt schon entsprechend Vorbereitungen getroffen und die Cache-Richtlinien auf 30 Tage eingestellt. Das war damals noch in Ordnung, heute soll es aber mehr sein. Also alles, was nicht zeitkritisch ist, soll mindestens für 6 Monate im Browsercache gespeichert werden. Wichtig hierbei ist jedoch, dass eingebundenes CSS und JavaScript mit einem Timestamp-Hash in der URL eingebunden wird. Das passiert automatisch, wenn man CSS und JS über includeCSS und includeJS via TypoScript einbindet. Bindet man solche Dateien selbst über headerData ein, muss man einfach selbst einen Hash an die URL hängen, und bei einer neuen Version der Datei dieses Hash ändern.

Wichtige Bilder die ausgetauscht werden müssen, sollten in dem jeweiligen Element dann einfach unter einem anderen Namen eingebunden werden. Wird das Bild nur über die Dateiliste getauscht, und der Name des Bildes bleibt gleich, wird der Besucher beim nächsten Besuch nicht die neue Version sehen können. Hier ein Beispiel wie die Cache-Richtlinien angepasst werden können. Das geschieht in der .htaccess des Projekts:

# This affects Frontend and Backend and increases performance.
<IfModule mod_expires.c>

	ExpiresActive on
	ExpiresDefault                                      "access plus 1 month"

	ExpiresByType text/css                              "access plus 1 year"

	ExpiresByType application/json                      "access plus 0 seconds"
	ExpiresByType application/ld+json                   "access plus 0 seconds"
	ExpiresByType application/schema+json               "access plus 0 seconds"
	ExpiresByType application/vnd.geo+json              "access plus 0 seconds"
	ExpiresByType application/xml                       "access plus 0 seconds"
	ExpiresByType text/xml                              "access plus 0 seconds"

	ExpiresByType image/vnd.microsoft.icon              "access plus 1 week"
	ExpiresByType image/x-icon                          "access plus 1 week"

	ExpiresByType text/x-component                      "access plus 1 month"

	ExpiresByType text/html                             "access plus 0 seconds"

	ExpiresByType application/javascript                "access plus 1 year"
	ExpiresByType application/x-javascript              "access plus 1 year"
	ExpiresByType text/javascript                       "access plus 1 year"

	ExpiresByType application/manifest+json             "access plus 1 week"
	ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
	ExpiresByType text/cache-manifest                   "access plus 0 seconds"

	ExpiresByType audio/ogg                             "access plus 6 months"
	ExpiresByType image/bmp                             "access plus 6 months"
	ExpiresByType image/gif                             "access plus 6 months"
	ExpiresByType image/jpeg                            "access plus 6 months"
	ExpiresByType image/png                             "access plus 6 months"
	ExpiresByType image/svg+xml                         "access plus 6 months"
	ExpiresByType image/webp                            "access plus 6 months"
	ExpiresByType video/mp4                             "access plus 6 months"
	ExpiresByType video/ogg                             "access plus 6 months"
	ExpiresByType video/webm                            "access plus 6 months"

	ExpiresByType application/atom+xml                  "access plus 1 hour"
	ExpiresByType application/rdf+xml                   "access plus 1 hour"
	ExpiresByType application/rss+xml                   "access plus 1 hour"

	ExpiresByType application/vnd.ms-fontobject         "access plus 6 months"
	ExpiresByType font/eot                              "access plus 6 months"
	ExpiresByType font/opentype                         "access plus 6 months"
	ExpiresByType application/x-font-ttf                "access plus 6 months"
	ExpiresByType application/font-woff                 "access plus 6 months"
	ExpiresByType application/x-font-woff               "access plus 6 months"
	ExpiresByType font/woff                             "access plus 6 months"
	ExpiresByType application/font-woff2                "access plus 6 months"

	ExpiresByType text/x-cross-domain-policy            "access plus 1 week"

</IfModule>

Diese Empfehlung ist zusammen mit der nächsten Empfehlung, wo es um das JavaScript geht, eine der größten Herausforderungen. Um die Zusammenhänge zu erläutern, habe ich die beiden Empfehlungen "Ressourcen beseitigen, die das Rendering blockieren" sowie "Nicht verwendete CSS entfernen" zusammen genommen. Je mehr nicht verwendetes CSS im aktuellen Sichtbereich vorhanden ist, umso mehr wirkt sich das auf die Empfehlung "Ressourcen beseitigen" aus. Konkret bedeutet dass: Je mehr CSS wir aus dem Projekt entfernen, umso besser werden also die Gesamtwerte. Wie viel CSS man entfernen kann, hängt sicher auch vom Projekt und der Kompromissbereitschaft ab, aber auch, welche Komponenten verwendet und eingebunden werden. Bereits weiter oben habe ich das vorgehen schon für FontAwesome gezeigt, mit der Möglichkeit, sich das Icon-Font selbst zu bauen. Ich habe das CSS für dieses Projekt um 50Kb reduziert. Binde ich das CSS weiter mittels includeCSS ein, sind beide Empfehlungen noch im Test sichtbar, allerdings mit sehr geringen Werten. Ich erreiche hier in der Regel 99 Punkte. Das ist schon Top für ein Projekt. Später zeige ich aber noch die Inline Variante, um die 100 garantiert zu erhalten.

Best Practice zum Verkleinern von CSS

Eine konkrete Anleitung gibt es leider nicht, aber für dieses Projekt habe ich zuerst den Ist-Zustand ermittelt. Dieser war in etwa so:

• Bootstrap komplett
• FontAwesome diverse Fonts
• 3 weitere Fonts mit diversen Schriftschnitten
• AOS Animation Library
• Prismjs Code Highlighter
• jQuery Fancybox
• Bootstrap Select

Danach habe ich mir überlegt, was für das Projekt tatsächlich benötigt wird. Das war in diesem Fall dann:

• Bootstrap mit Custom Build: Grid, Nav, Dropdown, Badge, Buttons und Carousel. Zusätzlich einbinden muss man noch Functions, Variables, MixIns, Root, Reboot und Utilities
• FontAwesome mit nur wenigen Icons
• Prismjs, ebenfalls sehr abgespeckt mit nur wenigen Sprachen
• Neu dazu gekommen ist Simple Lightbox

Übrig bleibt nur noch ein schmales CSS, welches man später auch Inline einbinden kann. Beim letzten Artikel habe ich noch recht viel mit "CSS Above the Fold" gearbeitet, finde das aber eher unpraktisch mit der Handhabung, vor allem, wenn das Projekt sich weiter entwickelt. Dabei ging es darum, das CSS, welches sich im sichtbaren Bereich befindet, Inline einzubinden, und den Rest später per Datei nachzuladen. Bei dieser Vorgehensweise macht man sich nicht wirklich bewusst, was wirklich benötigt wird für ein Projekt, und was überflüssig ist, oder einfacher umgesetzt werden kann.

Jetzt wird es wild. Wir verlassen den Pfad des einfachen und machen uns auf, in eine Welt voller Kompromisse und alternativen Lösungen. Im Prinzip verhält es sich beim JavaScript ähnlich wie beim CSS. Einfach alles herauswerfen was nicht benötigt wird. Aber am Ende ist das doch nicht so einfach, wie man denkt. Was wird benötigt, was wird wirklich benötigt, und was wird tatsächlich benötigt? Auch hier wieder eine Liste, was bisher bei diesem Projekt eingebunden ist, und was künftig davon verwendet werden soll.

• Modenizr
• Detectizr
• jQuery
• jQuery.bridget
• popper
• jQuery.easing
• picturefill
• bootstrap
• bootstrap-select
• Driftjs
• Swiperjs
• AOS Animation Library
• jQuery Fancybox
• Isotope
• jQuery DateTimePicker (Powermail)
• Parsley (Powermail)
• Tabs  (Powermail)
• Form  (Powermail)
• PrismJS
• Cookiebot
• Analytics

Ja... so hab ich auch geschaut. Da sammelt sich mit der Zeit wirklich was an. Ein halbes MB nur JavaScript. Na denn, einmal ausmisten und die Liste was bei diesem Projekt wirklich gebraucht wird:

• PrismJS
• Analytics

Huch? Nur die beiden Sachen? Natürlich nicht, aber das ist tatsächlich das einzige, was aus der alten Liste übrig bleibt. Ich sagte bereits am Anfang, man muss Kompromisse machen. Aber wie schaut das im Detail aus?

Modernizr, Detectizr, jQuery und alle Plugins, Drift (kein Plan was das sein soll), AOS (das war wirklich ein Kompromiss) Isotope und das ganze andere braucht man nicht wirklich. Boostrap? Benötigt jQuery. Also eine fette Library nur wegen Bootstrap? Nein, braucht man nicht. Man kann auch Bootstrap rauswerfen, und Bootstrap.Native einbinden. Klein, leicht und ohne jQuery. Für den Rest muss man dann zurück zu den Basics, was eigenes JavaScript angeht. Für die Fancybox kam die Simple Lightbox als Ersatz. Hier nochmal in der Übersicht, welche Module nach der Auf- und Umbauaktion enthalten sind:

• Bootstrap.Native
• Simple Lightbox
• LazySizes (Dazu unten mehr)
• Prismjs

Das schaut wirklich sehr übersichtlich aus. Und klein. keine 40Kb groß. Wer es bis hierhin geschafft hat, dürfte sich nun im Test bei deutlich über 90 Punkte sehen. Vermutlich wird an der 100 gekratzt. Im weiteren Verlauf zeige ich einige Best Practices, um von der oberen Liste auf die untere zu kommen.

Für jede Root-Seite des Projekts ist im Listenmodul ein Eintrag zu finden. Hier werden die diversen Cookies angelegt und kategorisiert. Alle Texte sind ebenfalls darin zu erstellen.

Hier wird der Cookie-Eintrag für Analytics angelegt. Leider gibt es keine Vorlagen die der Extension Beiligen, aber nach kurzer Zeit ist relativ klar wie das ganze funktioniert. Neben dem Anlegen von Cookies im Backend muss dann auch im Frontend die Verknüpfung zum eigentlichen JavaScript Code hergestellt werden. Im Fall von Analytics schaut das wie folgt aus: