Drittanbieterressourcen wie Embeds und Scripts werden heute im Web häufig verwendet. Sie bieten Lösungen für das Einbetten von Social-Media-Inhalten, Videos, Analysen, Livechats, Werbung, A/B-Tests, Personalisierung und mehr. Einbettungen von Drittanbietern sind ein notwendiger Bestandteil moderner Websites, mit denen sich Websiteinhaber auf ihre Kernkompetenzen konzentrieren und gleichzeitig standardmäßige, aber wichtige Funktionen an externe Anbieter auslagern können.
Wenn sowohl selbst erhobene Daten als auch Drittanbieterdaten auf einer Webseite harmonisch zusammenarbeiten, kann die Seite eine gute Nutzererfahrung bieten. Dies erfordert jedoch erheblichen Aufwand sowohl von den Entwicklungs- als auch von den Geschäftsteams und wird oft übersehen. Dies führt zu weniger leistungsfähigen Webseiten und zu negativen Auswirkungen auf nutzerorientierte Messwerte wie die Core Web Vitals. Das ist für beide Seiten schädlich und führt zu verpassten Chancen in Unternehmen. Können wir das verbessern?
Wir haben eine Vision für das Web, in der Scripts und Ressourcen von Drittanbietern den beabsichtigten Geschäftswert bieten, ohne dass die Leistung oder Nutzerfreundlichkeit von Websites, auf denen sie im Browser verwendet werden, beeinträchtigt wird. So könnten Nutzer Seiten schneller laden.
Im letzten Jahr haben wir viele Möglichkeiten geprüft, diskutiert und ausprobiert, mit denen die Nutzerfreundlichkeit vor den schädlichen Auswirkungen von Drittanbieter-Scripts geschützt werden kann, ohne den Geschäftswert für Websiteinhaber zu beeinträchtigen.
In diesem Beitrag möchten wir euch über einige unserer Tests informieren. Wir hoffen, dass dies der Beginn eines Prozesses ist, der für mehr Transparenz und Sichtbarkeit zwischen User-Agents, Unternehmen und Drittanbietern sorgt und den Weg zu einem schnelleren Web ebnet.
Drittanbieter genauer kennenlernen
Drittanbieter sind Ressourcen, die von einem externen Anbieter bereitgestellt werden. Sie liegen nicht direkt in der Kontrolle der Websiteinhaber, sind aber mit deren Genehmigung vorhanden. Ressourcen von Drittanbietern:
- Sie werden auf einem geteilten und öffentlichen Ursprung gehostet, der sich vom Ursprung der primären Website unterscheidet.
- Sie werden nicht von einem einzelnen Websiteinhaber verfasst oder beeinflusst.
- Wird von vielen Websites verwendet.
Drittanbieter können bei der Umsatzgenerierung (über Anzeigen) und bei der Bereitstellung besserer Marketingmöglichkeiten (Embeddings in sozialen Medien) helfen und so eine Vielzahl von Geschäftszielen unterstützen. Zu den gängigen Kategorien von Drittanbietern gehören:
Quelle: Drittanbieter nach Kategorie
| Kategorie | Definition |
|---|---|
| Werbung | Scripts, die für die Anzeigenbereitstellung oder die Analyse der Anzeigenleistung verwendet werden. |
| Video | Scripts, die Videoplayer und Streamingfunktionen ermöglichen. |
| Gehostete Bibliotheken | Eine Mischung aus öffentlich gehosteten Open-Source-Bibliotheken. |
| Inhalt | Scripts von Contentanbietern oder publisherspezifisches Affiliate-Tracking |
| Customer Success | Scripts von Kundensupport-/Marketinganbietern, die Chat- und Kontaktlösungen anbieten. |
| Hosting | Scripts von Webhosting-Plattformen |
| Marketing | Scripts von Marketingtools, die Pop-ups, Newsletter und andere Elemente einfügen |
| Sozial | Scripts, die soziale Funktionen aktivieren. |
| Tag Manager | Scripts, die viele andere Scripts laden und viele Aufgaben initiieren. |
| Analytics | Scripts, mit denen Nutzer und ihre Aktionen gemessen oder erfasst werden. |
| Cookie-Einwilligungsplattform | Scripts, mit denen Websites die Einwilligung der Nutzer (DSGVO, ePR, CCPA) auf informierte und transparente Weise einholen können. |
| Utility | Scripts, die Entwickler-Dienstprogramme sind (API-Clients, Website-Monitoring, Betrugserkennung usw.) |
| Sonstiges | Sonstige Scripts, die über einen gemeinsamen Ursprung ohne genaue Kategorie oder Zuordnung ausgeliefert werden. |
Mit diesen Scripts und Bibliotheken von Drittanbietern können Webentwickler bewährte Lösungen nutzen, um Standardfunktionen zu implementieren, anstatt das Rad neu zu erfinden. So verkürzen Drittanbieter die Entwicklungszeit und helfen Unternehmen, ihre Produkte schneller auf den Markt zu bringen oder zu aktualisieren. Kein Wunder also, dass mehr als 94% aller Websites auf Computern und Mobilgeräten Drittanbieter verwenden.
Wie wirken sich Drittanbieter auf die Leistung aus?
Idealerweise sind die Entwickler von Drittanbietern Fachleute für die von ihnen angebotenen Funktionen. Die meisten beliebten Drittanbieter haben mehrere Iterationen durchlaufen und man kann davon ausgehen, dass ihr Code für ihre eigenen Geschäftsziele optimiert ist, was die Leistung der Seiten, auf denen sie verwendet werden, möglicherweise einschließt. Wir wissen jedoch, dass sich selbst die am besten optimierten Drittanbieter auf die Leistung auswirken. Die Hauptgründe dafür sind:
Größe und Kosten der Scriptausführung: Drittanbieter bieten oft umfangreiche Funktionen, indem sie einfach ein
<script>- oder<iframe>-Element auf Ihrer Seite einfügen. Diese Elemente ziehen dann Scripts und Ressourcen heran, die sehr groß sind und deren Download und Ausführung länger dauert. Zu viel JavaScript hält den Haupt-Thread länger beschäftigt, blockiert das Rendering und verzögert Nutzerinteraktionen. Einige der größten Drittanbieter blockieren den Haupt-Thread bei mehr als 50% der analysierten Websites für 42 ms bis 1,6 s. Ein blockierter Hauptthread führt zu einer hohen Gesamtblockierzeit (Total Blocking Time, TBT). Dieser Messwert wirkt sich auf den Leistungsbewertungswert der Website aus. Außerdem verzögert es die Reaktion auf Nutzerinteraktionen und verschlechtert den Messwert Interaction to Next Paint (INP), mit dem die Reaktionsfähigkeit von Websites gemessen wird. Die Kosten für die Scriptausführung haben daher einen erheblichen Einfluss auf die Leistung.Anzahl: Im Durchschnitt nutzen Websites auf Mobilgeräten und im Web etwa 21 verschiedene Drittanbieter. Häufig werden Drittanbieter-Tags über Tag-Management-Tools hinzugefügt, die nicht direkt von den technischen/Entwicklungsteams verwaltet werden. Nicht erforderliche Tags können von anderen Teams ohne Überprüfung hinzugefügt werden und werden nie entfernt. Diese können sich erheblich auf die Nutzerfreundlichkeit, das Seitengewicht oder die CPU-Auslastung auswirken. Mit einem Governance-Prozess können solche Situationen angegangen und die Auswirkungen der einzelnen Anbieter geprüft werden. Es wäre hilfreich, wenn Entwickler für alle Drittanbieter, die eine bestimmte Funktion bereitstellen, Daten zu den Leistungsauswirkungen, Vorteilen und Nachteilen zur Verfügung hätten, um sie zu vergleichen. Eine weitere Herausforderung für Teams besteht darin, dass die Drittanbieter-Tags für viele Websites nur in der Produktionsumgebung, aber nicht in den Entwicklungsumgebungen ausgeführt werden. Das erschwert es den Entwicklern, sie zu testen.
Netzwerk: Da Drittanbieter an verschiedenen Orten gehostet werden, müssen Browser mehr Verbindungen herstellen, um Inhalte von ihnen herunterzuladen. Die verschiedenen Verbindungen können den Download nicht nach Priorität koordinieren, was zu Netzwerkkonflikten führt. Das kann den Seitenaufbau weiter verzögern, wenn die richtigen Optimierungen nicht berücksichtigt werden.
Abfolge: Drittanbieter können den Hauptthread blockieren und um die Bandbreite für wichtigere Ressourcen konkurrieren. In einigen Fällen sind Drittanbieter jedoch die wichtigsten Ressourcen, die für das Rendern der Seite erforderlich sind. Eine optimale Abfolge der Ressourcen von selbst erhobenen Daten und Drittanbietern wird erforderlich, wenn auf Websites mehrere Drittanbieter verwendet werden. Webentwickler sollten sich mit den verschiedenen Optionen zur Optimierung der Sequenzierung vertraut machen.
Aus den oben genannten Gründen können Drittanbieter sich auf eine oder alle Komponenten der Core Web Vitals auswirken. Die meisten Drittanbieter haben negative Auswirkungen auf den Largest Contentful Paint (LCP) und das First Input Delay (FID). YouTube-Embeds blockieren den Hauptthread bei 10% der Websites auf Mobilgeräten für 4,5 Sekunden und bei 50% der untersuchten Websites für mindestens 1,6 Sekunden. Stellen Sie sich die Frustration eines Nutzers vor, der bei einer langsamen Verbindung auf eine Seite mit 20 solchen Scripts stößt. Die folgende Visualisierung von thirdpartyweb.today zeigt die Drittanbieter mit der derzeit größten Leistungsauswirkung.
„Bei den etwa 4 Millionen Top-Websites entfallen etwa 2.700 Ursprünge auf etwa 57% der gesamten Scriptausführungszeit. Die 50 wichtigsten Entitäten machen bereits etwa 47 % aus.“ – third-party-web
Seiten, die schnell gerendert werden und innerhalb eines angemessenen Zeitraums interaktiv werden, sind für eine gute Nutzererfahrung, gemessen an den Core Web Vitals, unerlässlich. Eine gute UX führt oft zu mehr Umsatz für Websites, was auch für die verwendeten Drittanbieter von Vorteil sein kann. Wenn alle Beteiligten gemeinsam daran arbeiten, die Auswirkungen von Drittanbietern zu reduzieren, kann das für alle Beteiligten von Vorteil sein.
Google bietet eine Reihe gängiger Drittanbieter-Scripts an, darunter Google Tag Manager, YouTube-Embeds und ReCaptcha. Wir sind uns bewusst, dass einige unserer Scripts die Leistung der Core Web Vitals geringfügig beeinträchtigen können. Wir arbeiten daran, diese Auswirkungen nach Möglichkeit zu verbessern.
Wie kann Chrome Ihnen helfen?
Die schlechte Leistung von Drittanbieterressourcen ist für Entwickler regelmäßig eine Herausforderung, die eine grundlegende Änderung der zugrunde liegenden Systemdynamik erfordert. Chrome möchte diesen Bereich erkunden, um die folgenden Ziele zu erreichen:
Sie finden bessere Möglichkeiten, Ressourcen von Drittanbietern im Web zu laden, ohne die Nutzerfreundlichkeit oder die Geschäftsergebnisse zu beeinträchtigen.
Wir wissen, dass wir bei diesem Vorhaben nicht weit kommen, wenn wir nicht mit Partnern, Unternehmen, Drittanbietern und Entwicklern zusammenarbeiten. Wir möchten ein offenes Feld schaffen, in dem wir über die Möglichkeiten diskutieren und uns über öffentliche Erläuterungen und Spezifikationen austauschen können. Entwickler haben Zeit, Feedback zu geben und die Auswirkungen vieler dieser Vorschläge zu testen.
Nutzer von Drittanbieter-Scripts erhalten eine bessere Zuordnung ihrer Kosten für Tools und für die Nutzung vor Ort, klare und gut ausgebaute Pfade für ihre Verwendung und bessere Anreize während der Erstellung, damit sie standardmäßig optimal sind.
Wir möchten alle Ebenen verbessern, z. B. User-Agents, Frameworks und Drittanbieter-Scripts, um die Leistungsauswirkungen von Drittanbietern zu reduzieren. Außerdem möchten wir Websiteinhabern ausreichend Informationen zur Verfügung stellen, damit sie die Best Practices für jedes eingebettete Script anwenden können, einschließlich schnellerer Alternativen, sofern zutreffend.
Vorgeschlagener Ansatz
Wir schlagen einen dreiteiligen Ansatz vor, um diese Ziele zu erreichen:
**Entwicklern detailliertere Informationen zur Wirkung von Drittanbietern über RUM und die Chrome-Entwicklertools zur Verfügung stellen.**
RUM bezieht sich auf Daten zu echten Nutzermesswerten (auch Felddaten genannt), die über APIs zur Überwachung der Webleistung verfügbar sind. Zu den Entwicklertools von Chrome gehören Lighthouse, Chrome DevTools und der Bericht zur Nutzererfahrung in Chrome. Wir schlagen vor, die verfügbaren APIs und Tools zu verbessern, damit Websiteentwickler die Auswirkungen jedes Drittanbieters auf jeder Seite nachvollziehen können. Die Tools informieren sie auch darüber, welche Maßnahmen sie ergreifen können, um die Auswirkungen zu verringern (z. B. die Deaktivierung oder die Verwendung von Fassaden). Außerdem werden andere potenzielle Lösungen (andere Drittanbieter oder DIY) mit Vor- und Nachteilen vorgestellt. Bei den APIs zur Überwachung der Webleistung prüfen wir, wie wir den Umfang der plattformübergreifenden Ressourcen erweitern können, ohne die Privatsphäre und Sicherheit unserer Nutzer zu gefährden.
**Bieten Sie Unternehmen einen klaren Pfad zum effizienten Laden von Drittanbieterressourcen.**
Wir möchten neue Standards vorschlagen, die Browser dazu anregen, intelligenter Kompromisse zwischen dem Laden von selbst erhobenen und Drittanbieterressourcen zu finden, um die Ladezeit für Nutzer zu verbessern. Später gehen wir auf einige dieser Vorschläge ein, z. B. das standardmäßige Lazy-Loading von Drittanbieter-Embeds oder die Anwendung einer anderen Ressourcenpriorisierung auf Drittanbieterressourcen, die für die ursprünglichen Inhalte, die für Nutzer am wichtigsten sind, möglicherweise nicht so wichtig sind. Das sind nur einige der Ideen, die wir in diesem Bereich prüfen. Wir würden uns freuen, sowohl mit Web-Performance-Experten als auch mit der breiteren Community zusammenzuarbeiten, um diese Arbeit zu gestalten.
Wir möchten solche Probleme auch in JavaScript-Frameworks und Content-Management-Systemen (CMS) beheben, sofern dies angebracht ist. Projekte wie Aurora und das WordPress Performance Team haben uns gezeigt, wie wichtig vordefinierte Standardeinstellungen sind, mit denen bekannte Ladeprobleme behoben werden. In Frameworks und CMS integrierte Standardeinstellungen führen Unternehmen auf einem gut ausgeleuchteten Weg. Sie können auch für den User-Agent (z. B. Chrome) hilfreich sein, da sie als Hinweise dienen, mit denen Heuristiken zur Optimierung des Seitenladevorgangs und der CWV angewendet werden können. Anhand dieser Hinweise kann der User-Agent entscheiden, wann und wie bestimmte Drittanbieter im Seitenlebenszyklus geladen werden sollen. So ist beispielsweise bei der Next.js-Scriptkomponente standardmäßig festgelegt, dass Drittanbieter-Scripts geladen werden, nachdem die Seite interaktiv geworden ist.
**Bieten Sie Drittanbietern Anreize, ihre Leistungsauswirkungen durch mehr Transparenz zu verringern.**
Drittanbietern fehlt derzeit die Transparenz, um die Auswirkungen ihrer Scripts auf Websites insgesamt zu verstehen. Wir planen, dieses Problem anzugehen und diesen Anbietern Tools zur Verfügung zu stellen, mit denen sie ihre Auswirkungen analysieren und mit anderen Produkten auf dem Markt vergleichen können, die denselben Mehrwert bieten. Außerdem möchten wir ihnen helfen, anhand der Daten die Ursache für die Auswirkungen zu ermitteln, damit sie diese im Vorfeld abmildern können. Wir müssen alle Drittanbieter nennen, auch die von Google, damit das funktioniert.
Herausforderungen
Ein Projekt dieser Größenordnung ist nicht ohne Herausforderungen. Zu den wichtigsten Herausforderungen, die wir berücksichtigen müssen, gehören:
- Drittanbieter sind ein Querschnittsproblem, das unter anderem Anzeigen, Analysen, Tag-Verwaltung und Dienstprogramme betrifft. Für jeden Bereich müssen spezifische Anforderungen und Abwägungen berücksichtigt werden. Beispiel:
- Die Entscheidung, das Laden von Anzeigen zu optimieren, ist ein Kompromiss zwischen Umsatz und Nutzerfreundlichkeit. Zu früh blockieren sie wertvolle Inhalte, zu spät sehen sie die Nutzer nicht.
- Analytics-Scripts erhöhen das Seitengewicht, liefern aber wertvolle Daten zu Nutzeraktionen.
Wir hoffen, mit verschiedenen Kategorien von Drittanbietern zusammenzuarbeiten, die Feinheiten zu verstehen, Kompromisse zu lösen und Anreize zu entwickeln, die für alle funktionieren. Uns ist bewusst, dass wir in jedem Bereich separat mit Organisationen zusammenarbeiten müssen, damit unsere Strategie effektiv ist. Dazu gehören auch unsere internen Partner wie Google Tag Manager, Google Ads und YouTube.
Wir möchten sowohl Website-Entwicklern als auch Drittanbietern eine detailliertere Attribution bieten. Dazu ist ein sorgfältiger Aufwand erforderlich, bei dem wir ermitteln, welche Daten für die Messung der Auswirkungen am relevantesten sind, sie korrekt und detailliert zuordnen und den richtigen Weg vorschlagen. Letztendlich sollte die Berechnung der Leistung eines Drittanbieters im Vergleich zu seinen Mitbewerbern für alle transparent sein.
Wir schlagen vor, Chrome so zu verbessern, dass Optimierungen angewendet werden können, mit denen das richtige Gleichgewicht beim Priorisieren des Ladens von Ressourcen von Erst- und Drittanbietern gefunden wird. Eine nützliche Änderung wird standardmäßig in allen Browsern verfügbar, aber es dauert einige Zeit. Das Attribut
loadingfür<img>- und<iframe>-Elemente ist beispielsweise seit 2019 in Chrome/Edge verfügbar, aber erst seit 2022 in Safari. Bis eine Funktion standardisiert ist, müssen Nutzer von Drittanbieterressourcen dafür sorgen, dass sie auch für andere Browser optimiert sind. Wir werden dies in unseren Richtlinien entsprechend hervorheben.Um dieses Projekt umzusetzen, müssen wir mit Partnern und Entwicklern zusammenarbeiten, um nicht nur spezifische Anforderungen zu verstehen, sondern auch experimentelle Lösungen im großen Maßstab zu testen, Feedback zu geben, nach Bedarf zu iterieren und zu improvisieren. Die Änderungen müssen geplant werden, wobei ein angemessener Zeitrahmen für Tests und Bewertungen eingeplant werden muss.
Erste Vorschläge für Standards
Wir haben einige erste Tests durchgeführt, um Funktionen zu entwickeln, die aktiviert werden können, um das Laden von Drittanbieterinhalten zu optimieren. Wir sind mit den beobachteten Ergebnissen zufrieden und können derzeit zwei dieser Funktionen besprechen.
LazyEmbeds
Bisher wurden <img>- und <iframe>-Elemente, die nicht im sichtbaren Bereich waren, für Nutzer des Lite-Modus lazy-loaded. Diese Funktion könnte auf alle Nutzer ausgeweitet werden, um das Laden von <iframe>-Elementen, die als Einbettungen von Drittanbietern eingestuft wurden, so lange zu verzögern, bis der Nutzer in ihre Nähe scrollt. Dadurch kann das Laden anderer Teile der Seite beschleunigt, die Core Web Vitals verbessert, die Arbeitsspeichernutzung reduziert und Daten gespart werden.
Hier ist eine Demo, in der YouTube-Videos mit LazyEmbeds auf einer Seite lazy geladen werden. Durch das Einbetten eines einzelnen YouTube-Videos wird der Seite in der Regel 500–600 KB JavaScript hinzugefügt. Wir haben versucht, einen Blogpost mit 14 solchen eingebetteten Videos mit LazyEmbeds zu optimieren. Die Ergebnisse waren vielversprechend, was die Seitenladezeit und die Dateneinsparungen angeht.
| Vorher | Nachher | |
|---|---|---|
| Daten | 15,4 MB | 6,1 MB |
| Total Blocking Time | 3,2 Sekunden | 1,6 Sekunden |
Weitere Informationen zu dieser Arbeit finden Sie in unserem Erklärartikel sowie im Thread zu „Intent-to-Experiment“ und in der Erweiterung für Tests auf blink-dev.
Gezieltes Drosseln von Drittanbietern
Drittanbieter-Scripts werden oft von verschiedenen Teams ohne ganzheitliche Kontrollprozesse hinzugefügt. Das Entwicklerteam von The Telegraph hat erklärt, dass „jeder das Tag auf einer Seite haben möchte, mit dem die Organisation Geld verdienen kann“. Das kann die Verwaltung der Leistungsauswirkungen kontinuierlich erschweren.
Bei der gezielten Drosselung von Drittanbieter-Scripts werden bestimmte Arten von Drittanbietern gedrosselt, um ihre Auswirkungen zu verringern. So können Browser wichtige Inhalte und kritische Drittanbieter frühzeitig laden, während solche, die auch später geladen werden können, gedrosselt werden.
Verbesserungen an RUM-APIs
Wir überlegen auch, RUM APIs um Informationen zu ergänzen, die für die Beurteilung der Leistung von Drittanbietern relevant sind. Zu den Verbesserungen gehören:
<iframe>Berichte: Wir arbeiten an Lösungen, mit denen die Performance Timeline API für rahmenübergreifende Berichte genutzt werden kann. So können die Autoren der übergeordneten Seite Leistungsdaten für einen iframe eines kooperierenden Drittanbieters prüfen, der auf der Seite eingebettet ist.Zuordnung von langen Aufgaben: Mit der Long Tasks API in RUM können Websiteinhaber lange Aufgaben identifizieren, die den Hauptthread für lange Zeit belegen und die Interaktion verzögern.
Weitere Updates
Wir experimentieren noch mit vielen dieser Ideen und hoffen, im Laufe der Zeit Erläuterungen und Spezifikationsentwürfe für Änderungen auf GitHub zu veröffentlichen. Drittanbieter und Websiteinhaber, die mit uns zusammenarbeiten oder Feedback geben möchten, können über diese Gruppen an den Diskussionen teilnehmen. Drittanbieter können sich auch darauf konzentrieren, ihre Websites für die Core Web Vitals- und INP-Messwerte zu optimieren, damit ihnen keine schlechten Core Web Vitals-/INP-Daten zugeordnet werden. Wer aktiv nach Updates sucht, kann sich die Beiträge in der Gruppe blink-dev ansehen.
Wir freuen uns darauf, dieses Problemfeld weiter zu erkunden und unsere Erkenntnisse mit der Community zu teilen.
Mit besonderer Unterstützung von Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. Jose, Melissa Mitchell, Yoav Weiss, Shunya Shishido und Minoru Chikamune für ihr Feedback und ihre Beiträge.