Uruchamianie Lighthouse na Gitlabie

Inne narzędzia

Loading

Uruchamianie Lighthouse na Gitlabie to kolejny wpis w którym chcemy Wam pokazać możliwości narzędzia i jego wykorzystania w codziennej pracy. Jest to kolejny z wpisów w którym przedstawiamy Wam możliwość integracji kolejnego narzędzia z Gitlabem. 

 

Czym jest Google Lighthouse

Google Lighthouse to narzędzie do audytu jakości i optymalizacji stron internetowych, oferowane przez Google. Narzędzie pozwala na analizę wydajności, użyteczności, dostępności oraz zgodności z najlepszymi praktykami SEO. Wyniki audytu są przedstawione w formie raportu, który zawiera sugestie dotyczące poprawy strony. Lighthouse jest dostępny jako rozszerzenie przeglądarki Chrome lub jako narzędzie linii poleceń.

 

Tworzenie gitlab-ci.yml

Chcąc uruchamiać testy z poziomu gitlaba nasze testy będą opierać się o stworzenie pliku gitlab-ci.yml, który będzie naszym centrum dowodzenia i zarządzania. Do uruchomienia naszych testów konieczne będzie:

  • runner na gitlabie, na podstawie którego testy będą uruchamiane (pytaj Devopsów o tag)
  • obraz dockerowy Lighthouse – my skorzystam z obrazu dockerowego Cypressa 
I. Najprostsza wersja

W naszym projekcie testowym tworzymy plik gitlab-ci.yml a następnie uzupełniamy go w najprostszy sposób:

lighthouse:
stage: test
image: cypress/browsers:node16.16.0-chrome107-ff107-edge
tags:
- nazwa-runnera
script:
- *some-script
- lighthouse https://www.google.com/ --output-path ./reportMobile.html
artifacts:
paths:
- ./reportMobile.html
expire_in: 1 week
 
1. Pierwszy element to nazwa testu
2. nazwa naszego runnera na którym uruchamiamy testy (zapytaj devopsów o tag, jeżeli nie korzystałeś)
3. image – nazwy dockerowych obrazów z których skorzystamy
4. skrypt – polecenie którym uruchamiamy testy (sprawdzenie wersji oraz polecenie do uruchomienia)
 
 
II. Tworzenie stage

W ramach naszych testów może zachodzić konieczność tworzenia faz egzekucji testów. 

stages:
- test
- test2
 
III. Raporty i artefakty

Jeżeli chcesz możesz generować i potem zapisywać swój raport. Dzięki temu będziesz mógł analizować dokładniej wyniki, lub przedstawiać je innym w formie graficznej. 

artifacts:
      when: always
      paths:
          - reportMobile.html
  expire_in: 10 days

Ważne jest abyście w skrypcie podanym w pierwszej linii podawali też rozszerzenie by otrzymać raporty. 

Schedules

Jeżeli chcemy tak przygotowane testy w ramach naszego repozytorium, możemy uruchamiać cyklicznie. Z pomocą przychodzi nam Gitlab i zakładka CI/CD – Schedules:

Rozwiązanie to jest korzystne, gdyż dzięki niemu możemy wykorzystywać możliwości narzędzia bez naszego ręcznego uruchamiania.  

Rozbudowany test ze zmiennymi

Przykłab bardziej rozbudowanego schematu

.job_template: &job_configuration  
  image: cypress/browsers:node16.16.0-chrome107-ff107-edge
  tags:
    - nazwa-runnera
  retry:
    max: 2
    when:
      - always
      
# image: edicom/lighthouse:latest

.some-script: &some-script
    - npm install -g lighthouse
    - export CHROME_PATH="/usr/bin/google-chrome"
    - npm install @sitespeed.io/throttle -g

stages:
  - test

variables:
  URL1: https://www.dlatesterow.pl/
  URL2: https://www.google.com/
  report1: reportDesktop.html
  report2: reportMobile.html


lighthouse:
  stage: test
  <<: *job_configuration  
  script:
    - *some-script
    - lighthouse $URL2 --throttling-method=provided --chrome-flags="--headless --no-sandbox" --disable-dev-shm-usage Chromium --disable-device-emulation --output html --screenEmulation.width=1920 --screenEmulation.height=1080 --output-path ./$report1 
  artifacts:
    paths:
     - ./$report1  
    expire_in: 1 week


lighthouse2:
  stage: test
  <<: *job_configuration  
  when: delayed
  start_in: 90 seconds
  script:
    - *some-script
    - lighthouse $URL2 --chrome-flags="--headless --no-sandbox" --disable-dev-shm-usage Chromium --disable-device-emulation --output html --output-path ./$report2   
  artifacts:
    paths:
     - ./$report2     
    expire_in: 1 week

Command line do wykorzystania:

$ lighthouse --help

lighthouse <url> <options>

Logging:
  --verbose  Displays verbose logging  [boolean] [default: false]
  --quiet    Displays no progress, debug logs, or errors  [boolean] [default: false]

