Automatyczne testy wydajności Core/Dash CI/CD

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

Dwa miesiące temu LCP wynosił 2,1 sekundy. Teraz to 2,9 sekundy. Od tamtej pory zrobiłeś czterdzieści wdrożeń. Ale jest problem: sama oś czasu nie powie ci, które wdrożenie to spowodowało.

Dlatego Core/Dash przypisuje każdą wizytę prawdziwego użytkownika do konkretnego wdrożenia. Uważamy, że dane RUM powinny mówić „wersja 2.4.1 to zrobiła”, a nie „coś zwolniło w zeszłym miesiącu”.

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

Te dwa testy wyłapują problemy z Core Web Vitals na różnych etapach. Test przed wdrożeniem jest syntetyczny. Widzi błędy w samym buildzie: nowy obraz hero jako 4MB PNG czy tag marketingowy dodający 300KB skryptu do paczki. Testy po wdrożeniu to czyste dane RUM. To daje pewność, jak wydanie faktycznie wpływa na LCP, INP oraz CLS.

1: Przed wdrożeniem: testy syntetyczne

Core/Dash potrafi 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. Co zrobisz z tym powiadomieniem, zależy od ciebie.

Aby test był wiarygodny, Core/Dash ocenia tylko elementy niezmienne między dwoma uruchomieniami tego samego buildu. Wynik wydajności Lighthouse może skakać o dziesięć punktów między dwoma skanami identycznej strony. Zależy on w dużej mierze od czasów CPU, a maszyna wykonująca audyt nigdy nie jest taka sama. Oceniaj to w CI, a dostaniesz czerwone pipeline'y, które nic nie znaczą.

Dodaj test do swojego pipeline'u 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 testowy i zajmuje około 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 werdykt trafia tylko do logów CI. Odkomentuj ostatnią linię, aby przerwać build, gdy strona przekracza budżet.

Schemat danych:

Pola Git służą tylko do linkowania w aplikacji. System nie opiera na nich żadnej logiki.

Zwracane dane

Prawidłowe żądanie zawsze zwraca kod HTTP 200. Wyniki lub werdykt odczytasz z odpowiedzi w data.check.status:

Uwaga: domena podglądu musi być dostępna z publicznego internetu dla naszych serwerów

2: Po wdrożeniu: walidacja RUM

Testy i walidacja po wdrożeniu polegają na przypisywaniu danych RUM do konkretnego wdrożenia. Żebyśmy mogli przypisać twoje dane do wdrożenia, po prostu wyślij aktualną wersję 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, używając referencji git jako wersji:

- name: Zgłoś wydanie do 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 }}\"}"

Nie masz pipeline'u? Żaden problem! Strona wydań CoreDash ma formularz Tag deployment. Wymaga on ręcznego działania i nie da się go zautomatyzować, dlatego nie jest to zalecana metoda.

Porównywanie wydań w Core/Dash

Strona wydań pokazuje ostatnie 30 dni, 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 i status budżetu na żywo.

Szczegóły wydania to miejsce, gdzie łączą się obie połówki. Test przed wdrożeniem znajduje się na górze, jeden wiersz na stronę i linię budżetu. Poniżej wydanie jest mierzone w skali całej witryny przy użyciu tych samych filtrów. Dzięki temu na jednym ekranie widzisz, co obiecywał build, a co faktycznie dostali użytkownicy.

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

Zobacz też: API Core/Dash do pobierania tych danych ze skryptu lub agenta AI, alerty i powiadomienia dla budżetów używanych przez te werdykty, oraz instalację, jeśli nie masz jeszcze skryptu na stronie.