PresseKat - Risiko

Das Einbinden von Drittanbieter-Erweiterungen wie Social Media Plugins auf der eigenen Website ist bequem – aber zugleich eine der größten Gefahren für Page Speed und eine gute User Experience. Lange Ladezeiten durch “Third Party Integrations” führten bereits zu Umsatzeinbußen bei vielen renommierten Websites. Wir zeigen, welche Probleme es gibt, und wie Anbieter damit umgehen können.

(firmenpresse) - Köln, 29. August 2017 – Nur wenige Websites kommen heute ohne so genannte “Third Party Integrations” aus. Videos, Social Media Streams und Share-Buttons, JavaScript Frameworks oder Ad Libraries: Die Einbindung ist einfach, meist genügt es, ein paar Codeschnipsel in den Quelltext der eigenen Website zu kopieren und schon kann man ein weiteres Feature anbieten oder Werbung ausliefern. Doch das bequeme Hinzufügen neuer Funktionen zum eigenen Service hat einen Preis: Wenige Byte eingebundener Code können viele Megabyte Content und Funktionen nachladen, den Umfang einer Website also signifikant steigern. Das führt zu längeren Ladezeiten, die User Experience leidet am wichtigen Punkt “Page Speed”. Bedenkt man, dass 53% der Nutzer eine Website verlassen, wenn diese länger als drei Sekunden zum Laden benötigt, dann sind Third Party Integrations oft eher kontraproduktiv.

** Warum können Drittanbieter-Erweiterungen problematisch sein? **

- Jede einzelne genutzte Library verursacht einen HTTP-Request: Der Nutzer muss warten, bis der Request bearbeitet und beantwortet wird.

- Jede Integration erhöht per se die Datenmenge einer Website: Der Nutzer muss mehr Daten herunterladen, um die Seite sehen und nutzen zu können.

- Manche Integrationen sind auf den ersten Blick zwar schlank und erhöhen die initiale Datenmenge kaum, laden im Live-Betrieb aber viele Daten nach: Das bedeutet noch mehr Traffic bei der Übertragung zum Nutzer.

- Auch wenn Entwickler alle diese Fälle prüfen und als Konsequenz auf besonders “schlanke” Drittanbieter-Integrationen setzen: Künftige Updates können neue Funktionen oder Änderungen mit sich bringen, die in höherer Datenmenge resultieren oder im schlimmsten Fall nicht kompatibel sind und das Laden der Website be- oder sogar verhindern.

Diese Punkte gelten auch für die meistgenutzten Third Party Integrations: YouTube Videos, Twitter Posts, Social Media Sharing Buttons, Disqus Comments, Addthis. Allein die Integration von YouTube, Addthis und Disqus macht eine Website um 1,6 Megabyte größer – und dann soll der Nutzer ja auch noch den genuinen Content der Seite laden.

Erweiterungen können auch generell problematisch sein oder werden, weil Websites ein komplexes Zusammenspiel aus Dokumenten (DOM), Layouts (CSS) und Programmcode (JavaScript) sind. Für Entwickler ist es eine große Herausforderung, sicherzustellen, dass dieses Zusammenspiel auf allen möglichen Endgeräten funktioniert. Doch was passiert, wenn über Erweiterungen nachträglich weiterer Content aus unterschiedlichen Quellen eingefügt wird? Und wer ist verantwortlich, wenn die Website dann nicht funktioniert: Website-Betreiber, Erweiterungs-Anbieter, Browser-Hersteller – oder doch der Nutzer und seine Konfigurationseinstellungen?

** Lange Ladezeiten kosten Geld – das wissen auch New York Times & Co. **

Natürlich achten gute Web-Entwickler darauf, dass ihre Website nicht zu groß wird und Bandbreiten sinnvoll genutzt werden. Aber es gibt viele Beispiele, die zeigen: Auch den “großen” Betreibern und Anbietern ist hier schon die Kontrolle entglitten. Zwei plakative Fälle zeigen dies:

1. Die bekannte Tech- und Kulturseite “The Verge” hat ihren Lesern eine Zeit lang den Download von bis zu 7 Megabyte (!) JavaScript aufgenötigt, um alle Funktionen nutzen zu können. Die vollständige Startseite von “The Verge” mit allem eigenen Content war rund 12 Megabyte groß. Für viele, vor allem Mobilnutzer, ist das einfach viel zu viel, auch heute noch. Sie springen ab, noch während die Seite lädt.

(Zum Vergleich: 12 Megabyte könnten rund 6.000 Seiten Text beinhalten. Und die Shareware-Version des Computerspiels “Doom” von 1993 bot 45 Minuten Spielspaß verpackt in nur 2,4 Megabyte.)

