Wymiar Core/Dash: Query String

Co rejestruje wymiar Query String

Wymiar Query String grupuje Twoje dane Core Web Vitals według pełnego ciągu zapytania obecnego w adresie URL w momencie wizyty na stronie. Obejmuje to wszystko, co znajduje się po znaku ?: parametry śledzenia takie jak utm_source=google, paginację taką jak page=2, parametry sortowania takie jak sort=price, zapytania wyszukiwania takie jak q=running+shoes, warianty testów A/B oraz kombinacje filtrów.

Większość narzędzi do monitorowania wydajności usuwa ciągi zapytań lub łączy je w jedną grupę URL. CoreDash zachowuje je w nienaruszonym stanie, co oznacza, że możesz porównać LCP, INP i CLS dla /products?sort=price w stosunku do /products?sort=popularity na tym samym szablonie strony, z tymi samymi użytkownikami i w tym samym okresie.

Dlaczego ciągi zapytań powodują regresje wydajności

Parametry zapytania to jedno z najczęstszych źródeł niewyjaśnionej wariancji wydajności. Oto dlaczego mają znaczenie:

Zachowanie buforowania CDN

Domyślnie większość sieci CDN traktuje adresy URL z różnymi ciągami zapytań jako osobne wpisy w pamięci podręcznej. /search?q=boots i /search?q=sandals to dwa odrębne klucze pamięci podręcznej. Jeśli Twoja strona wyników wyszukiwania generuje setki unikalnych zapytań na godzinę, prawie żadne z tych żądań nie zostanie obsłużone z pamięci podręcznej. Każdy odwiedzający uderza w Twój serwer źródłowy całkowicie na nowo.

Niektóre sieci CDN pozwalają ignorować określone parametry (jak tagi UTM) w kluczu pamięci podręcznej, ale łatwo przeoczyć taką konfigurację. Jeśli utm_source=email zostanie uwzględniony w kluczu pamięci podręcznej, strona docelowa kampanii e-mailowej będzie miała niemal zerowy wskaźnik trafień w pamięci podręcznej, a każdy odbiorca otrzyma pełne renderowanie serwera zamiast scachowanej odpowiedzi. Jest to powszechny i mierzalny skok LCP.

Koszt renderowania po stronie serwera

Parametry filtrowania i sortowania często uruchamiają najdroższe zapytania do bazy danych na stronie. Zwykła lista produktów pod adresem /products może być w pełni scachowana. Ta sama strona pod adresem /products?color=red&size=M&brand=Nike&sort=price-asc może wymagać złożonego zapytania, innej struktury odpowiedzi lub nawet całkowitego ponownego wyrenderowania. Na stronach, które nie potrafią wydajnie buforować przefiltrowanych wyników, Time to First Byte rośnie, a za nim podąża LCP.

Paginacja to kolejny stały winowajca. Strona 1 listy jest zazwyczaj szybka, ponieważ jest to widok domyślny i jest agresywnie buforowana. Strona 10 lub strona 50 jest rzadko buforowana, często wolniejsza do wygenerowania i nierzadko w ogóle nietestowana. CoreDash uwidacznia te różnice bezpośrednio, nie zmuszając Cię do zgadywania.

Zachowanie po stronie klienta wyzwalane przez parametry

Niektóre parametry zapytania nie zmieniają odpowiedzi serwera, ale zmieniają to, jaki JavaScript jest uruchamiany podczas ładowania. Parametry wariantów testów A/B, kody śledzenia afiliacyjnego i tokeny polecające są często odczytywane przez skrypty, które inicjują różne przepływy UI, uruchamiają dodatkowe żądania sieciowe lub opóźniają renderowanie w oczekiwaniu na konfigurację eksperymentu. Parametry te mogą dodać wymierny koszt INP i czasami powodować przesunięcia układu, jeśli dany wariant zmienia widoczną treść po początkowym malowaniu.

Popularne wzorce warte zbadania

• Parametry UTM w płatnym ruchu: Odwiedzający z reklam często lądują z ?utm_source=google&utm_medium=cpc&utm_campaign=.... Jeśli Twoja sieć CDN uwzględnia je w swoim kluczu pamięci podręcznej, płatny ruch konsekwentnie otrzymuje wolniejsze odpowiedzi niż ruch organiczny.
• Strony wyników wyszukiwania: Krótkie, popularne zapytania mogą być scachowane. Zapytania z długiego ogona lub te wpisywane po raz pierwszy prawie nigdy nie są. Porównanie ?q=nike z ?q=blue+trail+running+shoes+mens+size+11 często wykazuje mierzalną różnicę w LCP.
• Ciężkie kombinacje filtrów: Strony kategorii e-commerce z wieloma aktywnymi filtrami są drogie w renderowaniu i rzadko buforowane. Jeśli Twój 75. percentyl LCP jest wysoki, to kombinacje filtrów są prawdopodobnie jednym z czynników.
• Paginacja powyżej strony 1: Strona 2 i kolejne są zazwyczaj wolniejsze i bardziej zasobożerne. Często zawierają one również ten sam obraz powitalny lub układ, ale bez korzyści płynących ze scachowanych zasobów z poprzedniej wizyty.

Jak korzystać z tego wymiaru w CoreDash

Wybierz Query String z selektora wymiarów w dowolnym raporcie CoreDash. Tabela pokaże każdy unikalny ciąg zapytania wraz z jego LCP, INP, CLS i liczbą wizyt. Posortuj według LCP, aby znaleźć najwolniejsze kombinacje parametrów, lub posortuj według liczby wizyt, aby znaleźć warianty o największym ruchu.

Połącz ten wymiar z wymiarem URL, aby zawęzić analizę do pojedynczego szablonu strony przed porównaniem jego wariantów ciągów zapytań. Ta kombinacja ułatwia potwierdzenie, czy problem z wydajnością tkwi w samej stronie, czy w konkretnym wzorcu parametrów.

Wymiar Query String znajduje się w kategorii Page & Navigation w CoreDash, obok takich wymiarów jak URL, Pathname i Navigation Type.