In den letzten Jahren bieten immer mehr Plattformen zur Optimierung von Frontend-Projekten die Möglichkeit, Ressourcen selbst zu hosten oder externe Ressourcen zu proxyen. Akamai ermöglicht es, für selbst erstellte URLs festzulegen. Cloudflare hat die Technologie Edge Workers. Fasterzine kann sodass sie auf externe Ressourcen verweisen, die sich auf der Hauptdomain der Website befinden.
Wenn bekannt ist, dass die externen Dienste, die in Ihrem Projekt verwendet werden, nicht allzu häufig geändert werden, und der Prozess ihrer Bereitstellung für die Kunden verbessert werden kann, denken Sie sicherlich über das Proxying solcher Dienste nach. Bei diesem Ansatz können Sie diese Ressourcen ``näher'' zu den Benutzern bringen und eine umfassendere Kontrolle über deren Caching auf der Client-Seite erlangen. Dies schützt zudem die Nutzer vor Problemen, die durch das ``Ausfallen'' eines externen Dienstes oder eine Verschlechterung seiner Leistungsfähigkeit verursacht werden könnten.
Gut: Leistungssteigerung
Das selbstständige Hosting externer Ressourcen verbessert die Leistung auf recht offensichtliche Weise. Der Browser muss nicht erneut auf DNS zugreifen, muss keine TCP-Verbindung herstellen und kein TLS-Handshake auf einer externen Domain durchführen. Wie sich das selbstständige Hosting externer Ressourcen auf die Leistung auswirkt, kann man sehen, indem man die folgenden zwei Abbildungen vergleicht.
Externe Ressourcen werden aus externen Quellen geladen (genommen )
Externe Ressourcen werden dort gespeichert, wo auch die anderen Materialien der Website sind (genommen )
Die Situation wird zusätzlich verbessert, da der Browser die Möglichkeiten zur Multiplexierung und Priorisierung von HTTP/2-Datenverbindungen nutzt, die bereits mit der Hauptdomain hergestellt wurden.
Wenn Sie externe Ressourcen nicht selbst hosten, können diese nicht priorisiert werden, da sie von einer Domain geladen werden, die sich von der Hauptdomain unterscheidet. Dies wird dazu führen, dass sie gegeneinander um die Bandbreite des Clients konkurrieren. Dies kann dazu führen, dass die Ladezeiten von für die Seitenbildung kritischen Materialien wesentlich länger sind als in einem idealen Fall. eine Präsentation zur HTTP/2-Priorisierung, in der all dies sehr gut erklärt wird.
Es kann angenommen werden, dass die Verwendung von Attributen in Links zu externen Ressourcen preconnect bei der Lösung des Problems helfen wird. Wenn es jedoch zu viele solcher Links zu unterschiedlichen Domains gibt, kann dies tatsächlich die Verbindung in einem entscheidenden Moment überlasten.
Wenn man externe Ressourcen selbst hostet, kann man kontrollieren, wie diese Ressourcen dem Client bereitgestellt werden. Konkret geht es um Folgendes:
- Man kann sicherstellen, dass ein Datenkompressionsalgorithmus angewendet wird, der am besten für jeden Browser geeignet ist (Brotli/gzip).
- Man kann die Cache-Zeit der Ressourcen erhöhen, die selbst bei den bekanntesten Anbietern oft nicht besonders hoch ist (zum Beispiel ist der entsprechende Wert für das GA-Tag auf 30 Minuten eingestellt).
Man kann sogar den TTL-Wert für eine Ressource, beispielsweise auf ein Jahr, erweitern, indem man die entsprechenden Materialien in seine Caching-Strategie einbezieht (URL-Hashes, Versionierung usw.). Darüber werden wir gleich sprechen.
▍Schutz vor Unterbrechungen bei externen Diensten oder deren Abschaltung
Ein weiterer interessanter Aspekt des Selbsthostings externer Ressourcen liegt darin, dass es hilft, die Risiken im Zusammenhang mit Unterbrechungen bei externen Diensten zu verringern. Angenommen, die von Ihnen verwendete externe Lösung für A/B-Tests wird in Form eines blockierenden Skripts implementiert, das im Header-Bereich der Seite geladen wird. Dieses Skript wird langsam geladen. Wenn das entsprechende Skript nicht geladen werden kann, wird die Seite leer sein. Wenn das Laden lange dauert, erscheint die Seite mit großer Verzögerung. Oder nehmen wir an, im Projekt wird eine Bibliothek verwendet, die von einem externen CDN geladen wird. Stellen Sie sich vor, dieser Dienst hat einen Ausfall erlitten oder wurde in einem bestimmten Land blockiert. Eine solche Situation würde die Logik der Website beeinträchtigen.
Um herauszufinden, wie Ihre Website in den Fällen funktioniert, in denen ein externer Dienst nicht verfügbar ist, können Sie den Abschnitt SPOF auf .
Der SPOF-Abschnitt auf webpagetest.org
▍Und was ist mit Problemen beim Caching von Materialien in Browsern? (Hinweis: Das ist ein Mythos)
Man könnte denken, dass die Verwendung öffentlicher CDNs automatisch zu einer besseren Leistung von Ressourcen führt, da diese Dienste über qualitativ hochwertige Netzwerke verfügen und weltweit verteilt sind. Doch in Wirklichkeit ist alles etwas komplizierter.
Angenommen, wir haben mehrere verschiedene Websites: website1.com, website2.com, website3.com. Auf all diesen Websites verwenden wir die jQuery-Bibliothek. Wir binden sie über ein CDN ein, beispielsweise — googleapis.com. Man könnte erwarten, dass der Browser die Bibliothek einmal lädt und im Cache speichert, und sie dann bei der Arbeit mit allen drei Websites verwendet. Das könnte die Netzwerkbelastung verringern. Möglicherweise spart das irgendwo Kosten und hilft, die Leistung der Ressourcen zu verbessern. Aus praktischer Sicht sieht es jedoch anders aus. Zum Beispiel ist im Safari-Browser eine Funktion implementiert, die : Im Cache werden doppelte Schlüssel verwendet, die auf der Dokumentquelle und der Quelle der Drittanbieter-Ressource basieren. ein guter Artikel zu diesem Thema.
Ältere Studien und , sowie neuere von Paula Calvano zeigen, dass Ressourcen nicht so lange in den Browser-Caches gespeichert werden, wie wir erwarten könnten: "Es gibt eine erhebliche Kluft zwischen der Cache-Dauer eigener und fremder Ressourcen eines Projekts. Dies gilt für CSS und Webfonts. Genauer gesagt, die Cache-Dauer von 95 % der eigenen Schriftarten überschreitet eine Woche, während die Cache-Dauer von 50 % der fremden Schriftarten weniger als eine Woche beträgt! Das gibt Webentwicklern triftige Gründe für das Self-Hosting von Schriftartdateien!"
Daher werden Sie, wenn Sie fremde Materialien selbst hosten, keine Probleme mit der Leistung bemerken, die durch das Browser-Caching verursacht werden.
Jetzt, wo wir die Vorteile des Self-Hostings von Drittanbieter-Ressourcen betrachtet haben, lassen Sie uns darüber sprechen, wie man eine gute Umsetzung dieses Ansatzes von einer schlechten unterscheidet.
Schlecht: Der Teufel steckt im Detail
Das Verschieben von Drittanbieter-Ressourcen auf die eigene Domain kann nicht automatisch erfolgen, ohne das richtige Caching dieser Ressourcen zu gewährleisten.
Eines der Hauptprobleme hier ist die Cache-Dauer. Beispielsweise werden Versionsinformationen in die Namen der Drittanbieter-Skripte etwa so eingebunden: jquery-3.4.1.js. Eine solche Datei wird sich in Zukunft nicht ändern, was keine Probleme beim Caching verursachen wird.
Wenn jedoch kein Versionsschema für die Arbeit mit Dateien angewendet wird, können gecachte Skripte, deren Inhalt sich bei unverändertem Dateinamen ändert, veraltet sein. Dies kann ein ernstes Problem darstellen, da es beispielsweise nicht ermöglicht, Sicherheitskorrekturen automatisch in die Skripte einzufügen, die so schnell wie möglich den Kunden zur Verfügung stehen müssen. Der Entwickler muss sich bemühen, solche Skripte im Cache zu aktualisieren. Darüber hinaus kann dies zu Fehlfunktionen der Anwendung führen, die daraus resultieren, dass der Code, der vom Client aus dem Cache verwendet wird, sich von der aktuellen Version des Codes unterscheidet, die für den Serverteil des Projekts vorgesehen ist.
Es stimmt, dass beim Sprechen von Materialien, die häufig aktualisiert werden (Tag-Manager, Lösungen für A/B-Tests), das Caching über CDN zwar umsetzbar, aber bereits deutlich komplexer ist. Dienste wie Commanders Act, Tag-Management-Lösungen, verwenden beim Veröffentlichen neuer Versionen Webhooks. Dies ermöglicht es, einen Cache-Reset auf CDN zu organisieren oder, was noch besser ist, die Aktualisierung des Hashes oder der Version der URL auszulösen.
▍Adaptive Bereitstellung von Materialien für Kunden
Wenn wir über Caching sprechen, muss auch berücksichtigt werden, dass die Caching-Einstellungen, die auf CDN verwendet werden, möglicherweise nicht für bestimmte externe Ressourcen geeignet sind. Beispielsweise können solche Ressourcen die Technologie des User-Agent-Sniffing (User-Agent-Detektion, adaptive Bereitstellung) nutzen, um spezifische, speziell für diese Browser optimierte Versionen von Materialien bereitzustellen. Diese Technologien verlassen sich auf reguläre Ausdrücke oder auf eine Datenbank, in der Informationen über HTTP-Header gesammelt sind. User-Agent. Nachdem sie herausgefunden haben, mit welchem Browser sie es zu tun haben, stellen sie ihm die Materialien zur Verfügung, die für ihn vorgesehen sind.
Hier können wir an zwei Dienste denken. Ersterer ist googlefonts.com. Zweiterer ist polyfill.io. Der Dienst Google Fonts bietet für eine bestimmte Ressource verschiedenen CSS-Code an, der von den Fähigkeiten des Browsers abhängt (indem er auf woff2-Ressourcen verweist, unter Verwendung von unicode-range).
Hier sind die Ergebnisse einiger Anfragen an Google Fonts, die aus verschiedenen Browsern durchgeführt wurden.
Das Ergebnis der Anfrage an Google Fonts, ausgeführt aus Chrome
Das Ergebnis der Anfrage an Google Fonts, ausgeführt aus IE10
Polyfill.io liefert dem Browser nur die Polyfills, die er benötigt. Dies geschieht aus Leistungsgründen.
Betrachten wir beispielsweise, was passiert, wenn wir die folgende Anfrage aus verschiedenen Browsern ausführen:
Als Antwort auf eine solche Anfrage, die aus IE10 ausgeführt wurde, werden 34 KB Daten zurückkommen. Die Antwort darauf, die aus Chrome ausgeführt wurde, wird leer sein.
Böse: einige Überlegungen zum Datenschutz
Dieser Punkt ist zwar der letzte in der Reihenfolge, jedoch nicht in der Wichtigkeit. Es geht darum, dass das Hosting von Drittressourcen auf der Hauptdomain des Projekts oder auf seinem Subdomain die Privatsphäre der Benutzer gefährden und sich negativ auf das Hauptwebprojekt auswirken kann.
Wenn Ihr CDN-System falsch konfiguriert ist, kann es letztendlich dazu führen, dass Sie Cookies Ihrer Domain an einen Drittanbieter senden. Wenn auf der CDN-Ebene keine richtige Filterung organisiert wird, könnten Ihre Session-Cookies, auf die in der Regel nicht in JavaScript zugegriffen werden kann (mit dem Attribut httponly), an einen fremden Host gesendet werden.
Genau das könnte mit Trackern wie Eulerian oder Criteo geschehen. Drittanbieter-Tracker konnten einen eindeutigen Identifikator in Cookies setzen. Wenn sie Teil der Webseiteninhalte waren, konnten sie den Identifikator nach Belieben lesen, während der Benutzer mit verschiedenen Webressourcen interagierte.
Heutzutage enthalten die meisten Browser Schutzmaßnahmen gegen solches Verhalten von Trackern. Infolgedessen verwenden Tracker jetzt die Technologie , indem sie sich als eigene Skripte verschiedener Projekte tarnen. Konkret bieten Tracker den Websitebesitzern an, CNAME für eine bestimmte Domain in ihre Einstellungen hinzuzufügen, deren Adresse normalerweise wie eine zufällige Zeichenfolge aussieht.
Obwohl es nicht empfohlen wird, die Cookies der Website für alle Subdomains zugänglich zu machen (z. B. *.website.com), geschieht dies auf vielen Websites. In diesem Fall werden solche Cookies automatisch an den tarngesuchten Drittanbieter-Tracker gesendet. Als Ergebnis kann man von Privatsphäre nicht mehr sprechen.
Darüber hinaus geschieht dasselbe mit den HTTP-Headern , die nur an die Hauptdomain gesendet werden, da sie zur Erstellung verwendet werden können. des Benutzers. Stellen Sie sicher, dass der von Ihnen verwendete CDN-Dienst solche Header korrekt filtert.
Ergebnisse
Wenn Sie in naher Zukunft die Selbsthosting-Option für externe Ressourcen einführen möchten, erlauben Sie mir, Ihnen einige Ratschläge zu geben:
- Hosten Sie Ihre wichtigsten JS-Bibliotheken, Schriftarten und CSS-Dateien selbst. Dies verringert das Risiko eines Ausfalls der Website oder einer Verschlechterung der Leistung, falls eine für die Funktion Ihrer Website essentielle Ressource aufgrund eines externen Dienstes nicht verfügbar ist.
- Bevor Sie externe Ressourcen auf dem CDN zwischenspeichern, stellen Sie sicher, dass eine Art von Versionierungssystem für die Benennung ihrer Dateien verwendet wird, oder dass Sie den Lebenszyklus dieser Ressourcen verwalten können, indem Sie den CDN-Cache manuell oder automatisch beim Veröffentlichen einer neuen Version des Skripts leeren.
- Seien Sie sehr vorsichtig mit den Einstellungen des CDN, des Proxy-Servers und des Caches. Dies wird Ihnen helfen, das Senden von Cookies Ihres Projekts oder Headern
Client-Hintsan externe Dienste zu vermeiden.
Liebe Leser! Veröffentlichen Sie auf Ihren Servern Materialien von Dritten, die für die Funktion Ihrer Projekte von entscheidender Bedeutung sind?
Quelle: habr.com
