Core/Dash Dimension: Repeat Visitor

Dimension: Nutzerverhalten: Repeat Visitor (fv)

Die Dimension Repeat Visitor teilt Ihre Performance-Daten in zwei Gruppen auf: Nutzer, die Ihre Website bereits besucht haben, und solche, die dies nicht getan haben. Der technische Unterschied zwischen diesen Gruppen ist der Browser-Cache. Ein wiederkehrender Besucher lädt Ihre Schriftarten, Skripte und Bilder von der Festplatte. Ein neuer Besucher ruft jedes Byte über das Netzwerk ab.

Dies ist wichtig, da Ihr aggregierter LCP-Wert ein gewichteter Durchschnitt aus beiden ist. Wenn 40 % Ihrer Sitzungen neue Besucher sind, ziehen deren Cold-Cache-Ladezeiten Ihren p75-Wert nach oben. Ohne diese Dimension können Sie nicht feststellen, ob eine LCP-Verschlechterung ein echtes Infrastrukturproblem oder ein vorübergehender Anstieg der Neuakquise von Nutzern ist.

Warum die Performance-Lücke größer ist, als Sie erwarten

Der Browser-Cache eliminiert ganze Request-Ketten für wiederkehrende Besucher. Auf einer typischen Content-Website überspringt ein wiederkehrender Besucher den DNS-Lookup, den TCP-Handshake, die TLS-Verhandlung und die Serverantwort für jedes gecachte Asset. Die LCP-Ressource selbst wird oft in unter 5 ms aus dem Memory-Cache bereitgestellt, anstatt 200 ms bis 800 ms über das Netzwerk zu benötigen. Das ist keine marginale Verbesserung: Es ist ein struktureller Unterschied in der Art und Weise, wie die Seite lädt.

In den CoreDash-Daten über überwachte Websites hinweg zeigen wiederkehrende Besucher typischerweise um 35 % bis 60 % niedrigere LCP-Werte als neue Besucher auf denselben Seiten. Die Lücke ist am größten auf bildlastigen Seiten, auf denen das Hero-Bild groß und der Ursprungsserver geografisch weit vom Nutzer entfernt ist. Auf Seiten mit serverseitigem Rendering und einem Text-LCP-Element verringert sich die Lücke, da die Ladeverzögerung für Text für beide Gruppen nahezu null beträgt.

Die INP-Unterschiede zwischen den beiden Gruppen sind kleiner, aber dennoch vorhanden. Neue Besucher lösen beim ersten Laden oft mehr JavaScript-Parsing aus, da Modul-Bundles zum ersten Mal ausgewertet werden. Wiederkehrende Besucher profitieren vom Code-Cache der V8-Engine, der kompilierten Bytecode speichert und den Parse- und Compile-Schritt komplett überspringt. Auf JavaScript-lastigen Seiten kann dies die Verarbeitungszeit um 50 ms bis 150 ms reduzieren.

Die drei Werte richtig lesen

0: Repeat Visitor

Der Browser hat gemeldet, dass dies nicht die erste Sitzung des Nutzers auf Ihrem Origin ist. Gecachte Ressourcen sind verfügbar. Auf den meisten Marketing- und Redaktions-Websites, die in CoreDash getrackt werden, machen wiederkehrende Besucher 55 % bis 70 % aller Sitzungen aus. Ihre Performance-Daten sind Ihre Warm-Cache-Baseline: das Best-Case-Szenario für echte Nutzer, die Ihre Website kennen. Wenn Ihr LCP hier schlecht ist, liegt das Problem nicht am Cache. Untersuchen Sie stattdessen renderblockierende Ressourcen, die Serverantwortzeit oder die Renderverzögerung (Render Delay).

1: New Visitor

Kein Cache. Der Browser ruft jede Ressource über das Netzwerk ab. Dies ist Ihr Cold-Cache-Worst-Case und repräsentiert den ersten Eindruck für jeden Nutzer, der Sie über die organische Suche, eine bezahlte Anzeige oder einen Social Share findet. Neue Besucher machen typischerweise 30 % bis 45 % der Sitzungen aus. Ihre LCP-Werte liegen auf bildbasierten Seiten 300 ms bis 700 ms höher als bei wiederkehrenden Besuchern. Wenn der LCP Ihrer neuen Besucher den Schwellenwert von 2,5 s verfehlt, der LCP Ihrer wiederkehrenden Besucher diesen aber besteht, ist Ihr Optimierungsziel klar: Reduzieren Sie die Größe und Verzögerung der LCP-Ressource selbst, da Sie sich bei dieser Zielgruppe nicht auf den Cache verlassen können.

