[Kein] Verwenden Sie ein CDN

Fast jeder Artikel oder jedes Tool zur Optimierung der Website-Geschwindigkeit enthält eine bescheidene Klausel „Verwenden Sie ein CDN“. Im Allgemeinen ist CDN ein Content-Delivery-Netzwerk oder Content-Delivery-Netzwerk. Wir bei Method Lab stoßen häufig auf Fragen von Kunden zu diesem Thema; einige von ihnen aktivieren ihr eigenes CDN. Der Zweck dieses Artikels besteht darin, zu verstehen, was ein CDN in Bezug auf die Ladegeschwindigkeit der Website leisten kann, welche Probleme auftreten können und in welchen Fällen die Verwendung eines CDN gerechtfertigt ist.

Die im Bild eingekreisten Verzögerungen werden durch die Verwendung eines CDN verursacht.

Ein wenig Geschichte

Wie viele Technologien sind auch CDNs aus der Not heraus entstanden. Mit der Entwicklung von Internetkanälen unter Internetnutzern entstanden Online-Videodienste. Natürlich benötigen Videoinhalte um Größenordnungen mehr Bandbreite als normale Website-Inhalte (Bilder, Text und CSS- oder JS-Code).

Wenn Sie versuchen, einen Videostream parallel von einem Server an viele Clients zu übertragen, wird höchstwahrscheinlich der Internetkanal des Servers zum Engpass. In der Regel reichen ein paar Tausend Threads aus, um einen typischen Serverkanal zu verstopfen. Natürlich kann es noch andere Ressourcenbeschränkungen geben, aber diese sind im Moment nicht wichtig. Wichtig ist auch, dass die Erweiterung des Serverkanals zu teuer (und manchmal unmöglich) und auch unpraktisch ist. Die Belastung des Kanals während der Übertragungen erfolgt zyklisch.

Das Problem der Kanalbegrenzung eines einzelnen Servers wird durch CDN perfekt gelöst. Clients verbinden sich nicht direkt mit dem Server, sondern mit Knoten im CDN-Netzwerk. Im Idealfall sendet der Server einen Stream an den CDN-Knoten, und dann nutzt das Netzwerk seine eigenen Ressourcen, um diesen Stream an viele Benutzer zu liefern. Aus wirtschaftlicher Sicht zahlen wir nur für die tatsächlich verbrauchten Ressourcen (dies kann Bandbreite oder Datenverkehr sein) und erhalten eine hervorragende Skalierbarkeit unseres Dienstes. Die Verwendung eines CDN zur Bereitstellung umfangreicher Inhalte ist völlig gerechtfertigt und logisch. Obwohl es erwähnenswert ist, dass die größten Player in diesem Bereich (z. B. Netflix) ihre eigenen CDNs aufbauen, anstatt große kommerzielle CDNs (Akamai, Cloudflare, Fastly usw.) zu verwenden.

Mit der Weiterentwicklung des Webs sind Webanwendungen selbst immer komplexer geworden. Das Problem der Ladegeschwindigkeit trat in den Vordergrund. Enthusiasten der Website-Geschwindigkeit erkannten schnell mehrere große Probleme, die dazu führten, dass Websites langsam geladen wurden. Eine davon waren Netzwerkverzögerungen (RTT – Round Trip Time oder Ping Time). Verzögerungen wirken sich auf viele Prozesse beim Laden einer Website aus: Aufbau einer TCP-Verbindung, Starten einer TLS-Sitzung, Laden jeder einzelnen Ressource (Bild, JS-Datei, HTML-Dokument usw.)

Das Problem wurde dadurch verschärft, dass Browser bei Verwendung des HTTP/1.1-Protokolls (vor dem Aufkommen von SPDY, QUIC und HTTP/2 war dies die einzige Option) nicht mehr als 6 TCP-Verbindungen zu einem Host öffnen. All dies führte zu Verbindungsausfällen und einer ineffizienten Nutzung der Kanalbandbreite. Das Problem wurde teilweise durch Domain-Sharding gelöst – die Schaffung zusätzlicher Hosts, um die Begrenzung der Anzahl der Verbindungen zu überwinden.

