Cloudflare Analytics: Besucher, Anfragen und Cache-Trefferquote verstehen

Vier Cloudflare-Metriken gemeinsam lesen

Ein allgemeines Beispiel: einige Hundert eindeutige Besucher, einige Tausend Anfragen, mehrere Dutzend Megabyte und eine einstellige Cache-Quote. Diese Signale sind nützlich, zeigen aber nicht, wie viele Menschen eine Seite gelesen haben. Cloudflare beobachtet HTTP-Verkehr, der für proxied DNS-Einträge durch sein Netzwerk läuft. Damit wird eine Infrastrukturebene vor browserbasierten Analytics gemessen. Anfragen können von Menschen, Crawlern, Bots, automatischen Prüfungen oder externen Diensten stammen.

Die vier Werte beschreiben verschiedene Dimensionen. Eindeutige Besucher nähern Verkehrsquellen an; Anfragen zählen einzelne HTTP-Vorgänge; bereitgestellte Daten summieren das Antwortvolumen; der Cache-Prozentsatz zeigt den am Edge ausgelieferten Anteil in der gewählten Ansicht. Vor der Bewertung einer Spitze oder einer niedrigen Quote müssen Zeitraum, Hostname, Filter, Cloudflare-Tarif und die Auswahl zwischen Anfragen und Datenübertragung geklärt werden.

Eindeutige Besucher sind IP-Adressen, keine identifizierten Personen

Warum ein eindeutiger Besucher nicht einem Leser entspricht

Cloudflare erläutert, dass ein Besuch erkannt wird, sobald eine eindeutige IP-Adresse einer Anfrage zugeordnet ist. Das ist eine technische Schätzung, keine Zahl menschlicher Leser, angemeldeter Benutzer oder Sitzungen. Mehrere Personen in einem Heim-, Firmen- oder Mobilfunknetz können eine IP teilen. Eine Person kann nach einem Netzwerk- oder Adresswechsel mehrfach erscheinen. Crawler und Teilabrufe können ebenfalls zählen, ohne eine vollständige Seitenansicht auszulösen.

Für Trends, Anomalien und Verkehrsverteilung bleibt die Zahl wertvoll, wenn Vergleiche dasselbe Fenster und dieselben Filter verwenden. Ein plötzlicher Anstieg kann echtes Interesse, automatisierte Scans, eine Kampagne, Vorschauen sozialer Links oder feindlichen Verkehr anzeigen. Segmentieren Sie zuerst nach Pfad, Land, User Agent, Sicherheitsaktion und HTTP-Status. Die Gesamtzahl der IP-Adressen allein ist kein Beleg für geschäftliche Akquisition.

Warum es viel mehr Anfragen als Besucher gibt

Eine Anfrage ist ein einzelner HTTP-Vorgang. Zum Laden einer Seite können HTML, Stylesheets, JavaScript, Bilder, Schriften, API-Aufrufe und Weiterleitungen nötig sein, sodass viele Anfragen entstehen. Wenn einige Hundert IP-Adressen mehrere Tausend Anfragen erzeugen, ist das resultierende Verhältnis misst kein Engagement: bereits im Browser gespeicherte Dateien, Bots mit einem Abruf, Fehler, Prefetching und die Architektur verändern es erheblich.

Datenübertragung, Cache-Quote und Cache-Status

Das angezeigte Volumen steht für HTTP-Daten in Antworten, die Cloudflare beobachtet hat, nicht für die Größe der Website und nicht zwingend für den von Vercel berechneten Verkehr. Aus gerundeten Summen entsteht nur ein grober Durchschnitt je Anfrage, der HTML, Bilder, Fehler und Antworten ohne Body vermischt. Filter nach Inhaltstyp und URL sind aussagekräftiger, weil sie große, häufig angeforderte Objekte zeigen, die noch den Ursprung erreichen.

Anfragequote und Bytequote beantworten unterschiedliche Fragen

Der Anteil aus dem Cache beantworteter Anfragen zeigt, wie viele Vorgänge den Ursprung vermeiden; der Anteil aus dem Cache gelieferter Daten zeigt die Zahl der Edge-Bytes. Eine Website kann wenige Cache-Treffer und dennoch viel Bandbreite sparen, wenn große Bilder gecacht werden. Umgekehrt können viele kleine Dateien HIT sein, während große Antworten dynamisch bleiben. In Cache Analytics kann eine revalidierte Antwort in der Anfrageansicht dem Ursprung, in der Datenansicht aber Cloudflare zugerechnet werden, weil der Ursprung geprüft wird, der Body jedoch im Cache bleibt.

HIT bedeutet gewöhnlich, dass eine Antwort im Cache verfügbar war; MISS erfordert den Abruf vom Ursprung; BYPASS folgt einer Regel oder einem Signal zur Umgehung; DYNAMIC bezeichnet nicht cachefähigen Inhalt; REVALIDATED führt eine Aktualitätsprüfung durch. Die Aufteilung nach Status, Pfad und Inhaltstyp ist aussagekräftiger als eine einstellige Prozentangabe allein. Sie trennt berechtigt dynamisches HTML von falsch konfigurierten oder nicht wiederverwendbaren Ressourcen.

Menschlichen Verkehr, Bots und Bedrohungen trennen

