[Nicht] verwenden Sie CDN

In praktisch jedem Artikel oder Tool zur Optimierung der Website-Geschwindigkeit gibt es einen bescheidenen Punkt "verwenden Sie CDN". Im Grunde ist ein CDN – ein Content Delivery Network или сеть доставки контента. In der Firma "Метод Лаб" sehen wir häufig Anfragen von Kunden zu diesem Thema, einige aktivieren eigenständig CDN. Ziel dieses Artikels ist es, zu klären, was CDN aus Sicht der Ladegeschwindigkeit einer Website leisten kann, welche Probleme auftreten können und in welchen Fällen die Nutzung von CDN gerechtfertigt ist.

Die im Bild markierten Verzögerungen sind auf die Verwendung von CDN zurückzuführen.

Ein wenig Geschichte

Wie viele Technologien entstand das CDN aus einer Notwendigkeit. Mit der Entwicklung der Internetkanäle der User entstanden Online-Video-Services. Natürlich erfordert Video-Content deutlich mehr Bandbreite im Vergleich zu herkömmlichem Website-Content (Bilder, Text und CSS oder JS-Code).

Bei dem Versuch, einen Video-Stream gleichzeitig an mehrere Kunden von einem Server aus zu übertragen, wird das enge Glied wahrscheinlich der Internetkanal des Servers sein. In der Regel genügen einige Tausend Streams, um einen typischen Server-Kanal auszulasten. Natürlich kann es auch andere Ressourcenbeschränkungen geben, aber diese sind momentan nicht wichtig. Es ist außerdem wichtig zu beachten, dass es zu teuer (und manchmal unmöglich) ist, den Server-Kanal zu erweitern, und es ist auch unwirtschaftlich. Die Last auf dem Kanal bei Übertragungen wird zyklischer Natur sein.

Das Problem der Einschränkung des Kanals eines einzelnen Servers wird durch CDN hervorragend gelöst. Die Kunden verbinden sich nicht direkt mit dem Server, sondern mit Knoten des CDN-Netzwerks. In der idealen Situation gibt der Server einen Stream an den CDN-Knoten weiter, und danach 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 (das kann Bandbreite oder Traffic sein) und erhalten eine ausgezeichnete Skalierbarkeit unseres Dienstes. Die Verwendung von CDN zur Auslieferung von schwerem Content ist vollkommen gerechtfertigt und logisch. Es lohnt sich jedoch zu beachten, dass die größten Akteure in diesem Bereich (z. B. Netflix) ihre eigenen CDNs aufbauen, anstatt große kommerzielle CDNs (Akamai, Cloudflare, Fastly usw.) zu nutzen.

Mit der Entwicklung des Webs wurden auch die Webanwendungen komplexer und schwerer. Das Problem der Ladegeschwindigkeit rückte in den Vordergrund. Geschwindigkeits-Enthusiasten fanden schnell mehrere Hauptprobleme, die zu langsamen Ladezeiten führten. Eines davon waren Verzögerungen im Netzwerk (RTT – Round Trip Time oder Ping-Zeit). Verzögerungen beeinflussen viele Prozesse beim Laden einer Webseite: die Einrichtung der TCP-Verbindung, den Start der TLS-Session und das Laden jeder einzelnen Ressource (Bilder, JS-Dateien, HTML-Dokumente usw.).

Das Problem wurde dadurch verschärft, dass beim Einsatz des Protokolls HTTP/1.1 (bis zur Einführung von SPDY, QUIC und HTTP/2 die einzige Option) Browser nicht mehr als 6 TCP-Verbindungen zu einem Host öffnen. Das führte zu Leerlaufzeiten für die Verbindungen und einer ineffizienten Nutzung der Bandbreite. Teilweise wurde das Problem durch Domain-Sharding gelöst – die Schaffung zusätzlicher Hosts, um die Verbindungslimits zu umgehen.