2: Not Measured

CoreDash konnte die Besuchsart für diese Sitzung nicht ermitteln. Dies tritt typischerweise auf, wenn der Browser den Speicherzugriff blockiert, der erforderlich ist, um zwischen neuen und wiederkehrenden Besuchern zu unterscheiden, oder wenn eine datenschutzorientierte Browserkonfiguration die Überprüfung verhindert. Auf den meisten Websites liegt dieser Anteil bei unter 5 % der Sitzungen. Betrachten Sie dies eher als Grundrauschen (Noise Floor) und nicht als ein Segment, auf das Sie hin optimieren sollten.

Debugging-Workflow

1. Ermitteln Sie Ihre Baseline-Verteilung: Öffnen Sie die Dimension Repeat Visitor in CoreDash und notieren Sie sich den Prozentsatz an neuen gegenüber wiederkehrenden Sitzungen. Wenn neue Besucher über 50 % des Traffics ausmachen, ist die Cold-Cache-Performance Ihre dominierende User Experience und muss das primäre Optimierungsziel sein.
2. Vergleichen Sie den LCP nach Besuchsart: Filtern Sie nur nach neuen Besuchern und notieren Sie den p75 LCP. Filtern Sie dann nach wiederkehrenden Besuchern und notieren Sie dieselbe Metrik. Eine Lücke von über 500 ms deutet auf die Asset-Größe oder die Netzwerkabrufzeit als Engpass hin. Eine Lücke von unter 200 ms weist auf renderseitige Probleme hin, die beide Gruppen gleichermaßen betreffen.
3. Zielen Sie direkt auf die LCP-Ressource ab: Für neue Besucher mit langsamem LCP besteht die Lösung darin, die Ladezeit der Ressource zu reduzieren. Komprimieren Sie das LCP-Bild, stellen Sie es über einen CDN-Edge-Node in der Nähe Ihrer Nutzer bereit und wenden Sie fetchpriority="high" an. Diese Verbesserungen bleiben unabhängig vom Cache-Status bestehen. Verlassen Sie sich nicht auf Caching, um ein übergroßes oder langsam bereitgestelltes LCP-Asset zu kompensieren.
4. Validieren Sie mit der Dimension Navigation Type: Gleichen Sie die Daten mit der Dimension Navigation Type ab. Reload- und Back-Forward-Navigationen tendieren stark zu wiederkehrenden Besuchern. Wenn der LCP Ihrer wiederkehrenden Besucher unerwartet langsam aussieht, könnte ein hoher Anteil an Reload-Navigationen (bei denen gecachte Ressourcen revalidiert statt direkt ausgeliefert werden) der Grund dafür sein.

Technische Faustregeln

• LCP-Ziel für neue Besucher: Unter 2,5 s beim p75. Dies ist schwerer zu erreichen als der LCP für wiederkehrende Besucher und erfordert tatsächliche Infrastrukturarbeit: CDN, Bildoptimierung und die korrekte Fetch Priority.
• Akzeptable Lücke zwischen LCP für neue und wiederkehrende Besucher: Bis zu 400 ms. Eine größere Lücke zeigt an, dass Ihre Website vom Browser-Cache abhängig ist, um die Core Web Vitals zu bestehen, was bedeutet, dass die ersten Eindrücke fehlschlagen.
• Not Measured unter 5 %: Wenn dieser Bereich auf über 10 % anwächst, untersuchen Sie, ob eine Cookie-Consent-Implementierung oder eine Änderung der Speicherberechtigungen die Erkennung der Besuchsart blockiert.

Die Dimension Repeat Visitor ist einer der ersten Filter, die ich anwende, wenn eine Website beim LCP ein grenzwertiges Bestehen (Borderline Pass) aufweist. Aggregierte Felddaten verbergen die wahre Geschichte. Die Aufschlüsselung nach Besuchsart zeigt sofort, ob die Optimierungsarbeit solide ist oder ob sich die Website auf Cache-Treffer eines treuen, wiederkehrenden Publikums verlässt, während sie bei jedem neuen Nutzer, der über die Suche kommt, versagt.