CI-Build-Gating & Deploy-Markierungen

Sie können einen Page-Speed-Monitor aus Ihrer CI-Pipeline starten und den Build fehlschlagen lassen, wenn die Seite ein Budget verletzt. So wird ein langsames Release gestoppt, bevor es Ihre Besucher erreicht. Derselbe Schritt kann das Deployment in den Verlaufsdiagrammen des Monitors markieren, damit eine Verlangsamung neben dem Release steht, das sie verursacht hat.

Alles läuft über ein kleines Skript unter https://speed.loadfocus.com/ci.js. Es braucht Node 14 oder neuer und hat keine Abhängigkeiten, funktioniert also in GitHub Actions und in jeder anderen CI, die Node ausführt.

Bevor Sie beginnen

• Ein Monitor für die Seite. Das Skript startet einen Monitor, den Sie bereits haben, siehe Erste Schritte.
• Die Monitor-ID. Öffnen Sie ein Ergebnis des Monitors und scrollen Sie unter den Verlaufsdiagrammen zu CI und Deploy-Markierungen. Der Schritt unter Build fehlschlagen lassen, wenn diese Seite langsamer wird enthält die ID bereits, und Kopieren legt ihn in die Zwischenablage. Die ID ist auch der Teil nach /speedtests/ in der Adresse der Ergebnisseite.
• Ein API-Schlüssel. Erstellen Sie einen auf der Seite API Keys und speichern Sie ihn als CI-Secret mit dem Namen LOADFOCUS_API_KEY. Wenn Sie in mehreren Teams arbeiten, setzen Sie zusätzlich LOADFOCUS_TEAM_ID; ohne diese Variable wird Ihr Standard-Team verwendet.

Jeder CI-Lauf startet einen echten Lauf des Monitors und zählt daher als ein Testlauf Ihres Plans.

Beispiel für GitHub Actions

Legen Sie Ihren API-Schlüssel als Repository-Secret an (Settings > Secrets and variables > Actions > LOADFOCUS_API_KEY) und erstellen Sie dann .github/workflows/page-speed.yml:

name: Page speed budget

on:
  push:
    branches: [ main ]

jobs:
  page-speed:
    runs-on: ubuntu-latest
    steps:
      - name: Page speed budget
        run: curl -fsSL https://speed.loadfocus.com/ci.js | node - --monitor YOUR_MONITOR_ID --marker "${{ github.sha }}" --budget "lcp<=2.5"
        env:
          LOADFOCUS_API_KEY: ${{ secrets.LOADFOCUS_API_KEY }}

Ersetzen Sie YOUR_MONITOR_ID durch Ihre Monitor-ID. Der Schritt setzt eine Deploy-Markierung mit dem Commit als Bezeichnung, startet den Monitor, wartet auf das Ergebnis und lässt den Job fehlschlagen, wenn ein Budget verletzt wird. Setzen Sie ihn hinter Ihren Deploy-Schritt, damit er das gerade veröffentlichte Release misst.

Um die Markierung mit der Commit-Seite zu verlinken, ergänzen Sie --marker-url "${{ github.server_url }}/${{ github.repository }}/commit/${{ github.sha }}". Wiederholen Sie --budget für weitere Grenzen, zum Beispiel --budget "lcp<=2.5" --budget "performance>=90".

Optionen

curl -fsSL https://speed.loadfocus.com/ci.js | node - --help gibt dieselbe Liste aus.

Welche Budgets geprüft werden

Jeder Lauf wird gegen zwei Gruppen von Grenzen geprüft:

• Die Schwellwert-Alerts des Monitors. Jeder aktivierte Alert mit über oder unter und einem Wert zählt als Budget: Ein Alert auf Largest Contentful Paint über 2.5 wird zum Budget "LCP höchstens 2.5 s". Das sind dieselben Budgets, die die Ergebnisseite zeigt, siehe Performance-Budgets. Alerts mit "verschlechtert sich um (%)" haben keine feste Grenze und werden nicht geprüft.
• Jedes --budget, das Sie übergeben. Ein Budget besteht aus einer Metrik, <= oder >= und einer Zahl. Sie können bis zu 30 übergeben.

Zeitmetriken werden in Sekunden angegeben, auch Total Blocking Time: tbt<=0.3 bedeutet 300 ms. Ein Budget, dessen Metrik im Lauf nicht gemessen wurde, schlägt fehl. Eine Seite, die nicht gemessen werden konnte, kommt also nie durch die Prüfung.

Exit-Codes und Ausgabe

Das Log zeigt pro Budget eine Zeile PASS oder FAIL mit dem gemessenen Wert, der Grenze und der Herkunft des Budgets (alert oder pipeline), danach einen Link zum vollständigen Bericht. Wenn keine Budgets gesetzt sind, meldet das Skript das und endet mit 0.

In GitHub Actions wird das Ergebnis zusätzlich in die Job-Zusammenfassung geschrieben: die vier Lighthouse-Scores, eine Tabelle aller Budgets und ein Link Full report.

Deploy-Markierungen

Eine Markierung ist eine gestrichelte Linie in den Verlaufsdiagrammen des Monitors, in der Reihe Deployments. Mit --marker setzt das Skript eine Markierung, bevor es den Lauf startet. Kann die Markierung nicht gesetzt werden, meldet das Skript das und fährt mit der Prüfung fort.

Um Deployments ohne Prüfung zu markieren, verwenden Sie den Befehl unter Oder nur Deployments markieren im selben Bereich:

curl -X POST "https://speed.loadfocus.com/api/test/applighthouse/annotations" \
  -H "loadfocus-auth: YOUR_API_KEY" -H "content-type: application/json" \
  -d '{"label":"Deployed v1.4.2","configId":"YOUR_MONITOR_ID"}'

• label ist Pflicht, bis zu 120 Zeichen.
• Lassen Sie configId weg, um jeden Monitor im Team zu markieren.
• Ergänzen Sie url, um das Release zu verlinken.
• Ergänzen Sie timestamp (ISO-Datum oder Epoch), um die Markierung um bis zu 30 Tage zurückzudatieren.

Letzte Markierungen im Bereich listet die Markierungen im angezeigten Zeitraum, die neueste zuerst. Markierungen ohne Monitor tragen den Hinweis alle Monitore, und Löschen entfernt eine Markierung. Erreicht ein Team 5.000 Markierungen, machen die ältesten Platz für neue.

Zwei Läufe vergleichen

Wenn ein Budget verletzt wurde, zeigt der Bereich Läufe vergleichen des Ergebnisses, was sich geändert hat. Wählen Sie unter Vergleichen mit einen anderen Lauf desselben Monitors, und LoadFocus stellt nebeneinander dar, mit einer Spalte Änderung:

• Scores und Metriken
• Seitengewicht, insgesamt und pro Ressourcentyp, dazu die Anzahl der Anfragen
• Neue Anfragen, Größer gewordene Anfragen und Entfernte Anfragen
• Neue Probleme und Seitdem behoben, also die Audits, die neu fehlschlagen oder nicht mehr fehlschlagen

Hängen Sie die ID des anderen Laufs als Parameter compare an die Adresse des Ergebnisses an (zum Beispiel &compare=12345 nach der testrunid), dann öffnet sich die Seite mit diesem Lauf bereits ausgewählt. Das ist praktisch zum Teilen.

Verwandt

• Performance-Budgets
• Alert-Konfiguration
• Page-Speed-Experimente