Wprowadzenie do programowego uruchamiania latarni morskiej

Opublikowany: 2022-03-10

Krótkie podsumowanie ↬ Możliwość programowego uruchomienia pakietu analitycznego Lighthouse firmy Google zapewnia wiele korzyści, zwłaszcza w przypadku większych lub bardziej złożonych aplikacji internetowych. Programowe użycie Lighthouse pozwala inżynierom skonfigurować monitorowanie jakości dla witryn, które wymagają większej personalizacji niż pozwalają na to proste aplikacje Lighthouse (takie jak Lighthouse CI). Ten artykuł zawiera krótkie wprowadzenie do Lighthouse, omawia zalety uruchamiania go programowo i przedstawia podstawową konfigurację.

Lighthouse to pakiet narzędzi Google do analizy jakości stron internetowych. Pozwala ocenić wydajność witryny, dostępność, SEO i nie tylko. Jest również wysoce konfigurowalny, dzięki czemu jest wystarczająco elastyczny, aby był użyteczny we wszystkich witrynach, od najprostszych do bardzo złożonych. Ta elastyczność obejmuje kilka różnych sposobów przeprowadzania testów, co pozwala wybrać metodę, która najlepiej pasuje do Twojej witryny lub aplikacji.

Jednym z najprostszych sposobów uruchamiania Lighthouse jest panel DevTools Lighthouse w przeglądarce Chrome. Jeśli otworzysz witrynę w Chrome, a następnie otworzysz DevTools Chrome, powinna pojawić się karta „Latarnia morska”. Stamtąd, jeśli klikniesz „Generuj raport”, powinieneś otrzymać pełny raport z danymi dotyczącymi jakości Twojej witryny.

To, na czym skupiam się w tym artykule, znajduje się jednak na drugim końcu spektrum. Programowe uruchamianie Lighthouse z JavaScriptem umożliwia nam konfigurowanie niestandardowych przebiegów, wybieranie i wybieranie funkcji, które chcemy przetestować, zbieranie i analizowanie wyników oraz określanie opcji konfiguracyjnych unikalnych dla naszych witryn i aplikacji.

Na przykład, być może pracujesz w witrynie, do której można uzyskać dostęp za pośrednictwem wielu adresów URL — każdy z własnymi danymi i stylami, a może nawet znacznikami, które chcesz analizować. A może chcesz zebrać dane z każdego przebiegu testu i skompilować lub przeanalizować je na różne sposoby. Możliwość wyboru sposobu, w jaki chcesz przeprowadzić analizę Lighthouse w oparciu o to, co najlepiej sprawdza się w Twojej witrynie lub aplikacji, ułatwia monitorowanie jakości witryny i wskazywanie, gdzie występują problemy z Twoją witryną, zanim się nagromadzą lub spowodują zbyt wiele problemów dla Twojej witryny. użytkowników witryny.

Programowe uruchamianie Lighthouse nie jest najlepszym wyborem dla każdej witryny i zachęcam do zapoznania się z różnymi metodami opracowanymi przez zespół Lighthouse do korzystania z tego narzędzia. Jeśli jednak zdecydujesz się na programowe korzystanie z Lighthouse, poniższe informacje i samouczek powinny ułatwić Ci rozpoczęcie pracy.

Dostosowywanie opcji latarni morskiej

Zaletą programowego uruchamiania Lighthouse jest nie tylko możliwość skonfigurowania samej Lighthouse, ale raczej wszystkie rzeczy, które możesz chcieć lub musisz zrobić w związku z testami Lighthouse. Lighthouse ma świetną dokumentację na początek. Aby jak najlepiej wykorzystać programowe uruchomienie, istnieją dwa główne miejsca, w których będziesz musiał zagłębić się i dowiedzieć się więcej o tym, jak działa Lighthouse: konfigurowanie przebiegów testowych i raportowanie wyników testów.

Konfiguracja przebiegu testowego w latarni morskiej

Konfiguracja uruchomienia testowego Lighthouse jest jednym z tych zadań, które mogą być tak proste lub tak złożone, jak chcesz.

