Drei Ursachen decken fast alles ab
Wenn wir eine langsame TYPO3-Installation übernehmen, ist der Befund selten exotisch. Fast immer liegt es an einem von drei Dingen: Die Seite kommt nicht aus dem Cache. Bilder werden in Originalgröße ausgeliefert. Oder es lädt auf jeder Seite Code, den nur eine einzige Seite braucht.
Alle drei sind gut zu finden, wenn man weiß, wo man nachsieht, und alle drei sind Konfigurationsfragen, keine Umbauprojekte. Deshalb steht am Anfang eine Messung und keine Aufwandsschätzung.
Der Seitencache ist der größte Hebel
TYPO3 speichert die fertig gerenderte Seite zwischen und liefert sie beim nächsten Aufruf direkt aus. Das ist der wichtigste einzelne Grund, warum eine TYPO3-Seite schnell sein kann, und die häufigste Stelle, an der Geschwindigkeit verloren geht.
Ausgehebelt wird der Cache leicht: ein Inhaltselement, das bewusst unzwischengespeichert rendert, ein Plugin, das seine Ausgabe je Aufruf neu berechnet, eine Erweiterung, die eine Sitzung startet und die Seite damit für alle personalisiert. Der Effekt fällt in der Entwicklung nicht auf, weil dort ohnehin ohne Cache gearbeitet wird. Er fällt auch im Test nicht auf. Er fällt auf, wenn Verkehr kommt.
Wir sehen deshalb zuerst nach, welche Seiten überhaupt zwischengespeichert werden und welches Element das verhindert. Häufig ist es genau eines, und häufig lässt es sich so umbauen, dass nur der dynamische Teil unzwischengespeichert bleibt statt der ganzen Seite. Was dahintersteckt, steht im Glossar unter Caching.
Bilder: nicht kleiner, sondern richtig
Die Dateiverwaltung von TYPO3 rechnet Bilder automatisch in die gebrauchten Größen um und legt die Ergebnisse ab. Das funktioniert gut, sobald es konfiguriert ist, und gar nicht, wenn im Template die Originaldatei ausgegeben wird.
Drei Dinge prüfen wir hier: ob überhaupt umgerechnet wird, ob moderne Formate ausgeliefert werden, und ob an jedem Bild Breite und Höhe im Markup stehen. Der letzte Punkt hat mit der Dateigröße nichts zu tun und ist trotzdem oft der sichtbarste: Ohne Maße weiß der Browser nicht, wie viel Platz er reservieren soll, und das Layout springt, während die Seite lädt. Genau das misst Google als Layoutverschiebung.
Was auf welcher Seite lädt
Der dritte Klassiker sind Assets, die per TypoScript global eingebunden sind. Ein Karussell-Skript, das nur die Startseite braucht. Ein Stylesheet für ein Formular, das auf einer einzigen Unterseite steht. Eine Icon-Sammlung, von der drei Symbole benutzt werden.
Das entsteht nicht aus Nachlässigkeit, sondern weil global einbinden der kürzere Weg ist und beim Bauen niemanden stört. Aufräumen heißt hier: nachsehen, was tatsächlich gebraucht wird, und den Rest dorthin verschieben, wo er hingehört.
Messen, und zwar richtig
Beim Optimieren ist die Messung die eigentliche Arbeit. Wer zwei Varianten nacheinander misst, misst zu einem erheblichen Teil die Tagesform der Maschine, auf der gemessen wird.
Wir arbeiten deshalb so: Der Ausgangswert wird auf Googles Infrastruktur erhoben, nicht auf einem Entwicklungsrechner. Vergleiche zwischen zwei Ständen laufen verschränkt, also abwechselnd A, B, A, B, und über mehrere Durchläufe, aus denen der Median genommen wird. Blockweise gemessen wandert jede Lastschwankung der Maschine vollständig in den Vergleich und man optimiert gegen Rauschen.
Das klingt umständlich und ist der Unterschied zwischen einer belegten Verbesserung und einer behaupteten.
Was danach passiert
Eine Optimierung ist ein Stichtag, kein Zustand. Inhalte wachsen, Erweiterungen bekommen Updates, irgendwann baut jemand ein Skript für eine Kampagne ein und entfernt es nicht mehr.
Damit das auffällt, bevor es jemand meldet, gehört eine laufende Messung dazu. Wir setzen dafür SiteSentry ein, das kostenlose Werkzeug der aceArt GmbH: Es misst regelmäßig über die offizielle Google-Schnittstelle und meldet sich, wenn ein Wert unter deine Schwelle fällt.