Hier zeigt sich die zweite Fähigkeit von CDN – die Reduzierung der Latenz (RTT) aufgrund der großen Anzahl von Punkten und der Nähe der Knoten zum Benutzer. Dabei spielt die Distanz eine entscheidende Rolle: Die Lichtgeschwindigkeit ist begrenzt (ca. 200 km/sec in Glasfaser). Dies bedeutet, dass alle 000 km Fahrt eine Verzögerung von 1000 ms bzw. 5 ms zur RTT entsteht. Dies ist die Mindestzeit, die für die Übertragung benötigt wird, da es auch auf den zwischengeschalteten Geräten zu Verzögerungen kommt. Da ein CDN normalerweise weiß, wie Objekte auf seinen Servern zwischengespeichert werden, können wir davon profitieren, solche Objekte über ein CDN zu laden. Notwendige Bedingungen hierfür: das Vorhandensein des Objekts im Cache, die Nähe des CDN-Punkts zum Benutzer im Vergleich zum Webanwendungsserver (Origin-Server). Es ist wichtig zu verstehen, dass die geografische Nähe eines CDN-Knotens keine Garantie für eine niedrige Latenz ist. Das Routing zwischen dem Client und dem CDN kann so aufgebaut sein, dass der Client eine Verbindung zu einem Host in einem anderen Land und möglicherweise auf einem anderen Kontinent herstellt. Hier kommen die Beziehung zwischen Telekommunikationsbetreibern und dem CDN-Dienst (Peering, Verbindungen, Teilnahme an IX usw.) und die Traffic-Routing-Richtlinie des CDN selbst ins Spiel. Beispielsweise garantiert Cloudflare bei Verwendung von zwei anfänglichen Plänen (kostenlos und günstig) nicht die Bereitstellung von Inhalten vom nächstgelegenen Host – der Host wird ausgewählt, um die Mindestkosten zu erzielen.

Viele führende Internetunternehmen wecken öffentliches Interesse (Webentwickler und Servicebetreiber) für das Thema Ladegeschwindigkeit und Website-Performance. Zu diesen Unternehmen gehören Yahoo (Yslow-Tool), AOL (WebPageTest) und Google (Page Speed ​​​​Insights-Dienst), die ihre eigenen Empfehlungen zur Beschleunigung von Websites entwickeln (hauptsächlich beziehen sie sich auf die Kundenoptimierung). Später erscheinen neue Tools zum Testen der Website-Geschwindigkeit, die auch Tipps zur Steigerung der Website-Geschwindigkeit geben. Für jeden dieser Dienste oder Plugins gibt es eine einheitliche Empfehlung: „Verwenden Sie ein CDN.“ Als Erklärung für die Wirkung von CDN wird meist die Reduzierung der Netzwerklatenz angeführt. Leider ist nicht jeder bereit, genau zu verstehen, wie der Beschleunigungseffekt von CDN erreicht wird und wie er gemessen werden kann, daher wird die Empfehlung als Glaubenssatz angenommen und als Postulat verwendet. Tatsächlich sind nicht alle CDNs gleich.

Heute ein CDN nutzen

Um den Nutzen der Verwendung von CDNs beurteilen zu können, müssen diese klassifiziert werden. Was nun in der Praxis zu finden ist (die Beispiele in Klammern erheben natürlich keinen Anspruch auf Vollständigkeit):

1. Kostenloses CDN zum Verteilen von JS-Bibliotheken (MaxCDN, Google. Yandex).
2. CDN von Diensten zur Client-Optimierung (z. B. Google Fonts für Schriftarten, Cloudinary, Cloudimage für Bilder).
3. CDN zur statischen und Ressourcenoptimierung in CMS (verfügbar in Bitrix, WordPress und anderen).
4. Allzweck-CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN zur Website-Beschleunigung (Cloudflare, Imperva, Airi).

Der Hauptunterschied zwischen diesen Typen besteht darin, wie viel Datenverkehr über das CDN läuft. Bei den Typen 1–3 handelt es sich um die Übermittlung nur eines Teils des Inhalts: von einer Anfrage bis zu mehreren Dutzend (normalerweise Bildern). Bei den Typen 4 und 5 handelt es sich um ein vollständiges Proxying des Datenverkehrs über ein CDN.

In der Praxis bedeutet dies die Anzahl der Verbindungen, die zum Laden der Site verwendet werden. Bei HTTP/2 verwenden wir eine einzige TCP-Verbindung zum Host, um beliebig viele Anfragen zu verarbeiten. Wenn wir die Ressourcen in den Haupthost (Ursprung) und CDN aufteilen, ist es notwendig, Anfragen auf mehrere Domänen zu verteilen und mehrere TCP-Verbindungen herzustellen. Der schlimmste Fall ist: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Diese Formel berücksichtigt nicht Verzögerungen in Mobilfunknetzen bei der Aktivierung des Funkkanals des Geräts (sofern dieser nicht aktiv war) und Verzögerungen auf dem Mobilfunkmast.