Podczas programowego uruchamiania Lighthouse istnieją trzy miejsca, w których możesz podać niestandardowe opcje: testowany adres URL, opcje Chrome i obiekt konfiguracyjny Lighthouse. Możesz zobaczyć wszystkie trzy z tych parametrów w funkcji uruchamiania Lighthouse z dokumentacji Lighthouse:

 function launchChromeAndRunLighthouse(url, opts, config = null) { return chromeLauncher.launch({chromeFlags: opts.chromeFlags}).then(chrome => { opts.port = chrome.port; return lighthouse(url, opts, config).then(results => { return chrome.kill().then(() => results.lhr) }); }); }

Możesz użyć dowolnego kodu, którego potrzebujesz, aby utworzyć te parametry. Załóżmy na przykład, że masz witrynę z wieloma stronami lub adresami URL, które chcesz przetestować. Być może chcesz uruchomić ten test w środowisku CI w ramach zadań CI, sprawdzając wszystkie niezbędne strony przy każdym uruchomieniu zadania. Korzystając z tej konfiguracji, możesz użyć JavaScript, aby utworzyć swoje adresy URL i utworzyć pętlę, która uruchomi Lighthouse dla każdego z nich.

Wszelkie opcje Chrome, których możesz potrzebować, można określić w obiekcie, który jest przekazywany do programu chrome-launcher. W przykładzie z dokumentacji obiekt opts zawiera tablicę, którą chromeFlags , którą można przekazać do chrome-launcher oraz port, w którym można zapisać port używany przez chrome-launcher, a następnie przekazać go do Lighthouse.

Wreszcie obiekt konfiguracyjny Lighthouse umożliwia dodanie dowolnych opcji specyficznych dla latarni morskiej. Pakiet Lighthouse zapewnia domyślny obiekt konfiguracyjny, którego można używać bez zmian lub rozszerzać i modyfikować. Możesz użyć tego obiektu do wielu rzeczy, w tym do określenia, które kategorie testowe Lighthouse chcesz przetestować.

Więcej po skoku! Kontynuuj czytanie poniżej ↓

Możesz użyć emulatedFormFactor , aby określić, czy test ma być uruchamiany w emulatorze mobilnym, czy stacjonarnym. Możesz użyć extraHeaders , aby dodać pliki cookie, których możesz potrzebować w przeglądarce. Na przykład test uruchamiający tylko kategorię ułatwień dostępu w emulatorze pulpitu, który wyświetla wyniki jako HTML, może mieć obiekt konfiguracyjny, który wygląda tak:

 const lighthouseOptions = { extends: 'lighthouse:default', settings: { onlyCategories: ['accessibility'], emulatedFormFactor:'desktop', output: ['html'], }, }

Ten przykład przedstawia minimalną konfigurację. Możesz zrobić o wiele więcej. Dokumentacja konfiguracyjna Lighthouse zawiera znacznie więcej informacji. Posiadają również zestaw przykładowych obiektów konfiguracyjnych dla niektórych bardziej złożonych implementacji.

Raportowanie wyników niestandardowych

Podczas programowego uruchamiania Lighthouse możesz uzyskać wyniki zwrócone w jednej lub więcej z trzech sformatowanych opcji i — i to jest moim zdaniem najbardziej ekscytujący — możesz mieć dostęp do nieprzetworzonego obiektu Lighthouse Result (LHR).

HTML, JSON, CSV

Lighthouse automatycznie sformatuje wyniki na trzy różne sposoby: HTML, JSON lub CSV. Są to wszystkie wstępnie skonfigurowane wyniki oparte na podstawowym szablonie raportowania Lighthouse, który zobaczysz na przykład po uruchomieniu testu Lighthouse w Chrome DevTools. W obiekcie konfiguracyjnym lighthouseOptions z poprzedniej sekcji możesz zobaczyć klucz output , który zawiera tablicę z pojedynczym ciągiem: html . Oznacza to, że chcę, aby zwracane wyniki były sformatowane jako HTML. Gdybym chciał uzyskać wyniki zarówno w formacie HTML, jak i JSON, ta tablica wyglądałaby jak ['html', 'json'] .

