Dimensión de Core/Dash: Query String

Qué captura la dimensión Query String

La dimensión Query String agrupa sus datos de Core Web Vitals por la cadena de consulta completa presente en la URL en el momento de la visita a la página. Esto incluye todo lo que va después del ?: parámetros de seguimiento como utm_source=google, paginación como page=2, órdenes de clasificación como sort=price, consultas de búsqueda como q=running+shoes, variantes de pruebas A/B y combinaciones de filtros.

La mayoría de las herramientas de monitorización del rendimiento eliminan las cadenas de consulta o las agrupan en un único grupo de URL. CoreDash las mantiene intactas, lo que significa que puede comparar el LCP, INP y CLS de /products?sort=price frente a /products?sort=popularity en la misma plantilla de página, con los mismos usuarios y durante el mismo periodo de tiempo.

Por qué las cadenas de consulta causan regresiones de rendimiento

Los parámetros de consulta son una de las fuentes más comunes de variaciones de rendimiento inexplicables. He aquí por qué son importantes:

Comportamiento de la caché de la CDN

Por defecto, la mayoría de las CDN tratan las URL con diferentes cadenas de consulta como entradas de caché separadas. /search?q=boots y /search?q=sandals son dos claves de caché distintas. Si su página de resultados de búsqueda genera cientos de consultas únicas por hora, casi ninguna de esas peticiones se servirá desde la caché. Cada visitante llega a su servidor de origen en frío.

Algunas CDN permiten ignorar parámetros específicos (como las etiquetas UTM) en la clave de caché, pero es fácil pasar por alto esa configuración. Si se incluye utm_source=email en su clave de caché, la página de destino de su campaña de correo electrónico tendrá una tasa de aciertos de caché cercana a cero, y cada destinatario obtendrá un renderizado completo en el servidor en lugar de una respuesta en caché. Ese es un pico de LCP común y medible.

Coste del renderizado del lado del servidor

Los parámetros de filtro y ordenación a menudo desencadenan las consultas a la base de datos más costosas de una página. Un listado de productos simple en /products podría estar completamente en caché. La misma página en /products?color=red&size=M&brand=Nike&sort=price-asc puede requerir una consulta compleja, un formato de respuesta diferente o incluso un renderizado completo. En las páginas que no pueden almacenar en caché los resultados filtrados de manera eficiente, el Time to First Byte aumenta, y el LCP le sigue.

La paginación es otra causante constante. La página 1 de un listado suele ser rápida porque es la vista predeterminada y se almacena en caché de forma agresiva. La página 10 o la 50 rara vez se almacenan en caché, a menudo son más lentas de generar y frecuentemente nunca se prueban. CoreDash saca a la luz estas diferencias directamente, sin obligarle a adivinar.

Comportamiento del lado del cliente desencadenado por parámetros

Algunos parámetros de consulta no cambian la respuesta del servidor, pero sí cambian el JavaScript que se ejecuta al cargar. Los parámetros de variantes de pruebas A/B, los códigos de seguimiento de afiliados y los tokens de referencia son leídos frecuentemente por scripts que inicializan diferentes flujos de interfaz de usuario, disparan solicitudes de red adicionales o retrasan el renderizado mientras esperan la configuración del experimento. Estos parámetros pueden añadir un coste de INP medible y, en ocasiones, causar cambios de diseño si la variante modifica el contenido visible después del pintado inicial.

Patrones comunes que vale la pena investigar

• Parámetros UTM en tráfico de pago: Los visitantes de anuncios a menudo llegan con ?utm_source=google&utm_medium=cpc&utm_campaign=.... Si su CDN los incluye en su clave de caché, el tráfico de pago obtiene sistemáticamente respuestas más lentas que el tráfico orgánico.
• Páginas de resultados de búsqueda: Las consultas cortas y populares pueden estar en caché. Las consultas de cola larga o de primera vez casi nunca lo están. Comparar ?q=nike frente a ?q=blue+trail+running+shoes+mens+size+11 a menudo muestra una diferencia medible de LCP.
• Combinaciones de filtros pesadas: Las páginas de categorías de comercio electrónico con múltiples filtros activos son costosas de renderizar y rara vez están en caché. Si su LCP del percentil 75 es alto, es muy probable que las combinaciones de filtros contribuyan a ello.
• Paginación más allá de la página 1: La página 2 y posteriores suelen ser más lentas y consumir más recursos. A menudo también contienen la misma imagen principal (hero) o diseño, pero sin el beneficio de los recursos en caché de una visita anterior.

Cómo utilizar esta dimensión en CoreDash

Seleccione Query String en el selector de dimensiones de cualquier informe de CoreDash. La tabla mostrará cada cadena de consulta única junto con su LCP, INP, CLS y el recuento de visitas. Ordene por LCP para encontrar las combinaciones de parámetros más lentas, u ordene por el recuento de visitas para encontrar las variantes con mayor tráfico.

Combine esta dimensión con la dimensión URL para acotar su análisis a una única plantilla de página antes de comparar sus variantes de cadena de consulta. Esa combinación facilita confirmar si un problema de rendimiento reside en la página en sí o en un patrón de parámetros específico.

La dimensión Query String pertenece a la categoría Página y Navegación en CoreDash, junto a dimensiones como URL, Pathname y Navigation Type.