• Wenn eine Website langsam lädt, sind die Besucher:innen dazu geneigt, die Seite vorzeitig zu verlassen. Eine hohe Absprungrate führt zu einem Verlust potenzieller Kund:innen und beeinträchtigt den Erfolg der Online-Präsenz [1].
  Das hat auch Google in einem Beitrag noch einmal verdeutlicht. Schon bei einer Ladezeit zwischen 1-3 Sekunden steigt die Wahrscheinlichkeit eines vorzeitigen Absprungs um 32% [2]!
• Die Benutzererfahrung wird allgemein negativ beeinflusst, wenn Besucher:innen nicht auf gewünschte Informationen zugreifen können. Das kann dazu führen, dass das Image Ihres Unternehmens, Ihrer Marke oder Ihres Produktes negativ bewertet wird.
• Suchmaschinen wie Google bewerten die Ladezeit einer Website als sehr wichtigen Ranking-Faktor. Somit hat die Ladezeit einen direkten Einfluss auf die Suchmaschinenoptimierung (SEO).

Aus diesem Grund ist es wichtig, die Performance einer Website laufend zu überwachen und vorausschauend zu optimieren. Nachfolgend wollen wir uns näher ansehen, welche Maßnahmen getroffen werden müssen, um Webanwendungen aus Performance-Sicht für eine:n Nutzer:in bestmöglich auszuliefern.

Wir treffen die Annahme, dass unsere Anwendung am Frontend performancetechnisch weitest möglich optimiert wurde. Damit ist gemeint, dass der sichtbare Teil der Anwendung überprüft und unterschiedliche Optimierungstechniken angewendet wurden. Das betrifft beispielsweise die Verwendung von modernen Dateiformaten und Komprimierung der visuellen Bestandteile, also Bilder, Videos und Layout Styles (CSS) sowie Ausführungsoptimierungen von dynamischen Inhalten (JavaScript). Dieses umfangreiche Thema behandeln wir in weiteren Blogbeiträgen genauer.

Was kann man machen, wenn also das Frontend bereits bestmöglich optimiert wurde oder hier keine nennenswerten Ladezeiten Verbesserungen mehr erzielt werden können? In diesem Fall sehen wir uns an, wie schnell der Webserver die Anwendung ausliefert und ob hier Engpässe erkannt werden können.

Es macht zuallererst Sinn in einer Bestandsaufnahme zu überprüfen, bei welchem Host System die Anwendung bzw. die Website liegt, wie das zugrunde liegende Server System funktioniert und wie die Anwendung strukturell aus Backend-Sicht aufgebaut ist. Vor allem aber interessiert uns, welche Datenbank eingesetzt wird und wie stark diese ausgelastet ist. Da im Normalfall immer irgendwo statische sowie dynamische Daten gespeichert und ausgeliefert werden müssen, stellt eine Datenbank häufig ein Nadelöhr in einer Webapplikation dar, vor allem wenn mit der Zeit die Besucherzahlen, der Traffic sowie die Datenmengen steigen.

Jetzt aber der Reihe nach: Wir werden darauf aufmerksam gemacht, dass es Performance Probleme gibt mit einer Webanwendung, entweder von Betreiber:innen oder Besucher:innen der Website. Optimalerweise aber von Monitoring Systemen automatisch über Benachrichtigungen (Alert-System) an Ihre Online-Agentur. Ein Beispiel dafür sind Server-Monitoring Systeme wie Grafana oder Prometheus. Aber auch Analysetools wie Google Analytics können hier Hinweise liefern.

Anhand von Page Speed Scannern wie beispielsweise Google PageSpeed Insights erfahren wir, dass die Server Response Time, spezifischer die Time to First Byte, miserabel ist. Als zeitlichen Richtwert kann man hier von rund einer halben Sekunde ausgehen (PageSpeed Insight sieht Ladezeiten ab 600 Millisekunden als problematisch, Stand 2023).

Falls die Webapplikation noch keine Möglichkeit zum Profilen, Debuggen und Loggen anbietet, dann müssen an den entsprechenden Stellen diese Fähigkeiten erst implementiert werden. Das ermöglicht uns herauszufinden, wo im Detail die Performance Engpässe stecken.