Po uruchomieniu Lighthouse zwróci obiekt wyników, który będzie zawierał dwa klucze: report i lhr . Porozmawiamy o zawartości klucza lhr w następnej sekcji, ale klucz report zawiera tablicę z wynikami sformatowanymi w żądany sposób. Na przykład, jeśli zażądaliśmy ['html', 'json'] , to results.report[0] będzie zawierało nasze wyniki sformatowane jako HTML, a results.report[1] będzie zawierało nasze wyniki sformatowane jako JSON.

Obiekt LHR

Programowe uruchomienie Lighthouse zapewnia również dostęp do znacznie bardziej elastycznego obiektu wyników: obiektu LHR. Ten obiekt zawiera nieprzetworzone wyniki i niektóre metadane z Twojego przebiegu Lighthouse. Pełniejszą dokumentację można znaleźć w repozytorium Lighthouse Github.

Możesz wykorzystać te wyniki na wiele sposobów, w tym tworzyć niestandardowe raporty i zbierać dane z wielu przebiegów do analizy.

Przykład: Uruchamianie testu dostępności dla urządzeń mobilnych i komputerów stacjonarnych

Załóżmy, że mam witrynę, która ładuje różne komponenty w zależności od tego, czy użytkownik korzysta z mniejszego ekranu, czy z większego, co oznacza, że kod HTML dla każdej wersji witryny będzie nieco inny. Chcę mieć pewność, że obie wersje witryny uzyskają wynik 95 punktów w testach dostępności Lighthouse i że żaden kod nie zostanie przypisany do naszej main gałęzi, która nie spełnia tego standardu.

Uwaga : Jeśli chcesz zobaczyć działający przykład poniższego kodu analizującego stronę główną Sparkbox, możesz znaleźć repozytorium tutaj.

Mogę skonfigurować Lighthouse tak, aby uruchamiał kategorię dostępności dwukrotnie, zapewniając różne obiekty konfiguracyjne dla każdego z nich — jeden ustawiający emulatedFormFactor na desktop i drugi ustawiający go na mobile . Prostym sposobem na to jest utworzenie tablicy z obydwoma obiektami, pokazanej poniżej.

 const lighthouseOptionsArray = [ { extends: 'lighthouse:default', settings: { onlyCategories: ['accessibility'], emulatedFormFactor:'desktop', output: ['html', 'json'], }, }, { extends: 'lighthouse:default', settings: { onlyCategories: ['accessibility'], emulatedFormFactor:'mobile', output: ['html', 'json'], }, }, ]

Następnie mogę utworzyć funkcję, która przejdzie przez tę tablicę i uruchomi test Lighthouse dla każdego obiektu znalezionego w tablicy.

Należy zauważyć, że konieczne jest wprowadzenie opóźnienia między każdym uruchomieniem, w przeciwnym razie Chromium może się pomylić, a przebiegi będą działać nieprawidłowo. W tym celu dodałem funkcję wait , która zwraca obietnicę po zakończeniu interwału setTimeout .

 function wait(val) { return new Promise(resolve => setTimeout(resolve, val)); } function launchLighthouse(optionSet, opts, results) { return chromeLauncher .launch({ chromeFlags: opts.chromeFlags }) .then(async chrome => { opts.port = chrome.port; try { results = await lighthouse(url, opts, optionSet); } catch (e) { console.error("lighthouse", e); } if (results) reportResults(results, runEnvironment, optionSet, chrome); await wait(500); chrome.kill(); }); } async function runLighthouseAnalysis() { let results; const opts = { chromeFlags: ["--no-sandbox", "--headless"] }; for (const optionSet of lighthouseOptionsArray) { console.log("****** Starting Lighthouse analysis ******"); await launchLighthouse(optionSet, opts, results); } }

W takim przypadku wysyłam wyniki do funkcji reportResults . Stamtąd zapisuję wyniki do lokalnych plików, drukuję wyniki do konsoli i wysyłam wyniki do funkcji, która określi, czy testy zaliczą lub nie spełnią naszego progu dostępności.

 async function reportResults(results, runEnvironment, optionSet, chrome) { if (results.lhr.runtimeError) { return console.error(results.lhr.runtimeError.message); } await writeLocalFile(results, runEnvironment, optionSet); printResultsToTerminal(results.lhr, optionSet); return passOrFailA11y(results.lhr, optionSet, chrome); }

