Selbsthostende Ressourcen von Drittanbietern: das Gute, das Schlechte, das Hässliche

In den letzten Jahren bieten immer mehr Plattformen zur Optimierung von Frontend-Projekten Möglichkeiten zum Selbsthosting oder Proxying von Ressourcen Dritter. Mit Akamai können Sie festlegen spezifische Parameter für selbstgenerierte URLs. Cloudflare verfügt über Edge Workers-Technologie. Fasterzine kann umschreiben URLs auf Seiten, sodass sie auf Ressourcen von Drittanbietern verweisen, die sich in der Hauptdomäne der Website befinden.

Wenn Sie wissen, dass sich die in Ihrem Projekt verwendeten Dienste von Drittanbietern nicht sehr oft ändern und dass der Prozess ihrer Bereitstellung für Kunden verbessert werden könnte, dann denken Sie wahrscheinlich darüber nach, solche Dienste als Proxy bereitzustellen. Mit diesem Ansatz können Sie diese Ressourcen sehr gut näher an Ihre Benutzer bringen und eine umfassendere Kontrolle über deren Caching auf der Clientseite erlangen. Darüber hinaus können Sie Benutzer vor Problemen schützen, die durch den „Absturz“ eines Drittanbieterdienstes oder eine Verschlechterung seiner Leistung verursacht werden.

Gut: Verbesserte Leistung

Das Selbsthosten der Ressourcen einer anderen Person verbessert die Leistung auf ganz offensichtliche Weise. Der Browser muss nicht erneut auf DNS zugreifen, keine TCP-Verbindung herstellen und keinen TLS-Handshake auf einer Drittanbieterdomäne durchführen. Sie können sehen, wie sich das Selbsthosten der Ressourcen einer anderen Person auf die Leistung auswirkt, indem Sie die folgenden beiden Zahlen vergleichen.

Ressourcen Dritter werden von externen Quellen heruntergeladen (entnommen von daher)

Ressourcen von Drittanbietern werden am selben Ort gespeichert wie die übrigen Materialien der Website (entnommen von daher)

Die Situation wird auch dadurch verbessert, dass der Browser die Möglichkeit nutzt, Daten aus der bereits mit der Hauptdomäne bestehenden HTTP/2-Verbindung zu multiplexen und zu priorisieren.

Wenn Sie keine Ressourcen von Drittanbietern hosten, können diese nicht priorisiert werden, da sie von einer anderen Domäne als der Hauptdomäne geladen werden. Dies führt dazu, dass sie miteinander um die Bandbreite des Clients konkurrieren. Dies kann dazu führen, dass die Ladezeiten für Inhalte, die für den Aufbau einer Seite wichtig sind, viel länger sind, als es unter idealen Umständen möglich wäre. Hier Vortrag über HTTP/2-Priorisierung, der das alles sehr gut erklärt.

Es kann davon ausgegangen werden, dass die Verwendung von Attributen in Links zu externen Ressourcen erfolgt preconnect wird bei der Lösung des Problems helfen. Wenn jedoch zu viele dieser Links zu unterschiedlichen Domänen vorhanden sind, kann es im entscheidenden Moment tatsächlich zu einer Überlastung der Kommunikationsleitung kommen.

Wenn Sie selbst Ressourcen von Drittanbietern hosten, können Sie steuern, wie genau diese Ressourcen dem Kunden zur Verfügung gestellt werden. Es geht nämlich um Folgendes:

• Sie können sicherstellen, dass der für den jeweiligen Browser am besten geeignete Datenkomprimierungsalgorithmus verwendet wird (Brotli/gzip).
• Sie können die Caching-Zeit für Ressourcen, die normalerweise nicht besonders lang sind, auch bei den bekanntesten Anbietern erhöhen (z. B. ist der entsprechende Wert für das GA-Tag auf 30 Minuten gesetzt).