Configuration:
  --save-assets                  Save the trace contents & devtools logs to disk  [boolean] [default: false]
  --list-all-audits              Prints a list of all available audits and exits  [boolean] [default: false]
  --list-trace-categories        Prints a list of all required trace categories and exits  [boolean] [default: false]
  --additional-trace-categories  Additional categories to capture with the trace (comma-delimited).  [string]
  --config-path                  The path to the config JSON.
                                 An example config file: core/config/lr-desktop-config.js  [string]
  --preset                       Use a built-in configuration.
                                 WARNING: If the --config-path flag is provided, this preset will be ignored.  [string] [choices: "perf", "experimental", "desktop"]
  --chrome-flags                 Custom flags to pass to Chrome (space-delimited). For a full list of flags, see https://bit.ly/chrome-flags
                                 Additionally, use the CHROME_PATH environment variable to use a specific Chrome binary. Requires Chromium version 66.0 or later. If omitted, any detected Chrome Canary or Chrome stable will be used.  [string] [default: ""]
  --port                         The port to use for the debugging protocol. Use 0 for a random port  [number] [default: 0]
  --hostname                     The hostname to use for the debugging protocol.  [string] [default: "localhost"]
  --form-factor                  Determines how performance metrics are scored and if mobile-only audits are skipped. For desktop, --preset=desktop instead.  [string] [choices: "mobile", "desktop"]
  --screenEmulation              Sets screen emulation parameters. See also --preset. Use --screenEmulation.disabled to disable. Otherwise set these 4 parameters individually: --screenEmulation.mobile --screenEmulation.width=360 --screenEmulation.height=640 --screenEmulation.deviceScaleFactor=2
  --emulatedUserAgent            Sets useragent emulation  [string]
  --max-wait-for-load            The timeout (in milliseconds) to wait before the page is considered done loading and the run should continue. WARNING: Very high values can lead to large traces and instability  [number]
  --enable-error-reporting       Enables error reporting, overriding any saved preference. --no-enable-error-reporting will do the opposite. More: https://github.com/GoogleChrome/lighthouse/blob/main/docs/error-reporting.md  [boolean]
  --gather-mode, -G              Collect artifacts from a connected browser and save to disk. (Artifacts folder path may optionally be provided). If audit-mode is not also enabled, the run will quit early.
  --audit-mode, -A               Process saved artifacts from disk. (Artifacts folder path may be provided, otherwise defaults to ./latest-run/)
  --only-audits                  Only run the specified audits  [array]
  --only-categories              Only run the specified categories. Available categories: accessibility, best-practices, performance, pwa, seo  [array]
  --skip-audits                  Run everything except these audits  [array]
  --budget-path                  The path to the budget.json file for LightWallet.  [string]

Output:
  --output       Reporter for the results, supports multiple values. choices: "json", "html", "csv"  [array] [default: ["html"]]
  --output-path  The file path to output the results. Use 'stdout' to write to stdout.
                   If using JSON output, default is stdout.
                   If using HTML or CSV output, default is a file in the working directory with a name based on the test URL and date.
                   If using multiple outputs, --output-path is appended with the standard extension for each output type. "reports/my-run" -> "reports/my-run.report.html", "reports/my-run.report.json", etc.
                   Example: --output-path=./lighthouse-results.html  [string]
  --view         Open HTML report in your browser  [boolean] [default: false]

Options:
  --version                            Show version number  [boolean]
  --help                               Show help  [boolean]
  --cli-flags-path                     The path to a JSON file that contains the desired CLI flags to apply. Flags specified at the command line will still override the file-based ones.
  --locale                             The locale/language the report should be formatted in
  --blocked-url-patterns               Block any network requests to the specified URL patterns  [array]
  --disable-storage-reset              Disable clearing the browser cache and other storage APIs before a run  [boolean]
  --throttling-method                  Controls throttling method  [string] [choices: "devtools", "provided", "simulate"]
  --throttling
  --throttling.rttMs                   Controls simulated network RTT (TCP layer)
  --throttling.throughputKbps          Controls simulated network download throughput
  --throttling.requestLatencyMs        Controls emulated network RTT (HTTP layer)
  --throttling.downloadThroughputKbps  Controls emulated network download throughput
  --throttling.uploadThroughputKbps    Controls emulated network upload throughput
  --throttling.cpuSlowdownMultiplier   Controls simulated + emulated CPU throttling
  --extra-headers                      Set extra HTTP Headers to pass with request
  --precomputed-lantern-data-path      Path to the file where lantern simulation data should be read from, overwriting the lantern observed estimates for RTT and server latency.  [string]
  --lantern-data-output-path           Path to the file where lantern simulation data should be written to, can be used in a future run with the `precomputed-lantern-data-path` flag.  [string]
  --plugins                            Run the specified plugins  [array]
  --channel  [string] [default: "cli"]
  --chrome-ignore-default-flags  [boolean] [default: false]

Examples:
  lighthouse <url> --view                                                                          Opens the HTML report in a browser after the run completes
  lighthouse <url> --config-path=./myconfig.js                                                     Runs Lighthouse with your own configuration: custom audits, report generation, etc.
  lighthouse <url> --output=json --output-path=./report.json --save-assets                         Save trace, screenshots, and named JSON report.
  lighthouse <url> --screenEmulation.disabled --throttling-method=provided --no-emulatedUserAgent  Disable device emulation and all throttling
  lighthouse <url> --chrome-flags="--window-size=412,660"                                          Launch Chrome with a specific window size
  lighthouse <url> --quiet --chrome-flags="--headless"                                             Launch Headless Chrome, turn off logging
  lighthouse <url> --extra-headers "{\"Cookie\":\"monster=blue\", \"x-men\":\"wolverine\"}"        Stringify'd JSON HTTP Header key/value pairs to send in requests
  lighthouse <url> --extra-headers=./path/to/file.json                                             Path to JSON file of HTTP Header key/value pairs to send in requests
  lighthouse <url> --only-categories=performance,pwa                                               Only run the specified categories. Available categories: accessibility, best-practices, performance, pwa, seo

Pełna informacja znajduje się tutaj

Podsumowanie

Uruchamianie Lighthousa na Gitlabie to kolejny wpis w ramach którego prezentujemy Wam możliwości integracji narzędzi z Gitlabem. Ponadto wpis ten tworzony jest w ramach szerzenia wiedzy z zakresu testów. Zapraszamy na inne wpisy związane z narzędziami