Hier kommt die zweite Fähigkeit von CDNs ins Spiel – die Verringerung von Verzögerungen (RTT) durch die Vielzahl an Punkten und die Nähe der Knoten zum Nutzer. Die Entfernung spielt hierbei eine entscheidende Rolle: Die Lichtgeschwindigkeit ist begrenzt (ca. 200.000 km/s in Glasfasern). Das bedeutet, dass jede 1000 km Strecke 5 ms Verzögerung oder 10 ms in der RTT hinzufügt. Dies sind die minimalen Zeitverluste für die Übertragung, da es noch Verzögerungen durch Zwischenhardware gibt. Da CDNs in der Regel in der Lage sind, Objekte auf ihren Servern zu cachen, können wir durch das Laden solcher Objekte über ein CDN profitieren. Die Voraussetzungen dafür sind: das Objekt muss im Cache vorhanden sein und die Nähe des CDN-Punkts zum Nutzer im Vergleich zum Server der Webanwendung (Origin-Server). Es ist wichtig zu verstehen: Die geografische Nähe eines CDN-Knotens garantiert keine niedrigen Verzögerungen. Die Routing-Strategien zwischen dem Kunden und dem CDN können so gestaltet sein, dass der Kunde mit einem Host in einem anderen Land oder möglicherweise sogar auf einem anderen Kontinent verbunden wird. Hier kommen die Beziehungen zwischen den Telekombetreibern und dem CDN-Service (Peering, Verfügbarkeit von Interconnects, Teilnahme an IX usw.) sowie die Routing-Politik des CDNs ins Spiel. Zum Beispiel garantiert Cloudflare bei der Nutzung der beiden Einstiegspläne (kostenlos und günstig) nicht, dass Inhalte vom nächstgelegenen Knoten bereitgestellt werden – die Wahl des Hosts erfolgt zur Minimierung der Kosten.

Viele führende Internetunternehmen ziehen das Interesse der Öffentlichkeit (Webentwickler und Dienstanbieter) an den Themen Ladegeschwindigkeit und Funktionalität von Websites an. Zu diesen Unternehmen gehören Yahoo (Tool Yslow), AOL (WebPageTest) und Google (Dienst Page Speed Insights), die ihre Empfehlungen zur Beschleunigung von Websites entwickeln (in erster Linie beziehen sie sich auf die Client-Optimierung). Später tauchen neue Tools zum Testen der Ladegeschwindigkeit von Websites auf, die ebenfalls Ratschläge zur Geschwindigkeitssteigerung geben. In jedem dieser Dienste oder Plugins gibt es die unveränderliche Empfehlung „Verwenden Sie ein CDN“. Als Erklärung für die Wirkung eines CDNs wird in der Regel eine Reduzierung der Netzverzögerungen angeführt. Leider sind nicht alle bereit, sich damit auseinanderzusetzen, wie genau der Beschleunigungseffekt eines CDNs erreicht wird und wie er gemessen werden kann, weshalb die Empfehlung als gegeben hingenommen und als Postulat verwendet wird. Tatsächlich sind nicht alle CDNs gleichermaßen nützlich.

Die Verwendung von CDNs heute

Um den Nutzen von CDNs zu bewerten, müssen sie klassifiziert werden. Was kann man heutzutage aus der Praxis entnehmen (die Beispiele in Klammern sind natürlich nicht abschließend):

1. Kostenlose CDNs für die Bereitstellung von JS-Bibliotheken (MaxCDN, Google, Yandex).
2. CDNs von Dienstanbietern zur Client-Optimierung (zum Beispiel Google Fonts für Schriftarten, Cloudinary, Cloudimage für Bilder).
3. CDNs für statische Inhalte und Ressourcenoptimierung in CMS (verfügbar in Bitrix, WordPress und anderen).
4. Allzweck-CDNs (StackPath, CDNVideo, NGENIX, Megafon).
5. CDNs zur Beschleunigung von Websites (Cloudflare, Imperva, Airi).

Der entscheidende Unterschied zwischen diesen Typen liegt darin, welcher Teil des Traffics über das CDN geleitet wird. Die Typen 1-3 liefern nur einen Teil des Inhalts: von einer Anfrage bis zu mehreren Dutzend (gewöhnlich Bilder). Die Typen 4 und 5 bedeuten ein vollständiges Proxying des Traffics über das CDN.

In der Praxis bedeutet dies die Anzahl der Verbindungen, die für das Laden der Website verwendet werden. Bei Verwendung von HTTP/2 nutzen wir eine einzige TCP-Verbindung zum Host, um eine beliebige Anzahl von Anfragen zu verarbeiten. Wenn wir Ressourcen zwischen dem Haupt-Host (Origin) und dem CDN aufteilen, müssen die Anfragen über mehrere Domains verteilt werden, und es müssen mehrere TCP-Verbindungen erstellt werden. Im schlimmsten Fall ergibt sich folgende Rechnung: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. In dieser Formel sind die Verzögerungen in mobilen Netzwerken zur Aktivierung des Funkkanals des Geräts (wenn er nicht aktiv war) und die Verzögerungen an der Mobilfunkantenne nicht berücksichtigt.