Sie können die TTL für eine Ressource sogar auf beispielsweise ein Jahr verlängern, indem Sie relevante Inhalte in Ihre Caching-Verwaltungsstrategie (URL-Hashes, Versionierung usw.) integrieren. Wir werden weiter unten darüber sprechen.

▍Schutz vor Unterbrechungen des Betriebs von Diensten Dritter oder deren Abschaltung

Ein weiterer interessanter Aspekt des Selbsthostings von Drittanbieterressourcen besteht darin, dass Sie damit die mit Ausfällen von Drittanbieterdiensten verbundenen Risiken mindern können. Nehmen wir an, dass die von Ihnen verwendete A/B-Testlösung eines Drittanbieters als Blockierungsskript implementiert ist, das im Kopfbereich der Seite geladen wird. Dieses Skript wird langsam geladen. Wenn das entsprechende Skript nicht geladen werden kann, ist die Seite leer. Wenn das Laden sehr lange dauert, erscheint die Seite mit großer Verzögerung. Oder nehmen wir an, das Projekt verwendet eine Bibliothek, die von einer CDN-Ressource eines Drittanbieters heruntergeladen wurde. Stellen wir uns vor, dass diese Ressource in einem bestimmten Land ausgefallen ist oder blockiert wurde. Eine solche Situation führt zu einem Verstoß gegen die Logik der Website.

Um herauszufinden, wie Ihre Website funktioniert, wenn ein externer Dienst nicht verfügbar ist, können Sie den SPOF-Bereich verwenden webpagetest.org.

SPOF-Bereich auf webpagetest.org

▍Was ist mit Problemen beim Zwischenspeichern von Materialien in Browsern? (Hinweis: Es ist ein Mythos)

Man könnte meinen, dass die Verwendung öffentlicher CDNs automatisch zu einer besseren Ressourcenleistung führen würde, da diese Dienste über relativ hochwertige Netzwerke verfügen und auf der ganzen Welt verteilt sind. Aber eigentlich ist alles etwas komplizierter.

Nehmen wir an, wir haben mehrere verschiedene Websites: website1.com, website2.com, website3.com. Alle diese Websites verwenden die jQuery-Bibliothek. Wir verbinden es beispielsweise über ein CDN mit ihnen – googleapis.com. Sie können davon ausgehen, dass der Browser die Bibliothek einmal herunterlädt, zwischenspeichert und sie dann auf allen drei Websites verwendet. Dies könnte die Belastung des Netzwerks verringern. Vielleicht können Sie dadurch irgendwo Geld sparen und die Ressourcenleistung verbessern. Aus praktischer Sicht sieht alles anders aus. Safari verfügt beispielsweise über eine Funktion namens Intelligente Tracking-Prävention: Der Cache verwendet Doppelschlüssel basierend auf der Quelle des Dokuments und der Quelle der Ressource eines Drittanbieters. Hier guter Artikel zu diesem Thema.

alte Studien Yahoo и Facebook, sowie neuere Studie Paul Calvano zeigen, dass Ressourcen nicht so lange in Browser-Caches gespeichert werden, wie wir es erwarten würden: „Es besteht eine erhebliche Lücke zwischen der Caching-Zeit der eigenen Ressourcen eines Projekts und denen von Drittanbietern.“ Die Rede ist von CSS und Webfonts. Das heißt, 95 % der nativen Schriftarten haben eine Cache-Lebensdauer von mehr als einer Woche, während 50 % der Schriftarten von Drittanbietern eine Cache-Lebensdauer von weniger als einer Woche haben! Dies gibt Webentwicklern einen überzeugenden Grund, Schriftartdateien selbst zu hosten!“

Wenn Sie also Inhalte anderer Personen hosten, werden Sie keine Leistungsprobleme bemerken, die durch das Browser-Caching verursacht werden.

Nachdem wir uns nun mit den Stärken des Drittanbieter-Selbsthostings befasst haben, wollen wir darüber sprechen, wie man eine gute Implementierung dieses Ansatzes von einer schlechten unterscheiden kann.

