Dimensione Core/Dash: Query String

Cosa cattura la dimensione Query String

La dimensione Query String raggruppa i dati dei Core Web Vitals in base all'intera query string 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 dei tool di monitoraggio delle performance rimuove le query string o le raggruppa 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 template di pagina, con gli stessi utenti, nello stesso periodo di tempo.

Perché le query string causano regressioni delle performance

I parametri di query sono una delle fonti più comuni di varianza di performance inspiegabile. Ecco perché sono importanti:

Comportamento della cache CDN

Di default, la maggior parte delle CDN tratta gli URL con diverse query string 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 interroga il server di origine a freddo.

Alcune CDN consentono 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 email avrà un tasso di hit della cache quasi nullo e ogni destinatario otterrà un rendering completo dal server anziché una risposta in cache. Questo è un picco LCP comune e misurabile.

Costo del server-side rendering

I parametri di filtro e ordinamento spesso attivano le query di database più costose su una pagina. Un semplice elenco di prodotti in /products potrebbe essere completamente in 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 in cache i risultati filtrati in modo efficiente, il Time to First Byte aumenta, e l'LCP lo segue.

La paginazione è un'altra criticità ricorrente. La pagina 1 di un elenco è di solito veloce perché è la vista predefinita e viene messa in cache in modo aggressivo. La pagina 10 o la pagina 50 è raramente in cache, spesso più lenta da generare e frequentemente mai testata. CoreDash fa emergere queste differenze in modo diretto, senza costringerti a tirare a indovinare.

Comportamento client-side attivato 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 delle affiliazioni 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 shift se la variante modifica il contenuto visibile dopo il paint iniziale.

Pattern comuni che vale la pena indagare

• 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 otterrà costantemente risposte più lente rispetto al traffico organico.
• Pagine dei risultati di ricerca: Le query brevi e popolari potrebbero essere in cache. Le query a coda lunga o effettuate per la prima volta non lo sono quasi mai. Confrontare ?q=nike con ?q=blue+trail+running+shoes+mens+size+11 spesso mostra una differenza misurabile dell'LCP.
• Combinazioni di filtri pesanti: Le pagine delle categorie e-commerce con molteplici filtri attivi sono costose da renderizzare e raramente in cache. Se il tuo 75° percentile dell'LCP è alto, le combinazioni di filtri sono un probabile responsabile.
• Paginazione oltre la pagina 1: La pagina 2 e le successive sono di solito più lente e richiedono più risorse. Spesso contengono anche la stessa hero image o layout, ma senza il vantaggio degli asset in cache da una visita precedente.

Come usare questa dimensione in CoreDash

Seleziona Query String dal selettore delle dimensioni in qualsiasi report di CoreDash. La tabella mostrerà ogni singola query string insieme ai suoi LCP, INP, CLS e conteggio delle visite. Ordina per LCP per trovare le combinazioni di parametri più lente, oppure ordina per conteggio delle visite per trovare le varianti con il traffico maggiore.

Abbina questa dimensione alla dimensione URL per restringere l'analisi a un singolo template di pagina prima di confrontare le sue varianti di query string. Questa combinazione rende facile confermare se un problema di performance risiede nella pagina stessa o in un pattern di parametri specifico.

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