GitLab CI: Performance-Tests mit sitespeed.io

Posted on by Hilko Holweg

Im letzten Beitrag ging es darum Regressionstests mit Lighthouse in GitLab einzurichten. Wer etwas mehr technische Details benötigt, woran es bei der Performance hakt, kann Performance-Tests mit sitespeed.io durchführen. GitLab bietet eine fertige Integration für alle mit „Premium“-GitLab an, aber man kann das Feature auch in der kostenlosen Version brauchbar nutzen.

Templates nutzen

Wie bereits erwähnt ist sitespeed.io in GitLab mitgedacht, daher gibt es auch ein Template, das man mit ein paar Anpassungen nutzen kann.

include:
  - template: "Jobs/Browser-Performance-Testing.gitlab-ci.yml"

Dieses kleine Snippet in der .gitlab-ci.yml reicht bereits um das Template generell zu nutzen.

Template anpassen

Folgende Anpassungen habe ich vorgenommen in meiner .gitlab-ci.yml um das Template zu benutzen:

browser_performance:
  needs: ["deploy_staging"]
  variables:
    URL: .performance_test_urls.txt
    SITESPEED_VERSION: "19.4.2"
    SITESPEED_OPTIONS: "--config sitespeed-config.json"
  artifacts:
    when: always
    expose_as: 'Sitespeed Reports'
    paths: ['sitespeed-results/']
    reports:
      browser_performance: browser-performance.json
      junit: sitespeed-results/junit.xml
  before_script:
    - echo $URL > environment_url.txt
  rules:
    - when: always

Wie bereits im letzten Posting geschrieben: Die Angabe von needs: ["deploy_staging"] ist natürlich nicht zwingend notwendig. Es steht hier nur um zu verdeutlichen, dass der geänderte Code irgendwo abrufbar sein muss, damit sitespeed.io ihn testen kann.

Ein paar Anmerkungen zur Konfiguration oben. Unter variables wird die Text-Datei angegeben in der die zu testenden URLs stehen (eine pro Zeile). Mit den zwei Umgebungsvariablen kann die Version von Sitespeed überschrieben werden (im Template ist noch eine 14er Version hinterlegt) und mit Options können wir auf eine JSON-Datei verweisen in der wir bequem die Sitespeed-Konfiguration hinterlegen können.

Bei den Artefakten ist der Abschnitt der reports erwähnenswert. Standardmäßig bekommt man einen Sitespeed-Report sonst nämlich nur als Artefakt angezeigt. Den kann man sich herunterladen oder bei eingerichteten GitLab Pages direkt im Browser ansehen. Mit dem junit-Report (junit: sitespeed-results/junit.xml) werden allerdings im Merge Requests direkt im Bereich der Tests die Ergebnisse des hinterlegten Sitespeed-Budgets angezeigt. Dazu kommen wir gleich. (Das Sitespeed-Budget ist leider nur ähnlich zum Lighthouse-Budget, aber nicht identisch)

Unter before_script mag einem das Vorgehen etwas komisch erscheinen. Das Template erwartet die URLs in einer environment_url.txt, die wollte ich aber in meinem Code so nicht herum liegen haben, weil sie vom Namen keine Beziehung zum verwendeten Zweck hat, weshalb ich hier diesen etwas komischen Umweg mache und über diesen Mechanismus die .performance_test_urls.txt in die environment_url.txt kopiere.

Detaillierte Testergebnisse

Neben der oben dargestellten Übersicht der Ergebnisse durch die junit-Ergebnisdatei kann man auch die Testdetails in der Pipeline sehen.

Sitespeed.io-Konfiguration

Wie oben bereits erwähnt kann die Konfiguration in einer JSON-Datei hinterlegt werden. Diese sieht beispielsweise so aus:

{
  "browsertime": {
    "cpu": true
  },
  "budget": {
    "configPath": "/sitespeed.io/sitespeedio-budgets.json",
    "output": "junit"
  },
  "mobile": true,
}

