Core/Dash CI/CD automatyczne testy wydajności

Które wdrożenie spowolniło stronę?

Dwa miesiące temu Twój LCP wynosił 2,1 sekundy. Teraz to 2,9 sekundy. Od tego czasu masz za sobą czterdzieści wdrożeń. Sama oś czasu nie wskaże, które wdrożenie to spowodowało.

Dlatego Core/Dash dopasowuje każdą wizytę prawdziwego użytkownika do konkretnego wdrożenia. Dane RUM powinny komunikować „zrobiła to wersja v2.4.1” zamiast „coś spowolniło w zeszłym miesiącu”.

Core/Dash uruchamia dwa testy przy każdym wdrożeniu. Przed wdrożeniem skanuje build podglądowy i oznacza potok, jeśli strona przekracza budżet. Po wdrożeniu każda odsłona otrzymuje tag z wersją. Dzięki temu każda wersja jest mierzona na własnym ruchu prawdziwych użytkowników.

Oba testy wyłapują problemy z Core Web Vitals na różnych etapach. Test przed wdrożeniem jest syntetyczny. Widzi błędy zaszyte w samym buildzie: nowy główny obraz będący plikiem PNG o wadze 4MB, tag marketingowy, który dodał 300KB skryptu do paczki. Testy po wdrożeniu to czyste dane RUM. Dają pewność, co dane wdrożenie faktycznie robi z LCP, INP i CLS.

1: Przed wdrożeniem: testy syntetyczne

Core/Dash może przeskanować próbkę monitorowanej strony. Wyniki są porównywane z twoimi budżetami wydajności w Core/Dash. Jeśli strona je przekracza, dostajesz powiadomienie przed wdrożeniem. Ty decydujesz, co z nim zrobisz.

Aby zachować rzetelność, Core/Dash ocenia tylko to, co nie zmienia się między dwoma uruchomieniami tego samego buildu. Wynik wydajności Lighthouse potrafi skakać o dziesięć punktów między dwoma testami dokładnie tej samej strony. Dzieje się tak, bo zależy od czasów procesora, a maszyna uruchamiająca audyt nigdy nie jest taka sama. Sprawdzaj to w CI, a otrzymasz czerwone potoki, które nic nie znaczą.

Dodaj test do potoku CI/CD

Najpierw utwórz klucz API projektu (w aplikacji: twój projekt, potem AI Insights, następnie Connect Your AI). Dodaj ten krok przed zadaniem wdrożenia. Wywołuje on endpoint testujący i zajmuje od 30 do 45 sekund.

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   ## odkomentuj, aby zablokować wdrożenie

Domyślnie raportuje to werdykt tylko do logów CI. Odkomentuj ostatnią linię, aby przerwać build, gdy strona przekracza budżet.

Schemat danych:

Pola Git służą do tworzenia linków w aplikacji. Żadna logika się na nich nie opiera.

Co wraca

Poprawne żądanie zawsze zwraca HTTP 200. Wyniki lub werdykt odczytasz z data.check.status:

Uwaga: Domena podglądowa musi być osiągalna dla naszych serwerów z publicznego internetu

2: Po wdrożeniu: walidacja RUM

Testy po wdrożeniu i walidacja polegają na dopasowaniu danych RUM do twojego wdrożenia. Abyśmy mogli powiązać dane z wdrożeniem, wyślij aktualną wersję wdrożenia do naszego 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"}'

Albo w pełni automatycznie w GitHub Actions, przekazując Git ref jako wersję:

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

Brak potoku? Żaden problem! Strona wydań CoreDash zawiera formularz Tag deployment. Wymaga on ręcznego działania. Nie można go zautomatyzować, dlatego nie jest to wymagana metoda.

Porównywanie wdrożeń w Core/Dash

Strona wydań wyświetla ostatnie 30 dni, zaczynając od najnowszych: wersję, źródło (CI czy aplikacja), czas wdrożenia, p75 dla każdego wskaźnika Core Web Vitals, różnicę względem poprzedniego wydania oraz status budżetu na żywo.

Szczegóły wdrożenia to miejsce, gdzie te dwie połówki się spotykają. Test przed wdrożeniem znajduje się na górze, po jednym wierszu na skanowaną stronę i linię budżetu. Poniżej wdrożenie jest oceniane na tle całej witryny przy użyciu tych samych filtrów. Na jednym ekranie widzisz założenia buildu i to, co faktycznie otrzymali użytkownicy.

Performance Snapshots potrafią rysować znaczniki wdrożeń na wykresach, wyłącznie dla wersji wydanych.

Zobacz też: API Core/Dash do odpytywania tych danych ze skryptu lub agenta AI, alerty i powiadomienia dotyczące budżetów używanych przez werdykty oraz instalację, jeśli skryptu śledzącego nie ma jeszcze na twojej stronie.