Geschwindigkeit ist alles
Es gibt ja für alles Untersuchungen. Auch dafür, wie sich die Ladezeit einer Website auf die mögliche Absprungrate der Besucher auswirkt. Und man mag es kaum glauben, aber die Erkenntnis ist, dass je länger eine Website zum Laden benötigt, desto höher ist die Chance, dass der Besucher den Tab schließt. Unglaublich.
Man sollte also alles daran setzen, dass eine Website so schnell wie möglich ausgeliefert und vor allem angezeigt wird. Mal abgesehen, dass man dafür sorgen sollte, dass Elemente im sichtbaren Bereich zuerst gerendert werden und schon gar nicht während des Ladens hin- und herflippen sollten, ist ein weiterer Faktor, den man ganz gut beeinflussen kann, die Anzahl und vor allem die Größe der Ressourcen wie Stylesheets und JavaScript so gering wie möglich zu halten.
Mit TYPO3 10.3 ist hierfür der AssetCollector integriert worden. Mit diesem können Skripte und Stylesheets in Fluid-Dateien mit den Viewhelpern f:asset.script und f:asset.css dem Renderingprozess hinzugefügt werden. Und das ähnlich dem schon in 8.6 hinzugefügten renderAssetsForRequest, mit dem man über die beiden Fluid-Sections HeaderAssets und FooterAssets entsprechenden Code rausrendern konnte.
Der entscheidende Unterschied ist, dass, wie der Name schon vermuten lässt, der AssetCollector die Stylesheets und Skripte erstmal sammelt und dann nur einmal im Rendering inkludiert. Heißt, ich kann in diversen Fluid-Dateien mit dem gleichen Namen auf die gleiche JavaScript-Datei referenzieren, die ich zum Beispiel für einen Slider benötige, die dann aber am Ende des Dokuments nur einmal per Script-Tag im Dokument hinterlegt wird.
Ein weiterer Vorteil ist, dass man auf diese Art und Weise dafür sorgen kann, dass nur benötigte Ressourcen an den Browser gesendet werden und nicht ein JavaScript-Plugin für ein Akkordeon, welches gar nicht auf der Seite vorhanden ist. Natürlich hebelt das ein wenig das Konzept aus, dass man eigentlich immer die gleichen Ressourcen an den Browser sendet, damit dieser diese auf der zweiten Seite gar nicht mehr anfordert, weil er sie dann aus seinem Cache nimmt.
Aber mit der gleichzeitigen Verwendung von HTTP/2, das dafür sorgt, dass die Ressourcen zum Rendern der Website an den Browser ausgeliefert werden, bevor dieser überhaupt weiß, dass er sie benötigt, wird in Verbindung mit der geringen Datengröße trotzdem ein Geschwindigkeitsvorteil erzielt, der sich vor allem in einem schnelleren Rendering der Seite bemerkbar macht. Dabei ist es gar nicht schlimm, dass die Ressourcen nicht im Concatenate- oder Komprimierungs-Prozess von TYPO3 integriert werden, wie man das ja bisher gewohnt war, wenn man seine Ressourcen mittels TypoScript eingebunden hat.
Und schon hat man wieder ein paar mehr Besucher seiner Website glücklicher gemacht.
Und ja, ich weiß, hier auf der Seite habe ich leider noch kein HTTP/2 aktiviert. Liegt nicht an mir. Tut mir leid.