2. Die Website von “BBC News” und andere Nachrichtenseiten wie die “Washington Post” oder die “New York Times” brachten dank einer fehlerhaften Ad Library auf älteren Geräten bei jedem Aufruf den Browser zum Absturz: Das JavaScript-Element, das Werbung nachladen sollte, war nicht kompatibel und blockierte die Darstellung der Website für jeweils 30 Sekunden, dann lud die Seite neu, ohne jemals vollständig angezeigt zu werden. Das ging solange, bis der Speicher des Nutzergerätes vollgeschrieben war und der Browser abstürzte.

Gerade wenn Werbung das Geschäftsmodell ist, sind solche Fehler besonders ärgerlich. Jeder verlorene Nutzer, der kein Banner angezeigt bekommt, lässt sich in Euro und Cent umrechnen. So können lange Ladezeiten zu einem echten Umsatzproblem werden.

Die “Financial Times” hat für ihre Website umfangreiche Tests durchgeführt, bei denen die Ladezeit künstlich auf eine, zwei oder drei Sekunden festgesetzt wurde. Die Studie kommt unter anderem zu dem Ergebnis, dass sich auch geringfügig längere Ladezeiten negativ auswirken auf die Anzahl an Seiten, die ein Nutzer besucht (Session depth). Das Fazit für die Experten der “FT” lautet, dass sich aus UX-Perspektive und aus finanziellen Gründen eine schnellere Website immer bezahlt macht.

** Wie sollte man dem Problem begegnen? **

Wie aber macht man eine Website schneller? Jede Website will Aufmerksamkeit und viele Klicks haben. Die Nutzung von Third Party Integrations ist dafür ein wichtiges Mittel, vor allem die Social Media Share-Buttons. Aus “Gewichtsgründen” darauf zu verzichten ist kaum eine Option. Wie findet man also ein ausgewogenes Verhältnis zwischen Page Speed und eingebauter Funktionalität? Vier Tipps:

1. Aussortieren: Nicht gleich alle verfügbaren Erweiterungen von Facebook und YouTube bis Whatsapp und Pinterest oder LinkedIN und XING einbauen. Dafür muss man die Zielgruppe kennen. Das Zusammenspiel aus Content, Kontext und Zielgruppe gibt vor, welche Integrationen wirklich sinnvoll sind.

2. Alternativen nutzen: Die meisten Sharing-Buttons sind JavaScript und bringen zusammengenommen recht viel Gewicht auf die Seite. Aber es gibt leichtgewichtige Alternativen wie sharingbuttons.io die für den Nutzer dieselben Funktionen erfüllen und dabei weniger HTTP-Requests und initiale Datenmengen benötigen. Daten nachladen müssen aber auch diese, spätestens bei einer Nutzer-Interaktion.

3. Experten fragen: Web-Entwicklung ist nicht gleich Web-Entwicklung, für alles gibt es Spezialisten, auch für Page Speed. Wer ein Problem mit langen Ladezeiten bekommt, sollte nicht am falschen Ende sparen, sondern sich klar machen: Ist es nicht besser, Expertenwissen einzubringen, als Conversions zu verlieren?

4. Automatisierte Optimierung: Mit Tools wie wao.io (aktuell in der Closed Beta) können bestehende Websites “on the fly” und ohne Änderungen am Code beschleunigt werden. Etwa indem Bilder besser komprimiert, das Caching optimiert oder blockierende Erweiterungen abgeschaltet werden – das kann im Einzelfall mehrere Megabyte einsparen. Und dann ist auch Platz für eine sinnvolle (!) Erweiterung.

** Kompromisse sind die halbe Miete **

Jeder Anbieter muss selber entscheiden, wie viele Features und externen Content er seiner Website hinzufügen will. Ab einem gewissen Umfang sollte man berücksichtigen, dass der von mehr Funktionen und Inhalten erhoffte positive Effekt auf die Conversion ins Negative umschlagen kann – weil die Page Speed zu stark sinkt und teilweise die Kontrolle über den Content verloren geht.

Es gilt also für jeden, der eine Website entwickelt oder betreibt, einen Kompromiss zwischen Geschwindigkeit und Funktionalität zu finden, und zu entscheiden, wie viel Kontrolle man an Drittanbieter abgeben will.

Schlanke Social Media Integrationen wie sharingbuttons.io und automatische Speed Optimierer wie wao.io können hier den entscheidenden Ausschlag geben.

Und bevor man in SEO und Werbung für seine Seite investiert oder Nutzer zum Teilen animiert, sollte man die Ladezeiten-Baustelle auf jeden Fall erledigt haben.