CDN oder schnelleres Hosting: Engpass richtig messen

Die erste Auswahl:

• Entfernte Besucher oder große statische Dateien bremsen: CDN prüfen.
• Die erste HTML-Antwort bleibt überall langsam: Anwendung, Datenbank und Ursprung prüfen.
• Bilder, JavaScript oder Schriften sind zu schwer: Zuerst die Seite optimieren.
• Statische und dynamische Teile bremsen: Maßnahmen können sich ergänzen.

Miss vor jeder Änderung denselben Seitentyp, dieselben Regionen und möglichst vergleichbare Last. Sonst vergleichst du unterschiedliche Situationen statt zwei Lösungen.

CDN und Ursprung lösen verschiedene Probleme

Der Webhost ist der Ursprung deiner Website. Dort liegen Dateien, Anwendung und häufig auch die Datenbank. Ein CDN sitzt zwischen Besuchern und diesem Ursprung. Es kann geeignete Antworten wiederverwenden und von einem näher gelegenen Standort ausliefern.

Das hilft nur bei Anfragen, die sicher zwischengespeichert werden dürfen. Öffentliche Bilder, CSS- und JavaScript-Dateien sind typische Kandidaten. Warenkorb, Kontoansicht oder individuell erzeugte Preise können dagegen von Nutzer zu Nutzer verschieden sein. Solche Antworten brauchen klare Cache-Regeln und dürfen nicht pauschal öffentlich wiederverwendet werden.

Beim Cache-Treffer antwortet ein Edge-Server direkt. Beim Fehlschlag muss er den Ursprung kontaktieren. Bleibt dieser langsam, verschwindet der Engpass nicht vollständig.

Nach der technischen Diagnose bleibt oft eine zweite Frage offen: Welches Hosting-Modell passt zu Verantwortung, Ausfallrisiko und Wechselaufwand des Teams? Dafür bietet Welches Hosting passt? 7 Fragen für eine klare Entscheidung die passende Vertiefung.

So findest du den Engpass

1. Feld- und Labordaten trennen

Felddaten zeigen, was echte Besucher mit ihren Geräten und Netzwerken erleben. Labortests zerlegen eine einzelne Ladefolge unter kontrollierten Bedingungen. Nutze Felddaten für das Ausmaß und einen Labortest mit Netzwerk-Wasserfall für die Ursachenanalyse.

Zwei Messgrößen helfen dabei zusammen: Largest Contentful Paint (LCP) beschreibt, wann der größte sichtbare Inhaltsblock erscheint; Time to First Byte (TTFB) misst den Beginn der Serverantwort. LCP lässt sich in erste Serverantwort, Verzögerung bis zum Start der Hauptressource, Übertragung und Rendern zerlegen. TTFB umfasst neben Backend-Arbeit auch DNS, Verbindungsaufbau, TLS und Weiterleitungen. Ein hoher Wert ist daher ein Ausgangspunkt für die Diagnose, kein Beweis für eine einzelne Ursache.

2. Regionen und Seitentypen vergleichen

Teste eine öffentliche, weitgehend statische und eine dynamische Seite. Vergleiche außerdem eine Region nahe am Ursprung mit einer wichtigen weiter entfernten Nutzerregion.

• Nur die entfernte Region ist langsam: Distanz oder Auslieferung untersuchen.
• Beide Regionen warten auf das erste HTML: Ursprung oder Anwendung untersuchen.
• Nur die dynamische Seite ist langsam: Statische Dateien zu cachen dürfte allein wenig helfen.

3. Cache und Ursprung beobachten

Prüfe bei geeigneten Dateien, ob Anfragen direkt von einem Edge-Server beantwortet werden. Die Status-Header unterscheiden sich je nach Anbieter. Achte zusätzlich auf Cache-Hit-Rate, Antwortalter, Cache-Control-Regeln und das Verhalten nach Inhaltsänderungen.

Eine hohe Trefferquote ist nur gut, wenn die richtige Variante ausgeliefert wird. Cookies, Sprachversionen, Query-Parameter und personalisierte Inhalte können den Cache-Schlüssel verändern oder öffentliches Caching ausschließen.

Miss am Ursprung CPU, Speicher, Datenbankzeit, langsame Abfragen, Fehlerquote und Antwortzeit gemeinsam. Bleiben CPU und Speicher frei, kann ein größerer Tarif wirkungslos sein: Dann liegen Wartezeiten womöglich in externen APIs, seriellen Abfragen, fehlendem Anwendungscache oder blockierendem Code.

Wann ein CDN zuerst sinnvoll ist

Ein CDN passt besonders, wenn viele übertragene Daten öffentlich und wiederverwendbar sind, wichtige Besucher weit vom Ursprung entfernt sind oder statische Downloads Lastspitzen erzeugen. Starte klein mit versionierten Bildern, Stylesheets, Skripten und Downloads. HTML folgt erst nach einer gesonderten Prüfung.

Die folgenden Punkte sind betriebliche Prüfungen; konkrete Funktionen und Preise variieren je nach Anbieter:

• Definiere Cache-Dauer und erlaubte Inhalte.
• Lege das Entfernen alter oder fehlerhafter Versionen fest.
• Plane einen Rückweg für Ausfälle.
• Prüfe HTTPS, Weiterleitungen und CORS.
• Bestimme Logs für Treffer, Fehlschläge und Fehler.
• Kalkuliere variable Kosten für Traffic, Anfragen und Zusatzfunktionen.

Ein CDN verbessert nicht automatisch jede Ladephase. Es fügt außerdem Konfiguration, Abhängigkeit und einen weiteren Fehlerpfad hinzu.

Wann Ursprung oder Backend wichtiger sind

Trenne drei Entscheidungen:

• Mehr Ressourcen: sinnvoll, wenn CPU, RAM oder Datenträger unter vergleichbarer Last nachweislich knapp werden.
• Andere Region oder anderer Anbieter: sinnvoll, wenn Standort, Isolation, Verfügbarkeit oder betrieblicher Support nicht zum Bedarf passen.
• Backend-Optimierung: nötig, wenn schlechte Abfragen, serielle API-Aufrufe, Plugin-Arbeit oder fehlende Anwendungscaches die Antwort verzögern.

Ein Shop oder eine SaaS-Anwendung kann trotzdem beides brauchen: Das CDN liefert Bilder und Skripte aus, während Login, Suche, Checkout und APIs vom Ursprung abhängen.

Risikoarmer Pilot für kleine Teams

Dokumentiere Ausgangswerte und Nutzerregionen. Rolle genau eine reversible Änderung für einen abgegrenzten Teil aus und prüfe unter vergleichbarer Last:

• Ladezeit in den betroffenen Regionen
• Origin-Last und Fehlerquote
• Sichtbarkeit neuer Dateien und Inhaltsänderungen
• korrekte Funktion von Login, Formularen und personalisierten Seiten
• Logs und Kosten

Zeigt die Messung keine relevante Verbesserung, ist „kein weiterer Ausbau“ ein valides Ergebnis. Das gilt ebenso für einen Tarifwechsel.

Dein nächster Schritt

Erfasse für eine öffentliche und eine dynamische Seite TTFB, LCP, wichtige Nutzerregionen und Origin-Auslastung. Wähle danach eine reversible Maßnahme für den auffälligsten Teil der Ladefolge. So wird aus einer pauschalen Infrastrukturfrage ein überprüfbarer Test.

Gute Core Web Vitals sind ein sinnvolles Nutzerziel, aber weder ein einzelner Messwert noch ein CDN garantiert bessere Google-Rankings.