So sieht es im Ladewasserfall der Site aus (Latenzen für die Verbindung zum CDN werden bei RTT 150 ms hervorgehoben):

Wenn das CDN den gesamten Site-Verkehr abdeckt (mit Ausnahme von Drittanbieterdiensten), können wir eine einzige TCP-Verbindung verwenden und so Verzögerungen bei der Verbindung zu zusätzlichen Hosts vermeiden. Dies gilt natürlich auch für HTTP/2-Verbindungen.

Weitere Unterschiede werden durch die Funktionalität eines bestimmten CDN bestimmt – beim ersten Typ wird nur eine statische Datei gehostet, beim fünften werden mehrere Arten von Website-Inhalten zum Zweck der Optimierung geändert.

CDN-Funktionen zur Website-Beschleunigung

Lassen Sie uns das gesamte Spektrum der CDN-Funktionen zur Beschleunigung von Websites beschreiben, ohne Rücksicht auf die Funktionalität einzelner CDN-Typen, und dann sehen, was in jedem von ihnen implementiert ist.

1. Komprimierung von Textressourcen

Die grundlegendste und verständlichste Funktion, die jedoch oft schlecht implementiert ist. Alle CDNs deklarieren das Vorhandensein von Komprimierung als ihre Beschleunigungsfunktion. Schaut man jedoch genauer hin, werden Mängel deutlich:

• Es können niedrige Grade für die dynamische Komprimierung verwendet werden – 5–6 (für gzip beträgt das Maximum beispielsweise 9);
• statische Komprimierung (Dateien im Cache) nutzt keine zusätzlichen Funktionen (z. B. Zopfi oder Brotli mit Grad 11)
• Es gibt keine Unterstützung für eine effiziente Brotli-Komprimierung (Einsparung von ca. 20 % im Vergleich zu gzip).

Wenn Sie ein CDN verwenden, lohnt es sich, diese wenigen Punkte zu überprüfen: Nehmen Sie die Datei, die vom CDN stammt, notieren Sie ihre komprimierte Größe und komprimieren Sie sie zum Vergleich manuell (Sie können zum Beispiel einen Online-Dienst mit Brotli-Unterstützung verwenden). vsszhat.rf).

2. Client-Caching-Header festlegen

Auch eine einfache Beschleunigungsfunktion: Fügen Sie Header für die Inhaltszwischenspeicherung durch den Client (Browser) hinzu. Der aktuellste Header ist „cache-control“, der veraltete ist „expires“. Zusätzlich kann Etag verwendet werden. Die Hauptsache ist, dass das maximale Alter der Cache-Kontrolle groß genug ist (von einem Monat oder mehr). Wenn Sie bereit sind, die Ressource so hart wie möglich zwischenzuspeichern, können Sie die unveränderliche Option hinzufügen.

CDNs können den Wert für das maximale Alter senken, wodurch der Benutzer gezwungen wird, statische Inhalte häufiger neu zu laden. Es ist nicht klar, womit dies zusammenhängt: dem Wunsch, den Datenverkehr im Netzwerk zu erhöhen oder die Kompatibilität mit Websites zu erhöhen, die nicht wissen, wie man den Cache zurücksetzt. Beispielsweise beträgt die standardmäßige Cloudflare-Header-Cache-Zeit 1 Stunde, was für unveränderliche statische Daten sehr niedrig ist.

3. Bildoptimierung

Da das CDN die Funktionen des Zwischenspeicherns und Bereitstellens von Bildern übernimmt, wäre es logisch, diese auf der CDN-Seite zu optimieren und in dieser Form den Benutzern bereitzustellen. Machen wir gleich einen Vorbehalt, dass diese Funktion nur für die CDN-Typen 2, 3 und 5 verfügbar ist.

Sie können Bilder auf verschiedene Weise optimieren: durch die Verwendung fortschrittlicher Komprimierungsformate (z. B. WebP), effizienterer Encoder (MozJPEG) oder einfach durch das Bereinigen unnötiger Metadaten.

