Die Idee
Beim Laden der Suchseiten wird etwa 50% der Rechenzeit für Dinge benötigt, die der Nutzer eigentlich nicht direkt braucht. Für den Nutzer sind initial lediglich die Suchergebnisse relevant. Weitere Informationen wie die Marker und Gebietsbuttons auf der Karte oder die Gebiets- und Eigenschaftslinks unter den Suchergebnissen können verzögert nachgeladen werden. Diese brauchen nämlich in der Summe einen großen Teil der Rechenzeit.
Wenn man also diese Daten in weiteren Requests nachladen könnte, würde man erreichen, dass das initiale Seitenladen der Suchseite viel weniger Zeit in Anspruch nimmt. Das würde Google auch sehr gut bewerten.
Kommen Suchseiten nicht aus dem Cache?
Normalerweise kommen Suchseiten aus dem Cache, solange man im Portal nicht eingeloggt ist. Voraussetzung ist aber auch, dass genau diese Suchseite in den letzten Stunden schonmal aufgerufen wurde und der Cache seitdem nicht zurückgesetzt wurde.
Wenn ein Eintrag gespeichert wird, dann wird immer der komplette Suchseiten-Cache zurückgesetzt, da der Eintrag ja auf extrem vielen Suchseiten vorkommen könnte. Für den Fall, dass sich das Portal im “Performance-Emergency-Zustand” befindet, also die Suchseiten ziemlich lange laden, wird der Suchseiten-Cache nicht zurückgesetzt.
Der Cache macht schon einen großen Unterschied: Suchseiten können 600ms oder 1500ms laden, aus dem Cache dauert es dann nur 50-100ms.
Da sich Crawler (Bots) an der Sitemap orientieren und somit auch viele Suchseiten aufrufen, die normale Nutzer eher selten aufrufen, kommt hier eine hohe Belastung der Server zustande.
Das kann man wohl nur lösen, indem man die Performance für Suchseiten verbessert, wenn sie nicht aus dem Cache kommen.
Suchseiten-Requests aufgetrennt
Hiervon haben wir uns am meisten versprochen, allerdings ist per Google Pagespeed keine richtige Verbesserung sichtbar. Die Messergebnisse sind annähernd identisch, was schwankenden Messwerten geschuldet sein kann.
Was allerdings positiv ist: Die Suchseite ist schneller für den Nutzer sichtbar. Auf familienausflug.info hat die Suchseite in den letzten 30 Tagen im Schnitt 0,773s gebraucht, in einem Zeitraum von 4 Stunden nach dem Deployment nur 0,395s. Dafür haben dann die Requests für die Gebiets- und Eigenschaftslinks im Schnitt 0,143s gebraucht und die für die Karten-Marker-Daten 0,338s.
Eintragsbilder in eigenem Cache
Vor der Idee, die Suchseiten-Requests aufzutrennen, hatte das Laden der Bild-Urls für die Eintrags-Slider auf der Suchseite z. B. auf kinderhotel 19% der Rechenzeit benötigt.
Am 5.11. ging mit dem Update 13.2.7 dann der Cache für die Bild-Urls live. Nach diesem Update sind die Suchseiten also um 1/5 schneller geworden, da die Bild-Urls nur noch extrem selten aus der Datenbank geladen werden müssen.
GZIP wieder aktiviert
Über das Tool Lighthouse ist uns aufgefallen, dass HTML, CSS und JavaScript nicht mehr per GZIP komprimiert wurde:
Das konnten wir aber wieder auf unserem vorgeschalteten NGINX-Server einschalten, wodurch diese großen Dateien weitaus schneller heruntergeladen werden. Vor allem auf Mobilgeräten und in Performance-Tests macht sich das bemerkbar. Da ist es wohl weitaus effizienter, eine komprimierte Version der Seite herunterzuladen, die dann durch den Browser sehr schnell entpackt wird.
Contentblock-Bilder herunterskalieren
Außerdem ist ein Feature live gegangen, bei dem die Größen der Bild-Attribute width und height auch vom Image-Resizer verwendet werden. Dadurch werden die Bilder in der richtigen Größe (herunterskaliert) geladen:
Beim Bearbeiten des Bilds im Contentblock kann man diese Größe setzen:
Das macht vor allem auf der Startseite einen Unterschied, da dort häufig viele kleine Bilder in Contentblöcken eingebettet sind, wo es ausreicht, diese in einer kleinen Größe zu laden.
Leave a Reply