Comprobaciones automáticas de rendimiento CI/CD de Core/Dash

¿Qué despliegue lo ralentizó?

Tu LCP era de 2,1 s hace dos meses. Ahora es de 2,9 s. Has desplegado cuarenta veces desde entonces. Pero este es el problema: la línea temporal por sí sola no te dirá qué despliegue lo causó.

Por eso Core/Dash asocia cada visita de cada usuario real a un despliegue específico. Creemos que los datos RUM deberían decirte "la v2.4.1 hizo esto" en lugar de "algo se volvió más lento el mes pasado".

Core/Dash ejecuta dos comprobaciones en cada despliegue. Antes del despliegue, Core/Dash escanea tu build de vista previa y marca el pipeline si una página supera el presupuesto. Después del despliegue, cada página vista se etiqueta con la versión del despliegue, de modo que cada versión se evalúa con su propio tráfico de usuarios reales.

Las dos comprobaciones detectan problemas de Core Web Vitals en momentos distintos. La comprobación previa al despliegue es sintética, por lo que ve los errores que residen en la propia build: la nueva imagen principal que es un PNG de 4 MB, o el tag de marketing que añadió 300 KB de script al bundle. Las comprobaciones posteriores al despliegue son datos RUM puros. Eso te dice con certeza lo que un lanzamiento le hace realmente al LCP, al INP y al CLS.

1: Pre-despliegue: comprobaciones sintéticas

Core/Dash puede escanear una muestra de tu página monitorizada. Los resultados se comparan con tus propios presupuestos de rendimiento en Core/Dash. Si una página se pasa, recibes un aviso antes de desplegar. Lo que hagas con ese aviso depende de ti.

Para mantener la fiabilidad de esa comprobación, Core/Dash solo puntúa lo que no cambia entre dos ejecuciones de la misma build. La puntuación de rendimiento de Lighthouse puede oscilar diez puntos entre dos ejecuciones exactas de la misma página, porque está dominada por los tiempos de CPU y la máquina que ejecuta la auditoría nunca es idéntica. Puntúa eso en CI y tendrás pipelines rojos que no significan nada.

Añade la comprobación a tu pipeline CI/CD

Primero crea una API key del proyecto (en la app: tu proyecto, luego AI Insights, y Connect Your AI). Después, añade este paso antes de tu tarea de despliegue. Llama al endpoint de comprobación y tarda entre 30 y 45 segundos.

STATUS=$(curl -sS -o gate.json -w '%{http_code}' -X POST "https://app.coredash.app/api/project/releases/check" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3","origin":"https://preview.example.app"}')

if [ "$STATUS" != "200" ]; then
  echo "CoreDash check failed to run (HTTP $STATUS): $(cat gate.json)" >&2
  exit 0
fi

VERDICT=$(jq -r '.data.check.status' gate.json)
echo "CoreDash: $VERDICT"

# if [ "$VERDICT" = "breach" ]; then exit 1; fi   ## uncomment to block the deploy

Por defecto, esto solo reporta el veredicto en tus logs de CI. Descomenta la última línea para hacer que la build falle cuando una página supere el presupuesto.

Esquema de datos:

Los campos de Git se almacenan para los deep links en la aplicación y nada se ramifica en función de ellos.

Qué recibes

Una petición válida siempre responde con HTTP 200. Los resultados o el veredicto se pueden leer del resultado en data.check.status:

Nota: Nuestros servidores deben poder acceder al dominio de vista previa desde la internet pública

2: Post-despliegue: validación RUM

Las comprobaciones y la validación posteriores al despliegue se realizan asociando los datos RUM con tu despliegue. Para que podamos asociar tus datos a tu despliegue, puedes enviar fácilmente la versión del despliegue actual a nuestra API. 

curl -sS -X POST "https://app.coredash.app/api/project/releases/ingest" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3"}'

O de forma totalmente automatizada en GitHub Actions, con la referencia de Git como versión:

- name: Report release to CoreDash
  if: success()
  env:
    COREDASH_API_KEY: ${{ secrets.COREDASH_API_KEY }}
  run: |
    curl -sS -f -X POST "https://app.coredash.app/api/project/releases/ingest" \
      -H "Authorization: Bearer ${COREDASH_API_KEY}" \
      -H "Content-Type: application/json" \
      -d "{\"tag\":\"${{ github.ref_name }}\"}"

¡Sin pipeline, no hay problema! La página de lanzamientos de CoreDash tiene un formulario de Etiquetar despliegue. Al requerir una acción manual y no poder automatizarse, este no es el método recomendado.

Comparar lanzamientos en Core/Dash

La página de lanzamientos enumera los últimos 30 días, los más recientes primero: la versión, si provino de CI o de la app, la hora de despliegue, el p75 por cada Core Web Vital, el delta frente al lanzamiento anterior, y el estado en vivo del presupuesto.

El detalle del lanzamiento es donde las dos mitades convergen. La comprobación previa al despliegue está arriba, con una fila por página escaneada y línea de presupuesto. Debajo, el lanzamiento se mide frente a todo el sitio con los mismos filtros, para que puedas ver en la misma pantalla lo que afirmaba la build y lo que tus usuarios obtuvieron realmente.

Performance Snapshots puede dibujar marcadores de despliegue en los gráficos, solo para las versiones lanzadas.

Consulta también: la API de Core/Dash para consultar estos datos desde un script o un agente de IA, las alertas y notificaciones sobre los presupuestos que usan estos veredictos, y la instalación si el tracker aún no está en tu sitio.