Core/Dash Boyutu: Query String

Query String boyutunun yakaladıkları

Query String boyutu, Core Web Vitals verilerinizi sayfa ziyareti sırasında URL'de bulunan tam sorgu dizesine göre gruplandırır. Bu, ? işaretinden sonraki her şeyi içerir: utm_source=google gibi izleme parametreleri, page=2 gibi sayfalama parametreleri, sort=price gibi sıralama ölçütleri, q=running+shoes gibi arama sorguları, A/B test varyantları ve filtre kombinasyonları.

Çoğu performans izleme aracı, sorgu dizelerini çıkarır veya bunları tek bir URL grubunda birleştirir. CoreDash bunları olduğu gibi korur; bu da /products?sort=price ile /products?sort=popularity sayfalarının LCP, INP ve CLS değerlerini aynı sayfa şablonunda, aynı kullanıcılarla ve aynı zaman diliminde karşılaştırabileceğiniz anlamına gelir.

Sorgu dizeleri neden performans düşüşlerine yol açar?

Sorgu parametreleri, açıklanamayan performans dalgalanmalarının en yaygın kaynaklarından biridir. İşte bu yüzden önemlidirler:

CDN önbelleğe alma davranışı

Varsayılan olarak çoğu CDN, farklı sorgu dizelerine sahip URL'leri ayrı önbellek kayıtları olarak değerlendirir. /search?q=boots ve /search?q=sandals iki farklı önbellek anahtarıdır. Arama sonuçları sayfanız saatte yüzlerce benzersiz sorgu üretiyorsa, bu isteklerin neredeyse hiçbiri önbellekten sunulmaz. Her ziyaretçi doğrudan başlangıç sunucunuza soğuk bir istek yapar.

Bazı CDN'ler, önbellek anahtarındaki belirli parametreleri (UTM etiketleri gibi) yok saymanıza olanak tanır, ancak bu yapılandırmayı gözden kaçırmak kolaydır. Eğer utm_source=email önbellek anahtarınıza dahil edilmişse, e-posta kampanyası açılış sayfanızın önbellek isabet oranı sıfıra yakın olacaktır ve her alıcı önbelleğe alınmış bir yanıt yerine tam bir sunucu tarafı oluşturma işlemiyle karşılaşır. Bu durum, yaygın ve ölçülebilir bir LCP sıçramasına neden olur.

Sunucu tarafı oluşturma maliyeti

Filtreleme ve sıralama parametreleri genellikle bir sayfadaki en maliyetli veritabanı sorgularını tetikler. /products adresindeki düz bir ürün listelemesi tamamen önbelleğe alınmış olabilir. Aynı sayfanın /products?color=red&size=M&brand=Nike&sort=price-asc versiyonu ise karmaşık bir sorgu, farklı bir yanıt yapısı veya hatta tamamen yeniden oluşturma gerektirebilir. Filtrelenmiş sonuçları verimli bir şekilde önbelleğe alamayan sayfalarda TTFB artar ve LCP de onu takip eder.

Sayfalama bir diğer tutarlı sorundur. 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ğunlukla hiç test edilmez. CoreDash, tahmin yürütmenize gerek kalmadan bu farkları doğrudan ortaya çıkarır.

Parametreler tarafından tetiklenen istemci tarafı davranışları

Bazı sorgu parametreleri sunucu yanıtını değiştirmez ancak yükleme sırasında hangi JavaScript kodlarının çalışacağını değiştirir. A/B test varyantı parametreleri, satış ortaklığı izleme kodları ve referans belirteçleri; farklı UI akışlarını başlatan, ek ağ istekleri gönderen veya deney yapılandırmasını beklerken işlemeyi geciktiren komut dosyaları tarafından sıklıkla okunur. Bu parametreler ölçülebilir bir INP maliyeti ekleyebilir ve eğer varyant, ilk boyamadan sonra görünür içeriği değiştirirse, zaman zaman düzen kaymalarına neden olabilir.

İncelemeye değer yaygın kalıplar

• Ücretli trafikteki UTM parametreleri: Reklamlardan gelen ziyaretçiler genellikle ?utm_source=google&utm_medium=cpc&utm_campaign=... ile açılış yapar. CDN'iniz bunları önbellek anahtarına dahil ediyorsa, ücretli trafik tutarlı bir şekilde organik trafikten 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 alınmaz. ?q=nike ile ?q=blue+trail+running+shoes+mens+size+11 sorgularını karşılaştırmak genellikle ölçülebilir bir LCP farkı gösterir.
• Ağır filtre kombinasyonları: Birden fazla aktif filtreye sahip e-ticaret kategori sayfalarını oluşturmak maliyetlidir ve bu sayfalar nadiren önbelleğe alınır. Eğer 75. yüzdelik LCP değeriniz yüksekse, filtre kombinasyonları muhtemelen buna katkıda bulunuyordur.
• 1. sayfanın ötesindeki sayfalamalar: 2. sayfa ve ötesi genellikle daha yavaş ve daha fazla kaynak tüketen sayfalardır. Ayrıca çoğunlukla aynı hero görselini veya düzeni içerirler, ancak önceki ziyaretten gelen önbelleğe alınmış varlıkların avantajından yoksundurlar.

CoreDash'te bu boyut nasıl kullanılır?

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

Sorgu dizesi varyantlarını karşılaştırmadan önce analizinizi tek bir sayfa şablonuna daraltmak için bu boyutu URL boyutuyla eşleştirin. Bu kombinasyon, bir performans sorununun sayfanın kendisinde mi yoksa belirli bir parametre modelinde mi 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.