Core/Dash Dimension: Stringa di Query

Cosa cattura la dimensione Stringa di Query

La dimensione Stringa di Query raggruppa i dati Core Web Vitals per l'intera stringa di query presente nell'URL al momento della visita della pagina. Questo include tutto ciò che segue il ?: parametri di tracciamento come utm_source=google, paginazione come page=2, ordinamenti come sort=price, query di ricerca come q=running+shoes, varianti di test A/B e combinazioni di filtri.

La maggior parte degli strumenti di monitoraggio delle prestazioni elimina le stringhe di query o le comprime in un unico gruppo di URL. CoreDash le mantiene intatte, il che significa che puoi confrontare LCP, INP e CLS di /products?sort=price rispetto a /products?sort=popularity sullo stesso modello di pagina, con gli stessi utenti, nello stesso periodo di tempo.

Perché le stringhe di query causano regressioni delle prestazioni

I parametri di query sono una delle cause più comuni di variazione inspiegabile delle prestazioni. Ecco perché sono importanti:

Comportamento di caching della CDN

Per impostazione predefinita, la maggior parte delle CDN tratta gli URL con diverse stringhe di query come voci di cache separate. /search?q=boots e /search?q=sandals sono due chiavi di cache distinte. Se la tua pagina dei risultati di ricerca genera centinaia di query uniche all'ora, quasi nessuna di queste richieste verrà servita dalla cache. Ogni visitatore colpisce il tuo server di origine a freddo.

Alcune CDN ti permettono di ignorare parametri specifici (come i tag UTM) nella chiave di cache, ma questa configurazione è facile da trascurare. Se utm_source=email è incluso nella tua chiave di cache, la landing page della tua campagna e-mail avrà un hit rate della cache vicino allo zero e ogni destinatario otterrà un rendering completo del server invece di una risposta memorizzata nella cache. Si tratta di un picco LCP comune e misurabile.

Costo del rendering lato server

I parametri di filtro e ordinamento spesso innescano le query di database più costose su una pagina. Un semplice elenco di prodotti in /products potrebbe essere completamente memorizzato nella cache. La stessa pagina in /products?color=red&size=M&brand=Nike&sort=price-asc potrebbe richiedere una query complessa, una forma di risposta diversa o persino un re-render completo. Sulle pagine che non possono memorizzare nella cache in modo efficiente i risultati filtrati, il Time to First Byte aumenta e LCP lo segue.

La paginazione è un altro trasgressore ricorrente. La pagina 1 di un elenco è di solito veloce perché è la vista predefinita e viene memorizzata nella cache in modo aggressivo. La pagina 10 o la pagina 50 raramente viene memorizzata nella cache, spesso è più lenta da generare e frequentemente non viene mai testata. CoreDash fa emergere queste differenze direttamente, senza costringerti a tirare a indovinare.

Comportamento lato client innescato dai parametri

Alcuni parametri di query non modificano la risposta del server, ma cambiano quale JavaScript viene eseguito al caricamento. I parametri delle varianti dei test A/B, i codici di tracciamento degli affiliati e i token di referral vengono spesso letti da script che inizializzano flussi UI diversi, attivano richieste di rete aggiuntive o ritardano il rendering in attesa della configurazione dell'esperimento. Questi parametri possono aggiungere un costo INP misurabile e occasionalmente causare layout shifts se la variante modifica il contenuto visibile dopo il initial paint.

Pattern comuni che vale la pena esaminare

• Parametri UTM sul traffico a pagamento: I visitatori provenienti dagli annunci spesso atterrano con ?utm_source=google&utm_medium=cpc&utm_campaign=.... Se la tua CDN li include nella sua chiave di cache, il traffico a pagamento ottiene costantemente risposte più lente rispetto al traffico organico.
• Pagine dei risultati di ricerca: Le query brevi e popolari potrebbero essere memorizzate nella cache. Le query di coda lunga o relative alla prima volta non lo sono quasi mai. Il confronto di ?q=nike con ?q=blue+trail+running+shoes+mens+size+11 mostra spesso una differenza LCP misurabile.
• Combinazioni di filtri pesanti: Le pagine delle categorie di e-commerce con più filtri attivi sono costose da renderizzare e raramente memorizzate nella cache. Se il tuo LCP al 75° percentile è elevato, le combinazioni di filtri sono un probabile fattore scatenante.
• Paginazione oltre la pagina 1: La pagina 2 e le successive sono di solito più lente e richiedono più risorse. Inoltre, spesso contengono la stessa hero image o lo stesso layout, ma senza il vantaggio delle risorse memorizzate nella cache di una visita precedente.

Come usare questa dimensione in CoreDash

Seleziona Stringa di Query dal selettore delle dimensioni in qualsiasi rapporto CoreDash. La tabella mostrerà ogni singola stringa di query insieme a LCP, INP, CLS e numero di visite. Ordina per LCP per trovare le combinazioni di parametri più lente, o ordina per numero di visite per trovare le varianti a traffico più elevato.

Abbina questa dimensione con la dimensione URL per restringere l'analisi a un singolo modello di pagina prima di confrontare le sue varianti di stringhe di query. Questa combinazione rende facile confermare se un problema di prestazioni risiede nella pagina stessa o in uno specifico pattern di parametri.

La dimensione Stringa di Query rientra nella categoria Page & Navigation in CoreDash, insieme a dimensioni come URL, Pathname e Navigation Type.