Wypróbuj nowy interfejs Lighthouse API, aby mierzyć wydajność i korzystać ze sprawdzonych metod w odniesieniu do przepływu użytkowników.
Lighthouse to fantastyczne narzędzie do testowania wydajności i sprawdzonych metod podczas wstępnego wczytywania strony. Pamiętaj jednak, że Lighthouse do tej pory trudno było analizować inne aspekty życia strony, np.:
- Strona wczytuje się z pamięcią podręczną w pamięci podręcznej
- Strony z aktywowanym skryptem Service Worker
- Uwzględnianie potencjalnych interakcji użytkowników
Oznacza to, że w narzędziu Lighthouse może brakować ważnych informacji. Podstawowe wskaźniki internetowe są oparte na wszystkich wczytaniach stron, a nie tylko tych z pustą pamięcią podręczną. Poza tym dane takie jak skumulowane przesunięcie układu (CLS) można mierzyć przez cały czas otwarcia strony.
Lighthouse ma nowy interfejs API przepływu użytkowników, który umożliwia przeprowadzanie testów laboratoryjnych w dowolnym momencie w okresie ważności strony. Narzędzie Puppeteer służy do skryptu ładowania stron i aktywowania syntetycznych interakcji z użytkownikami, a Lighthouse można wywoływać na wiele sposobów, aby rejestrować kluczowe statystyki podczas tych interakcji. Oznacza to, że skuteczność można mierzyć podczas wczytywania strony oraz podczas interakcji z nią. Kontrole ułatwień dostępu można przeprowadzać w CI, nie tylko w widoku początkowym, lecz także w obrębie procesu płatności, aby mieć pewność, że nic nie powróci.
Prawie każdy skrypt Puppeteer napisany w celu zapewnienia działającego wzorca przeglądania, można teraz w każdej chwili wstawić Lighthouse w celu pomiaru wydajności i sprawdzonych metod. W tym samouczku omawiamy nowe tryby Lighthouse, które pozwalają mierzyć różne części wzorców zachowania użytkowników: nawigacji, migawki i przedziały czasu.
Konfiguracja
Interfejsy API do obsługi przepływu użytkowników są nadal w wersji testowej, ale są już dostępne w Lighthouse. Aby wypróbować poniższe wersje demonstracyjne, musisz mieć Node w wersji 14 lub nowszej. Utwórz pusty katalog i uruchom go:
# Default to ES modules.
echo '{"type": "module"}' > package.json
# Init npm project without the wizard.
npm init -y
# Dependencies for these examples.
npm install lighthouse puppeteer open
Nawigacje
Nowa „nawigacja” w Lighthouse nadaje nazwę (do tej pory) standardowemu działaniu w Lighthouse, czyli analizie wczytywania strony „na zimno”. Ten tryb służy do monitorowania wydajności wczytywania stron, ale przepływy użytkowników otwierają też możliwość uzyskiwania nowych statystyk.
Aby skrypt Lighthouse przechwycił wczytanie strony:
- Użyj aplikacji Puppeteer, by otworzyć przeglądarkę.
- Rozpocznij wzorzec użytkownika w Lighthouse.
- Przejdź do docelowego adresu URL.
import fs from 'fs';
import open from 'open';
import puppeteer from 'puppeteer';
import {startFlow} from 'lighthouse/lighthouse-core/fraggle-rock/api.js';
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
const flow = await startFlow(page, {name: 'Single Navigation'});
await flow.navigate('https://web.dev/performance-scoring/');
await browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
To najprostsza procedura. Po otwarciu raport zawiera widok podsumowania tylko z jednym krokiem. Gdy klikniesz ten krok, wyświetli się tradycyjny raport Lighthouse dotyczący danej nawigacji.
Jak zwykle w Lighthouse najpierw czyści się całą pamięć podręczną lub pamięć lokalną, ale prawdziwi użytkownicy odwiedzający stronę odnotowują mieszankę wizyt z „zimną” i „ciepłą” pamięcią podręczną, a także mogą występować duże różnice w wydajności między takimi działaniami w przypadku wczytywania „na zimno” a powracaniem do strony z nadal ciepłą pamięcią podręczną.
Rejestruję obciążenie częściowo z pamięci
Możesz też dodać do tego skryptu 2 elementy nawigacyjne, tym razem wyłączając czyszczenie pamięci podręcznej i pamięci podręcznej domyślnie wyłączonej przez Lighthouse w nawigacjach. W następnym przykładzie wczytujemy artykuł na stronie web.dev, aby przekonać się, jak dobrze korzysta z buforowania:
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
const testUrl = 'https://web.dev/performance-scoring/';
const flow = await startFlow(page, {name: 'Cold and warm navigations'});
await flow.navigate(testUrl, {
stepName: 'Cold navigation'
});
await flow.navigate(testUrl, {
stepName: 'Warm navigation',
configContext: {
settingsOverrides: {disableStorageReset: true},
},
});
await browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
Wynikowy raport procesu będzie wyglądał mniej więcej tak:
Połączenie wczytywania „na zimno” i „na ciepło” zapewnia pełniejszy obraz sytuacji rzeczywistych użytkowników. Jeśli masz witrynę, w której użytkownicy wczytują wiele stron podczas jednej wizyty, możesz dzięki temu uzyskać bardziej realistyczny obraz ich zachowań.
Zrzuty
Zrzuty to nowy tryb, w którym można przeprowadzać audyty Lighthouse w jednym punkcie. W przeciwieństwie do zwykłego uruchomienia narzędzia Lighthouse, strona nie jest odświeżana. Dzięki temu można skonfigurować stronę i przetestować ją dokładnie w takim stanie, w jakim może być – na przykład z otwartym menu lub częściowo wypełnionym formularzem.
Na potrzeby tego przykładu załóżmy, że chcesz sprawdzić, czy nowy interfejs Ustawień zaawansowanych w Squoosh przejdzie automatyczne testy Lighthouse. Te ustawienia są widoczne tylko po wczytaniu obrazu i rozwinięciu menu opcji, aby wyświetlić ustawienia zaawansowane.
Ten proces można skryptować w Puppeteer, a na każdym kroku można wykonać zrzut ekranu w Lighthouse:
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
const flow = await startFlow(page, {name: 'Squoosh snapshots'});
await page.goto('https://squoosh.app/', {waitUntil: 'networkidle0'});
// Wait for first demo-image button, then open it.
const demoImageSelector = 'ul[class*="demos"] button';
await page.waitForSelector(demoImageSelector);
await flow.snapshot({stepName: 'Page loaded'});
await page.click(demoImageSelector);
// Wait for advanced settings button in UI, then open them.
const advancedSettingsSelector = 'form label[class*="option-reveal"]';
await page.waitForSelector(advancedSettingsSelector);
await flow.snapshot({stepName: 'Demo loaded'});
await page.click(advancedSettingsSelector);
await flow.snapshot({stepName: 'Advanced settings opened'});
browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
Wynika z niego, że wyniki są zwykle zadowalające, ale pewne kryteria ułatwień dostępu trzeba sprawdzić ręcznie:
Okresy
Jedną z największych różnic między wynikami wydajności w praktyce (np. w CrUX) i w module (np. w Lighthouse) jest brak danych wejściowych użytkownika. Z pomocą przydaje się zakres czasu – ostatni tryb przepływu użytkownika.
Przedział czasu przeprowadza audyty Lighthouse na pewien czas, który może obejmować nawigację, ale nie musi. Jest to świetny sposób na rejestrowanie, co dzieje się na stronie podczas interakcji. Na przykład domyślnie Lighthouse mierzy CLS podczas wczytywania strony, ale w tym polu CLS jest mierzony od pierwszej nawigacji do zamknięcia strony. Jeśli przyczyną CLS są interakcje użytkownika, Lighthouse nie byłby w stanie wykryć problemu i pomóc w jego rozwiązaniu.
Aby to zademonstrować, przedstawiamy witrynę testową, która symuluje reklamy wstrzykiwane do artykułu podczas przewijania bez przydzielonego miejsca. W długich serii kart w widocznym obszarze pojawia się czasami czerwony kwadrat. Ponieważ dla tych czerwonych kwadratów nie zarezerwowano miejsca, karty znajdujące się pod nimi są przesunięte w kierunku, co powoduje przesunięcie układu.
Zwykła nawigacja w Lighthouse ma wartość CLS równą 0. Jednak po przewinięciu strony wystąpią problematyczne przesunięcia układu i wartość CLS będzie rosnąć.
Poniższy skrypt wygeneruje raport przepływu użytkownika zawierający oba działania, aby uwidocznić różnicę.
async function captureReport() {
const browser = await puppeteer.launch({headless: false});
const page = await browser.newPage();
// Get a session handle to be able to send protocol commands to the page.
const session = await page.target().createCDPSession();
const testUrl = 'https://pie-charmed-treatment.glitch.me/';
const flow = await startFlow(page, {name: 'CLS during navigation and on scroll'});
// Regular Lighthouse navigation.
await flow.navigate(testUrl, {stepName: 'Navigate only'});
// Navigate and scroll timespan.
await flow.startTimespan({stepName: 'Navigate and scroll'});
await page.goto(testUrl, {waitUntil: 'networkidle0'});
// We need the ability to scroll like a user. There's not a direct puppeteer function for this, but we can use the DevTools Protocol and issue a Input.synthesizeScrollGesture event, which has convenient parameters like repetitions and delay to somewhat simulate a more natural scrolling gesture.
// https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-synthesizeScrollGesture
await session.send('Input.synthesizeScrollGesture', {
x: 100,
y: 600,
yDistance: -2500,
speed: 1000,
repeatCount: 2,
repeatDelayMs: 250,
});
await flow.endTimespan();
await browser.close();
const report = await flow.generateReport();
fs.writeFileSync('flow.report.html', report);
open('flow.report.html', {wait: false});
}
captureReport();
Spowoduje to wygenerowanie raportu porównującego zwykłą nawigację z przedziałem czasu, który obejmuje zarówno nawigację, jak i przewijanie po niej:
Przy każdym kroku zobaczysz wartość CLS równą 0 w kroku tylko do nawigacji. Świetna witryna!
Natomiast opcje „Nawigacja i przewijanie” to inna historia. Obecnie dostępne są tylko wartości całkowity czas blokowania i skumulowane przesunięcie układu w określonych przedziałach czasowych, ale treści wczytywane metodą leniwego ładowania na tej stronie wyraźnie odzwierciedlają CLS witryny.
Wcześniej narzędzie Lighthouse nie było w stanie zidentyfikować problematycznego zachowania CLS, chociaż niemal na pewno byłoby to widoczne w przypadku rzeczywistych użytkowników. Testowanie wydajności w ramach interakcji ze skryptem znacznie poprawia dokładność modułu.
Czekamy na opinie
Nowe interfejsy API przepływu użytkowników w Lighthouse mogą oferować wiele nowych możliwości, ale pomiar scenariuszy napotykanych przez użytkowników może być trudny.
Jeśli masz pytania, skontaktuj się z nami na forach dyskusyjnych Lighthouse, a wszelkie błędy i sugestie zgłoś w narzędziu do śledzenia problemów.