Dimensión Core/Dash: Cadena de consulta (Query String)

Qué captura la dimensión Cadena de consulta

La dimensión Cadena de consulta (Query String) agrupa tus datos de Core Web Vitals según 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, orden de clasificación como sort=price, consultas de búsqueda como q=zapatillas+running, 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 una única URL. CoreDash las mantiene intactas, lo que significa que puedes comparar el LCP, el INP y el CLS de /productos?sort=precio frente a /productos?sort=popularidad 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. /buscar?q=botas y /buscar?q=sandalias son dos claves de caché distintas. Si tu página de resultados de búsqueda genera cientos de consultas únicas por hora, casi ninguna de esas solicitudes se servirá desde la caché. Cada visitante llega a tu servidor de origen en frío.

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

Coste del renderizado del lado del servidor

Los parámetros de filtrado y ordenación a menudo desencadenan las consultas a la base de datos más costosas de una página. Un listado de productos normal en /productos podría estar completamente almacenado en caché. La misma página en /productos?color=rojo&talla=M&marca=Nike&sort=precio-asc puede requerir una consulta compleja, una forma de respuesta diferente o incluso un re-renderizado completo. En las páginas que no pueden almacenar en caché los resultados filtrados de manera eficiente, el Time to First Byte (tiempo hasta el primer byte) aumenta y el LCP le sigue de cerca.

La paginación es otro infractor habitual. 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 tardan más en generarse y con frecuencia nunca se prueban. CoreDash saca a la luz estas diferencias de forma directa, sin que tengas que adivinar.

Comportamiento del lado del cliente activado por parámetros

Algunos parámetros de consulta no cambian la respuesta del servidor, pero sí modifican el JavaScript que se ejecuta durante la carga. Los parámetros de variantes de pruebas A/B, los códigos de seguimiento de afiliados y los tokens de recomendación a menudo son leídos por scripts que inicializan diferentes flujos de la 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, ocasionalmente, causar cambios de diseño (layout shifts) si la variante altera el contenido visible después del renderizado inicial.

Patrones comunes que merece la pena investigar

• Parámetros UTM en el tráfico de pago: Los visitantes de los anuncios suelen llegar con ?utm_source=google&utm_medium=cpc&utm_campaign=.... Si tu CDN los incluye en su clave de caché, el tráfico de pago obtiene constantemente respuestas más lentas que el tráfico orgánico.
• Páginas de resultados de búsqueda: Las consultas cortas y populares pueden almacenarse en caché. Las consultas de larga cola (long-tail) o realizadas por primera vez casi nunca lo hacen. Comparar ?q=nike con ?q=zapatillas+trail+running+azules+hombre+talla+44 a menudo muestra una diferencia medible en el 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 se almacenan en caché. Si tu LCP en el percentil 75 es alto, es probable que las combinaciones de filtros contribuyan a ello.
• Paginación más allá de la página 1: La página 2 y las siguientes suelen ser más lentas y consumir más recursos. A menudo también contienen la misma imagen hero o el mismo diseño, pero sin el beneficio de los recursos almacenados en caché de una visita anterior.

Cómo usar esta dimensión en CoreDash

Selecciona Query String (Cadena de consulta) en el selector de dimensiones de cualquier informe de CoreDash. La tabla mostrará cada cadena de consulta única junto a su LCP, INP, CLS y recuento de visitas. Ordena por LCP para encontrar las combinaciones de parámetros más lentas, u ordena por número de visitas para encontrar las variantes con mayor tráfico.

Combina esta dimensión con la dimensión URL para acotar tu análisis a una única plantilla de página antes de comparar las variantes de su cadena de consulta. Esa combinación facilita la confirmación de si un problema de rendimiento está en la propia página o en un patrón de parámetros específico.

La dimensión Cadena de consulta se encuentra en la categoría Page & Navigation (Página y navegación) en CoreDash, junto a dimensiones como URL, Pathname (Ruta) y Navigation Type (Tipo de navegación).