Die neue Version 1.1.0 von IndexReloaded hat Neuerungen, welche die Performance von WordPress-Webseiten weiter verbessert.
Viele Website benutzen CSS oder JavaScript, das auf externen Servern ist.
Seiten, die solche Ressourcen verwenden können nicht vollständig vom Verketten von JS und CSS profitieren.
Neu kann IndexReloaded externes CSS und JS lokal abspeichern und es so in den Prozeß zur Erstellung von verkettetem JavaScript, CSS und CCSS (Critical CSS) miteinbeziehen.
Das Resultat sind kürzere Ladezeiten der Website.
Das Feature kann im Backend unter „Settings->Rules for CSS and JS processing“ aktiviert oder deaktiviert (default) werden.
Ebenfalls kann dort die Zeit in Tagen, bis die externen Files erneut gecheckt werden, eingestellt werden.
Im Backend unter Overview sehen Sie ob und wieviele externe CSS und JS-Dateien im lokalen Cache vorhanden sind.
Die damit verbundene „Migration“ von „fremden Daten“ führt in dem Sinn zu einer eindeutigen Verbesserung der Leistungsfähigkeit lokaler Systeme. 😀
Auch im Overview-Panel findet sich ein neuer Button „Reveal Cache„, er zeigt eine Liste im ObjectCache gecachter Webseiten an.
Es wird unterschieden zwischen „Cached pages used by Indexreloaded“ und „Pages prepared for CCSS“.
Erstere sind vollständig gecachte Seiten, für die CCSS erstellt ist.
Diese können über das -icon gezielt aus dem Cache entfernt werden.
„Pages prepared for CCSS“ sind Seiten, für welche nur das Server-generierte HTML-Model vorliegt.
Das vom Client erstellte HTML-Model wurde noch nicht an den Server zur Verarbeitung (und Erstellung von CCSS) gesendet.
Typischerweise entstehen diese Cache-Einträge durch Besuche von Suchmaschinen wie Google oder Bing.
Diese verwenden kein JavaScript und senden somit das client-generierte HTML nicht an den Server zurück.
Für versteckte, also gecachte Sachen gilt „Vertrauen ist gut, Kontrolle ist besser“. Wir werden diesem Umstand mit „Reveal cached pages“ gerechter als zuvor.
Auch findet sich nun im Backend, in den Settings im oberen linken Bereich der Seite, ein praktischer Link zurück zur Overview.
Das client-generierte HTML wird per Default 2 Sekunden nach dem vollständigen Laden der Webseite an den Server gesendet.
Wer nun die JavaScript-Library „ko“ nutzt muß länger als 2 Sekunden warten, bis die Webseite alle von „ko“ erstellten HTML-Elemente enthält.
Vielleicht gibt es weitere „Slowmotion-Solutions“ – das nehmen wir an – aber wir kennen bislang nur „ko“ – es wird vom Plugin „Wallets“ eingesetzt.
Für „ko“ setzen wir den Delay in IndexReloaded 1.1.0 auf 6 Sekunden, was empirisch gesehen genügt, um vom Client eine vollständige Version der endgültigen Website zu erhalten und damit gültiges CCSS zu bilden.
CCSS sehen wir mittlerweile als dynamisches und sequentiell aufgebautes Resultat, das nach der ersten Erstellung von CCSS nicht abschließend genügend sein muss.
Nehmen wir das Beispiel einer „Einkaufskorb“-Seite in einem Webshop:
Der „Einkaufkorb“ kann leer oder voll sein.
Wird das erste CCSS ab einem „leeren Einkaufkorb“ erstellt, so wird das funktionieren, solange der Einkaufskorb leer ist.
Aber wenn ein Benutzer Produkte kauft und sich dann den Einkaufskorb ansieht, wird dieses CCSS das zusätzliche HTML der Webpage nicht abdecken.
IndexReloaded 1.1.0 ist auf diese Situation nun vorbereitet und generiert CCSS in einer solchen Situation neu.
Mit CCSS gilt „der Pfad ist das Ziel“.
Das gilt nicht nur für den DOM-Path, es gilt „Overall“
2 beseitigte Bugs
Gerade bei dieser Anpassung ist uns aufgefallen, daß HTML welches in Scripts vom Typ „text/html“ in der Webpage vorliegt, ungleich zum HTML in Scripts vom Typ „text/template“, nicht ins HTML-Model zur Erzeugung von CCSS miteinbezogen wurde.
Dieser Bug wurde in 1.1.0 beseitigt.
Offenbar wurden auch Inline-Scripts, die direkt nach extern gehosteten CSS oder JS-Dateien im Seitenquelltext vermerkt sind, nicht in die Verarbeitung beim Verketten miteinbezogen.
Auch das wurde in Version 1.1.0 korrigiert.
CDATA ist tot, lang lebe das Nonce
Wir sind darauf gestoßen, als wir für die Verarbeitung von Inline-Scripts das Ausschlußkriterium CDATA ersetzten durch das Ausschlußkriterium „nonce“.
Mit dem Ausschluß von CDATA wurde nicht jedes Script mit nonces erfasst – auch sind CDATA-Einträge nicht auf jeder Website als solche im Seitenquelltext markiert.
Das mit CDATA verbundene Problem sind Werte, die oft oder jedesmal ändern und somit zu einer Flut von generierten JS-Dateien führen können.
Typischerweise sind diese als „nonce“ in Inline-JavaScript erkennbar.
Die Ausnahme des Werts „WordfenceTestMonBot“ im Inline-JS vom Plugin „WordFence“ zeigt, daß die Regel für „nonce“ als nicht allgemeingültig gehalten werden kann.
Sehen Sie eine übermäßige Anzahl von JS-Dateien im IndexReloaded-Backend, unter Overview, so sollten Sie den „Inline-JS Bösewicht“ identifizieren und in den Settings von IndexReloaded unter den Excludes auflisten.
Diese Identifikaton erfolgt am besten über den Vergleich von JS-Dateien mit identischer oder fast identischer Größe.
Der Nutzen vom JavaScript Filelinks besteht mitunter darin, daß diese Dateien über längere Zeit, das heisst mehrere Tage, und über mehrere Webseiten genutzt werden können
Automatisch generierte <link rel=“preload“-Einträge für jQuery, generiertes CSS und JS verhelfen in Version 1.1.0 ebenfalls neu zu besserer Performance.
Diese Änderung ist nicht ganz unwesentlich, denn damit kann bereits mit der Free-Version von IndexReloaded 1.1.0 erreicht werden, daß sich PageSpeed Insights nicht mehr über „render-blocking elements“ beschwert.
Fürs Verzögerte Laden von JavaScript hat Version 1.1.0 nun die Möglichkeit auch Inline-JS verzögert zu laden.
Das erfolgt durch die Umwandlung des Inline-JS in base64-codierten Text, der dann als src (Source) verzögert (mit defer im HTML Script-tag) geladen wird.
Wird aber ein Inline-JS über die Excludes-Liste ausgeschlossen (und nicht über eine nonce-Eigenschaft) so wird das Original Inline-JS belassen, wie es ist.
Bleibt zu bemerken, daß Server, welche die „Header set Content-Security-Policy“-Direktive in der Apache-Konfiguration nutzen, zum entsprechenden Wert für „script-src“ einen Eintrag data für data enthalten müssen, Beispiel: „data: data;“
Mit all diesen Anpassungen konnte die Liste der empfohlenen Excludes merkbar reduziert werden, was das Erstinstallieren von IndexReloaded erleichtert.