Im Allgemeinen gibt es zwei Arten solcher Optimierungen: mit Qualitätsverlust und ohne Qualitätsverlust. CDNs streben in der Regel eine verlustfreie Optimierung an, um mögliche Kundenbeschwerden über Änderungen der Bildqualität zu vermeiden. Unter solchen Bedingungen wird der Gewinn minimal sein. In der Realität ist die JPEG-Qualitätsstufe oft viel höher als nötig und Sie können bedenkenlos mit einer niedrigeren Qualitätsstufe neu komprimieren, ohne das Benutzererlebnis zu beeinträchtigen. Andererseits ist es schwierig, das Qualitätsniveau und die Einstellungen allgemein für alle möglichen Webanwendungen zu bestimmen. Daher verwenden CDNs konservativere Einstellungen als diejenigen, die unter Berücksichtigung des Kontexts (Zweck der Bilder, Art der Webanwendung) angewendet werden können , usw.)

4. Optimierung der TLS-Verbindung

Der Großteil des Datenverkehrs läuft heutzutage über TLS-Verbindungen, was bedeutet, dass wir zusätzliche Zeit für die TLS-Aushandlung aufwenden. In jüngster Zeit wurden neue Technologien entwickelt, um diesen Prozess zu beschleunigen. Dies sind beispielsweise EC-Kryptografie, TLS 1.3, Sitzungscache und Tickets, Beschleunigung der Hardwareverschlüsselung (AES-NI) usw. Durch die korrekte Einstellung von TLS kann die Verbindungszeit auf 0-1 RTT reduziert werden (DNS und TCP nicht mitgezählt).

Mit moderner Software ist es nicht schwer, solche Praktiken selbst umzusetzen.

Nicht alle CDNs implementieren TLS-Best Practices; Sie können dies überprüfen, indem Sie die TLS-Verbindungszeit messen (z. B. in Webpagetest). Ideal für eine neue Verbindung – 1RTT, 2RTT – durchschnittliches Niveau, 3RTT und mehr – schlecht.

Außerdem ist zu beachten, dass auch bei der Verwendung von TLS auf CDN-Ebene der Server mit unserer Webanwendung ebenfalls TLS verarbeiten muss, allerdings von der CDN-Seite, da der Verkehr zwischen dem Server und dem CDN über das öffentliche Netzwerk läuft. Im schlimmsten Fall kommt es zu doppelten TLS-Verbindungsverzögerungen (die erste zum CDN-Host, die zweite zwischen diesem und unserem Server).

Bei einigen Anwendungen lohnt es sich, auf Sicherheitsaspekte zu achten: Der Datenverkehr wird normalerweise auf CDN-Knoten entschlüsselt, was eine potenzielle Möglichkeit zum Abfangen des Datenverkehrs darstellt. Die Möglichkeit, ohne Verkehrsmeldung zu arbeiten, wird in den Top-Tarifen meist gegen Aufpreis angeboten.

5. Reduzieren Sie Verbindungsverzögerungen

Der Hauptvorteil von CDN, über den alle sprechen: geringe Latenz (geringere Entfernung) zwischen dem CDN-Host und dem Benutzer. Erreicht durch die Schaffung einer geografisch verteilten Netzwerkarchitektur, in der sich Hosts an Konzentrationspunkten der Benutzer befinden (Städte, Verkehrsknotenpunkte usw.)

In der Praxis können Prioritäten für verschiedene Netzwerke in bestimmten Regionen liegen. Beispielsweise werden russische CDNs mehr Präsenzpunkte in Russland haben. Die Amerikaner werden zunächst das Netzwerk in den USA aufbauen. Beispielsweise hat eines der größten CDN Cloudflare nur zwei Punkte in Russland – Moskau und St. Petersburg. Das heißt, wir können im Vergleich zur direkten Platzierung in Moskau maximal etwa 2 ms Latenz einsparen.

Die meisten westlichen CDNs haben überhaupt keine Punkte in Russland. Wenn Sie sich mit ihnen verbinden, können Sie die Verzögerungen für Ihr russisches Publikum nur erhöhen.

6. Content-Optimierung (Minimierung, Strukturveränderungen)

Der komplexeste und technologisch fortschrittlichste Punkt. Das Ändern von Inhalten während der Übermittlung kann sehr riskant sein. Auch wenn wir eine Minimierung vornehmen: Eine Reduzierung des Quellcodes (aufgrund zusätzlicher Leerzeichen, unwichtiger Strukturen usw.) kann sich auf seine Leistung auswirken. Wenn wir über schwerwiegendere Änderungen sprechen – das Verschieben des JS-Codes an das Ende des HTML-Codes, das Zusammenführen von Dateien usw. – ist das Risiko einer Beeinträchtigung der Funktionalität der Website noch höher.

