Diese Seite wurde von der Cloud Translation API übersetzt.

„document.write()“ eingreifen

Paul Kinlan

Haben Sie kürzlich in Ihrer Developer Console eine Warnung wie die folgende gesehen: Chrome und haben sich gefragt, was das ist?

(index):34 A Parser-blocking, cross-origin script,
https://paul.kinlan.me/ad-inject.js, is invoked via document.write().
This may be blocked by the browser if the device has poor network connectivity.

Zusammensetzbarkeit ist eine der großen Möglichkeiten des Webs. Sie ermöglicht es uns, Integration in Dienste, die von Drittanbietern entwickelt wurden, um großartige neue Produkte zu entwickeln! Eins der Nachteile der Zusammensetzbarkeit besteht darin, dass sie eine gemeinsame Verantwortung die User Experience. Wenn die Integration nicht optimal ist, beeinträchtigt werden.

Ein bekannter Grund für eine schlechte Leistung ist die Verwendung von document.write() innerhalb von Seiten, insbesondere die Verwendung, die Skripte einschleust. So harmlos das Folgende aussieht, zu echten Problemen für Nutzende führen.

document.write('<script src="https://example.com/ad-inject.js"></script>');

Bevor der Browser eine Seite rendern kann, muss er die DOM-Baumstruktur erstellen, indem er das HTML-Markup parst. Immer wenn der Parser auf ein Skript stößt, muss er es anhalten und ausführen, bevor er fortfahren kann beim Parsen des HTML-Codes. Wenn das Skript dynamisch ein anderes Skript einfügt, wird der Parser gezwungen zu warten. noch länger dauert, bis die Ressource heruntergeladen ist, was einen oder mehrere Netzwerk-Roundtrips und die Zeit bis zum ersten Rendern der Seite verzögern

Für Nutzer mit langsamen Verbindungen wie 2G werden externe Skripts über document.write() eingeschleust, kann die Anzeige des Hauptseiteninhalts für oder dazu führen, dass die Seiten entweder gar nicht geladen werden oder so lange dauern, die Nutzenden aufgeben. Anhand der Instrumentierung in Chrome haben wir gelernt, Seiten mit über document.write() eingefügten Drittanbieter-Skripts sind mit einer 2G-Verbindung normalerweise doppelt so langsam geladen werden wie andere 2G-Seiten.

Wir haben im Rahmen eines 28-tägigen Field Trials für 1% der Chrome-Nutzer Daten erhoben. stabile Nutzer, beschränkt auf Nutzer mit 2G-Verbindungen. 7,6% aller Seitenaufbauvorgänge in 2G mindestens ein websiteübergreifendes Parser-Blocking-Skript enthalten, über document.write() in das Dokument auf oberster Ebene eingefügt. Aufgrund der Blockierung wurden folgende Verbesserungen erzielt:

10% mehr Seitenladevorgänge bis First Contentful Paint (eine visuelle Bestätigung für den Nutzer, dass die Seite effektiv geladen wird) 25% mehr Seitenladevorgänge, die den vollständig geparsten Status erreichen, und 10% weniger Neuladevorgänge was auf eine geringere Frustration bei den Nutzenden hindeutet.
21% Verringerung der mittleren Zeit (über eine Sekunde schneller) bis zum First Contentful Paint
38% Reduzierung der durchschnittlichen Parsing-Zeit einer Seite. Dies entspricht einem eine Verbesserung um fast sechs Sekunden, damit Nutzern präsentiert werden können, was ihnen wichtig ist.

Aufgrund dieser Daten wird Chrome ab Version 55 eingreift im Namen aller wenn wir dieses bekannte schlechte Muster erkennen, indem wir die document.write() die in Chrome verarbeitet werden (siehe Chrome-Status). Insbesondere führt Chrome keine <script>-Elemente aus, die über document.write(), wenn alle folgenden Bedingungen erfüllt sind:

Der Nutzer hat eine langsame Verbindung, insbesondere wenn er 2G verwendet. (In möglicherweise auch auf andere Nutzer mit langsamen Verbindungen ausgeweitet, wie langsames 3G oder langsames WLAN.
Die Datei document.write() befindet sich in einem Dokument auf oberster Ebene. Die Maßnahme können auch auf „document.Writing“-Skripts in iFrames angewendet werden, da diese die für das Rendering der Hauptseite.
Das Skript im document.write() blockiert den Parser. Skripts mit async oder "defer" weiterhin ausgeführt werden.
Das Skript wird nicht auf derselben Website gehostet. Mit anderen Worten: nicht bei Skripts mit einer übereinstimmenden eTLD+1 eingreifen (z.B. ein auf js.example.org auf www.example.org eingefügt).
Das Skript befindet sich nicht bereits im HTTP-Cache des Browsers. Skripts im Cache keine Netzwerkverzögerung und wird trotzdem ausgeführt.
Bei der Anfrage für die Seite handelt es sich nicht um eine Aktualisierung. Chrome greift nicht ein, wenn der -Nutzer hat eine Aktualisierung ausgelöst und führt die Seite wie gewohnt aus.

Drittanbieter-Snippets verwenden manchmal document.write(), um Skripts zu laden. Glücklicherweise bieten die meisten Drittanbieter asynchrone Ladealternativen verwenden, die das Laden von Drittanbieter-Skripts zulassen, ohne die Anzeige der für den Inhalt der Seite.

Wie kann ich das beheben?

Diese einfache Antwort lautet: Fügen Sie keine Skripts mit document.write() ein. Mi. Verwaltung mehrerer bekannter Dienste zur Unterstützung des asynchronen Ladeprogramms sollten Sie dies regelmäßig überprüfen.

Wenn Ihr Anbieter nicht in der Liste aufgeführt ist und das asynchrone Laden von Skripts unterstützt Dann informieren Sie uns bitte darüber, damit wir die Seite aktualisieren, um allen Nutzern zu helfen.

Wenn Ihr Anbieter das asynchrone Laden von Skripts nicht unterstützt auf Ihrer Seite ein, dann wenden Sie sich bitte an informieren Sie uns bitte wie sie betroffen sein werden.

Wenn du von deinem Anbieter ein Snippet mit document.write() erhältst, können Sie dem Skriptelement möglicherweise ein async-Attribut hinzufügen oder können Sie die Skriptelemente mit DOM-APIs wie document.appendChild() hinzufügen. oder parentNode.insertBefore().

So erkennen Sie, wann Ihre Website betroffen ist

Ob die Einschränkung erzwungen wird, hängt von vielen Kriterien ab. Woher wissen Sie also, ob Sie betroffen sind?

Erkennen, wenn ein Nutzer 2G verwendet

Um die möglichen Auswirkungen dieser Änderung zu verstehen, müssen Sie zunächst verstehen, wie viele Ihrer Nutzer 2G nutzen werden. Sie können den aktuellen Netzwerktyp des Nutzers ermitteln mit der Network Information API optimieren, ist in Chrome verfügbar. Sie erhalten dann eine Mitteilung zu Ihren Analyse- oder echten Nutzermesswerten. (RUM-Systemen).

if(navigator.connection &&
    navigator.connection.type === 'cellular' &&
    navigator.connection.downlinkMax <= 0.115) {
    // Notify your service to indicate that you might be affected by this restriction.
}

Warnungen in den Chrome-Entwicklertools abfangen

Seit Chrome 53 gibt die Entwicklertools Warnungen für problematische document.write() aus Aussagen. Wenn eine document.write()-Anfrage die Kriterien 2 bis 5 erfüllt, (Chrome ignoriert die Verbindungskriterien beim Senden dieser Warnung) etwa so aus:

Warnungen in den Chrome-Entwicklertools sind toll, aber wie erkennt man das unter Skalierung? Sie können nach HTTP-Headern suchen, die an Ihren Server gesendet werden, wenn der der Intervention.

Hinweis:Sie können „2G“ aktivieren. in den Chrome-Entwicklertools, aber in Chrome 55 die Intervention auslösen. Die beste Option ist, diese Aufforderung mit chrome://flags/#disallow-doc-written-script-loads.

Hinweis:Eine der Heuristiken für diesen Eingriff, um festzustellen, ob sich die Datei nicht bereits im Cache Mit den Entwicklertools kannst du den Cache deaktivieren. Das onerror-Ereignis wird jedoch nicht angezeigt. für das ausgelöste Skriptelement. Sie sehen es jedoch, wenn Sie Entwicklertools. Dieses Problem wurde in Chrome 56 behoben.

HTTP-Header in der Skriptressource prüfen

Wenn ein über document.write eingefügtes Script blockiert wird, sendet Chrome die Meldung folgenden Header an die angeforderte Ressource:

Intervention: <https://shorturl/relevant/spec>;

Wenn ein über document.write eingefügtes Script gefunden wird und blockiert werden könnte in kann Chrome Folgendes senden:

Intervention: <https://shorturl/relevant/spec>; level="warning"

Der Interventionsheader wird als Teil der GET-Anfrage an das Skript gesendet (asynchron im Falle einer tatsächlichen Intervention).

Was wird die Zukunft bringen?

Der anfängliche Plan besteht darin, diese Maßnahme auszuführen, wenn wir die Kriterien ermittelt haben. erfüllt werden. Zunächst wurde in der Developer Console in Chrome 53 nur eine Warnung angezeigt. Die Betaversion wurde im Juli 2016 eingeführt. Die stabile Version wird voraussichtlich für alle Nutzer in folgendem Land verfügbar sein: September 2016)

Wir werden eingeschleuste Skripts für 2G-Nutzer blockieren, die vorläufig Chrome 54, das voraussichtlich in einer stabilen Version für alle Nutzer in Mitte Oktober 2016. In der Chrome-Statuseintrag .

Im Laufe der Zeit versuchen wir, einzugreifen, wenn Nutzer eine langsame Verbindung haben (z. B. langsames 3G oder WLAN). Folgen Sie diesem Eintrag zum Chrome-Status.

Möchten Sie mehr erfahren?

Weitere Informationen finden Sie in diesen zusätzlichen Ressourcen: