LiteSpeed Cache Plugin für WordPress – Komplette Schritt für Schritt Anleitung mit den besten Einstellungen für eine schnelle WordPress Website!
Ich zähle das LiteSpeed Cache Plugin zu den besten Caching Plugins für WordPress, die es gibt! Das beste ist, dass es vollkommen kostenlos ist.
Achtung!
Das LiteSpeed Cache Plugin für WordPress ist für Webserver mit LiteSpeed Technologie entwickelt worden. Sofern du aktuell kein LiteSpeed-Webhosting nutzt, empfehle ich dir das Webhosting von ChemiCloud! Das nutze ich auch für diese Website und zwar im WordPress Turbo Tarif, da der Redis Object Cache inklusive ist. Auf Apache oder NGINX Servern würde ich dieses Plugin nicht nutzen.
Sofern du nicht ganz sicher bist, ob dein Webhosting Anbieter LiteSpeed Server nutzt, kannst du das ganz einfach herausfinden. Gehe in deinem WP-Admin Bereich einfach auf:
Werkzeuge -> Website-Zustand -> Bericht -> Server
Wenn du nun das Tab ausklappst, findest du in der Tabelle die Zeile Webserver. Hier wird angezeigt, auf welcher Art Webserver deine WordPress Installation gehostet wird. Apache, NGINX, oder LiteSpeed.
LiteSpeed Cache Plugin installieren
Da es sich um ein kostenloses Plugin handelt, kann es einfach aus dem WP Plugin-Verzeichnis geladen werden.
Die folgenden Einstellungen sind meine Standardeinstellungen und sollten für die meisten Websites gut funktionieren.
Achtung:
Performance steigernde Maßnahmen, wie Caching und Code-Optimierung können Fehler auf der Webseite verursachen! Daher ist es wichtig, die Funktionalität und die Darstellung der Website nach jeder gespeicherten Optimierung zu prüfen. Außerdem sollte zuvor ein Website-Backup durchgeführt werden.
LiteSpeed Cache Dashboard
Das Dashboard von LiteSpeed zeigt den Status von optimierten Bildern, CDN-Nutzung und weiteren Performance-Metriken an. Die Messung der PageSpeed-Scores ist hier deutlich genauer als Browser-Tools von Drittanbietern wie Google PageSpeed Insights.
Configuration Presets
Das Plugin bietet Voreinstellungen in verschiedenen Performance-Stufen an. Ich habe davon noch nie gebrauch gemacht und bevorzuge die manuelle Konfiguration mit Zwischentests.
General Settings
Automatically Upgrade: Ein – Diese Funktion bezieht sich auf die Plugin-Updates. Wer vorsichtig ist, kann hier deaktivieren und LiteSpeed Cache manuell aktualisieren. Ich stelle es grundsätzlich auf automatische Updates.
Domain Key: Request Domain Key – Wird benötigt um die Verbindung zu den Diensten von QUIC.cloud herzustellen. Der Key wird im Hintergrund generiert und der Vorgang dauert eine knappe Minute. Aktualisiert man dann die Seite, befindet sich der Domain Key in dem entsprechenden Feld.
Das CDN benötigen wir nicht, daher können wir den Link to QUIC.cloud Button in Ruhe lasen.
Guest Mode: Ein – Der „Gast Modus“ verbessert die Ladezeit für Erstbesucher, indem eine Standardversion der Website aus dem Cache geladen wird. Sobald das Standard-HTML vollständig geladen ist, beginnt der Ladevorgang der aktuellen Seite, um die gecachte Version zu ersetzen.
Da auch Suchmaschinen und Speed-Checking-Tools zu den Erstbesuchern zählen, ist es für viele Websites sinnvoll, den Guest Mode zu aktivieren. Es sollte jedoch bedacht werden, das diese Funktion Server-Ressourcen verbraucht und auf komplexeren Seiten zu Darstellungsfehlern führen kann!
Tipp:
Du kannst deine Website im Inkognito-Modus aufrufen, um einen Erstbesuch zu simulieren. Sofern die Seite nicht korrekt dargestellt wird, bis der tatsächliche Code geladen ist, kann der Guest Mode deaktiviert werden.
Guest Optimization: Aus – Die zusätzliche Optimierung des Guest Modes sorgt zwar für noch bessere Ladezeiten für jene Benutzer, die zum ersten mal auf der Seite sind, kann jedoch zu Fehlern im Seitenlayout und der Funktionalität führen. Außerdem verbraucht die maximale Optimierungsstufe zusätzliche QUIC.cloud-Ressourcen, jedes mal wenn ein Erstbesucher auf der Seite rumturnt.
Speed-Junkies können diese Funktion bei aktiviertem Guest Mode einschalten, dann die Seite testen und zusätzlich prüfen, ob das QUIC.cloud Kontingent danach noch für den Rest des Monats reicht.
Sofern folgende Optimierungen alle aktiviert sind (was ich nicht empfehle), hat die Guest Optimization keine zusätzliche Auswirkung auf die Ressourcen von QUIC.cloud:
Critical CSS Generation (dazu kommen wir noch)
Unique CSS Generation (dazu kommen wir noch)
Viewport Images Generation (dazu kommen wir noch)
Separater Mobile Cache (dazu kommen wir noch)
WebP Image Replacement (dazu kommen wir noch)
Server IP: Klick auf Check my public IP from DoAPI.us um die öffentliche IP-Adresse deines Webservers zu ermitteln. Sofern diese Funktion nicht funktioniert (so wie in meinem Fall), findest du die IP-Adresse in deinem Webhosting Account.
Bei ChemiCloud muss nur das cPanel geöffnet werden und man findet die IP in der Sidebar unter General Information -> Shared IP Address.
Notifications: Aus – Wenn du auf die klassischen Benachrichtigungen der Plugin-Entwickler verzichten kannst, solltest du die Notifications abschalten.
Enable Cache: Ein – Nachdem der Cache aktiv ist, kannst du bei uptrends.com das erfolgreiche Caching deiner Website testen. Achte in der Ergebnistabelle auf:
Status: 200 OK
x-litespeed-cache: hit
Cache Logged-in Users: Aus – Das Caching für angemeldete Benutzer macht nur in vereinzelten Fällen Sinn. Ein gutes Beispiel wäre eine Membership Website, bei der sich Mitglieder einloggen, um bestimmte Inhalte zu abzurufen.
Cache Commenters: Aus – Sofern die Kommentare inkl. Admin-Bestätigung aktiviert sind, kann diese Funktion aktiviert werden, damit für Benutzer, die einen Kommentar hinterlassen, ein separater Cache erstellt wird, solange der Kommentar Pending ist. Bei einem hohen Aufkommen an Kommentaren (inkl. Spam), werden für diese Funktion eine menge Ressourcen verbraucht.
Cache REST API: Ein – Die WordPress REST-API wird von vielen Themes und Plugins genutzt, um mit der WP Datenbank zu kommunizieren. Teste deine Website inkl. Cookie Banner nach dem Aktivieren im Inkognito Modus.
Cache Login Page: Ein – Kann Server-Ressourcen einsparen, da diese Seite gern von Bots attackiert wird. (Funktioniert nur mit der Standard Login-URL von WordPress).
Cache favicon.ico: Ein – Gemeint ist das kleine Website-Icon im Browser-Tab. Auf jeden Fall aktivieren, da auch eine 404-Antwort zwischengespeichert wird, sofern der Browser die Datei favicon.ico auf deiner Website nicht findet.
Cache PHP Resources: Ein – Statische CSS- oder JS-Ressourcen, die vom Theme in PHP geladen werden geladenen werden, werden mit dieser Option zwischengespeichert (gecacht). Sofern dein Theme dynamische Ressourcen lädt, was sehr unwahrscheinlich ist, muss diese Option ausgeschaltet werden.
Cache Mobile: Kommt drauf an – Verbraucht Ressourcen, da eine separate Cache-Datei für Mobil-Geräte erstellt wird. Bei modernen Themes mit Responsive-Design, ist das nicht erforderlich.
Nur einschalten wenn mind. einer dieser Punkte zutrifft:
Wenn du AMP auf Ihrer Website verwendest (Keine gute Idee)
Wenn du den CCSS-Service aktiviert hast (dazu kommen wir noch)
Wenn du den UCSS-Service aktiviert hast (dazu kommen wir noch)
Ich aktiviere die Cache Mobile Funktion meistens, da ich häufig für die mobile Ansicht separate Elemente erstelle, um die Performance und das Design der Website zu verbessern. Außerdem…
List of Mobile User Agents: Wenn man Cache Mobile Funktion aktiviert hat und der Meinung ist, diese Liste sei unvollständig, können zusätzliche User Agents eingetragen werden.
Syntax:
Jeder Eintrag sollte mit einem Strich, ‚|‘, getrennt werden. Alle Leerzeichen sollten mit einem Backslash vor dem Leerzeichen, ‚ ‚, getrennt werden. Die Standardliste, die WordPress verwendet, ist: Mobile|Android|Silk/|Kindle|BlackBerry|Opera Mini|Opera Mobi
Private Cached URIs: (Uniform Resource IdentifiernichtUniform Resource Locator) – Dieser Liste können Pfadmuster hinzugefügt werden, die privat gecacht werden sollen. Es handelt sich dabei um Pfade, die niemals öffentlich gecacht werden sollten.
Private Cache vs. Public Cache:
Der öffentliche Cache wird grundsätzlich an alle Website-Besucher ausgeliefert.
Der private Cache wird nur für einen einzelnen Besucher erstellt. Er enthält in der Regel Informationen, die nur für diesen bestimmten Benutzer relevant sind (z. B. die WordPress Admin Bar für angemeldete Benutzer)
Auch wenn es für die meisten Websites nicht notwendig ist, da sich die Einstellung „Cache Logged-in Users“ um private URIs im Cache kümmert, werde ich diese Funktion mal kurz anreißen. Im Allgemeinen müssen jedoch keine Seiten auf deiner Website zwangsweise gecacht werden.
Um den Anfang eines URIs anzugeben, gehört ^ an den Anfang des Strings. Für eine exakte Übereinstimmung muss $ an das Ende des Strings eigefügt werden.
Beispiel für Übereinstimmungen der Strings:
Folgende URIs sollen privat gecacht werden:
1. /rezepte/bbq/
2. /rezepte/bbq/rippchen
3. /rezepte/bbq/spanferkel
4. /beliebt/rezepte/bbq/
Der String /rezepte/bbq/ stimmt mit allen vier URIs überein und würde sie alle dem Private Cache hinzufügen.
Der String /rezepte/bbq/$ entspricht der Nummer 1 (da $ eine exakte Übereinstimmung anzeigt).
Der String ^/rezepte/bbq passt zu 1, 2 und 3 (weil ^ den Anfang des URIs angibt).
Force Cache URIs: Pfade, die die hier gelisteten Strings enthalten, werden im öffentlichen Cache zwischengespeichert, unabhängig von irgendwelchen „non-cacheable“ Einstellungen, die ggf. an anderer Stelle durchgeführt wurden.
Einer pro Zeile. Jeder String wird mit der Servervariablen REQUEST_URI verglichen. Bei einer Übereinstimmung wird der URI zwischengespeichert. Um den Anfang eines URIs anzugeben, muss ^ an den Anfang des Strings gesetzt werden. Für eine exakte Übereinstimmung, $ am Ende des Strings einfügen.
Um eine benutzerdefinierte TTL für einen URI zu definieren, muss ein Leerzeichen gefolgt von dem TTL-Wert am Ende des URIs eingefügt werden. Zum Beispiel definiert /mypath/mypage 300 eine TTL von 300 Sekunden für /mypath/mypage.
Force Public Cache URIs: Genau wie bei Force Caches URIs, können hier Strings gelistet werden, jedoch in diesem Fall für den Public Cache, also den Cache für nicht angemeldete Benutzer.
Drop Query String: Mit dieser Einstellung können query strings angeben werden, die von LS-Cache ignoriert werden sollen. Marketingkampagnen und Tracking-URLs enthalten oft query strings, bei denen das Caching ignoriert wird. Die Standardliste ist in der Regel in Ordnung, aber wenn du weitere hast, füg sie hinzu.
Save Changes um alle Einstellungen zu speichern.
Achtung! Nicht einfach weiter scrollen, es geht oben weiter mit dem TTL Tab!
TTL
Die Standardeinstellungen sind normalerweise vollkommen in Ordnung. Cache TTL gibt die Zeitspanne vor, in der LiteSpeed Cache eine Datei im Cache hält. Sobald sie abläuft, wird eine neue Datei erstellt.
Eine kürzere TTL wird nur benötigt, wenn die Website häufig aktualisiert wird und man sicherstellen will, dass Besucher die aktuelle gecachte Version zu sehen bkommen. Das verbraucht aber auch mehr Ressourcen.
Eine lange TTL spart Ressourcen, aber der Cache wird nicht so häufig aktualisiert, so dass die Besucher den neuen Inhalt möglicherweise nicht angezeigt bekommen.
Purge all on Upgrade: Ein – Aktualisiert den Cache, wenn WordPress Core Dateien, Themes, oder Plugins aktualisiert werden. Auf jeden Fall aktivieren, um sicherzustellen, dass die Website korrekt angezeigt wird.
Auto Purge Rules For Publish/Update: Die Standardeinstellungen sind in Ordnung – Wenn ein Beitrag veröffentlicht oder aktualisiert wird, ändert sich nicht nur die Beitragsseite. Auch die Auflistung der Kategorien und Tags, die Blog Seite und eine Reihe von Archiven können sich ändern. Hier kann festgelegt werden, welche Inhalte bei jeder Aktualisierung oder Erstellung eines Beitrags automatisch bereinigt werden sollen.
Serve Stale: Aus – Wenn diese Einstellung aktiviert ist, kann einem Besucher die zuletzt bereinigte (abgelaufene) Cache-Kopie einer Seite angezeigt werden, sofern die aktualisierte Cache-Kopie noch nicht generiert wurde. Das aktivieren dieser Funktion verbraucht Ressourcen)
Scheduled Purge URLs: Es besteht keine Notwendigkeit hier URLs hinzuzufügen, es sei denn, du möchtest den Cache bestimmter Seiten zu einem gewissen Zeitpunkt löschen. In diesem Fall müsste auch eine geplante Löschzeit festgelegt werden.
Sollten sich z.B. extern generierte Inhalte auf deiner Seite befinden und die entsprechende Seite täglich gecacht werden soll, damit die externen Inhalte korrekt angezeigt werden, müsste die Eingabe wie folgt aussehen:
Beispiele
Immer nur ein String pro Zeile eingeben!
Bestimmte Seite cachen: https://beispiel.de/rezepte/bbq/rippchen
Hier kann sowohl die URL eingegeben werden: https://beispiel.de/rezepte/bbq/rippchen
Als auch der Pfad: /rezepte/bbq/rippchen
Sofern mehrere Seiten einer bestimmten Kategorie gecacht werden sollen, können auch Wildcards eingegeben werden: /rezepte/bbq/*
In diesem Beispiel werden alle Seiten, die mit: https://beispiel.de/rezepte/bbq/... beginnen gecacht.
Scheduled Purge Time: Sofern eben URL’s eingefügt wurden, kann hier bestimmt werden, zu welcher Zeit die Seiten gecacht werden sollen (am besten zu einer Tageszeit mit geringem Datenverkehr).
Purge All Hooks: Auch hier sind die Standardeinstellungen OK.
Wenn du z.B. jedes mal den Cache leeren möchtest, wenn ein Kommentar auf deiner Website veröffentlicht wird, könnest du den comment_post-Hook hinzufügen.
Für die meisten Websites gibt es hier nichts zu tun. Der Cache wird bereits in anderen LiteSpeed Cache-Einstellungen kontrolliert, sodass es normalerweise keinen Grund gibt, hier Inhalte vom Caching auszuschließen.
Für diejenigen, die es ganz genau wissen wollen, werde ich die einzelnen Punkte, ggf. mit Eingabebeispielen, kurz anreißen.
Do Not Cache URIs: Sofern gewisse Seiten deiner Website aus irgendeinem Grund nicht gecacht werden sollen, können die URIs hier aufgelistet werden, wie immer eine pro Zeile. Das Syntax-Beispiele hatte ich ja in den Cache Control Settings bereits aufgeführt.
Do Not Cache Query Strings: Hier können URLs mit bestimmten Query Strings vom Caching ausgeschlossen werden.
Mal angenommen, dein Website-Design ermöglicht das Ändern des kompletten Farbschemas mit einem Query String. Bei einem violetten Farbschema würde die URL wie folgt aussehen: https://beispiel.de/page?color=purple. Wenn du keine Seite cachen möchtest, die in einem anderen Farbschema gerendert wird, dann müsstest du color zur Do Not Cache Query Strings Liste hinzufügen.
Dies würde alle Seiten mit dem Query String?color= vom Caching ausschließen. Der tatsächliche Wert von color ist hierbei nicht relevant. Der Schlüssel (color) wird abgeglichen, während der Wert alles sein kann, von purple über green bis hin zu rotkehlcheneiblau …
Do Not Cache Categories: Standardmäßig werden alle Kategorien gecacht. Sofern bestimmte Kategorien deiner Website ausgeschlossen werden sollen, müssten hier die entsprechenden Kategorie-Slugs (ein Slug pro Zeile) aufgelistet werden.
Beispiel:
Um folgende Kategorie auszuschließen: https://beispiel.de/category/beispiel-slug/, müsste beispiel-slug in die Liste eingetragen werden.
Do Not Cache Tags: Tags werden genauso behandelt wie Kategorien und können nach dem selben Schema vom Caching ausgeschlossen werden.
Do Not Cache Cookies: Mit dieser Funktion wäre ich vorsichtig. Wenn ein Cookie ausgeschlossen wird, der auf jeder Seite der Website vorhanden ist, dann kann mal schnell die gesamte Website vom Caching ausgeschlossen werden!
Do Not Cache User Agents: Wenn du z.B. bestimmten Browsern Webcrawlern keine gecachte Version deiner Website präsentieren möchtest, dann können diese hier gelistet werden.
Do Not Cache Roles: Hier kann verhindert werden, dass bestimmten Benutzerrollen, z.B. den Administratoren, gecachte Inhalte angezeigt werden.
Save Changes sofern irgendwelche Eingaben vorgenommen wurden.
Mit Edge Side Includes (ESI) können Seiten für eingeloggte Benutzer aus dem Cache bereitgestellt werden.
Enable ESI: Aus – Grob gesagt werden mit ESI Teile von öffentlich gecachten Seiten mit Inhalten aus dem Private Cache gefüllt.
Beispiele:
1. Du rufst als Administrator eine Seite auf deiner Website auf. Diese wird für unangemeldete Benutzer aus dem Public Cache ausgeliefert. Da für dich als Admin jedoch die Admin Bar angezeigt wird. Kann der Public Cache dich nicht Bedienen und es geht eine PHP Anfrage ans Backend raus.
Mit FSI würde die besagte Seite aus dem öffentliche Cache für dich bereitgestellt, und die Admin Bar würde aus dem privaten Cache dazugepuzzelt werden.
2. Ein Nutzer verirrt auf deinen Webshop und bekommt die Website aus dem Public Cache angezeigt. Nun packt er ein Produkt in den Warenkorb und die Seite kann für ihn nicht mehr regulär gecacht werden, da das Produkt im Warenkorb Benutzerspezifisch ist.
Mit FSI kann der Warenkorb als privat gecachter FSI-Block gekennzeichnet werden, sodass der Rest der Seite öffentlich- und nur der Warenkorb individuell gecacht werden kann. Für den Benutzer werden dann beide Inhalte zusammengepuzzelt.
Klingt doch eigentlich recht sinnvoll, warum also deaktivieren? Nun, für den Server ist es viel einfacher, vollständige Seiten auszugeben, als Seiten aus mehreren Blöcken zusammenzusetzen. Am Ende hat man leichte Geschwindigkeitsvorteile die Effizienzeinbußen gegenüberstehen.
Dafür ist mir das Setup von Private Cache Inhalten und das Einrichten von FSI-Blöcken ehrlich gesagt zu viel Alarm… Wer einen WooCommerce Store betreibt, könnte mit aktiviertem FSI ggf. Vorteile haben, da der Warenkorb automatisch als privater ESI-Block betrachtet wird.
Cache Admin Bar: Ein – Ich hab die Erfahrung gemacht, dass diese Einstellung das Backend beschleunigt, wenn sie aktiv ist.
Cache Comment Form: Ein
ESI Nonces:
Vary Group:
Was diese Einstellungen betrifft, habe ich mich immer rausgehalten und kann daher nicht wirklich sagen, in welchen Fällen es sich lohnt sie zu nutzen.
Wer an dieser Stelle dennoch neugierig ist, kann sich gern die LiteSpeed Docs dazu einverleiben.
Save Changes sofern irgendwelche Eingaben vorgenommen wurden.
Beim persistenten Object Caching werden die Ergebnisse von Datenbankabfragen gespeichert, so dass beim nächsten Mal ein Ergebnis aus dem Cache abgerufen werden kann, ohne die Datenbank wiederholt abfragen zu müssen.
Eine wirklich mächtige Funktion, da WordPress als CMS sehr viel mit der Datenbank kommuniziert, ganz besonders wenn WooCommerce installiert ist.
Um den Object Cache aktivieren zu können, solltest du zuvor recherchieren, ob dein Webhosting Anbieter in deinem aktuellen Tarif, diesen überhaupt unterstützt.
Erinnerst du dich, ich habe zu Beginn dieses Posts den WordPress Turbo Tarif von ChemiCloud empfohlen, weil der Object Cache inklusive ist.
Object Cache: Ein
Status: Memcached Extension: Disabled
Status: Redis Extension: Enabled
Status: Connection Test: Passed
Method: Redis – Redis ist leistungsfähiger als Memcached, insbesondere für sehr dynamische Websites, mit Shop- oder Membership-System. Zusätzlich wird der WordPress Admin-Bereich beschleunigt. Sofern du die Wahl hast, nimm Redis!
Sofern dein Webhoster Object Cache unterstützt, starte eine Google suche nach einer Anleitung zum aktivieren des Object Caches.
Ich bin z.B. dieser Anleitung gefolgt, um Redis bei ChemiCloud für WordPress aufzuschalten.
Host: Eingabedaten im Webhosting Account – Sollte in deinem Webhosting Account als /beispiel/pfad/memcached.sock oder /beispiel/pfad/redis.sock aufgeführt sein.
Port: Eingabedaten im Webhosting Account – Sollte in deinem Webhosting Account angegeben sein. Andernfalls versuch es mit den Standard-Ports (Memcached: 11211, Redis: 6379)
Redis Database ID: 0-100 – Wird verwendet, um Redis von einem Webhost auf mehreren Websites hinzuzufügen, jede Seite erhält ihre eigene Redis-Datenbank-ID.
Global Groups: Einfach so belassen (Eine Liste von Gruppen, die auf der Netzwerkebene gecacht werden sollen).
Do Not Cache Groups: Auch so belassen (Eine Liste von Gruppen, die nicht in den Objekt-Cache aufgenommen werden sollen).
Persistent Connection: Ein – Wenn diese Option aktiviert ist, wird die Verbindung aufrechterhalten, um den Object Cache noch schneller zu machen.
Cache WP-Admin: Ein – Beschleunigt den WordPress Admin Bereich. Nur abschalten, wenn dir veraltete Daten aus dem Objekt-Cache angezeigt werden.
Store Transients: Aus – Nur aktivieren, wenn Cache WP-Admin abgeschaltet ist, um Server-Meldungen (wie z.B. XXXX has been completed successfully. erhalten zu können)
Browser Cache: Ein – Bei aktiviertem Browser-Caching werden statische Inhalte (z.B. das Website Logo) bei der ersten Anforderung lokal auf dem Gerät des Nutzers gespeichert. Danach wird der Inhalt aus dem lokalen Speicher abgerufen, was deutlich schneller geht, als die Übertragung eines Bildes über das Internet.
Browser Cache TTL: 31557600 – Die Zeitspanne in Sekunden, die die Dateien im Browser-Cache gespeichert werden, bevor sie ablaufen. LiteSpeed Cache empfiehlt 31557600 Sekunden, das entspricht einem Jahr.
Login Cookie: Frei lassen – Wird nur benötigt, wenn mehrere WordPress-Installationen mit einem LSCache-Plugin auf einem einzigen virtuellen Host verwendet werden. (Nicht bei Multisites)
Ein Beispiel für ein Login Cookie ist: _wp_login_1
Vary Cookies: Frei lassen – Wird nur benötigt, wenn ein Plugin eines Drittanbieters eingesetzt wird, das Cookies verwendet, um den angezeigten Inhalt auf einer Seite zu ändern.
Beispiel
Ein Membership-Plugin zeigt gewisse Shop-Preise für Mitglieder an und für Nicht-Mitglieder werden andere Preise angezeigt. Das bedeutet, dass es zwei Versionen jeder Seite gibt, basierend auf dem Wert des _member-Cookies des Plugins. Um diese beiden Versionen im Cache zu speichern, muss LSCache ein „vary“ auf der Grundlage des _member-Cookies erstellen.
Also trägst du _member in das Vary Cookies Feld ein. Weite Cookies können Zeile für Zeile hinzugefügt werden.
Improve HTTP/HTTPS Compatibility: Aus – Wird nur benötigt, wenn sowohl HTTP als HTTPS verwendet wird. Aktiviert man diese Option, wird das Anmelde-Cookie immer als HTTP-Cookie gespeichert, egal welches Protokoll für den Zugriff auf die Seite verwendet wird.
Dadurch wird sichergestellt, dass das Login-Cookie immer sowohl für HTTP- als auch für HTTPS-Verbindungen zugänglich ist.
Forcing SSL, z.B. mit dem Really Simple SSL Plugin, könnte hier eine Alternativlösung sein.
Instant Click: Ein – Wenn ein Nutzer mit der Maus über einem Link hovert, oder ihn auf dem Smartphone berührt, wird der HTML-Code der Ziel-Seite im Hintergrund vorgeladen, sodass die Seite, sofort present ist, wenn der Nutzer den Link tatsächlich klickt.
Diese Funktion verbessert die wahrgenommene Ladezeit für einen Benutzer, auf die Werte von Speed-Testing-Tools hat sie jedoch keine Auswirkung.
Das Vorladen der Linkziele erhöht zwar die CPU-Auslastung, trägt aber enorm zu einer guten Benutzererfahrung bei. Daher würde ich diese Option immer aktivieren!
Save Changes um alle Einstellungen zu speichern.
WooCommerce Tab
CDN
Da für Websites im deutschsprachigen Raum ein CDN keine großen Auswirkungen auf die Website-Performance hat und die Anbindung zum QUIC.cloud CDN sehr technisch ist, hatten wir auf die CDN-Nutzung verzichtet.
In diesem Video zum LiteSpeed Cache Plugin, beschreibe ich das Anbinden einer Website ans QUIC.cloud CDN:
Image Optimization
[2] Image Optimization Settings
Keine Ahnung warum Image Optimization Summary das erste Tab ist und die Image Optimization Settings das zweite, aber wir starten im 2. Tab.
Auto Request Cron: Ein – Wenn diese Option eingeschaltet ist, werden für neu hochgeladene Bilder automatisch Bildoptimierungsanfragen per Cron-Job gesendet.
Auto Pull Cron: Ein – Aktivieren wenn Auto Request Cron aktiv ist, andernfalls müssten neu optimierte Bilder immer manuell über den Button „Pull Images“ abgerufen werden.
Optimize Original Images: Ein – Wenn die Bildoptimierung ausgeführt wird, werden JPG- und PNG-Bilder optimiert und entsprechende Backups gespeichert.
Beispiel
Wird z.B. das Bild image.jpg optimiert, dann wird eine Kopie davon in image.bk.jpg gespeichert. Anschließend wird die neu optimierte Version wieder in image.jpg gespeichert.
Du kannst diese Option ausschalten, wenn du keine optimierten JPG- und PNG-Dateien möchtest.
Remove Original Backups: Aus – Löscht automatisch alle Originalbilder, nachdem sie die optimierten Versionen erstellt sind. Wenn die Backups gelöscht sind, kann die Optimierung nicht mehr rückgängig gemacht werden!
Nur aktiveren, wenn du mit dem Optimierungsergebnis aller Bilder 100%ig zufrieden bist!
Optimize Losslessly: Ein – Losslessly ist die verlustfreie Bild-Komprimierung. Ich bevorzuge das gegenüber Lossy (verlustbehaftete Komprimierung), da ich meine Bilder schon vor dem Upload bearbeite.
Preserve EXIF/XMP data: Aus – Die EXIF- oder XMP-Daten eines Bildes können Informationen, wie das Aufnahmedatum, GPS-Koordinaten, Kommentare, Schlüsselwörter usw. enthalten. LiteSpeed Cache entfernt die EXIF-Daten bei der Bildoptimierung standardmäßig.
Dadurch verringert sich logischerweise die Größe der Bilddatei, was dann einen positiven Affekt auf die Gesamtperformance der Website hat. Auch aus Gründen des Datenschutzes kann es Sinn machen, diese Informationen zu entfernen.
Im Durchschnitt bestehen über 15% des Gewichts einer JPEG-Datei aus Bild-Metadaten.
Beeinträchtigt das Entfernen EXIF-Daten die Suchmaschinenoptimierung?Ja! Die genannten Informationen helfen Google und anderen Suchmaschinen dabei, das Bild und dessen Inhalt besser zu verstehen. Das hat auch Auswirkungen auf das Ranking im Index.
Bei einem Travel-Blog zum Beispiel, könnte die Information, wo ein Bild aufgenommen wurde, durchaus relevant sein. Du solltest diese Option nur dann deaktiviert lassen, wenn die Metadaten deiner Bilder keinerlei SEO-Relevanz haben.
Image WebP Replacement: Ein – LiteSpeed Cache liefert nun.jpg– oder .png-Bilder im.webp-Format an alle Browser, die .webp unterstützen. Wenn ein nicht unterstützter Browser eine Seite mit WebP-Bildern anfordert, stellt LSCache diesem Browser eine Version mit dem ursprünglichen Bild-Dateiformat zur Verfügung.
WebP Attribute To Replace: Entferne ein Attribut aus der Liste, sofern du nicht möchtest, dass WebP-Bilder dort ersetzt werden. Du kannst auch weitere Attribute zur Liste hinzufügen.
WebP For Extra srcset: Ein – WordPress erstellt üblicherweise verschiedene Versionen eines Bildes, z.B. für unterschiedliche Bildschirmgrößen. Damit diese auch im webP Format bereitegstellt werden können, muss diese Funktion aktiv sein.
WordPress Image Quality Control: 82 – Regelt die Qualität der Bildkomprimierung von WordPress. Je kleiner die Zahl, desto stärker die Komprimierung. LS Cache und viele weitere Tools für Bildoptimierung empfehlen 82.
Save Changes um alle Einstellungen zu speichern.
[2] Image Optimization Summary
Page Optimization
Aufgepasst!
Bei der Seiten-Optimierung gibt es keine Pauschallösung, die für alle Websites funktioniert. Daher sollte nach jeder gespeicherten Einstellung zunächst der Cache gelöscht, und dann die Website auf korrekte Darstellung und Funktionalität geprüft werden. Ich führe diese Test immer im Inkognito-Modus und mit verschiedenen Webbrowsern durch. Ggf. sollte auch die Mobil-Version der Website getestet werden.
CSS Minify: Ein – Auch wenn die meisten Entwickler ihre Dateien schon von Haus aus minimieren, sollte das Komprimieren von CSS-Dateien immer aktiviert werden. Hierbei werden u.a. Leerzeichen und Kommentare aus dem CSS-Code entfernt, was natürlich die Dateigröße verringert.
CSS Combine: Kommt drauf an– Hierbei werden alle einzelnen CSS-Dateien zu einer großen CSS-Datei zusammengefasst. Diese Datei ist zwar insgesamt kleiner, als alle einzelnen zusammen, aber deutlich größer als jede einzelne Datei.
Seiten werden grundsätzlich erst gerendert, sobald ein gesamtes Asset geladen ist.
Sofern deine Website in der Lage ist, die Seite nur mit datei1.css zu rendern, da datei2.css – datei4.css zum Rendern der unteren Teile der Seite verwendet werden, kann das schneller sein als mit kombiniertem CSS. In diesem Fall solltest du CSS Combine nicht aktivieren.
Der Grund dafür ist, dass datei1.css früher gerendert wird, als die große Datei mit dem kombinierten CSS. (Wie beim Konzept des „Critical CSS“ verbessert sich der TTFB-Wert)
Das gilt allerdings nur für Erstbesucher, da wiederkehrende Besucher ja eh aus’m Cache versorgt werden.
Fazit
Ich persönlich bin kein Fan von kombiniertem CSS und aktiviere diese Funktion grundsätzlich nicht! Auch wenn diese Maßnahme von den meisten Speed-Testing-Tools mit besseren Scores honoriert wird, profitieren nur bestimmte Websites davon.
Ob das kombinieren von CSS aktiviert werden sollte oder nicht, muss am ende durch testen entschieden werden. Hier sollte jedoch nicht das Speed-Test Tool genutzt werden, sondern es gilt die reale Benutzererfahrung im Inkognito-Mudus zu testen.
Generate UCSS: Ein – Sofern CSS Combine aktiv ist, generiert diese Funktion Unique CSS und erstellt für jede Seite deiner Website eine eigene optimierte CSS-Datei. Diese kombinierte Datei enthält nur das CSS, das für die Darstellung der jeweiligen Seite erforderlich ist.
Vorteil
Diese Datei enthält nur das notwendige CSS, daher bleibt jede kombinierte CSS-Datei klein und kann daher schneller geladen- und somit die Seite früher gerendert werden.
UCSS Inline: Aus – Sollte grundsätzlich ausgeschaltet sein! Das Unique CSS in der <head>Sektionder Website inline zu laden, anstatt in einer separaten Datei, ist keine gute Idee. Eine separate Datei kann im Cache gespeichert werden und bläht das HTML nicht unnötig auf. Inline CSS hingegen kann nicht gecacht werden!
Tools wie PageSpeed Insights honorieren inline geladenes CSS häufig mit besseren Scores, da eine zusätzliche Anfrage (HTTP-Request) vermieden wird. Für den realen Benutzer lädt die Seite jedoch schneller, wenn das CSS in einer separaten Datei geladen wird. Da seit HTTP/2 und inzwischen HTTP/3, Serveranfragen deutlich schneller verarbeitet werden können!
CSS Combine External and Inline: Ein – Kann Server-Ressourcen einsparen, da diese Seite gern von Bots attackiert wird. (Funktioniert nur mit der Standard Login-URL von WordPress).
Load CSS Asynchronously: Ein – Gemeint ist das kleine Website-Icon im Browser-Tab. Auf jeden Fall aktivieren, da auch eine 404-Antwort zwischengespeichert wird, sofern der Browser die Datei favicon.ico auf deiner Website nicht findet.
CCSS Per URL: Ein – Statische CSS- oder JS-Ressourcen, die vom Theme in PHP geladen werden geladenen werden, werden mit dieser Option zwischengespeichert (gecacht). Sofern dein Theme dynamische Ressourcen lädt, was sehr unwahrscheinlich ist, muss diese Option ausgeschaltet werden.
Inline CSS Async Lib: Kommt drauf an – Verbraucht Ressourcen, da eine separate Cache-Datei für Mobil-Geräte erstellt wird. Bei modernen Themes mit Responsive-Design, ist das nicht erforderlich.
Nur einschalten wenn mind. einer dieser Punkte zutrifft:
Wenn du AMP auf Ihrer Website verwendest (Keine gute Idee)
Wenn du den CCSS-Service aktiviert hast (dazu kommen wir noch)
Wenn du den UCSS-Service aktiviert hast (dazu kommen wir noch)
Wenn du den Guest Mode und die Guest Optimization aktiviert hast
Ich aktiviere die Cache Mobile Funktion meistens, da ich häufig für die mobile Ansicht separate Elemente erstelle, um die Performance und das Design der Website zu verbessern. Außerdem…
List of Mobile User Agents: Wenn man Cache Mobile Funktion aktiviert hat und der Meinung ist, diese Liste sei unvollständig, können zusätzliche User Agents eingetragen werden.
Font Display Optimization:Swap – Um Layout Shifts beim Ladevorgang der Fonts zu vermeiden und folgender Google PageSpeed Insights Meldung vorzubeugen; „Darauf achten, dass der Text während der Webfont-Ladevorgänge sichtbar bleibt„, würde ich diese Funktion auf Swap setzen.
Save Changes um alle Einstellungen zu speichern.
Achtung! Nicht einfach weiter scrollen, es geht oben weiter mit dem JS Tab!
JS Settings
JS Minify: Ein – Komprimiert den Code, indem u.a. Leerzeichen und Kommentare aus dem JavaScript-Code entfernt werden, was natürlich die Dateigröße verringert.
JS Combine: Aus – Ich würde niemals JavaScript zusammenfassen und zwar aus folgenden Gründen:
Wenn verschiedenste JavaScript Dateien, die überhaupt nix mit einander zu tun haben, zu einer großen Datei zusammengefügt werden, besteht die Gefahr, dass bestimmte Skripte plötzlich nicht mehr geladen werden.
Auch wenn nach dem Aktivieren dieser Funktion beim Website-Check alles läuft, besteht schon beim nächsten Update eines Plugins die Gefahr, dass irgendetwas nicht mehr richtig funktioniert.
Außerdem sind wir inzwischen im Zeitalter von HTTP/2 / HTTP/3 und das parallele Laden mehrerer Assets ist effizienter als das Laden eines kombinierten Assets.
Hinzu kommt, dass die Performance bestimmter Seiten unter dem zusammengefassten JavaScript leiden kann, da mehr viel mehr JS geladen wird, als tatsächlich nötig.
JS Combine External and Inline: Aus – Nur aktivieren, wenn JS Combine aktiviert ist.
Load JS Deferred: Kommt drauf an– Delayed ist prinzipiell am besten für die Performance, da JS-Dateien erst dann geladen werden, sobald der Nutzer mit der Website in irgendeiner Form interagiert. Das könnte z.B. Scrollen, oder oder einfach das Bewegen der Maus über den Bildschirm sein.
Hier muss getestet werden, ob die Seite mit verzögert geladenem JavaScript noch anständig läuft. In der Tuning Sektion, können JS-Dateien vom verzögerten laden ausgeschlossen werden, dass erfordert jedoch etwas Erfahrung.
Deferred bedeutet, dass die JS-Dateien an den unteren Teil der Website verschoben werden und daher aufgeschoben werden, bis der HTML-Code fertig geladen ist. Auch hier können Ausnahmen in der Tuning Sektion eingerichtet werden.
Am Ende hängt es von Tests und der Erfahrung des Administrators ab, welche Option hier Optimal ist. Im Zweifelsfall deaktivieren.
Save Changes um alle Einstellungen zu speichern.
Achtung! Nicht einfach weiter scrollen, es geht oben weiter mit dem HTML Tab!
HTML Settings
HTML Minify: Ein – Genau wie beim Komprimieren von CSS und JavaScript, werden hier z.B. Leerzeichen und Kommentare aus dem Code entfernt.
DNS Prefetch: Hier können URL’s eingegeben werden, die Dienste von externen Quellen auf der Website einbinden, damit diese geprefetcht (vorabgerufen) werden. Hierbei wird eine Verbindung zu Code von Drittanbietern hergestellt, bevor er tatsächlich angefordert wird.
Die URL’s werden Zeile für Zeile wie folgt eingegeben: //maps.googleapis.com
Einige Assets sollten besser lokal gehostet werden, anstatt sie extern einzubinden und dann die Verbindung zu beschleunigen. Ein Beispiel dafür sind die Google Fonts. Dann gibt es Dienste wie YouTube, die per iFrame eingebunden werden. Hier ist es besser die iFrames durch ein Vorschaubild-Bild zu ersetzten, als sie zu prefetchen. Ich nutze dafür das Presto-Player Plugin.
DNS Prefetch Control: Ein – Aktiviert DNS Prefetch für alle URLs im Dokument, einschließlich Bilder, CSS, JavaScript usw.
DNS Preconnect: Ähnlich wie DNS Prefetch beschleunigt DNS Preconnect die Website nicht wirklich. Allerdings werden die Verbindungsprozesse zu anderen Websites beschleunigt und dadurch reagiert die Website schneller auf die Klicks der Benutzer.
Wie immer werden die URL’s Zeile für Zeile eingegeben: //fonts.gstatic.com
HTML Lazy Load Selectors: Jedes below the fold HTML -Element kann anhand seines Selektors (in der Regel eine ID oder Klasse) verzögert geladen werden.
Öffne deine Website in Chrome
Klick ein Element, dass verzögert geladen werden soll, mit der rechten Maustaste an
Geh auf Untersuchen, um die Entwicklerkonsole zu öffnen
Kopier den Selektor
Selektoren einzeln pro Zeile auflisten, ohne # oder ..
Sollten sich z.B. extern generierte Inhalte auf deiner Seite befinden und die entsprechende Seite täglich gecacht werden soll, damit die externen Inhalte korrekt angezeigt werden, müsste die Eingabe wie folgt aussehen:
Remove Query Strings: Aus – Wenn eingeschaltet, wird der Query-String, wie z.B. “?” oder “&”, aus statischen Ressourcen entfernt. Deaktivieren, da diese Einstellung veraltet ist. Moderne CDNs können Query-Strings bei Bedarf zwischenspeichern. Außerdem zeigen Speed Testing-Tools keine Warnungen mehr an, dass Query-Strings entfernt werden sollen.
Load Google Fonts Asynchronously: Aus – Wenn die Google Fonts lokal geladen werden, so wie ich es bei jeder Gelegenheit empfehle, dann ist diese Funktion nicht erforderlich.
Remove Google Fonts: Ein – Diese Einstellung verhindert das Laden der Google Fonts vom Google CDN auf der gesamten Website. Ich aktiviere diese Funktion aus DSGVO-Gründen.
Achtung:
Nur aktivieren, wenn du deine Fonts alle lokal hostest und sicher bist, dass du keine Plugins verwendest, die Google Fonts auf deiner Website einbinden. Nach dem Aktivieren sollte die Seite ausgiebig getestet werden, um zu vermeiden, dass sich die Darstellung stark verändert.
Remove WordPress Emoji: Ein – Entfernt eine zusätzliche JavaScript-Datei, die Emojis für ältere Browsern unterstützt. Besucher, die moderne Browser mit eigener Emoji-Unterstützung verwenden, werden keinen Unterschied feststellen.
Remove Noscript Tags: Aus – Entfernt man die <noscript> tags, führt das zwar zu einer geringeren Seitengröße, aber es verringert die Kompatibilität mit älteren Browsern, die kein JavaScript unterstützen, oder mit modernen Browsern, bei denen JS aus Sicherheitsgründen ausgeschaltet ist. Ohne JavaScript läuft die gesamte Seite nicht und daher lasse ich die tags drin.
Preload Featured Image: Ein – Insbesondere dann, wenn man Blog Beiträge auf der Website hat, macht es Sinn den Browser anzuweisen, das Featured Image eines Beitrags vorzuladen. Dadurch beginnt das Laden des Bildes noch bevor das Rendering der Seite startet. Verbessert den LCP-Wert und eliminiert das Bild als Rendering-blockierendes Element.
Lazy Load Images: Ein – Effizienter als das Lazy Load im WordPress Core, das beim Einschalten dieser Funktion automatisch deaktiviert wird. Außerdem bietet LS-Cache hier zusätzliche Features, w.z.B. Viewport Images (VPI Tab) und mit etwas zusätzlichem CSS, kann ein fade-in Effekt für die Bilder erstellt werden.
Was ist Lazy Load?
Lazy Load Images bewirkt, dass Bilder nur dann geladen werden, wenn sie im sich im sichtbaren Bereich des Bildschirms befinden. Die übrigen Bilder werden nur bei Bedarf geladen, wenn der Nutzer sie durch scrollen in den sichtbaren Bereich bewegt.
Wenn du den ladenden Bildern einen Einblend-Effekt verpassen möchtest, anstatt sie einfach nur aufpoppen zu lassen, dann kannst du die folgenden zwei CSS3-Codeschnipsel in deinem Customizer unter Zusätzliches CSS hinzufügen:
Fade-in für Lazy Load:
/* PART 1 - Before Lazy Load */
img[data-lazyloaded]{
opacity: 0;
}
/* PART 2 - Upon Lazy Load */
img.litespeed-loaded{
-webkit-transition: opacity .5s linear 0.2s;
-moz-transition: opacity .5s linear 0.2s;
transition: opacity .5s linear 0.2s;
opacity: 1;
}
Info:
Sofern der Browser CSS3 nicht unterstützt, wird der obige Code ignoriert!
Basic Image Placeholder: Wenn Lazy Load Images aktiviert ist, wird ein grauer Kasten als Platzhalter angezeigt, bis das Bild geladen ist. Sofern hier etwas kreativeres gewünscht ist, kann ein eigenes Base64-Bild hier angeben werden.
Um ein Bild ins Base64-Format umzuwandeln, kann z.B. dieser Base64 Converter genutzt werden.
Responsive Placeholder: Ein – Aktiviere diese Funktion wenn du Basic Image Placeholder verwendest, um Layout Shifts beim Laden der Bilder zu vermeiden.
Responsive Placeholder SVG: Hier kannst du ein SVG als responsives Platzhalter-Bild festlegen. Dieses wird dann von LS-Cache in ein base64 Platzhalter umgewandelt.
Responsive Placeholder Color: Sofern dir das Grau als Platzhalter-Farbe nichtgefällt, kannst du entweder den Color-Picker nutzen, um einen eigenen Farbton zu bestimmen, oder du gibst einen Hex-Code ein. Dazu einfach 2x ins R G B Feld klicken und voilà, der Hex-Code kann eingegeben werden.
LQIP Cloud Generator: Ein – Low Quality Image Placeholder (LQIP) ist ein QUIC.cloud-Dienst, mit dem eine unscharfe und verkleinerte Version des zu ladenden Originalbildes als Platzhalter generiert wird.
LQIP Quality: Ein – Wenn LQIP aktiv ist, kann hier die Qualität der erzeugten LQIPs bestimmt werden. Höhere Auflösung bedeutet größere Dateien, daher bleibe ich beim Standardwert von 4.
LQIP Minimum Dimensions: 150 x150 Pixel sind in Ordnung. Dies gilt nur, wenn der LQIP-Cloud Generator eingeschaltet ist, und legt fest, dass LQIP ab diesen Bilddimensionen verwendet wird.
Generate LQIP In Background: Ein – Verbessert die Ladezeiten für Erstbesucher auf der Website, also ein.
Lazy Load Iframes: Ein – Verzögertes Laden von Videos, Maps und anderen iFrames verbessert die Geschwindigkeit.
Add Missing Sizes: Ein – Das Festlegen einer eindeutigen Breite (width) und Höhe (height) für alle Bilder ist eine gute Praxis. Es reduziert Layoutverschiebungen, was sowohl die Benutzerfreundlichkeit, als auch die Seitenbewertung verbessert. Wenn diese Option aktiviert ist, fügt LS-Cache automatisch die Breite und Höhe zu jedem Bild hinzu, bei dem die Attribute fehlen.
Save Changes Jetzt noch die Einstellungen speichern.
QUIC.cloud erkennt bei jeder Post-URL, die zur Verarbeitung übermittelt wird, welche Bilder des Posts beim Laden im Viewport sichtbar wären. Diese Bilder werden als Viewport Images (oder VPI) bezeichnet.
Viewport Images: Ein – Auf jeden Fall einschalten, wenn Lazy Load aktiv ist! Diese Funktion verhindert, dass Bilder im sichtbaren Bereich (Above the Fold) verzögert geladen werden. Der QUIC.cloud VPI-Dienst generiert Viewport Images automatisch im Hintergrund auf QUIC.cloud-Servern, somit wird der eigene Server nicht beeinträchtigt.
Viewport Images Cron: Ein – Aktivieren, wenn Viewport Images aktiv ist, um die Viewport Images automatisch via Cron zu generieren, anstatt alle URLs manuell zur Verarbeitung übermitteln zu müssen.
Hammer Service!
Das automatische Erkennen von Bildern, die sich im Above the Fold Bereich befinden, um sie dann entsprechend vom Lazy Loading auszuschließen, ist ein wertvoller Service. Dieser Dienst verbraucht zwar Optimierungs-Ressourcen von QUIC.cloud, ist aber wirklich Gold wert und ist kostenlos nirgendwo anders zu bekommen!
Die VPI Optionen können Für jeden Beitrag einzeln angepasst werden. Dazu einfach einen Beitrag bearbeiten und in der Sidebar etwas nach unten scrollen. Dann findet man eine Metabox LiteSpeed Options.
Sofern der Beitrag bereits für VPI bearbeitet wurde, befinden sich Einträge in einem, oder beiden Feldern, Viewport Images und Viewport Images – Mobile. Diese Werte können nach Belieben angepasst werden. Bilder, die in diesen Einstellungen aufgeführt sind, werden nicht verzögert geladen.
Hier hat man folgende Optionen:
Bilder entfernen, die verzögert (Lazy Load) geladen werden sollen
Eine eigene Liste von Bildern hinzufügen, die für diese URL vom „Lazy Loading“ ausgeschlossen werden sollen
Alle Einträge aus den Feldern entfernen und eine Neuberechnung des VPI erzwingen
Wenn der Beitrag noch nicht für VPI verarbeitet wurde, sind beide Felder leer. In dem Fall können Bilder manuell zu den Feldern Viewport Images und/oder Viewport Images – Mobile hinzugefügt werden. LiteSpeed registriert diese Werte und sendet den Beitrag nicht zur VPI-Verarbeitung.
Zusätzlich zur „Viewport Images“-Einstellung, die Viewport-Bilder vom Lazy Load ausschließt, um den LCP-Wert zu verbessern, können die Bilder auch manuell ausgeschlossen werden.
Das mach u.a. bei Hintergrundbildern Sinn, da der Page Builder sie im CSS lädt und sie somit nicht verzögert geladen werden.
Lazy Load Image Excludes: Das Logo der Website ist ein Beispiel für Bilder, die in den meisten Fällen sofort geladen werden sollen und daher vom Lazy Load ausgeschlossen werden können.
Die Pfade der entsprechenden Bilder können hier Zeile für Zeile gelistet werden.
Lazy Load Image Class Name Excludes: Hier können Bilder mit einer bestimmten CSS-Klasse, vom Lazy Load ausgeschlossen werden. Wie immer eine pro Zeile eintragen.
Beispiel:
profil-bild profil-img
Lazy Load Image Parent Class Name Excludes: Hier können CSS-Parent-Classes eingegeben werden, um Bilder audzuschließen.
Lazy Load Iframe Class Name Excludes: Das selbe Spiel, wie eben, nur auf iFrames bezogen, anstatt auf Bilder.
Beispiel:
video-iframe
Lazy Load Iframe Parent Class Name Excludes: Das selbe Spiel, wie eben mit den Bildern, nur auf iFrames bezogen.
Lazy Load URI Excludes: Gilt für Bilder und iFrames. Die URIs (Uniform Resource Identifier)
Angenommen du hat folgende URIs:
1. /rezepte/bbq/
2. /rezepte/bbq/rippchen
3. /rezepte/bbq/spanferkel
4. /beliebt/rezepte/bbq/
Der String /rezepte/bbq/ stimmt mit allen vier URIs überein und würde sie alle vom Lazy Load auschließen.
Der String /rezepte/bbq/$ entspricht der Nummer 1 (da $ eine exakte Übereinstimmung anzeigt).
Der String ^/rezepte/bbq passt zu 1, 2 und 3 (weil ^ den Anfang des URIs angibt).
LQIP Excludes: Mit dieser Einstellung können Bilder von der LQIP Cloud Generator Funktion ausgeschlossen werden.
Gravatar Cache: Ein – Aktivieren, wenn Kommentare aktiviert sind, damit Gravatare lokal gecacht werden können.
Gravatar Cache Cron: Ein – Aktivieren, wenn Gravatar Cache aktiv ist.
Gravatar Cache TTL: 604800 – Diese Einstellung gibt an, wie lange (in Sekunden) Gravatare zwischengespeichert werden sollen.
Localize Resources: Ein – Großartige Funktion zur Lokalisierung externer JS-Dateien. Die lokalisierten Ressourcen werden automatisch lokal gespeichert, sodass sie nach Bedarf optimiert werden können.
Localization Files: Hier können zusätzlich URLs gelistet werden, um lokale Kopien von externen JavaScript-Ressourcen zu erstellen. Standardmäßig wird eine Liste mit empfohlenen URLs angeboten, aber es können beliebig viele Ressourcen hinzugefügt werden.
JS Delayed Includes: Hier können JavaScript-Dateinamen oder Teilstrings gelistet werden, um sicherzustellen, dass der aufgeführte JS immer verzögert wird.
Beispiel an Facebook Pixel:
fbevents.js
fbq(
/busting/facebook-tracking/
JS Excludes: Wenn in den JavaScript Settings, JS Minify oder JS Combine aktiv ist, können hier JS-Dateien gelistet werden (eine pro Zeile), die von den Optimierungsfunktionen ausgeschlossen werden sollen.
JS Deferred / Delayed Excludes: Wenn die Option „Load JS Deferred“ im Tab JS Settings aktiviert ist, gibt es möglicherweise einige JavaScript-Dateien, die nicht verzögert geladen werden sollen. Diese können hier gelistet werden.
Beispiel am Real Cookie Banner:
jquery.js
jquery.min.js
gtm.js
analytics.js
/wp-content/plugins/vendor-banner.pro.js
/wp-content/plugins/banner.pro.js
realCookieBanner
real-cookie-banner-pro-banner-js-before
Guest Mode JS Excludes: Wenn Guest Mode und Guest Mode Optimization in den General Settings aktiv sind, dann können hier JavaScript-Dateien oder Inline-JS-Code gelistet werden, um diese von der Optimierung auszuschließen.
URI Excludes: Wenn es Seiten gibt, die Sie von der Optimierung ausgeschlossen werden sollen, können Sie sie hier die URIs gelistet werden. Wie das Listen von URIs funktioniert, hatte ich bereits in den Cache Einstellungen und im Tab Media Excludes beschrieben.
Optimize for Guests Only: Ein – Damit CSS- und JavaScript-Optimierungen nur für nicht eingeloggte Besucher durchgeführt werden. Nur deaktivieren, wenn sich regelmäßig Benutzer auf der Website anmelden, w.z.B. bei einer Membership Site.
Role Excludes: Sofern bestimmte Benutzerrollen von jeglicher Art der Optimierung ausgeschlossen werden sollen, einfach die entsprechende Checkbox aktivieren. Das könnte z.B. als Administrator bei Testings dienlich sein. Ansonsten sehe ich hier Grund für Handlungsbedarf…
CSS Excludes: Wenn im Tab CSS Settings die die Funktionen, CSS Minify oder CSS Combine aktiv sind, können hier CSS-Dateien ausgeschlossen werden. Die Dateien werden gelistet, wie immer eine pro Zeile.
Beispiel Block quotes:
.wp-block-quote
blockquote
UCSS File Excludes and Inline: Wenn eine bestimmte CSS-Datei nicht in die UCSS-Berechnung einbezogen werden soll, kann die entsprechende Datei hier gelistet werden, damit das CSS stattdessen im HTML inline hinzugefügt wird.
Beispiel am Astra Theme:
/uploads/astra/astra-theme-dynamic-css
/uploads/astra-addon/astra-addon-dynamic-css
UCSS Selector Allowlist: Hier können CSS-Selektoren (IDs oder Klassen) gelistet werden, die grundsätzlich in das berechnete Unique CSS aufgenommen werden sollen.
UCSS URI Excludes: Hier können die URIs (nicht URLs) von Seiten gelistet werden, die bei der UCSS-Optimierung nicht berücksichtigt werden sollen. Beispiele zum Auflisten von URIs findet man u.a. im Media Excludes Tab.
Separate CCSS Cache Post Types: Standardmäßig wird für jeden Beitragstyp (Seiten, Beiträge, oder Custom Post Types wie Produkte) das jeweilige Critical CSS generiert und gespeichert. Sofern man jedoch Beitragstypen mit Elementen unterschiedlicher Formatierung hat, dann reicht dass gespeicherte CSS nicht aus.
Dieser Custom Post Type müsse in der Box hinzugefügt werden, damit für jedes Element dieses Beitragstyps kritisches CSS generiert werden kann.
Separate CCSS Cache URIs: Wenn es auf der Website Beitragstypen gibt, dessen Seiten anderen Formatierungsregeln folgen, wie der Rest des Beitragstyps, können die URIs (oder Teil-URIs) für diese Seiten in diesem Feld aufgelistet werden. Für diese Seiten werden dann separate kritische CSS-Dateien erstellt.
Die URIs werden mit der Servervariablen REQUEST_URI verglichen. Syntax Beispiele findet man u.a. im Media Excludes Tab.
Critical CSS Rules: Wenn die Option Load CSS Asynchronously im Tab CSS Settings aktiviert ist, wird wichtiges CSS automatisch generiert. Ggf. müssen zusätzliche Definitionen bestimmt werden, die zuerst geladen werden müssen, um den Inhalt des Above the Fold Bereichs richtig darzustellen. Diese Regeln können dem Stylesheet entnommen und hier in eingeben werden.