Core/Dash Boyutu: Query String

Query String boyutu neleri yakalar

Query String boyutu, Core Web Vitals verilerini sayfa ziyareti sırasında URL'de bulunan tam sorgu dizesine göre gruplar. Bu, ? işaretinden sonraki her şeyi kapsar: utm_source=google gibi takip parametreleri, page=2 gibi sayfalama, sort=price gibi sıralama düzenleri, q=running+shoes gibi arama sorguları, A/B testi varyantları ve filtre kombinasyonları.

Çoğu performans izleme aracı sorgu dizelerini temizler veya tek bir URL grubunda birleştirir. CoreDash bunları olduğu gibi korur. Böylece aynı sayfa şablonunda, aynı kullanıcılarla ve aynı zaman diliminde /products?sort=price ile /products?sort=popularity adreslerinin LCP'sini, INP'sini ve CLS'ini karşılaştırabilirsin.

Sorgu dizeleri neden performans regresyonlarına yol açar?

Sorgu parametreleri, açıklanamayan performans dalgalanmalarının en yaygın kaynaklarından biridir. Neden önemli oldukları:

CDN önbellekleme davranışı

Varsayılan olarak çoğu CDN, farklı sorgu dizelerine sahip URL'leri ayrı önbellek girişleri olarak ele alır. /search?q=boots ve /search?q=sandals iki farklı önbellek anahtarıdır. Eğer arama sonuçları sayfan saatte yüzlerce benzersiz sorgu üretiyorsa, bu isteklerin neredeyse hiçbiri önbellekten sunulmaz. Her ziyaretçi doğrudan origin sunucuna ulaşır.

Bazı CDN'ler önbellek anahtarında belirli parametreleri (UTM etiketleri gibi) yoksaymana izin verir, ancak bu yapılandırmayı gözden kaçırmak kolaydır. Eğer utm_source=email önbellek anahtarına dahil edilirse, e-posta kampanyası açılış sayfanın önbellek isabet oranı sıfıra yakın olur. Her alıcı, önbelleğe alınmış bir yanıt yerine sunucu tarafında sıfırdan oluşturulan bir yanıt alır. Bu durum, yaygın ve ölçülebilir bir LCP sıçramasına yol açar.

Sunucu tarafı oluşturma maliyeti

Filtreleme ve sıralama parametreleri genellikle bir sayfadaki en maliyetli veritabanı sorgularını tetikler. /products adresindeki sade bir ürün listesi tamamen önbelleğe alınmış olabilir. Aynı sayfa /products?color=red&size=M&brand=Nike&sort=price-asc adresinde karmaşık bir sorgu, farklı bir yanıt yapısı ve hatta tamamen yeniden oluşturma gerektirebilir. Filtrelenmiş sonuçları verimli bir şekilde önbelleğe alamayan sayfalarda Time to First Byte artar ve LCP de bunu takip eder.

Sayfalama da bir diğer kronik sorun kaynağıdır. Bir listenin 1. sayfası varsayılan görünüm olduğu ve agresif bir şekilde önbelleğe alındığı için genellikle hızlıdır. 10. veya 50. sayfa ise nadiren önbelleğe alınır, oluşturulması genellikle daha yavaştır ve çoğu zaman hiç test edilmez. CoreDash, tahmin yürütmene gerek kalmadan bu farkları doğrudan ortaya koyar.

Parametrelerin tetiklediği istemci tarafı davranışları

Bazı sorgu parametreleri sunucu yanıtını değiştirmez, ancak yükleme sırasında çalışan JavaScript'i etkiler. A/B testi varyant parametreleri, affiliate takip kodları ve referral token'ları; farklı arayüz akışlarını başlatan, ek ağ istekleri tetikleyen veya deney yapılandırmasını beklerken oluşturmayı geciktiren script'ler tarafından sıklıkla okunur. Bu parametreler ölçülebilir INP maliyeti ekleyebilir ve varyantın ilk çizimden sonra görünür içeriği değiştirmesi durumunda zaman zaman düzen kaymalarına neden olabilir.

Araştırmaya değer yaygın kalıplar

• Ücretli trafikteki UTM parametreleri: Reklamlardan gelen ziyaretçiler genellikle ?utm_source=google&utm_medium=cpc&utm_campaign=... ile gelir. Eğer CDN'in bunları önbellek anahtarına dahil ediyorsa, ücretli trafik organik trafiğe kıyasla sürekli olarak daha yavaş yanıtlar alır.
• Arama sonuç sayfaları: Kısa ve popüler sorgular önbelleğe alınabilir. Uzun kuyruklu veya ilk kez yapılan sorgular ise neredeyse hiçbir zaman önbelleğe alınmaz. ?q=nike ile ?q=blue+trail+running+shoes+mens+size+11 adreslerinin karşılaştırılması genellikle ölçülebilir bir LCP farkı gösterir.
• Yoğun filtre kombinasyonları: Birden fazla aktif filtre içeren e-ticaret kategori sayfalarının oluşturulması maliyetlidir ve bunlar nadiren önbelleğe alınır. Eğer 75. persentil LCP'n yüksekse, filtre kombinasyonları bunun muhtemel sorumlusudur.
• 1. sayfanın ötesindeki sayfalama: 2. sayfa ve sonrası genellikle daha yavaştır ve daha fazla kaynak tüketir. Ayrıca genellikle aynı hero görselini veya düzenini içerirler, ancak önceki bir ziyaretten kalan önbelleğe alınmış kaynakların avantajından yoksundurlar.

Bu boyutu CoreDash'te nasıl kullanırsın?

Herhangi bir CoreDash raporundaki boyut seçiciden Query String seçeneğini belirle. Tablo, her bir benzersiz sorgu dizesini LCP, INP, CLS ve ziyaret sayısı değerleriyle birlikte gösterir. En yavaş parametre kombinasyonlarını bulmak için LCP'ye göre sırala veya en yüksek trafiğe sahip varyantları bulmak için ziyaret sayısına göre sırala.

Sorgu dizesi varyantlarını karşılaştırmadan önce analizini tek bir sayfa şablonuna daraltmak için bu boyutu URL boyutuyla eşleştir. Bu kombinasyon, bir performans sorununun sayfanın kendisinde mi yoksa belirli bir parametre kalıbında mı olduğunu doğrulamayı kolaylaştırır.

Query String boyutu, CoreDash'te URL, Pathname ve Navigation Type gibi boyutlarla birlikte Page & Navigation kategorisi altında yer alır.