So sieht es auf dem Ladebildschirm der Website aus (Verzögerungen beim Anschluss an das CDN bei RTT 150 ms sind hervorgehoben):

Wenn das CDN den gesamten Traffic der Website abdeckt (außer von Drittanbietern), können wir eine einzige TCP-Verbindung nutzen, was Verzögerungen beim Anschluss an zusätzliche Hosts spart. Natürlich betrifft das HTTP/2-Verbindungen.

Die weiteren Unterschiede hängen von der Funktionalität des jeweiligen CDNs ab – für den ersten Typ handelt es sich lediglich um Hosting eine statische Datei, beim fünften Typ geht es um die Anpassung mehrerer Arten von Inhalten auf der Website zur Optimierung.

Die Möglichkeiten des CDNs zur Beschleunigung der Website

Lassen Sie uns das gesamte Spektrum der Möglichkeiten des CDNs zur Beschleunigung von Websites beschreiben, ohne uns auf die Funktionalität einzelner CDN-Typen zu konzentrieren, und anschließend sehen, was davon in jedem von ihnen implementiert ist.

1. Kompression von Textressourcen

Die grundlegende und verständliche Möglichkeit, die jedoch häufig schlecht umgesetzt ist. Alle CDNs deklarieren die Kompression als ihr Feature zur Beschleunigung. Bei genauerer Betrachtung ergeben sich jedoch Mängel:

• es können niedrige Stufen für die dynamische Kompression verwendet werden – 5-6 (zum Beispiel ist für gzip das Maximum — 9);
• bei der statischen Kompression (Dateien im Cache) werden keine zusätzlichen Möglichkeiten genutzt (z. B. zopfi oder brotli mit Stufe 11);
• es gibt keine Unterstützung für eine effektive brotli-Kompression (Einsparung von etwa 20 % im Vergleich zu gzip).

Wenn Sie ein CDN verwenden, sollten Sie diese Punkte überprüfen: Nehmen Sie eine Datei, die vom CDN gekommen ist, notieren Sie sich ihre Größe im komprimierten Format und komprimieren Sie sie manuell zur Vergleichszwecken (Sie können einen Online-Service zur Unterstützung von brotli verwenden, z. B. alleskomprimieren.de).

2. Festlegung von Client-Caching-Headern

Eine ebenfalls einfache Funktion zur Beschleunigung: Setzen Sie Header für das Caching von Inhalten durch den Client (Browser). Die relevanteste Header ist cache-control, und der veraltete – expires. Außerdem kann Etag verwendet werden. Wichtig ist, dass max-age bei cache-control ausreichend groß ist (mindestens einen Monat oder mehr). Wenn Sie die Ressource maximales Caching auferlegen wollen, können Sie die Option immutable hinzufügen.

CDN können den max-age-Wert herabsetzen, was dazu führt, dass der Benutzer statische Inhalte häufiger erneut laden muss. Unklar ist, ob dies mit dem Wunsch zusammenhängt, den Datenverkehr im Netzwerk zu erhöhen oder die Kompatibilität mit Websites zu verbessern, die den Cache nicht zurücksetzen können. Zum Beispiel beträgt der Standardwert für die Cache-Zeit in den Cloudflare-Headern 1 Stunde, was für unveränderliche statische Inhalte sehr wenig ist.

3. Bilderoptimierung

Da CDN die Funktionen der Caching und Bereitstellung von Bildern übernehmen, ist es logisch, sie auf der Seite des CDN zu optimieren und in dieser Form den Nutzern bereitzustellen. Vorab sei gesagt, dass diese Möglichkeit nur für die CDN-Typen 2, 3 und 5 verfügbar ist.

Bilder können auf verschiedene Weise optimiert werden: durch die Verwendung fortschrittlicher Komprimierungsformate (zum Beispiel WebP), effizientere Encoder (MozJPEG) oder einfach durch das Entfernen überflüssiger Metadaten.