Hier ist nur beispielhaft mobile und browsertime gesetzt, Sitespeed.io hat insgesamt eine Fülle an Konfigurationsoptionen. Interessant für uns ist gerade der budget-Abschnitt. Das Template mappt das aktuelle Arbeitsverzeichnis in den Sitespeed-Container nach /sitespeed.io, weshalb die JSON-Datei im Container den oben angegebenen configPath hat. Damit man später die junit-Datei hat, die GitLab interpretieren und dann in Merge Request und der Pipeline präsentieren kann, muss hier noch "output": "junit" angegeben werden.

Das Sitespeed-Budget

Das oben angegebenen Sitespeed-Budget ist eine JSON-Datei mit diversen frei definierbaren Schwellwerten. Zum Beispiel kann diese so aussehen:

{
  "budget": {
    "timings": {
      "firstPaint": 1000,
      "pageLoadTime": 2000,
      "fullyLoaded": 2000,
      "FirstVisualChange": 1000,
      "LastVisualChange": 1200,
      "SpeedIndex": 1200,
      "PerceptualSpeedIndex":1200,
      "VisualReadiness": 200,
      "VisualComplete95": 1190
    },
    "requests": {
      "total": 89,
      "html": 1,
      "javascript": 0,
      "css": 1,
      "image": 50,
      "font": 0,
      "httpErrors" : 0
    },
    "transferSize": {
      "total": 400000,
      "html": 20000,
      "javascript": 0,
      "css": 10000,
      "image": 200000,
      "font": 0
    },
    "thirdParty": {
      "transferSize": 0,
      "requests": 0
    },
    "score": {
      "bestpractice": 80,
      "privacy": 70,
      "performance": 90
    },
  }
}

Auch hier kann wieder sehr viel eingestellt werden, die Doku bei sitespeed.io gibt im Detail Auskunft. Core Web Vitals (bzw. deren Entsprechung für Synthetic Tests, also TBT statt FID) können im Budget angegeben werden. Wird für den Testlauf ein Chrome-Browser verwendet, werden diese Metriken automatisch mit gesammelt und können so mit dem Budget verglichen werden.

Was bieten die Sitespeed-Reports?

Sitespeed – besonders im Vergleich zu Lighthouse – bietet sehr viel mehr technische Details. Man bekommt in einem Report eine kleine Website, die einen allgemeinen Überblick über den Testlauf gibt, dann aber auch aufschlüsselt nach URLs, wo es wieder über mehrere Testläufe technische Details auszuwerten gibt. Das oben erwähnte Performance-Budget hat ebenfalls eine eigene Seite, auf der man schauen kann auf welcher Seite welche Metrik wie im Verhältnis zum Performance-Budget war.

Detaillierte technische Details eines Sitespeed-Reports

Darüber hinaus gibt es automatisch erstellte Filmstrips, Videos vom Seitenaufbau und HAR-Files, die man in den Chrome-Dev-Tools importieren kann für detailliertere Analysen. Des Weiteren gibt der „Coach“ Hilfestellungen, wo noch etwas im Argen liegt.

Um Performance-Problemen auf die Schliche zu kommen und nicht nur die Änderung einer Metrik zu bemerken, empfiehlt sich Sitespeed.io absolut. Gerade in der Entwicklung, spätestens in einem Merge Request, kann man so frühzeitig über Performance-Probleme informiert werden und dank der technischen Details auch die Ursache des Problems eingrenzen.
Das Tool ist Open Source, völlig kostenlos und bietet über die hier gezeigten Möglichkeiten noch einiges mehr. Beispielsweise gibt es spezielle Analysen für 3rd-Parties, ein Plugin für Accessibility-Tests mit Axe, die Möglichkeit Metriken in Graphite zu speichern oder eigene Scripts für Selenium zu schreiben, die vor/nach einem Test durchgeführt werden (für Logins, Consent-Banner, etc.).