W przypadku tego projektu chcę mieć możliwość zapisywania wyników JSON w określonym katalogu dla naszych testów CI i pliku HTML w określonym katalogu dla naszych lokalnych testów. Sposób, w jaki Lighthouse zwraca te różne typy wyników, ma postać tablicy w kolejności, w jakiej zostały zażądane.

Tak więc w tym przykładzie, w naszym obiekcie lighthouseOptions , nasza tablica najpierw pyta o kod HTML, a następnie JSON. Tak więc tablica report będzie zawierać najpierw wyniki w formacie HTML, a następnie wyniki w formacie JSON. Funkcja writeToLocalFile zapisuje następnie poprawną wersję wyników w pliku o niestandardowej nazwie.

 function createFileName(optionSet, fileType) { const { emulatedFormFactor } = optionSet.settings; const currentTime = new Date().toISOString().slice(0, 16); const fileExtension = fileType === 'json' ? 'json' : 'html'; return `${currentTime}-${emulatedFormFactor}.${fileExtension}`; } function writeLocalFile(results, runEnvironment, optionSet) { if (results.report) { const fileType = runEnvironment === 'ci' ? 'json' : 'html'; const fileName = createFileName(optionSet, fileType); fs.mkdirSync('reports/accessibility/', { recursive: true }, error => { if (error) console.error('error creating directory', error); }); const printResults = fileType === 'json' ? results.report[1] : results.report[0]; return write(printResults, fileType, `reports/accessibility/${fileName}`).catch(error => console.error(error)); } return null; }

Chcę również wydrukować wyniki na terminalu po zakończeniu testów. Zapewnia to szybki i łatwy sposób przeglądania wyników bez konieczności otwierania pliku.

 function printResultsToTerminal(results, optionSet) { const title = results.categories.accessibility.title; const score = results.categories.accessibility.score * 100; console.log('\n********************************\n'); console.log(`Options: ${optionSet.settings.emulatedFormFactor}\n`); console.log(`${title}: ${score}`); console.log('\n********************************'); }

I na koniec chcę móc oblać moje przebiegi testów, jeśli wyniki dostępności nie osiągną mojego progowego wyniku 95.

 function passOrFailA11y(results, optionSet, chrome) { const targetA11yScore = 95; const { windowSize } = optionSet; const accessibilityScore = results.categories.accessibility.score * 100; if (accessibilityScore) { if (windowSize === 'desktop') { if (accessibilityScore < targetA11yScore) { console.error(`Target accessibility score: ${targetA11yScore}, current accessibility score ${accessibilityScore}`); chrome.kill(); process.exitCode = 1; } } if (windowSize === 'mobile') { if (accessibilityScore < targetA11yScore) { console.error(`Target accessibility score: ${targetA11yScore}, current accessibility score ${accessibilityScore}`); chrome.kill(); process.exitCode = 1; } } } }

Zapraszam wszystkich do zabawy i odkrywania różnych sposobów, w jakie Lighthouse może pomóc w monitorowaniu jakości witryny.

Uwagi końcowe

Chociaż celowo utrzymywałem powyższy przykład stosunkowo prosty, mam nadzieję, że dał ci dobry przegląd tego, co można osiągnąć, gdy programowo uruchomisz Lighthouse. Mam nadzieję, że zainspiruje Cię do znalezienia nowych sposobów korzystania z tego elastycznego, potężnego narzędzia.

Jak powiedział Peter Drucker:

„Jeśli nie możesz tego zmierzyć, nie możesz tego poprawić”.

Możliwość nie tylko mierzenia, ale także monitorowania jakości naszej witryny, zwłaszcza w przypadku witryn złożonych, znacznie pomoże nam w tworzeniu lepszej sieci.

Dalsze czytanie na SmashingMag:

Testy A/B dla doświadczeń mobilnych
Jak przetestować koncepcję projektową pod kątem skuteczności?
Znaczenie ręcznego testowania dostępności
Uczenie maszynowe dla programistów front-end z Tensorflow.js
Rozpocznij projektowanie interfejsu użytkownika dzięki tym wskazówkom, aby przyspieszyć przepływ pracy