SpeedCurve combina la monitorización de usuarios reales con pruebas sintéticas repetibles para identificar qué visitantes encuentran páginas lentas e investigar qué ha cambiado. Está pensado para sitios que necesitan un diagnóstico continuo del rendimiento entre versiones, plantillas y dispositivos. Su función es aportar evidencias para tomar decisiones: instalar un script de monitorización no mejora por sí solo las Core Web Vitals.
Qué aporta SpeedCurve al trabajo de rendimiento
Una prueba de laboratorio describe una página en unas condiciones determinadas. La monitorización de usuarios reales, conocida como RUM, mide las visitas mientras las personas utilizan el sitio. SpeedCurve ofrece ambos enfoques. Su documentación describe un panel Vitals que reúne resultados sintéticos y datos RUM cuando la recopilación está activada, además de vistas más detalladas para investigar el rendimiento.
La plataforma de monitorización del rendimiento SpeedCurve resulta pertinente cuando una sola URL de prueba ya no representa bien el sitio. Un medio puede necesitar distinguir las plantillas de artículos de las páginas de categorías. Una tienda puede necesitar separar la búsqueda de productos del proceso de compra. Son experiencias distintas, aunque compartan dominio y sistema de diseño.
La documentación también describe etiquetas de página, presupuestos de rendimiento y vistas de despliegues. Estas funciones permiten organizar un proceso para localizar un grupo de páginas afectado, investigar una versión y registrar el trabajo pendiente. No demuestran que el último despliegue haya causado todos los cambios de una gráfica. También hay que examinar la composición del tráfico y los cambios en la recopilación.
Define grupos de páginas útiles antes de medir la situación inicial
Empieza por preguntas sobre las que el equipo pueda actuar. Para un medio, podrían ser si la plantilla de artículo carga a tiempo su imagen principal y si el menú móvil responde correctamente. El plan inicial debe identificar las plantillas, los dispositivos y las interacciones importantes. Reunir muchas métricas sirve de poco si nadie se responsabiliza del trabajo que generan.
SpeedCurve utiliza por defecto el título del documento como etiqueta de página en RUM. Esto puede producir más detalle del necesario: cada título de artículo podría convertirse en un grupo independiente. El servicio documenta reglas de URL y una API de JavaScript para asignar etiquetas. Elige etiquetas estables de plantilla cuando quieras comparar muchas páginas similares.
Haz coincidir las etiquetas de las pruebas sintéticas con las de RUM. SpeedCurve señala expresamente esta correspondencia como requisito para relacionar ambos conjuntos de datos en los paneles pertinentes. Comprueba algunas URL representativas antes de ampliar la implantación. Una página de producto agrupada por error con los resultados de búsqueda puede producir una gráfica convincente, pero una comparación poco útil.
Documenta las reglas de etiquetado junto con la implementación. SpeedCurve indica que los cambios de etiquetas no reclasifican las páginas vistas ya recopiladas. Si modificas la agrupación durante una investigación, considéralo un cambio en la medición. Anota cuándo ocurrió y evita presentar la tendencia resultante como una comparación continua de la misma población.
Interpreta las Core Web Vitals junto con la población medida
Google define como buenos unos valores de LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, evaluados en el percentil 75. LCP se refiere a la carga, INP a la capacidad de respuesta y CLS a la estabilidad visual. Estos umbrales clasifican una experiencia, pero no indican qué cambio de implementación resolverá el problema.
Por eso, un informe útil identifica la población medida. Incluye el grupo de páginas, el segmento de dispositivos, el periodo y la muestra disponible. El percentil de las páginas de producto en móviles y el de todo el sitio en todos los dispositivos responden a preguntas diferentes. Tratarlos como equivalentes puede ocultar precisamente el problema que se busca.
Utiliza la referencia de umbrales de Core Web Vitals para interpretar los valores y vuelve después al segmento afectado. Examina la distribución, además del percentil. Un cambio en la composición de las visitas puede mover un resultado agregado aunque la plantilla no haya cambiado.
La ausencia de datos necesita una explicación
Una medición ausente no equivale a un resultado aprobado. Confirma que se ejecutó la recopilación y que el navegador, el ciclo de vida de la página y el comportamiento del visitante permitían comunicar la métrica antes de sacar conclusiones.
Utiliza pruebas sintéticas para investigar un problema de campo
Los datos de campo permiten identificar una experiencia que merece atención. Una prueba controlada facilita examinar una explicación propuesta. La distinción importa cuando la lentitud solo aparece en algunos dispositivos, después de una interacción concreta o en un estado que una prueba básica de navegación nunca alcanza.
La guía sobre datos de campo y de laboratorio explica por qué pueden discrepar. La documentación de SpeedCurve ofrece vistas de investigación separadas para datos sintéticos y RUM. Úsalas como evidencias complementarias. No promedies sus valores ni presentes una ejecución sintética como la experiencia de todos los visitantes.
Antes de cambiar el sitio, escribe una hipótesis breve. Por ejemplo, una hipótesis ilustrativa sería que una nueva plantilla de artículo retrasa el descubrimiento de la imagen principal por parte del navegador. Es una explicación propuesta, no un hallazgo. Selecciona una página representativa y examina la carga de recursos en condiciones constantes antes y después de un cambio concreto.
Después vuelve a RUM. Compara el mismo grupo de páginas y segmento de dispositivos durante un periodo adecuado, comprobando si cambió la composición del tráfico. Si mejora la prueba controlada, pero no la distribución de campo correspondiente, investiga la diferencia. La página probada, la versión entregada, el estado del consentimiento o el segmento de tráfico pueden no representar las visitas que siguen teniendo problemas.
Convierte un presupuesto de rendimiento en una tarea asignada
SpeedCurve documenta presupuestos de rendimiento y vistas que relacionan los despliegues registrados con cambios en el rendimiento. Solo son útiles si el equipo acuerda qué hacer después. Define quién recibe el hallazgo, qué evidencias necesita y cómo distinguirá una regresión de una versión de la variación habitual.
El registro de investigación puede ser breve. Incluye la plantilla afectada, la métrica, el segmento de dispositivos, el despliegue pertinente, las condiciones de comparación y la persona encargada de comprobar la hipótesis. Añade la decisión posterior: corregir, revertir, seguir investigando o cerrar con una explicación. No trates una alerta como prueba de una causa.
Ante problemas de respuesta, identifica la interacción concreta. Decir únicamente «INP es lento» obliga a la siguiente persona a repetir el trabajo de descubrimiento. Indica si el retraso aparece al abrir la navegación, filtrar un listado o enviar un formulario. La guía para mejorar INP ayuda a convertir esa observación en una investigación del hilo principal y del renderizado.
Elige un periodo de observación acorde con el tráfico del segmento. Una plantilla con pocas visitas puede necesitar más tiempo antes de que su distribución permita una comparación útil. No fabriques certeza mediante una cifra más precisa o una gráfica más acotada. Indica cuándo las evidencias siguen siendo escasas y mantén la investigación abierta mientras se recopilan más datos.
Evalúa la recopilación, el esfuerzo operativo y los límites
Antes de adoptar SpeedCurve, confirma que alguien puede instalar y mantener la integración RUM, administrar los accesos e investigar los hallazgos. Revisa las condiciones comerciales vigentes para el volumen previsto, las pruebas sintéticas necesarias y la conservación de datos. La cuestión es si el servicio facilita las decisiones del equipo con un coste operativo aceptable.
Revisa los datos que envía realmente tu implementación. SpeedCurve documenta las categorías que recopila y admite datos personalizados. Inspecciona las URL, las etiquetas y los valores personalizados antes del despliegue para evitar enviar información no prevista. Coordina la recopilación con la configuración de privacidad y consentimiento del sitio, sin asumir que la descripción general del proveedor resuelve todas las cuestiones de cada implementación.
La instalación RUM también introduce una dependencia en la página. Comprueba que se carga según lo previsto, que no aparece duplicada mediante distintas integraciones y que permanece después de modificar las plantillas. Si la recopilación comienza solo tras obtener consentimiento, recuerda que las visitas observadas representan esa condición. Regístrala junto a los informes utilizados para comparar versiones.
SpeedCurve no puede reescribir una aplicación lenta, corregir una estrategia de carga de imágenes ni garantizar posiciones en buscadores. Sus datos no tienen por qué coincidir con Chrome User Experience Report de Google, porque las poblaciones y los métodos de elaboración de informes difieren. Investiga esas diferencias sin asumir que una fuente está fallando.
Haz una prueba piloto que termine en una decisión
Elige una plantilla importante, una prueba sintética representativa y un grupo RUM claramente etiquetado. Establece una referencia inicial, investiga un problema concreto y registra si las evidencias permitieron realizar un cambio útil. Utiliza la lista de comprobación del rendimiento web para mantener visibles las verificaciones técnicas y el seguimiento.
Al terminar, evalúa el proceso además de las gráficas. ¿Puede el equipo identificar a quién afecta el problema, reproducir una causa plausible y comprobar qué ocurrió después del cambio? Si la respuesta sigue sin estar clara, mejora la agrupación o el proceso de investigación antes de ampliar la recopilación a todo el sitio.
Contenido de socios. Este artículo trata sobre SpeedCurve y se publica por separado de la cobertura editorial de WebVitalsDev.