Laut Zone-Analytics-Dokumentation umfasst das HTTP-Traffic-Panel im kostenlosen Tarif legitime Anfragen ebenso wie Crawler und Bedrohungen. Cloudflare arbeitet am Edge und sieht Clients, die nie JavaScript ausführen. Deshalb kann die Zahl eindeutiger Besucher höher als die Benutzer- und Sitzungszahl browserbasierter Produkte sein. Suchmaschinen-Crawler, Verfügbarkeitsmonitor, Linkvorschau oder Scanner erzeugen echten Infrastrukturverkehr, ohne zwingend Interessenten zu sein.

Schätzen Sie interessierte Menschen durch die Kombination erfolgreicher HTML-Seitenaufrufe, Referrer, besuchter Pfade, bekannter Quellen, Conversion-Ereignisse und verfügbarer Bot-Filter. Untersuchen Sie auch Spitzen bei 403-, 404- und 5xx-Antworten, ungewöhnliche Methoden und unerwartete Länder. Nicht jede Automatisierung ist wertlos: Suchcrawler helfen der Auffindbarkeit, Monitore schützen die Verfügbarkeit. Jede Metrik braucht die passende Frage; identische Summen in allen Dashboards sind kein Qualitätsziel.

Cloudflare, Web Analytics, GA4 und PostHog messen verschiedene Ebenen

Zone Analytics beschreibt den HTTP-Verkehr aus Netzwerksicht. Cloudflare Web Analytics ergänzt Signale auf Seitenebene und zur realen Browserleistung. GA4 modelliert Benutzer, Sitzungen, Akquisitionskanäle und Marketingereignisse; PostHog eignet sich besonders für Produktereignisse, Funnels und Wege. Browserwerkzeuge hängen von Skriptladung, Einwilligung, Blockern, abgeschlossener Navigation und Implementierungsqualität ab. Cloudflare erkennt eine Anfrage auch dann, wenn jemand die Seite vor dem Start des Analytics-Codes verlässt.

Für einen sinnvollen Abgleich vereinheitlichen Sie Zeitraum, Zeitzone, Hostnamen und Umgebungen. Vergleichen Sie dann passende Größen: erfolgreiche HTML-Seitenaufrufe mit Views, Conversions mit bestätigten Ereignissen und Edge-Anfragen mit technischen Logs. Die Erwartung, eindeutige IPs müssten GA4- oder PostHog-Benutzern entsprechen, erzeugt Fehlalarme. Eine praktische Hierarchie nutzt Cloudflare für Volumen und Sicherheit, Web Analytics für Seitenerlebnis, GA4 für Akquisition und PostHog für Verhalten sowie eine serverseitige Quelle für kritische Conversions.

Warum eine niedrige Cache-Quote nicht automatisch ein Fehler ist

Eine niedrige Quote kann korrekt sein, wenn Anfragen vor allem personalisiertes HTML, APIs, Vorschauen, Authentifizierung oder Antworten mit Cookies und privaten Direktiven betreffen. MDN warnt davor, personalisierte Inhalte in gemeinsam genutzten Caches abzulegen, weil andere Benutzer sie erhalten könnten. Fehler, Weiterleitungen, stark variable Query-Parameter und Nicht-GET-Anfragen können die Quote ebenfalls senken. Optimierung bedeutet, nur öffentliche, stabile und wiederverwendbare Antworten zu cachen, nicht einem universellen Zielwert nachzujagen.

Bei Vercel hinter Cloudflare wirken zwei CDN-Ebenen. Ein Cloudflare-MISS, der den konfigurierten Ursprung erreicht, kann weiterhin aus Vercels Edge-Cache kommen. Das Cloudflare-Panel allein zeigt daher weder Funktions- noch Anwendungsserverlast vollständig. Prüfen Sie CF-Cache-Status und x-vercel-cache zusammen mit Cache-Control, CDN-Cache-Control und Vercel-CDN-Cache-Control. Die Header können unterschiedliche Empfänger und TTLs steuern; überlappende Regeln erschweren Invalidierung und Fehlersuche.

Vor Änderungen an Cache Rules sicher prüfen

Beginnen Sie mit einer repräsentativen Woche und ordnen Sie URLs versionierten Assets, öffentlichen Seiten, dynamischem HTML, öffentlichen APIs oder privaten Antworten zu. Messen Sie je Gruppe Anfragen, Bytes, Cache-Status, HTTP-Status und Zeit zum Ursprung. Prüfen Sie die häufigsten MISS-URLs, Header bei wiederholten Anfragen und das Verhalten nach Deployment und Purge. Priorisieren Sie große, häufige öffentliche Assets und schließen Sie Login, Administration, Sitzungscookies sowie personalisierte Daten aus.

• Vergleichen Sie Anfragequote und Bytequote, statt beide als eine Metrik zu behandeln.
• Definieren Sie Cache-Key und TTL nach Pfad und Inhalt, nicht über eine globale Regel.
• Testen Sie Query-Parameter, Cookies, Autorisierung, Sprache und Varianten vor dem Rollout.
• Beobachten Sie Cloudflare und Vercel und dokumentieren Sie die zuständige Ebene.
• Überwachen Sie 4xx, 5xx, Aktualität und Conversions neben der Cache-Verbesserung.

Eine pauschale “cache everything”-Regel ohne Inventar kann veraltete oder private Daten ausliefern und Fehler verbergen. Rollen Sie kleine URL-Gruppen mit Rückweg aus und prüfen Sie Browser sowie Ursprung. Unsere Leistungen für Infrastruktur, Analytics und Performance schaffen ein belastbares Messmodell; für ein Audit Ihrer Cloudflare- und Vercel-Konfiguration können Sie AE Digital Agency kontaktieren.