Für noch mehr Website-Performance: INT-Objekte im Admin-Panel von TYPO3 10 analysieren
Aus dem Changelog:
Feature: #88441 – Show configuration of USER_INT objects in adminpanelA new panel “USER_INT” is introduced in the info module of the admin panel, which lists the basic configuration of each USER_INT present on the current page.
Wer den Change nicht kennt, übersieht das neue Feld im Admin-Panel vielleicht sogar.
Warum ist dieses Feature so interessant?
Bei unseren neuen Tarifen haben wir ein ganz besonderes Augenmerk auf das Thema Performance gelegt. Doch selbst bei sehr viel Power unter der Haube kann es sein, dass eine Seite noch nicht ausreichend schnell ist. In solchen Fällen solltet ihr einen Blick auf die Konfiguration der Anwendung werfen, um mögliche Blocker zu finden. Wenn es um eine TYPO3 Installation geht, nutze ich dafür das Admin-Panel. Es zeigt mir u. a. die Seitengenerierungszeit auf dem Server an. Im Gegensatz zu „externen“ Messungen der TTFB (Time-to-first-Byte) kann ich alle netzwerkseitigen Einflüsse damit außer Acht lassen. Ob z. B. meine WLAN-Verbindung gerade stark belastet ist, ist für die Messung auf dem Server egal. Gibt es große Abweichungen zwischen der Seitengenerierungszeit im Admin-Panel und der gemessenen TTFB, schaue ich da natürlich genauer.
Butter bei die Fische – wie nutze ich das?
Als Basis dient eine TYPO3 10.4.0-Installation, in der neben dem Introduction-Package und dem Bootstrap-Package eine kleine Test-Extension von mir installiert ist. Diese dient nur dazu, das System künstlich zu verlangsamen. Mithilfe des Admin-Panels werden wir diese Extension „finden“ und uns anschauen, wie genau sie die Seite verlangsamt.
Um das Admin-Panel zu nutzen, müsst ihr nur die Systemextension „adminpanel“ im Extensionmanager aktivieren und eine Zeile TypoScript ins Setup schreiben:
config.admPanel = 1Beim Introduction-Package braucht ihr diesen Eintrag übrigens nicht machen, da er schon gesetzt ist. Im Frontend unserer Seite erscheint nun unten rechts ein kleines Icon für das Admin-Panel:
Achtung: Damit das Admin-Panel angezeigt werden kann, müsst ihr im Backend eingeloggt sein und das Frontend über die gleiche Domain aufrufen. Ein Klick auf das Icon und ihr bekommt direkt angezeigt, wie lange TYPO3 gebraucht hat, um die Seite zu generieren. In diesem Fall 1870ms:
Das ist natürlich zu viel! Aber es war der erste Aufruf des Frontends. Es mussten also noch alle möglichen Caches generiert werden. Vielleicht hilft ein zweiter Aufruf?
Leider nur bedingt. Mit 1539ms sind wir etwas schneller, aber nicht wirklich schnell. Vielleicht ist der Seitencache mittels config.no_cache = 1 oder etwas ähnlichem deaktiviert? Um das herauszufinden, klappen wir also den Info-Tab aus:
Auch das scheint nicht der Fall zu sein. Die Seite ist laut TYPO3 grundsätzlich erst mal gecached. Das bedeutet allerdings nicht, dass nicht doch noch Inhalte generiert werden. Mit COA_INT und USER_INT habe ich die Möglichkeit, bestimmte Elemente vom Caching rauszunehmen. TYPO3 generiert dann zwar den restlichen Content und legt diesen im Cache ab, die _INT-Elemente werden aber nur als Platzhalter im Cache eingefügt. Beim Aufruf werden sie wieder komplett neu generiert – und zwar bei jedem Aufruf!
Dass es solche Elemente auf der Seite gibt, sehe ich ebenfalls im Admin-Panel. Direkt unter der Angabe zum Seitencache finden wir „Count of USER_INT objects“ mit dem Wert 1. Bis hierhin ist der Informationsgehalt noch identisch zu TYPO3 9 LTS. Ab hier müsste ich mich nun z. B. über den TypoScript-Object-Browser auf die Suche nach allen *_INT-Objekten begeben, um dazwischen jenes zu finden, das tatsächlich auf der Seite eingebunden ist. In TYPO3 10 LTS kann ich eine Abkürzung nehmen, indem ich den USER_INT-Tab oben aufrufe:
Zugegeben: Als ich meine minimalistische Test-Extension schrieb, habe ich jeglicher Kreativität abgeschworen und sehr sprechende Bezeichnungen verwendet. In der echten Welt werde ich hier vermutlich nicht direkt wissen, was im Hintergrund passiert. Aber: Ich weiß, welche Funktion aufgerufen wird und kann flott danach suchen. Wenn ihr eine IDE (integrierte Entwicklungsumgebung) wie PHPStorm verwendet, werdet ihr die Funktionen dort vermutlich am schnellsten finden. Da ich bei der Analyse von Kundensystemen i.d.R. direkt auf dem Server arbeite, sei hier einmal mein Weg über einen kurzen grep gezeigt:
pXXXXXX:/html/typo3 > grep delayAndPrintTime typo3conf/ext/* -rl
typo3conf/ext/mw_performance_test/Classes/TimeDelay.php
typo3conf/ext/mw_performance_test/Configuration/TypoScript/setup.typoscriptDer Inhalt der setup.typoscript ist überschaubar:
page.100 = USER_INT
page.100 {
userFunc = Mittwald\MwPerformanceTest\TimeDelay->delayAndPrintTime
}
Hier binde ich einfach ein USER_INT-Objekt auf der Seite ein, welches die delayAndPrintTime-Funktion aufruft. Diesen Teil könnte man auch über den TypoScript-Objectbrowser finden. Dazu rufen wir das Template-Modul im Backend auf, gehen auf die zu testende Seite (in meinem Fall die Root-Seite, da ich keine Unterseite mit eigenem Template eingemessen habe), wählen den TypoScript-Objectbrowser aus und suchen im Setup nach „_INT“:
Wir sehen: Es gibt zwei USER_INT-Objekte. Vom fluidAjaxWidgetResponse sollten wir – wie von jedem anderem Ajax-Response auch – meist die Finger lassen. Diese sind gewollt ungecached. Bei unserem page.100-Element sieht es anders aus: Hier sollten wir uns die Frage stellen, ob dieses Content-Element wirklich ungecached ausgeliefert werden muss. Ist das nicht der Fall, können wir es umstellen. Aus einem USER_INT-Objekt machen wir ein USER-Objekt, aus einem COA_INT ein COA-Objekt.
Machen wir das doch einmal für unser konkretes Element, indem wir folgendes TypoScript-Snippet im Backend in unser Setup schreiben: page.100 = USER
Langfristig wäre es für meine Test-Extension sauber, wenn wir die setup.typoscript anpassen.
Egal, welchen der beiden Wege wir wählen, am Ende sollte unsere Seite schneller sein. Zu beachten ist hier, dass der erste Aufruf nach der Änderung noch langsam sein wird. Der Cache muss erst aufgebaut werden. Der zweite ist dann rasend schnell. ;-)
Die über delayAndPrintTime wird übrigens wirklich nur über einen usleep 1,5 Sekunden gewartet und dann die Serverzeit ausgegeben:
<?php
namespace Mittwald\MwPerformanceTest;
class TimeDelay {
/**
* Output the current time in white letters and delay the request
*
* @return string HTML output, showing the current server time.
*/
public function delayAndPrintTime()
{
usleep(1500000);
return '<p style="color: white;">time of last execution: ' . date('H:i:s') . '</p><br />';
}
}
Sobald ich also aus page.100 ein USER-Objekt mache, würde die Zeit auf der Seite nicht mehr aktualisiert werden. Rein logisch sollte das Element in der Tat nicht gecached werden. Dem stehen aber andere Faktoren entgegen:
1. Die Ausgabe der Uhrzeit ist für einen Websitebesucher kein Mehrwert.
2. Die Ausgabe wird sogar versteckt (weiße Schrift auf weißem Hintergrund). Ich verarbeite also Daten, von denen der Benutzer am Ende des Tages nichts hat.
3. Ich mache eine unnötige Operation (usleep), die für die eigentliche Funktion (Ausgabe der Uhrzeit) keine Relevanz hat.
Anhand dieser Kriterien sollte man im Einzelfall prüfen, ob die Implementierung der ungecachten Funktionen wirklich in der Form notwendig ist. Alternativ könnte man das Element auch per Ajax nachladen. Für die User-Experience wäre das bedeutend besser, da die Seite erst mal sehr schnell angezeigt wird und nur ein einzelnes Element später kommt.
Wo wir gerade davon sprechen: In TYPO3 10 ist das lazy-loading für Bilder jetzt bei Fluid-Styled-Content standardmäßig aktiv. Ich glaube, dazu schreibe ich noch einen Blog-Artikel… :-)
Tipp: Ihr könnt diese Funktion auch unter TYPO3 9 LTS nutzen, indem ihr die folgende Extension installiert: https://github.com/IndyIndyIndy/adminpanel_int
TYPO3 Hosting wie du es dir wünschst
Du möchtest mehr von diesem TYPO3 Experten-Wissen? Wünschst dir dazu vielleicht auch kostenfreie ELTS-Versionen oder coole TYPO3 Extensions? Das und vieles mehr erhältst du bei Mittwald. Wir sind TYPO3 Hoster der ersten Stunde. Überzeug dich selbst und teste dein TYPO3 30 Tage kostenlos.
Disclaimer: Die Beispielseite ist eine über den Softwaremanager installierte TYPO3 10.4 LTS-Version auf einem Agentur-Server. Das Projekt ist dabei ein CMS-Hosting in der kleinstmöglichen Konfiguration (2,50 EUR pro Monat). Als Cache-Backend kommt der APCu im Zusammenspiel mit dem OpCache zum Einsatz, der mit einem Klick im Kundencenter aktiviert werden kann: https://www.mittwald.de/faq/tipps-und-tricks/typo3/apcu-mit-typo3-verwenden
Kommentar hinzufügen