Beim Profilen möchte man herausfinden, welche und wie Systemressourcen zur Laufzeit der Applikation verwendet werden. Ein Debugging dient zur genauen Fehleranalyse und gibt bei Bedarf viele Details zu bestimmten Funktionalitäten aus, die aber zur Laufzeit auf Produktivsystemen deaktiviert werden. Der Grund dafür ist, dass ein exzessives Monitoring wiederum einen spürbaren Performance-Nachteil mit sich bringt. 

Ein minimales Loggen von Performance relevanten Parametern sollte jedoch immer aktiv geschaltet sein, um Engpässe frühzeitig erkennen zu können. Solche Parameter können zum Beispiel im Falle einer Schnittstellenanbindung die Anzahl von API-Endpunkt Anfragen, die Ausführungsdauer und der benötigte Speicher sein.

Wenn ein Monitoring erst zu einem Zeitpunkt eingerichtet wurde, bei dem bereits Performance Probleme auftreten, dann kann es notwendig sein, dass das Monitoring erst eine gewisse Zeit lang laufen muss, um Rückschlüsse ziehen zu können.

Nun können sich unterschiedliche Bereiche als Performance-kritisch herausstellen. Unserer Erfahrung nach betrifft es meistens Fehler in der Applikationslogik, Schnittstellen zu externen Services oder Datenbankabfragen bzw. die Datenbank als Ganzes. Bei manchen CMS Systemen wie WordPress findet sich die Ursache an einem langsamen System gerne in Erweiterungen und Plugins, welche aktualisiert, optimiert oder ersetzt werden sollten.

Die meisten Probleme können durch Code-Optimierungen recht einfach gelöst werden. Wurde die Applikation oder das Framework/CMS soweit wie sinnvoll möglich verbessert, müssen im nächsten Schritt etwaige Schnittstellen kontrolliert werden. Ähnlich wie bei kritischen Datenbankabfragen hilft hier in den meisten Fällen ein Caching System, welches den Server entlastet. Ein Cache ist ein Zwischenspeicher, der dahinter liegende Systeme entlasten soll. Wie bereits oben genannt, ist häufig die verwendete Datenbank besonders interessant. Hier gibt es eine Reihe von Analyse- und Optimierungsmaßnahmen, die wir in einem weiteren Beitrag ausführlich beleuchten wollen.
Bei einer Datenbank können Abfragen während der Laufzeit der Applikation im Speicher zwischengespeichert werden. Es gibt weitaus komplexere Caching Systeme wie zum Beispiel Redis oder Memcached. Dabei werden Daten als Schlüssel-Werte Paare in diesen extrem performanten Systemen gespeichert und bei Bedarf von dort statt der Datenbank geladen. 

Nicht immer muss eine durchaus zeitaufwändige Analyse und Applikationsoptimierung vorgenommen werden. Vorausschauend kann eine vertikale Skalierung, also ein Upgrade auf eine bessere Server-Hardware (CPU, Arbeitsspeicher), sinnvoll sein. Ein Beispiel dafür wäre, wenn bekannt ist, dass in einem bestimmten Zeitraum ein erhöhter Besucheransturm auf Ihre Website oder Ihrem Online-Shop zu erwarten ist.

Natürlich gibt es noch viele weitere Sonderfälle und weitere Techniken, die wir in weiteren Beiträgen anführen möchten. Durch die oben genannte Vorgehensweise und Maßnahmen konnten wir bereits viele Anwendungen bestmöglich optimieren.

Eine schnelle und reaktionsfreudige Website fördert längeres Verweilen und höhere Conversion-Raten, während eine langsame Website Besucher:innen frustriert und zu einem vorzeitigen Absprung führt. Die Auswirkungen einer schlechten Ladezeit auf die Nutzererfahrung und das Suchmaschinen-Ranking haben wir verdeutlicht. 

Die vorgestellten Strategien konzentrieren sich darauf, Engpässe zu erkennen und effektive Lösungen zur Optimierung von Webanwendungen aus Backend-Sicht zu implementieren. Verschiedene Ansätze, wie Profiling, Debugging und Caching, wurden behandelt, um Performance-Probleme zu beheben. Eine vorausschauende Skalierung und der Einsatz einer leistungsfähigeren Server-Hardware können mögliche Lösungswege sein.

• [1] https://www.section.io/blog/page-load-time-bounce-rate/
• [2] https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/