Core/Dash Dimension: Query-String

Was die Query-String-Dimension erfasst

Die Dimension Query-String gruppiert deine Core Web Vitals-Daten nach dem vollständigen Query-String, der zum Zeitpunkt des Seitenbesuchs in der URL vorhanden war. Das umfasst alles nach dem ?: Tracking-Parameter wie utm_source=google, Paginierung wie page=2, Sortierungen wie sort=price, Suchanfragen wie q=running+shoes, A/B-Testvarianten und Filterkombinationen.

Die meisten Performance-Monitoring-Tools entfernen Query-Strings oder fassen sie in einer einzigen URL-Gruppe zusammen. CoreDash behält sie unverändert bei. So kannst du LCP, INP und CLS von /products?sort=price direkt mit /products?sort=popularity auf demselben Seitentemplate vergleichen – mit denselben Nutzern und im selben Zeitraum.

Warum Query-Strings Performance-Regressionen verursachen

URL-Parameter sind eine der häufigsten Ursachen für ungeklärte Performance-Schwankungen. Darum sind sie wichtig:

CDN-Caching-Verhalten

Standardmäßig behandeln die meisten CDNs URLs mit unterschiedlichen Query-Strings als separate Cache-Einträge. /search?q=boots und /search?q=sandals sind zwei verschiedene Cache-Keys. Wenn deine Suchergebnisseite Hunderte von eindeutigen Anfragen pro Stunde generiert, wird fast keine dieser Anfragen aus dem Cache bedient. Jeder Besucher trifft deinen Origin-Server kalt.

Einige CDNs erlauben es, bestimmte Parameter (wie UTM-Tags) im Cache-Key zu ignorieren. Diese Konfiguration wird jedoch leicht übersehen. Wenn utm_source=email in deinem Cache-Key enthalten ist, hat die Landingpage deiner E-Mail-Kampagne eine Cache-Hit-Rate von nahezu null. Jeder Empfänger erhält ein vollständiges Server-Rendering anstelle einer Antwort aus dem Cache. Das sorgt für einen häufigen und messbaren LCP-Spike.

Kosten für serverseitiges Rendering

Filter- und Sortierparameter lösen oft die teuersten Datenbankabfragen einer Seite aus. Eine einfache Produktliste unter /products ist vielleicht vollständig gecacht. Dieselbe Seite unter /products?color=red&size=M&brand=Nike&sort=price-asc erfordert eventuell eine komplexe Abfrage, eine andere Antwortstruktur oder sogar ein komplettes Re-Rendering. Auf Seiten, die gefilterte Ergebnisse nicht effizient cachen können, steigt die Time to First Byte – und der LCP folgt.

Die Paginierung ist ein weiterer typischer Übeltäter. Seite 1 einer Liste ist meist schnell, da sie die Standardansicht ist und aggressiv gecacht wird. Seite 10 oder Seite 50 wird selten gecacht, ist oft langsamer in der Generierung und wird meist nie getestet. CoreDash zeigt diese Unterschiede direkt auf, ohne dass du raten musst.

Durch Parameter ausgelöstes clientseitiges Verhalten

Einige Query-Parameter ändern zwar nicht die Serverantwort, aber sie beeinflussen, welches JavaScript beim Laden ausgeführt wird. Parameter für A/B-Testvarianten, Affiliate-Tracking-Codes und Referral-Token werden häufig von Skripten gelesen, die andere UI-Flows initialisieren, zusätzliche Netzwerk-Requests auslösen oder das Rendering verzögern, während sie auf die Experiment-Konfiguration warten. Diese Parameter können die INP-Kosten spürbar erhöhen und gelegentlich Layout-Shifts verursachen, wenn die Variante sichtbare Inhalte nach dem ersten Paint verändert.

Typische Muster, die eine Untersuchung wert sind

• UTM-Parameter bei bezahltem Traffic: Besucher über Werbeanzeigen landen oft mit ?utm_source=google&utm_medium=cpc&utm_campaign=.... Wenn dein CDN diese im Cache-Key berücksichtigt, erhält bezahlter Traffic durchgehend langsamere Antworten als organischer Traffic.
• Suchergebnisseiten: Kurze, beliebte Suchanfragen sind oft gecacht. Long-Tail- oder erstmalige Suchanfragen fast nie. Ein Vergleich von ?q=nike mit ?q=blue+trail+running+shoes+mens+size+11 zeigt oft einen messbaren LCP-Unterschied.
• Komplexe Filterkombinationen: E-Commerce-Kategorieseiten mit mehreren aktiven Filtern sind teuer im Rendering und selten gecacht. Wenn dein LCP im 75. Perzentil hoch ist, sind Filterkombinationen eine wahrscheinliche Ursache.
• Paginierung ab Seite 2: Seite 2 und folgende sind meist langsamer und ressourcenintensiver. Zudem enthalten sie oft dasselbe Hero-Image oder Layout, profitieren aber nicht von gecachten Assets eines vorherigen Besuchs.

So nutzt du diese Dimension in CoreDash

Wähle Query String aus der Dimensionsauswahl in einem beliebigen CoreDash-Bericht. Die Tabelle zeigt jeden eindeutigen Query-String zusammen mit LCP, INP, CLS und der Anzahl der Besuche. Sortiere nach LCP, um die langsamsten Parameterkombinationen zu finden, oder nach der Anzahl der Besuche für die Varianten mit dem meisten Traffic.

Kombiniere diese Dimension mit der Dimension URL, um deine Analyse auf ein einzelnes Seitentemplate einzugrenzen, bevor du dessen Query-String-Varianten vergleichst. Diese Kombination macht es leicht zu prüfen, ob ein Performance-Problem auf der Seite selbst oder an einem bestimmten Parametermuster liegt.

Die Dimension Query String fällt in CoreDash unter die Kategorie Page & Navigation, zusammen mit Dimensionen wie URL, Pathname und Navigation Type.