Ressourcen von Drittanbietern wie Einbettungen und Skripts werden heutzutage im Web häufig verwendet. Sie bieten vorkonfigurierte Lösungen zum Einbetten von sozialen Medien, Videos, Analysen, Livechats, Werbung, A/B-Tests, Personalisierung und mehr. Einbettungen von Drittanbietern sind ein notwendiger Bestandteil moderner Websites, mit denen Websiteinhaber sich auf ihre Kernkompetenzen konzentrieren können, während herkömmliche, aber wichtige Funktionen externen Anbietern zur Verfügung gestellt werden.
Wenn Erstanbieter und Drittanbieter auf einer Webseite harmonisch zusammenarbeiten, kann eine Seite eine sehr gute Nutzererfahrung bieten. Dies ist jedoch mit einem erheblichen Aufwand von Entwickler- und Geschäftsteams verbunden und wird häufig übersehen. Das führt zu weniger effizienten Webseiten und negativen nutzerorientierten Messwerten wie den Core Web Vitals. Das schadet beider Parteien und schafft verpasste Chancen für Unternehmen. Können wir es hier besser machen?
Wir haben eine Zukunftsvision des Webs, in der Skripts und Ressourcen von Drittanbietern den beabsichtigten geschäftlichen Nutzen bieten, ohne dass die Leistung oder Nutzererfahrung von Websites beeinträchtigt wird, die diese im Browser verwenden. Dadurch wird die Seite im Idealfall schneller geladen.
Im letzten Jahr haben wir viele Möglichkeiten in Betracht gezogen, diskutiert und getestet, um die Nutzererfahrung vor den negativen Auswirkungen von Drittanbieter-Skripts zu schützen, ohne den Geschäftswert der Website-Inhaber zu schmälern.
In diesem Beitrag möchten wir Sie über einige unserer Tests informieren. Wir hoffen, dass dies der Beginn eines Prozesses ist, der Transparenz und Transparenz zwischen User-Agents, Unternehmen und Drittanbietern fördert und den Weg zu einem schnelleren Web ebnet.
Weitere Informationen zu Drittanbietern
Ein Drittanbieter ist eine Ressource, die von einem Anbieter außerhalb der Website bereitgestellt wird. Sie unterliegen nicht direkt der Kontrolle des Websiteinhabers, müssen aber von ihnen genehmigt werden. Ressourcen von Drittanbietern sind:
- Sie wird an einem gemeinsamen und öffentlichen Ursprung gehostet, der sich von der primären Website unterscheidet.
- Sie dürfen nicht von einem einzelnen Websiteinhaber erstellt oder beeinflusst werden.
- Weitverbreitet auf einer Vielzahl von Websites
Drittanbieter unterstützen eine Vielzahl von Geschäftszielen – von der Generierung von Umsatz (über Anzeigen) bis hin zur Bereitstellung besserer Marketingmöglichkeiten (Einbettungen in sozialen Medien). Zu den häufigsten Kategorien von Drittanbietern gehören:
Quelle: Drittanbieter nach Kategorie.
| Kategorie | Definition |
|---|---|
| Werbung | Skripts zum Ausliefern von Anzeigen oder zum Messen der Anzeigenleistung. |
| Video | Skripts, die Video-Player- und Streaming-Funktionen ermöglichen. |
| Gehostete Bibliotheken | Eine Mischung aus öffentlich gehosteten Open-Source-Bibliotheken. |
| Inhalte | Scripts von Contentanbietern oder Publisher-spezifisches Affiliate-Tracking |
| Kundenerfolg | Skripts von Kundensupport-/Marketinganbietern, die Chat- und Kontaktlösungen anbieten. |
| Hosting | Skripts von Webhosting-Plattformen. |
| Marketing | Skripts von Marketingtools, die Pop-ups, Newsletter und andere Elemente hinzufügen. |
| Sozial | Scripts, die Social-Media-Funktionen ermöglichen |
| Tag Manager | Skripts, die viele andere Skripts laden und viele Aufgaben initiieren. |
| Analysen | Skripts, mit denen Nutzer und deren Aktionen erfasst oder nachverfolgt werden können. |
| Plattform zur Cookie-Einwilligung | Skripts, mit denen Websites die Nutzereinwilligung (DSGVO, ePR, CCPA) auf fundierte und transparente Weise einholen können. |
| Utility | Skripts, die Dienstprogramme für Entwickler sind (z. B. API-Clients, Website-Monitoring, Betrugserkennung usw.) |
| Sonstiges | Verschiedene Skripts, die über einen gemeinsamen Ursprung ohne genaue Kategorie oder Zuordnung bereitgestellt werden. |
Diese Skripte und Bibliotheken von Drittanbietern ermöglichen es Webentwicklern, Standardfunktionen mithilfe bewährter Lösungen zu implementieren, anstatt das Rad neu zu erfinden. So können Drittanbieter die Entwicklungszeit verkürzen und Unternehmen dabei unterstützen, ihre Produkte schneller auf den Markt zu bringen oder zu aktualisieren. Daher ist es kein Wunder, dass für mehr als 94% aller Websites auf Computern und Mobilgeräten Drittanbieter-Websites verwendet werden.
Wie wirken sich Drittanbieter auf die Leistung aus?
Im Idealfall sind die Entwickler von Drittanbietern Experten für die von ihnen bereitgestellten Funktionen. Die meisten beliebten Drittanbieter haben mehrere Iterationen durchlaufen und man kann davon ausgehen, dass ihr Code für ihre eigenen Geschäftsziele optimiert wird, was die Leistung der Seiten mit einbezieht, für die sie verwendet werden. Wir wissen aber, dass selbst optimierte Drittanbieter die Leistung beeinflussen. Dies sind die Hauptgründe dafür:
Kosten für Größe und Skriptausführung: Drittanbieter versuchen oft, umfangreiche Funktionen bereitzustellen, indem sie einfach ein
<script>- oder<iframe>-Element in Ihre Seite einfügen. Diese Elemente rufen dann Skripts und Ressourcen ab, die sehr groß sind und deren Download und Ausführung länger dauern. Zu viel JavaScript führt dazu, dass der Hauptthread länger ausgelastet wird, das Rendern blockiert und Nutzerinteraktionen verzögert werden. Bekanntermaßen blockieren einige der wichtigsten Drittanbieter den Hauptthread von 42 ms bis 1,6 s bei mehr als 50% der analysierten Websites. Ein blockierter Hauptthread führt zu einer hohen Total Blocking Time (TBT). Dies ist einer der Messwerte, die sich auf die Leistungsbewertung der Website auswirken. Außerdem wird dadurch die Reaktion auf Nutzerinteraktionen verzögert und der Messwert Interaction to Next Paint (INP), mit dem die Reaktionsfähigkeit von Websites gemessen wird, beeinträchtigt. Daher haben die Kosten für die Skriptausführung erhebliche Auswirkungen auf die Leistung.Zahl: Websites nutzen durchschnittlich etwa 21 verschiedene Drittanbieter auf Mobilgeräten und im Web. Drittanbieter-Tags werden häufig mit Tag-Management-Tools hinzugefügt, die nicht direkt von den Technik- oder Entwicklungsteams kontrolliert werden. Nicht benötigte Tags können von anderen Teams ohne Überprüfungsprozess hinzugefügt und nie entfernt werden. Dies kann sich erheblich auf die Nutzerfreundlichkeit, die Seitengröße oder die CPU-Auslastung auswirken. Die Einrichtung eines Governance-Prozesses kann auf solche Situationen eingehen und es Entwicklern ermöglichen, die Auswirkungen der einzelnen Anbieter zu prüfen. Es wäre hilfreich, wenn die Entwickler für alle Drittanbieter entsprechende Daten zur Verfügung hätten, die eine bestimmte Funktion mit ihren Auswirkungen auf die Leistung, ihre Vorteile und ihre Nachteile zum Vergleich hätten. Eine weitere Herausforderung für Teams besteht darin, dass Drittanbieter-Tags auf vielen Websites nur in der Produktion ausgeführt werden, jedoch nicht in den Entwicklungsumgebungen. Dadurch wird es für Entwickler schwieriger, sie zu testen.
Werbenetzwerk: Da Drittanbieter von unterschiedlichen Ursprüngen gehostet werden, benötigen Browser eine größere Anzahl von Verbindungen, um Inhalte herunterzuladen. Die verschiedenen Verbindungen können den Download nicht anhand der Priorität koordinieren, was zu Netzwerkkonflikten führt. Dies kann den Seitenaufbau zusätzlich verzögern, wenn die richtigen Optimierungen nicht berücksichtigt werden.
Sequenzierung: Drittanbieter können den Hauptthread blockieren und Bandbreite für kritische Ressourcen in Anspruch nehmen. In manchen Fällen sind jedoch Drittanbieter die wichtigsten Ressourcen, die für das Rendern der Seite erforderlich sind. Wenn auf Websites mehrere Drittanbieter eingesetzt werden, ist eine optimale Sequenzierung der eigenen Ressourcen und der Ressourcen von Drittanbietern erforderlich. Webentwickler sollten die verschiedenen Optionen zur Optimierung der Sequenz kennen.
Aus diesem Grund können sich Drittanbieter auf einige oder alle Komponenten von Core Web Vitals auswirken. Die Mehrheit der Drittanbieter wirkt sich negativ auf den Largest Contentful Paint (LCP) und den First Input Delay (FID) aus. Eingebettete YouTube-Inhalte blockieren den Hauptthread bei 10% der Websites auf Mobilgeräten 4,5 Sekunden lang und bei 50% der untersuchten Websites mindestens 1,6 Sekunden. Stellen Sie sich vor, es wäre frustrierend für einen Nutzer, wenn er bei einer langsamen Verbindung auf eine Seite mit 20 solchen Skripts stößt. In der folgenden Visualisierung von thirdpartyweb.today sehen Sie die Drittanbieter, die derzeit die größten Auswirkungen auf die Leistung haben.
„Auf etwa 2.700 Ursprüngen bei den meisten 4 Millionen Websites entfallen etwa 57% der Skriptausführungszeit, wobei die Top-50-Entitäten bereits 47 % ausmachen.“ - Drittanbieter-Web
Seiten, die schnell gerendert werden und innerhalb eines angemessenen Zeitraums interaktiv werden, sind laut Core Web Vitals für eine gute Nutzererfahrung unerlässlich. Eine gute UX bedeutet oft ein gutes Geschäft für Websites und somit auch ein gutes Geschäft für Drittanbieter. Eine Zusammenarbeit zur Reduzierung der Auswirkungen Dritter kann von Vorteil für alle Beteiligten sein.
Uns ist bewusst, dass Google eine Reihe häufig verwendeter Drittanbieter-Skripts anbietet, darunter Google Tag Manager, YouTube-Einbettungen und reCAPTCHA, um nur einige zu nennen. Uns ist bewusst, dass sich einige unserer Skripts möglicherweise weniger stark auf die Core Web Vitals auswirken, und wir arbeiten daran, diese Auswirkungen nach Möglichkeit zu verbessern.
Wie kann Chrome Ihnen dabei helfen?
Ressourcen von Drittanbietern mit schlechter Leistung stellen für Entwickler häufig eine Herausforderung dar, die eine schrittweise Änderung der zugrunde liegenden Systemdynamik erfordert. Chrome möchte diesen Bereich untersuchen, um folgende Ziele zu erreichen:
Finden Sie bessere Möglichkeiten, um Ressourcen von Drittanbietern im Web zu laden, ohne dabei die Nutzererfahrung oder die Geschäftsergebnisse zu beeinträchtigen.
Wir wissen, dass wir diese Bemühungen nur dann fortsetzen können, wenn wir nicht mit Partnern, Unternehmen, Dritten und Entwicklern zusammenarbeiten. Wir möchten ein offenes Feld schaffen, in dem die Möglichkeiten diskutiert und Ideen über öffentliche Erklärungen und Spezifikationen ausgetauscht werden können. Entwickler haben Zeit, Feedback zu geben und die Auswirkungen vieler dieser Vorschläge zu testen.
Ermöglichen Sie Nutzern von Drittanbieter-Scripts eine bessere Zuordnung ihrer Kosten in Tools und vor Ort, klare, gut befestigte Nutzungspfade und bessere Anreize während der Erstellungszeit, damit sie von vornherein optimal funktionieren.
Wir möchten alle Ebenen wie User-Agents, Frameworks und Drittanbieter-Scripts verbessern, um die Leistung von Drittanbietern zu reduzieren. Wir beabsichtigen außerdem, ausreichende Informationen bereitzustellen, um Websiteinhaber bei der Anwendung von Best Practices für jedes eingebettete Skript zu unterstützen, einschließlich schnellerer Alternativen gegebenenfalls.
Vorgeschlagener Ansatz
Wir schlagen einen dreigleisigen Ansatz vor, um diese Ergebnisse zu erzielen...
**Geben Sie Entwicklern über RUM und die Entwicklertools von Chrome eine tiefere Quellenangabe zu den Auswirkungen des Drittanbieters.**
RUM bezieht sich auf echte Nutzermesswertdaten (auch als Felddaten bezeichnet), die über Web Performance Monitoring APIs verfügbar sind. Zu den Chrome-Entwicklertools gehören Lighthouse, die Chrome-Entwicklertools und der Bericht zur Nutzererfahrung in Chrome. Wir schlagen vor, die verfügbaren APIs und Tools zu verbessern, damit Website-Entwickler die Auswirkungen jedes Drittanbieters, den sie auf jeder Seite verwendet haben, nachvollziehen können. Die Tools informieren sie auch über Maßnahmen, mit denen die Auswirkungen abgemildert werden können (z. B. indem sie sie zurückstellen oder Fassaden verwenden) und andere mögliche Lösungen (andere Drittanbieter oder Heimwerker) mit Kompromissen finden. Für die APIs zur Überwachung der Webleistung suchen wir nach Möglichkeiten, wie wir die Abdeckung von ursprungsübergreifenden Ressourcen erweitern können, ohne den Datenschutz und die Sicherheit unserer Nutzer zu gefährden.
**Geben Sie Unternehmen einen gut beleuchteten Pfad zum effizienten Laden von Drittanbieterressourcen.**
Wir möchten neue Standards vorschlagen, die Browser dazu anregen, intelligentere Kompromisse zwischen dem Laden von Erstanbieter- und Drittanbieter-Ressourcen zu finden, um die Ladezeiten für die Nutzer zu verbessern. Später werden wir einige dieser Vorschläge hervorheben, z. B. standardmäßig das Lazy Loading von Einbettungen von Drittanbietern oder die Anwendung unterschiedlicher Ressourcenpriorisierung für Drittanbieterressourcen, die für die Nutzer anfangs am wichtigsten sind. Das sind nur einige der Ideen, die wir in diesem Bereich gerade testen. Wir würden uns sehr freuen, wenn wir mit Experten für Webleistung und der Community zusammenarbeiten würden.
Ähnlich möchten wir solche Probleme in JavaScript-Frameworks und Content-Management-Systemen (CMS) angehen, wo es besser passt. Projekte wie Aurora und das WordPress Performance Team haben uns gezeigt, wie wichtig integrierte Standardeinstellungen sind, mit denen sich bekannte Probleme beim Laden lösen lassen. Durch die in Frameworks und CMS verankerten Standards können Unternehmen einen gut beleuchteten Weg finden. Sie können auch für den User-Agent (z. B. Chrome) hilfreich sein, um Heuristiken anzuwenden, um den Seitenaufbau und den CWV zu optimieren. Solche Hinweise können dem User-Agent helfen zu entscheiden, wann und wie bestimmte Drittanbieter im Seitenlebenszyklus laden sollen. So ist beispielsweise die Next.js-Skriptkomponente standardmäßig integriert, damit sie Skripts von Drittanbietern laden können, sobald die Seite interaktiv wird.
**Geben Sie Drittanbietern Anreize, um durch bessere Transparenz ihre Auswirkungen auf die Leistung zu verringern.**
Drittanbieter-Entwicklern fehlt derzeit der Überblick, um die Auswirkungen ihrer Skripts auf Websites als Ganzes 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 Wert bieten. Wir möchten sie auch dabei unterstützen, anhand der Daten die Ursachen der Auswirkungen zu diagnostizieren, damit sie diese vorgelagerten Risiken mindern können. Wir müssen alle Dritten, einschließlich der von Google verfassten, auf den Erfolg hinweisen.
Challenges
Ein Anstrengung dieser Größenordnung bringt Herausforderungen mit sich. Hier sind einige der größten Herausforderungen, die wir berücksichtigen müssen.
- Drittanbieter sind ein übergreifendes Problem, das Anzeigen, Analysen, Tag-Management, Dienstprogramme und viele andere umfasst. Für jeden Bereich müssen spezifische Anforderungen und Vor- und Nachteile berücksichtigt werden. Beispiel:
- Die Entscheidung, das Laden von Anzeigen zu optimieren, hängt von einem Kompromiss zwischen Umsatz und Nutzererfahrung ab. Zu früh blockierten sie wertvolle Inhalte. Zu spät würden sie dem Nutzer nicht angezeigt werden.
- Analytics-Skripts erhöhen die Seitenstärke, liefern aber wertvolle Daten zu Nutzeraktionen für das Unternehmen.
Wir hoffen, mit verschiedenen Kategorien von Drittanbietern zusammenzuarbeiten, die Feinheiten zu verstehen, Kompromisse zu schließen und Anreize zu entwickeln, die für alle funktionieren. Uns ist bewusst, dass wir mit verschiedenen Unternehmen in allen Bereichen zusammenarbeiten müssen, damit unsere Strategie effektiv ist. Dazu gehören unsere internen Partner wie Google Tag Manager, Google Ads und YouTube.
Wir möchten sowohl Website-Entwicklern als auch Drittanbieter-Entwicklern eine tiefere Quellenangabe hinzufügen. Dies erfordert gewissenhafte Bemühungen, bei denen wir ermitteln, welche Daten für die Messung der Wirkung am relevantesten sind, sie genau und detailliert zuordnen und den richtigen Weg für die Zukunft aufzeigen. Letztlich sollte die Berechnung, wie ein bestimmter Drittanbieter im Vergleich zu der Konkurrenz abschneidet, für alle transparent sein.
Wir schlagen vor, Chrome so zu verbessern, dass Optimierungen vorgenommen werden können, um das richtige Gleichgewicht beim Laden von eigenen Ressourcen im Vergleich zu Drittanbieterressourcen zu finden. Eine wertvolle Änderung wird standardmäßig in allen Browsern übernommen, die jedoch einige Zeit in Anspruch nimmt. Das Attribut
loadingfür die Elemente<img>und<iframe>ist beispielsweise seit 2019 in Chrome/Edge verfügbar, in Safari wurde es beispielsweise erst seit 2022 verfügbar. Bis eine Funktion standardisiert ist, müssen Nutzer von Drittanbieter-Ressourcen sicherstellen, dass sie auch für andere Browser optimiert sind. Sofern relevant, heben wir dies in unseren Anleitungen hervor.Um dieses Projekt durchzuführen, müssen wir mit Partnern und Entwicklern zusammenarbeiten, um nicht nur spezifische Anforderungen zu verstehen, sondern auch in großem Maßstab experimentelle Lösungen zu testen, Feedback zu geben, nach Bedarf zu iterieren und zu improvisieren. Die Änderungen müssen geplant werden und einen angemessenen Zeitrahmen für Tests und Bewertungen einräumen.
Erste Standardvorschläge
Wir haben einige erste Experimente durchgeführt, um Funktionen zu entwickeln, mit denen sich der Ladeprozess von Drittanbietern optimieren lässt. Wir sind mit den Ergebnissen sehr zufrieden und können derzeit zwei dieser Funktionen erörtern.
LazyEmbeds
Früher hat Chrome für Nutzer im Lite-Modus aus dem Bildschirm die <img>- und <iframe>-Elemente per Lazy Loading geladen. Diese Funktion könnte für alle Nutzer ausgeweitet werden, um das Laden von <iframe>-Elementen, die als Einbettungen von Drittanbietern eingestuft wurden, zu verzögern, bis der Nutzer durch Scrollen zu ihnen scrollt. Dadurch können andere Teile der Seite schneller geladen, Core Web Vitals verbessert, Arbeitsspeichernutzung reduziert und Daten gespart werden.
Hier ist eine Demo, die LazyEmbeds verwendet, um YouTube-Videos auf einer Seite per Lazy Loading zu laden. Durch ein einzelnes YouTube-Video werden in der Regel 500–600 KB JavaScript auf der Seite eingefügt. Wir haben versucht, einen Blogpost mit 14 solchen Videoeinbettungen mithilfe von LazyEmbeds zu optimieren. Die Ergebnisse waren vielversprechend, was die Seitenladezeit und die Datenersparnis angeht.
| Vorher | Nachher | |
|---|---|---|
| Daten | 15,4 MB | 6,1 MB |
| Total Blocking Time | 3,2 Sekunden | 1,6 Sekunden |
Weitere Informationen finden Sie im Intent-to-Experiment-Thread und in der Erweiterung für Tests.
Gezielte Drosselung durch Drittanbieter
Drittanbieter-Skripte werden oft von verschiedenen Teams ohne ganzheitliche Überwachungsprozesse hinzugefügt. Das Engineering-Team bei The Telegraph sagte, dass „jeder ‚dieses Tag‘ auf einer Seite möchte, mit der das Unternehmen Geld verdient“. Dadurch kann der Verwaltungsaufwand für die Auswirkungen auf die Leistung kontinuierlich erhöht werden.
Bei der gezielten Drittanbieter-Skriptdrosselung wird vorgeschlagen, sehr spezifische Arten von Drittanbieter zu drosseln, um deren Auswirkungen zu verringern. Auf diese Weise können Browser wichtige Inhalte und kritische Drittanbieter frühzeitig laden, während Browser, die sicher später geladen werden können, gedrosselt werden.
RUM APIs werden optimiert
Wir erwägen auch, die RUM APIs um Informationen zu erweitern, die für die Bewertung der Leistung von Drittanbietern relevant sind. Zu den Verbesserungen gehören:
<iframe>-Berichte: Wir arbeiten an Lösungen, bei denen die Performance Timeline API für frameübergreifende Berichte genutzt werden kann. So können die Autoren der Seite auf oberster Ebene Leistungsdaten für einen kooperativen Drittanbieter-iFrame einsehen, der in die Seite eingebettet ist.Zuordnung langer Aufgaben: Die Long Tasks API in RUM hilft Websiteinhabern, lange Aufgaben zu identifizieren, die den Hauptthread eine lange Zeit binden und Interaktionen verzögern.
Weitere Updates
Wir experimentieren noch mit vielen solcher Ideen und hoffen, im Laufe der Zeit GitHub-Erklärungen und Spezifikationsentwürfe für Änderungen veröffentlichen zu können. Drittanbieter und Websiteinhaber, die eine Partnerschaft mit uns eingehen oder Feedback geben möchten, können über diese Tools an Diskussionen teilnehmen. Drittanbieter können sich auch auf die Optimierung im Hinblick auf Core Web Vitals- und INP-Messwerte konzentrieren, damit ihnen keine schlechten Core Web Vitals-/INP-Daten zugeordnet werden. Wer aktiv nach Updates sucht, kann sich vorerst über Beiträge in der Gruppe blink-dev informieren.
Wir freuen uns darauf, diesen Problembereich weiter zu untersuchen und mit der Community über unsere Erkenntnisse zu sprechen.
Ein besonderer Dank geht an 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.