Das Schlechte: Der Teufel steckt im Detail

Das Verschieben von Ressourcen von Drittanbietern in Ihre eigene Domäne kann nicht automatisch erfolgen, ohne sicherzustellen, dass diese Ressourcen ordnungsgemäß zwischengespeichert werden.

Eines der Hauptprobleme hierbei ist die Caching-Zeit. Versionsinformationen sind beispielsweise in Skriptnamen von Drittanbietern wie folgt enthalten: jquery-3.4.1.js. Eine solche Datei wird sich in Zukunft nicht ändern und daher keine Probleme bei der Zwischenspeicherung verursachen.

Wenn bei der Arbeit mit Dateien jedoch kein Versionierungsschema verwendet wird, können zwischengespeicherte Skripts, deren Inhalt sich ändert, während der Dateiname unverändert bleibt, veraltet sein. Dies kann ein ernstes Problem darstellen, da es beispielsweise nicht möglich ist, automatisierte Sicherheitspatches zu Skripten hinzuzufügen, die Clients so schnell wie möglich erhalten müssen. Der Entwickler muss sich Mühe geben, solche Skripte im Cache zu aktualisieren. Darüber hinaus kann es zu Anwendungsfehlern kommen, da der auf dem Client verwendete Code aus dem Cache von der neuesten Version des Codes abweicht, für den der Serverteil des Projekts ausgelegt ist.

Wenn es sich zwar um Materialien handelt, die häufig aktualisiert werden (Tag-Manager, Lösungen für A/B-Tests), dann ist deren Zwischenspeicherung mithilfe von CDN-Tools eine lösbare, aber viel komplexere Aufgabe. Dienste wie Commanders Act, eine Tag-Management-Lösung, verwenden Webhooks bei der Veröffentlichung neuer Versionen. Dies gibt Ihnen die Möglichkeit, eine Cache-Leerung im CDN zu erzwingen oder, noch besser, eine Hash- oder URL-Aktualisierung zu erzwingen.

▍Adaptive Bereitstellung von Materialien an Kunden

Wenn wir über Caching sprechen, müssen wir außerdem die Tatsache berücksichtigen, dass die im CDN verwendeten Caching-Einstellungen möglicherweise nicht für einige Ressourcen von Drittanbietern geeignet sind. Beispielsweise können solche Ressourcen die User-Agent-Sniffing-Technologie (Adaptive Serving) nutzen, um bestimmte Browser mit Inhaltsversionen zu versorgen, die speziell für diese Browser optimiert sind. Diese Technologien basieren auf regulären Ausdrücken oder einer Datenbank, die HTTP-Header-Informationen sammelt, um die Fähigkeiten des Browsers herauszufinden. User-Agent. Sobald sie wissen, mit welchem ​​Browser sie es zu tun haben, stellen sie ihm die dafür konzipierten Materialien zur Verfügung.

Hier können Sie sich an zwei Gottesdienste erinnern. Die erste ist googlefonts.com. Der zweite ist polyfill.io. Der Google Fonts-Dienst stellt für eine bestimmte Ressource verschiedene CSS-Codes bereit, abhängig von den Fähigkeiten des Browsers (und stellt Links zu woff2-Ressourcen bereit, die verwendet werden). unicode-range).

Hier sind die Ergebnisse einiger Google Fonts-Abfragen, die von verschiedenen Browsern aus durchgeführt wurden.

Google Fonts-Abfrageergebnis von Chrome

Google Fonts-Abfrageergebnis von IE10

Polyfill.io stellt dem Browser nur die Polyfills zur Verfügung, die er benötigt. Dies erfolgt aus Performancegründen.

Schauen wir uns zum Beispiel an, was passiert, wenn Sie die folgende Anfrage in verschiedenen Browsern ausführen: https://polyfill.io/v3/polyfill.js?features=default

