Core/Dash CI/CD verificações automáticas de performance

Qual deploy deixou mais lento?

Seu LCP era 2,1s há dois meses. É 2,9s agora. Você fez deploy quarenta vezes desde então. Mas aqui está o problema: a linha do tempo sozinha não diz qual deploy causou isso.

Por isso o Core/Dash vincula cada visita de cada usuário real a um deploy específico. Acreditamos que dados RUM devem dizer "a v2.4.1 fez isso" em vez de "algo ficou mais lento no mês passado."

O Core/Dash executa duas verificações em cada deploy. Antes do deploy, o Core/Dash faz uma varredura no seu build de preview e sinaliza o pipeline se uma página estourar o orçamento. Após o deploy, cada pageview recebe a tag da versão do deploy. Assim, cada versão é medida contra seu próprio tráfego de usuários reais.

As duas verificações pegam problemas de Core Web Vitals em momentos diferentes. A verificação pré-deploy é sintética. Ela vê erros que residem no próprio build: a nova imagem de hero que é um PNG de 4MB, a tag de marketing que adicionou 300KB de script ao bundle. As verificações pós-deploy são puros dados RUM. Isso diz com certeza o que um release realmente faz com o LCP, o INP e o CLS.

1: Pré-deploy: verificações sintéticas

O Core/Dash pode varrer uma amostra da sua página monitorada. Os resultados são comparados com seus orçamentos de performance no Core/Dash. Se uma página estourar, você é notificado antes do deploy. O que você faz com essa notificação é com você.

Para manter essa verificação honesta, o Core/Dash pontua apenas coisas que não mudam entre duas execuções do mesmo build. A pontuação de performance do Lighthouse pode variar dez pontos entre duas execuções da exata mesma página. Isso ocorre porque ela é dominada por tempos de CPU, e a máquina que executa a auditoria nunca é a mesma duas vezes. Pontue isso no CI e você terá pipelines vermelhos que não significam nada.

Adicione a verificação no seu pipeline CI/CD

Crie uma chave de API de projeto primeiro (no aplicativo: seu projeto, depois AI Insights, depois Connect Your AI). Então, adicione este passo antes do seu job de deploy. Ele chama o endpoint de verificação e leva cerca de 30 a 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 "A verificação do CoreDash falhou ao executar (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   ## descomente para bloquear o deploy

Por padrão, isso apenas reporta o veredito nos seus logs de CI. Descomente a última linha para falhar o build quando uma página estourar o orçamento.

Esquema de dados:

Os campos do git são armazenados para deep links no aplicativo. Nenhuma lógica depende deles.

O que retorna

Uma requisição válida sempre responde HTTP 200. Os resultados ou o veredito podem ser lidos no resultado em data.check.status:

Nota: O domínio de preview precisa ser acessível pela internet pública através dos nossos servidores

2: Pós-deploy: validação RUM

Verificações e validações pós-deploy ocorrem vinculando os dados RUM ao seu deploy. Para conseguirmos vincular seus dados ao seu deploy, você pode enviar a versão atual do deploy para a nossa 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"}'

Ou de forma totalmente automatizada no GitHub Actions, com o ref do git como versão:

- name: Reportar release ao 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 }}\"}"

Sem pipeline, sem problema! A página de releases do CoreDash tem um formulário de Tag deployment. Como isso exige uma ação manual e não pode ser automatizado, este não é o método obrigatório.

Comparando Releases no Core/Dash

A página de Releases lista os últimos 30 dias, do mais recente para o mais antigo: versão, se veio do CI ou do app, horário do deploy, p75 por Core Web Vital, o delta em relação ao release anterior, e o status em tempo real do orçamento.

Detalhe do release é onde as duas metades realmente se encontram. A verificação pré-deploy fica no topo, uma linha por página varrida por linha de orçamento. Abaixo, o release é medido contra o site inteiro sob os mesmos filtros. Assim, você vê na mesma tela o que o build prometeu e o que seus usuários realmente receberam.

Performance Snapshots podem desenhar marcadores de deploy nos gráficos, apenas de versões lançadas.

Veja também: a API do Core/Dash para consultar esses dados de um script ou agente de IA, alertas e notificações para os orçamentos que esses vereditos usam, e instalação se o tracker ainda não estiver no seu site.