Wymiar Core/Dash: Ciąg zapytań (Query String)

Co rejestruje wymiar Ciąg zapytań

Wymiar Ciąg zapytań (Query String) grupuje dane Core Web Vitals według pełnego ciągu zapytań obecnego w adresie URL w momencie odwiedzin strony. Obejmuje to wszystko, co znajduje się po znaku ?: parametry śledzenia takie jak utm_source=google, paginację jak page=2, kolejność sortowania jak sort=price, zapytania wyszukiwania jak q=running+shoes, warianty testów A/B i kombinacje filtrów.

Większość narzędzi do monitorowania wydajności usuwa ciągi zapytań lub zwija je w jedną grupę adresów 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, w tym samym przedziale czasu.

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

Parametry zapytania są jednym z najczęstszych źródeł niewyjaśnionej zmienności 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 oddzielne wpisy w pamięci podręcznej (cache). /search?q=boots i /search?q=sandals to dwa odrębne klucze pamięci podręcznej. Jeśli Twoja strona z wynikami 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 trafia bezpośrednio na Twój serwer pochodzenia (origin server).

Niektóre sieci CDN pozwalają na ignorowanie określonych parametrów (takich jak tagi UTM) w kluczu pamięci podręcznej, ale tę konfigurację łatwo przeoczyć. Jeśli utm_source=email zostanie uwzględniony w Twoim kluczu pamięci podręcznej, Twoja strona docelowa kampanii e-mailowej będzie miała prawie zerowy wskaźnik trafień w pamięci podręcznej, a każdy odbiorca otrzyma pełne renderowanie serwera zamiast buforowanej odpowiedzi. To częsty i mierzalny skok LCP.

Koszt renderowania po stronie serwera

Parametry filtrowania i sortowania często uruchamiają najbardziej kosztowne zapytania do bazy danych na stronie. Zwykła lista produktów na /products może być w pełni zbuforowana. Ta sama strona na /products?color=red&size=M&brand=Nike&sort=price-asc może wymagać złożonego zapytania, innego kształtu odpowiedzi, a nawet pełnego ponownego wyrenderowania. Na stronach, które nie potrafią wydajnie buforować przefiltrowanych wyników, czas do pierwszego bajtu (TTFB) rośnie, a za nim podąża LCP.

Paginacja (stronicowanie) to kolejny konsekwentny winowajca. Strona 1 z listą jest zazwyczaj szybka, ponieważ jest widokiem domyślnym i jest agresywnie buforowana. Strona 10 lub strona 50 jest rzadko buforowana, często wolniej się generuje i nierzadko nigdy nie jest testowana. CoreDash bezpośrednio uwidacznia te różnice, 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 programów partnerskich i tokeny polecające są często odczytywane przez skrypty, które inicjują różne przepływy interfejsu użytkownika, uruchamiają dodatkowe żądania sieciowe lub opóźniają renderowanie w oczekiwaniu na konfigurację eksperymentu. Parametry te mogą dodać mierzalny koszt INP i czasami powodować przesunięcia układu (layout shifts), jeśli wariant zmienia widoczną treść po początkowym wyrenderowaniu (initial paint).

Typowe wzorce warte zbadania

• Parametry UTM dla ruchu płatnego: Odwiedzający z reklam często trafiają na stronę 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ć buforowane. Zapytania z długiego ogona (long-tail) lub zapytania 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ę LCP.
• Ciężkie kombinacje filtrów: Strony kategorii e-commerce z wieloma aktywnymi filtrami są kosztowne w renderowaniu i rzadko buforowane. Jeśli Twój LCP na 75. percentylu jest wysoki, kombinacje filtrów są prawdopodobnym winowajcą.
• Paginacja powyżej strony 1: Strona 2 i kolejne są zazwyczaj wolniejsze i bardziej zasobochłonne. Często zawierają również ten sam obraz powitalny (hero image) lub układ, ale bez korzyści płynących z buforowanych zasobów z poprzedniej wizyty.

Jak korzystać z tego wymiaru w CoreDash

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

Połącz ten wymiar z wymiarem URL, aby zawęzić analizę do jednego szablonu strony przed porównaniem wariantów jej ciągów zapytań. Takie połączenie ułatwia potwierdzenie, czy problem z wydajnością tkwi w samej stronie, czy w określonym wzorcu parametrów.

Wymiar Ciąg zapytań znajduje się w kategorii Page & Navigation w CoreDash, obok wymiarów takich jak URL, Pathname (Ścieżka) i Navigation Type (Typ nawigacji).