Im Allgemeinen gibt es zwei Arten solcher Optimierungen: mit Qualitätsverlust und ohne Qualitätsverlust. CDN streben normalerweise an, die verlustfreie Optimierung zu verwenden, um mögliche Kundenbeschwerden über die Veränderung der Bildqualität zu vermeiden. Unter diesen Bedingungen wird der Gewinn minimal sein. In der Realität liegt das Qualitätsniveau von JPEG oft weit über dem erforderlichen, und man kann ruhig eine Rekodierung mit einem niedrigeren Qualitätswert durchführen, ohne die Wahrnehmung durch die Nutzer zu beeinträchtigen. Andererseits ist es schwierig, das Qualitätsniveau und die Einstellungen universell für alle möglichen Webanwendungen festzulegen, daher verwenden CDN konservativere Einstellungen im Vergleich zu denen, die im Kontext anwendbar sind (Verwendung der Bilder, Art der Webanwendung usw.).

4. Optimierung der TLS-Verbindung

Der Großteil des Datenverkehrs wird heute über TLS-Verbindungen übertragen, was bedeutet, dass wir zusätzliche Zeit für die TLS-Aushandlung aufwenden. In letzter Zeit wurden neue Technologien entwickelt, um diesen Prozess zu beschleunigen. Dazu gehören EC-Kryptografie, TLS 1.3, Sitzungs-Caching und Sitzungs-Tickets, hardwarebeschleunigte Verschlüsselung (AES-NI) usw. Eine korrekte TLS-Konfiguration kann die Verbindungszeit auf 0-1 RTT (ohne Berücksichtigung von DNS und TCP) reduzieren.

Mit moderner Software ist es nicht schwer, solche Praktiken in den eigenen Einrichtungen zu implementieren.

Nicht alle CDNs setzen die besten Praktiken für TLS um; dies kann durch die Messung der TLS-Verbindungszeit (zum Beispiel mit Webpagetest) überprüft werden. Idealerweise sollte eine neue Verbindung 1 RTT haben, 2 RTT sind ein mittleres Niveau, 3 RTT und mehr sind schlecht.

Es muss auch beachtet werden, dass selbst bei der Verwendung von TLS auf der Ebene des CDN der Server mit unserer Webanwendung ebenfalls TLS verarbeiten muss, und zwar vom CDN aus, da der Verkehr zwischen dem Server und dem CDN über ein öffentliches Netzwerk läuft. Im schlimmsten Fall erhalten wir doppelte TLS-Verbindungslatenzen (die erste zum CDN-Host, die zweite zwischen diesem und unserem Server).

Für einige Anwendungen sollten Sicherheitsfragen berücksichtigt werden: Normalerweise wird der Verkehr an den Knotenpunkten des CDNs entschlüsselt, was eine potenzielle Möglichkeit für den Datenverkehrsabbau darstellt. Eine Option, die keinen Offenlegungsverkehr vorsieht, wird normalerweise in den besten Tarifen gegen eine zusätzliche Gebühr angeboten.

5. Reduzierung der Verbindungslatenzen

Der Hauptvorteil eines CDNs, über den alle reden: geringe Latenzen (geringere Entfernungen) zwischen dem CDN-Host und dem Benutzer. Dies wird durch den Aufbau einer geografisch verteilten Netzwerkarchitektur erreicht, in der die Hosts an Orten mit hoher Benutzerkonzentration (Städte, Internet-Austauschpunkte usw.) platziert sind.

In der Praxis können die Prioritäten für verschiedene Netzwerke in bestimmten Regionen variieren. Zum Beispiel werden russische CDNs mehr Präsenzpunkte in Russland haben. Amerikanische CDNs werden sich hauptsächlich darauf konzentrieren, ihr Netzwerk in den USA auszubauen. Zum Beispiel hat einer der größten CDNs, Cloudflare, nur zwei Punkte in Russland – Moskau und St. Petersburg. Das bedeutet, dass wir maximal etwa 10 ms Latenz im Vergleich zum Direkt-Hosting in Moskau einsparen können.

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

6. Optimierung des Inhalts (Minifizierung, strukturelle Änderungen)

Der komplexeste und technologisch anspruchsvollste Punkt. Die Änderung von Inhalten während der Übertragung kann sehr riskant sein. Selbst wenn wir von Minifizierung sprechen: Die Reduzierung des Quellcodes (durch überflüssige Leerzeichen, unwichtige Strukturen usw.) kann dessen Funktionalität beeinträchtigen. Bei ernsthafteren Änderungen – wie dem Verschieben von JS-Code ans Ende des HTML, dem Zusammenfassen von Dateien und ähnlichem – ist das Risiko, die Funktionalität der Website zu beeinträchtigen, noch größer.

