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
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.