Als Antwort auf eine solche vom IE10 ausgeführte Anfrage werden 34 KB Daten empfangen. Und die von Chrome ausgeführte Antwort darauf wird leer sein.

Wütend: Einige Überlegungen zum Datenschutz

Dieser Punkt ist der letzte, aber nicht der unwichtigste. Der Punkt ist, dass das Selbsthosten von Ressourcen Dritter auf der Hauptdomain des Projekts oder seiner Subdomain die Privatsphäre der Benutzer gefährden und sich negativ auf das Hauptwebprojekt auswirken kann.

Wenn Ihr CDN-System nicht richtig konfiguriert ist, kann es sein, dass Sie die Cookies Ihrer Domain an einen Drittanbieter senden. Wenn auf CDN-Ebene keine ordnungsgemäße Filterung organisiert ist, werden Ihre Sitzungscookies, die normalerweise nicht in JavaScript verwendet werden können (mit dem httponly), kann an einen ausländischen Host gesendet werden.

Genau das kann bei Trackern wie Eulerian oder Criteo passieren. Drittanbieter-Tracker haben möglicherweise eine eindeutige Kennung im Cookie festgelegt. Wenn sie Teil von Site-Materialien wären, könnten sie die Kennung nach eigenem Ermessen lesen, während der Benutzer mit verschiedenen Webressourcen arbeitete.

Heutzutage verfügen die meisten Browser über einen Schutz gegen diese Art von Tracker-Verhalten. Aus diesem Grund verwenden Tracker jetzt Technologie CNAME-Tarnung, getarnt als eigene Skripte für verschiedene Projekte. Tracker bieten nämlich Websitebesitzern die Möglichkeit, ihren Einstellungen für eine bestimmte Domain einen CNAME hinzuzufügen, dessen Adresse normalerweise wie ein zufälliger Satz von Zeichen aussieht.

Obwohl es nicht empfohlen wird, Website-Cookies für alle Subdomains (z. B. *.website.com) verfügbar zu machen, tun dies viele Websites. In diesem Fall werden solche Cookies automatisch an einen getarnten Drittanbieter-Tracker gesendet. Von einer Privatsphäre kann daher nicht mehr gesprochen werden.

Das Gleiche passiert auch mit HTTP-Headern Kundenhinweise, die nur an die Hauptdomäne gesendet werden, da sie zum Erstellen verwendet werden können digitaler Fingerabdruck Benutzer. Stellen Sie sicher, dass der von Ihnen verwendete CDN-Dienst diese Header korrekt filtert.

Ergebnisse

Wenn Sie planen, demnächst das Selbsthosting von Ressourcen Dritter einzuführen, möchte ich Ihnen einige Tipps geben:

• Hosten Sie Ihre wichtigsten JS-Bibliotheken, Schriftarten und CSS-Dateien. Dadurch wird das Risiko eines Site-Ausfalls oder einer Leistungseinbuße verringert, weil eine für die Site wichtige Ressource aufgrund des Verschuldens eines Drittanbieterdienstes nicht verfügbar ist.
• Bevor Sie Ressourcen von Drittanbietern auf einem CDN zwischenspeichern, stellen Sie sicher, dass bei der Benennung ihrer Dateien eine Art Versionierungssystem verwendet wird oder dass Sie den Lebenszyklus dieser Ressourcen verwalten können, indem Sie den CDN-Cache beim Veröffentlichen einer neuen Version manuell oder automatisch zurücksetzen das Drehbuch.
• Seien Sie sehr vorsichtig mit Ihren CDN-, Proxyserver- und Cache-Einstellungen. Dadurch können Sie verhindern, dass Ihrem Projekt oder Ihren Headern Cookies gesendet werden Client-Hints Dienstleistungen Dritter.

Liebe Leser! Hosten Sie auf Ihren Servern Materialien anderer Personen, die für den Betrieb Ihrer Projekte äußerst wichtig sind?

Source: habr.com