Deshalb beschäftigen sich nur einige CDNs vom Typ 5 damit. Natürlich kann man nicht alle notwendigen Änderungen zur Beschleunigung automatisieren – eine manuelle Analyse und Optimierung sind erforderlich. Zum Beispiel gehört das Entfernen von nicht verwendeten oder doppelten Code zu den manuellen Aufgaben.

In der Regel werden alle solchen Optimierungen über Einstellungen gesteuert, und die gefährlichsten sind standardmäßig deaktiviert.

Unterstützung für Beschleunigungsfunktionen nach CDN-Typen

Schauen wir uns also an, welche potenziellen Beschleunigungsmöglichkeiten verschiedene CDN-Typen bieten.

Zur Übersicht wiederholen wir die Klassifikation.

1. Kostenlose CDNs für die Bereitstellung von JS-Bibliotheken (MaxCDN, Google, Yandex).
2. CDNs von Dienstanbietern zur Client-Optimierung (zum Beispiel Google Fonts für Schriftarten, Cloudinary, Cloudimage für Bilder).
3. CDNs für statische Inhalte und Ressourcenoptimierung in CMS (verfügbar in Bitrix, WordPress und anderen).
4. Allzweck-CDNs (StackPath, CDNVideo, NGENIX, Megafon).
5. CDNs zur Beschleunigung von Websites (Cloudflare, Imperva, Airi).

Jetzt vergleichen wir die Features und Typen von CDNs.

Die Möglichkeit
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Textkompression
+–
–
+–
+–
+

Cache-Header
+
+
+
+
+

Bilder
–
+–
+–
–
+

TLS
–
–
–
+–
+

Latenzen
–
–
–
+
+

Inhalt
–
–
–
–
+

In dieser Tabelle wird „+“ verwendet, um volle Unterstützung anzuzeigen, „–“ bedeutet keine Unterstützung, „+–“ steht für Teilunterstützung. Natürlich sind Abweichungen von dieser Tabelle in der Realität möglich (zum Beispiel kann ein universelles CDN Funktionen zur Bildoptimierung implementieren), aber sie ist für einen allgemeinen Überblick nützlich.

Ergebnisse

Ich hoffe, dass Sie nach dem Lesen dieses Artikels ein klareres Bild von der Empfehlung „verwenden Sie CDN“ zur Beschleunigung von Websites haben.

Wie bei allem darf man den Marketingversprechen eines Dienstes nicht glauben. Die Effekte müssen gemessen und unter realen Bedingungen überprüft werden. Wenn Sie bereits ein CDN verwenden, überprüfen Sie dessen Effizienz anhand der im Artikel beschriebenen Kriterien.

Es ist möglich, dass die Verwendung eines CDNs derzeit das Laden Ihrer Website verlangsamt.

Als allgemeine Empfehlung kann Folgendes festgehalten werden: Analysieren Sie Ihr Publikum und definieren Sie dessen geografische Rahmen. Wenn Ihr Hauptpublikum in einem Radius von 1.000 bis 2.000 Kilometern konzentriert ist, benötigen Sie kein CDN für den ursprünglichen Zweck – die Verringerung der Latenzen. Stattdessen können Sie Ihren Server näher an den Nutzern platzieren und ihn entsprechend konfigurieren, wobei Sie die meisten in diesem Artikel beschriebenen Optimierungen (kostenlos und dauerhaft) erhalten.

Falls Ihr Publikum tatsächlich geografisch verteilt ist (Radius von mehr als 3000 Kilometern), wird die Verwendung eines hochwertigen CDN tatsächlich von Vorteil sein. Es ist jedoch wichtig, im Voraus zu verstehen, was genau Ihr CDN beschleunigen kann (siehe Tabelle mit Möglichkeiten und deren Beschreibung). Die Beschleunigung der Website bleibt trotzdem eine komplexe Aufgabe, die nicht allein durch die Anbindung an ein CDN gelöst werden kann. Abgesehen von den genannten Optimierungen bleiben die effektivsten Beschleunigungsmaßnahmen außerhalb des CDNs: Optimierung der Serverseite, fortschrittliche Änderungen an der Clientseite (Entfernung ungenutzten Codes, Optimierung des Renderprozesses, Arbeiten mit Inhalten, Schriftarten, Responsivität usw.)

Quelle: habr.com