Daher tun dies nur einige Typ-5-CDNs. Natürlich wird es nicht möglich sein, alle notwendigen Änderungen zu automatisieren, um die Prozesse zu beschleunigen – manuelle Analysen und Optimierungen sind erforderlich. Das Entfernen ungenutzten oder doppelten Codes ist beispielsweise eine manuelle Aufgabe.

In der Regel werden alle derartigen Optimierungen durch Einstellungen gesteuert und die gefährlichsten sind standardmäßig deaktiviert.

Unterstützung für Beschleunigungsfunktionen nach CDN-Typ

Schauen wir uns also an, welche potenziellen Beschleunigungsmöglichkeiten die verschiedenen Arten von CDNs bieten.

Der Einfachheit halber wiederholen wir die Klassifizierung.

1. Kostenloses CDN zum Verteilen von JS-Bibliotheken (MaxCDN, Google. Yandex).
2. CDN von Diensten zur Client-Optimierung (z. B. Google Fonts für Schriftarten, Cloudinary, Cloudimage für Bilder).
3. CDN zur statischen und Ressourcenoptimierung in CMS (verfügbar in Bitrix, WordPress und anderen).
4. Allzweck-CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN zur Website-Beschleunigung (Cloudflare, Imperva, Airi).

Vergleichen wir nun die Funktionen und Typen von CDN.

Gelegenheit
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Textkomprimierung
+–
-
+–
+–
+

Cache-Header
+
+
+
+
+

Bilder
-
+–
+–
-
+

TLS
-
-
-
+–
+

Verzögerungen
-
-
-
+
+

Inhalt
-
-
-
-
+

In dieser Tabelle wird „+“ verwendet, um volle Unterstützung anzuzeigen, „–“ bedeutet keine Unterstützung und „+–“ bedeutet teilweise Unterstützung. Natürlich kann es in der Realität zu Abweichungen von dieser Tabelle kommen (z. B. implementieren einige Allzweck-CDNs Funktionen zur Optimierung von Bildern), aber für eine allgemeine Vorstellung ist sie nützlich.

Ergebnisse

Hoffentlich haben Sie nach der Lektüre dieses Artikels ein klareres Bild von der Empfehlung „Verwenden Sie ein CDN“, um Ihre Websites zu beschleunigen.

Wie in jedem Unternehmen können Sie den Marketingversprechen einer Dienstleistung nicht glauben. Der Effekt muss unter realen Bedingungen gemessen und getestet werden. Wenn Sie bereits ein CDN nutzen, prüfen Sie dieses anhand der im Artikel beschriebenen Kriterien auf Wirksamkeit.

Es ist möglich, dass die aktuelle Verwendung eines CDN die Ladezeit Ihrer Website verlangsamt.

Als allgemeine Empfehlung können wir uns auf Folgendes konzentrieren: Studieren Sie Ihre Zielgruppe und bestimmen Sie deren geografische Reichweite. Wenn sich Ihr Hauptpublikum auf einen Umkreis von 1 bis 2 Kilometern konzentriert, benötigen Sie kein CDN für seinen Hauptzweck – die Reduzierung der Latenz. Stattdessen können Sie Ihren Server näher an Ihren Benutzern platzieren und ihn richtig konfigurieren und so die meisten der im Artikel beschriebenen Optimierungen erhalten (kostenlos und dauerhaft).

Wenn Ihr Publikum wirklich geografisch verteilt ist (Umkreis von mehr als 3000 Kilometern), ist die Verwendung eines hochwertigen CDN wirklich nützlich. Sie müssen jedoch im Voraus verstehen, was genau Ihr CDN beschleunigen kann (siehe Tabelle der Funktionen und deren Beschreibung). Dennoch bleibt die Website-Beschleunigung eine komplexe Aufgabe, die nicht durch die Anbindung eines CDN gelöst werden kann. Zusätzlich zu den oben genannten Optimierungen bleiben die effektivsten Mittel zur Beschleunigung hinter dem CDN: Optimierung des Serverteils, erweiterte Änderungen am Clientteil (Entfernen nicht verwendeten Codes, Optimierung des Rendering-Prozesses, Arbeiten mit Inhalten, Schriftarten, Anpassungsfähigkeit usw. )

Source: habr.com