Coba Lighthouse API baru untuk mengukur performa dan praktik terbaik di seluruh alur penggunaan.
Lighthouse adalah alat yang fantastis untuk menguji performa dan praktik terbaik selama pemuatan halaman awal. Namun, biasanya Lighthouse sulit digunakan untuk menganalisis aspek lain dari halaman, seperti:
- Halaman dimuat dengan warm cache
- Halaman dengan Service Worker yang diaktifkan
- Memperhitungkan interaksi pengguna potensial
Artinya Lighthouse dapat melewatkan informasi penting. Core Web Vitals didasarkan pada semua pemuatan halaman, bukan hanya halaman dengan cache kosong. Selain itu, metrik seperti Pergeseran Tata Letak Kumulatif (CLS) dapat diukur selama halaman dibuka.
Lighthouse memiliki API alur pengguna baru yang memungkinkan pengujian lab di titik mana pun dalam masa aktif halaman. Puppeteer digunakan untuk membuat skrip pemuatan halaman dan memicu interaksi pengguna sintetis, dan Lighthouse dapat dipanggil dalam beberapa cara untuk mendapatkan insight utama selama interaksi tersebut. Artinya, performa dapat diukur selama pemuatan halaman dan selama interaksi dengan halaman. Pemeriksaan aksesibilitas dapat dijalankan di CI, tidak hanya pada tampilan awal tetapi jauh di dalam alur checkout Anda untuk memastikan tidak ada yang mengalami regresi.
Hampir semua skrip Puppeteer yang ditulis untuk memastikan alur pengguna yang berfungsi kini dapat menyertakan Lighthouse di titik mana pun untuk mengukur performa dan praktik terbaik secara keseluruhan. Tutorial ini akan menjelaskan mode Lighthouse baru yang dapat mengukur berbagai bagian alur pengguna: navigasi, snapshot, dan rentang waktu.
Penyiapan
API alur penggunaan masih dalam versi pratinjau, tetapi tersedia di Lighthouse saat ini. Untuk mencoba demo di bawah, Anda memerlukan Node versi 14 atau yang lebih baru. Buat direktori kosong lalu jalankan:
# 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
Navigasi
"Navigasi" Lighthouse baru sebenarnya adalah memberi nama pada perilaku standar Lighthouse (sampai sekarang): menganalisis beban dingin sebuah laman. Ini adalah mode yang digunakan untuk memantau performa pemuatan halaman, tetapi alur penggunaan juga membuka kemungkinan insight baru.
Untuk membuat skrip Lighthouse yang mengambil pemuatan halaman:
- Gunakan puppeteer untuk membuka browser.
- Mulai alur pengguna Lighthouse.
- Buka URL target.
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();
Ini adalah alur paling sederhana. Saat dibuka, laporan menunjukkan tampilan ringkasan hanya dengan satu langkah. Dengan mengklik langkah tersebut, laporan Lighthouse tradisional untuk navigasi tersebut akan muncul.
Seperti halnya Lighthouse, halaman ini dimuat dengan cache atau penyimpanan lokal yang dihapus terlebih dahulu, tetapi pengguna sebenarnya yang mengunjungi situs akan memiliki campuran kunjungan dengan cache dingin dan hangat, dan mungkin ada perbedaan performa yang besar antara pemuatan dingin seperti ini dan pengguna yang kembali ke halaman dengan cache yang masih hangat.
Menangkap beban hangat
Anda juga dapat menambahkan navigasi kedua ke skrip ini, kali ini menonaktifkan pembersihan cache dan penyimpanan yang dilakukan Lighthouse secara default dalam navigasi. Contoh berikutnya ini memuat artikel di web.dev itu sendiri untuk melihat seberapa besar manfaat dari penyimpanan dalam cache:
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();
Hasil laporan alur akan terlihat seperti ini:
Kombinasi pemuatan cold dan warm menawarkan gambaran yang lebih lengkap tentang apa yang sebenarnya dialami pengguna. Jika Anda memiliki situs di mana pengguna memuat banyak halaman dalam kunjungan yang sama, hal ini mungkin dapat memberi Anda tampilan yang lebih realistis mengenai apa yang mereka alami di lapangan.
Snapshot
Snapshot adalah mode baru yang menjalankan audit Lighthouse pada satu waktu. Tidak seperti operasi Lighthouse biasa, halaman tidak dimuat ulang. Tindakan ini akan membuka kemampuan untuk menyiapkan halaman dan mengujinya dalam status yang tepat: dengan drop-down terbuka atau formulir yang terisi sebagian, misalnya.
Untuk contoh ini, Anda ingin memeriksa apakah beberapa UI baru untuk Setelan Lanjutan di dalam Squoosh lulus pemeriksaan Lighthouse otomatis. Setelan ini hanya terlihat jika gambar telah dimuat dan menu opsi diperluas untuk menampilkan setelan lanjutan.
Proses ini dapat dibuat skrip dengan Puppeteer dan Anda benar-benar dapat mengambil snapshot Lighthouse di setiap langkah:
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();
Laporan yang dihasilkan menunjukkan bahwa hasilnya umumnya baik, tetapi mungkin ada beberapa kriteria aksesibilitas yang perlu diperiksa secara manual:
Rentang waktu
Salah satu perbedaan terbesar antara hasil performa di lapangan (seperti dari CrUX) dan di lab (seperti dari Lighthouse) adalah kurangnya input pengguna. Di sinilah rentang waktu—mode alur pengguna terakhir—dapat membantu.
Rentang waktu menjalankan audit Lighthouse selama jangka waktu tertentu, yang mungkin menyertakan atau tidak menyertakan navigasi. Ini adalah cara yang bagus untuk mencatat hal-hal yang terjadi di halaman selama interaksi. Misalnya, secara default Lighthouse mengukur CLS selama pemuatan halaman, tetapi di kolom, CLS diukur dari navigasi awal hingga halaman ditutup. Jika interaksi pengguna merupakan pemicu CLS, ini adalah sesuatu yang sebelumnya tidak dapat dideteksi dan dibantu oleh Lighthouse.
Untuk menunjukkannya, berikut adalah situs pengujian yang menyimulasikan iklan yang dimasukkan ke dalam artikel selama scroll tanpa menyediakan ruang untuk iklan tersebut. Dalam rangkaian kartu yang panjang, sesekali kotak merah ditambahkan ketika slotnya memasuki area pandang. Karena tidak ada ruang untuk kotak merah ini, kartu di bawahnya digeser ke luar, menyebabkan pergeseran tata letak.
Navigasi Lighthouse reguler akan memiliki CLS 0. Namun, setelah di-scroll, halaman akan mengalami pergeseran tata letak yang bermasalah dan nilai CLS akan muncul.
Skrip berikut akan menghasilkan laporan alur penggunaan dengan kedua tindakan tersebut, untuk menunjukkan perbedaannya.
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();
Tindakan ini akan menghasilkan laporan yang membandingkan navigasi reguler dengan rentang waktu yang berisi navigasi dan scroll setelahnya:
Secara mendalam setiap langkah, langkah khusus navigasi akan menampilkan CLS 0. Situs yang bagus!
Namun, "Navigate and scroll" menceritakan kisah yang berbeda. Saat ini hanya Total Waktu Pemblokiran dan Pergeseran Tata Letak Kumulatif yang tersedia dalam rentang waktu, tetapi konten yang lambat dimuat di halaman ini secara jelas mengosongkan CLS untuk situs.
Sebelumnya, Lighthouse tidak akan dapat mengidentifikasi perilaku CLS yang bermasalah ini, meskipun hampir pasti akan muncul dalam pengalaman pengguna nyata. Pengujian performa terhadap interaksi dengan skrip meningkatkan fidelitas lab secara signifikan.
Meminta masukan
API alur pengguna baru di Lighthouse dapat melakukan banyak hal baru, tetapi mungkin masih rumit untuk mengukur jenis skenario yang dihadapi pengguna Anda.
Jika ada pertanyaan, silakan hubungi forum diskusi Lighthouse, dan laporkan bug atau saran apa pun di issue tracker.