Core/Dash CI/CD otomatik performans kontrolleri

Hangi dağıtım yavaşlattı?

İki ay önce LCP'n 2,1 saniyeydi. Şimdi 2,9 saniye. O zamandan beri kırk kez dağıtım yaptın. Ama sorun şu: Sadece zaman çizelgesine bakarak buna hangi dağıtımın sebep olduğunu bulamazsın.

Bu yüzden Core/Dash, her gerçek kullanıcı ziyaretini belirli bir dağıtımla eşleştirir. RUM verilerinin "geçen ay bir şeyler yavaşladı" yerine "bunu v2.4.1 yaptı" demesi gerektiğine inanıyoruz.

Core/Dash her dağıtım için iki kontrol çalıştırır. Dağıtım öncesinde, önizleme build'ini tarar ve bir sayfa bütçeyi aşarsa pipeline'ı işaretler. Dağıtım sonrasında, her sayfa görüntülemesi dağıtım sürümüyle etiketlenir. Böylece her sürüm kendi gerçek kullanıcı trafiğine göre ölçülür.

Bu iki kontrol, Core Web Vitals sorunlarını farklı zamanlarda yakalar. Dağıtım öncesi kontrol sentetiktir; build'in içindeki hataları görür: 4MB'lık PNG olan yeni hero görseli, bundle'a 300KB script ekleyen pazarlama etiketi gibi. Dağıtım sonrası kontroller ise saf RUM verisidir. Bir sürümün LCP'ye, INP'ye ve CLS'ye gerçekte ne yaptığını sana kesin olarak söyler.

1: Dağıtım öncesi: sentetik kontroller

Core/Dash, izlenen sayfanın bir örneğini tarayabilir. Sonuçlar kendi Core/Dash performans bütçelerinle karşılaştırılır. Bir sayfa sınırı aşarsa, dağıtım yapmadan önce bildirim alırsın. Bu bildirimle ne yapacağın sana kalmış.

Bu kontrolün doğruluğunu korumak için Core/Dash yalnızca aynı build'in iki çalıştırılması arasında değişmeyen şeyleri puanlar. Bir Lighthouse performans puanı, tamamen aynı sayfanın iki taraması arasında on puan oynayabilir. Çünkü CPU süreleri baskındır ve denetimi yapan makine hiçbir zaman birebir aynı durumda olmaz. Bunu CI'da puanlarsan hiçbir anlam ifade etmeyen kırmızı pipeline'lar elde edersin.

Kontrolü CI/CD pipeline'ına ekle

Önce bir proje API anahtarı oluştur (uygulamada: projen, ardından AI Insights, sonra Connect Your AI). Ardından bu adımı dağıtım görevinden önce ekle. Kontrol uç noktasını çağırır ve yaklaşık 30 ila 45 saniye sürer.

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

Varsayılan olarak bu sadece sonucu CI loglarına raporlar. Bir sayfa bütçeyi aştığında build'in hata vermesi için son satırı yorum olmaktan çıkar.

Veri şeması:

Git alanları uygulamadaki derin bağlantılar için saklanır, bunlar üzerinden hiçbir dallanma yapılmaz.

Ne döner

Geçerli bir istek her zaman HTTP 200 yanıtı verir. Sonuçlar veya karar, yanıttaki data.check.status yolundan okunabilir:

Not: Önizleme domain'i, sunucularımız tarafından açık internet üzerinden erişilebilir olmalıdır

2: Dağıtım sonrası: RUM doğrulaması

Dağıtım sonrası kontroller ve doğrulama, RUM verilerinin dağıtımınla eşleştirilmesiyle gerçekleşir. Verilerini dağıtımınla eşleştirebilmemiz için mevcut dağıtım sürümünü API'mize kolayca gönderebilirsin. 

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"}'

Veya GitHub Actions'da sürüm olarak git ref'ini kullanarak tamamen otomatik bir şekilde:

- 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 }}\"}"

Pipeline yoksa sorun da yok! CoreDash sürümler sayfasında bir Tag deployment formu bulunur. Bu manuel bir eylem gerektirdiğinden ve otomatikleştirilemediğinden, zorunlu yöntem bu değildir.

Core/Dash'te Dağıtımları Karşılaştırmak

Releases sayfası son 30 günü yeniden eskiye doğru listeler: Sürüm, CI'dan mı yoksa uygulamadan mı geldiği, dağıtım zamanı, Core Web Vitals başına p75, önceki sürüme göre değişim ve anlık bütçe durumu.

Sürüm detayı, iki yarının gerçekten buluştuğu yerdir. Dağıtım öncesi kontrol üstte yer alır (taranan her sayfa ve bütçe kriteri için bir satır) ve altında sürüm, aynı filtreler altında tüm siteye karşı ölçülür. Böylece build'in vaat ettiği şeyle kullanıcılarının gerçekte elde ettiği şeyi aynı ekranda görebilirsin.

Performans Snapshot'ları grafikler üzerinde dağıtım işaretçileri çizebilir, sadece yayınlanan sürümler için.

Ayrıca bakınız: Bu verileri bir script veya yapay zeka ajanıyla sorgulamak için Core/Dash API'si, bu kararların kullandığı bütçeler için uyarılar ve bildirimler ve tracker henüz sitende değilse kurulum.