Un'introduzione all'esecuzione del faro in modo programmatico

Pubblicato: 2022-03-10

Riepilogo rapido ↬ Essere in grado di eseguire la suite di analisi Lighthouse di Google in modo programmatico offre molti vantaggi, soprattutto per applicazioni Web più grandi o complesse. L'utilizzo di Lighthouse a livello di codice consente agli ingegneri di impostare il monitoraggio della qualità per i siti che richiedono una maggiore personalizzazione rispetto a quanto consentito dalle semplici applicazioni di Lighthouse (come Lighthouse CI). Questo articolo contiene una breve introduzione a Lighthouse, illustra i vantaggi dell'esecuzione a livello di codice e illustra una configurazione di base.

Lighthouse è la suite di Google di strumenti di analisi della qualità dei siti web. Ti consente di valutare le prestazioni, l'accessibilità, la SEO e altro del tuo sito. È inoltre altamente configurabile, il che lo rende sufficientemente flessibile da essere utile per tutti i siti, dal più semplice al più complesso. Questa flessibilità include diversi modi di eseguire i test, consentendoti di scegliere il metodo che funziona meglio per il tuo sito o applicazione.

Uno dei modi più semplici per eseguire Lighthouse è tramite il pannello DevTools Lighthouse di Chrome. Se apri il tuo sito in Chrome e quindi apri DevTools di Chrome, dovresti vedere una scheda "Faro". Da lì, se fai clic su "Genera rapporto", dovresti ottenere un rapporto completo delle metriche di qualità del tuo sito.

Ciò su cui mi sto concentrando in questo articolo, tuttavia, è all'altra estremità dello spettro. L'esecuzione di Lighthouse in modo programmatico con JavaScript ci consente di configurare esecuzioni personalizzate, selezionare e scegliere le funzionalità che vogliamo testare, raccogliere e analizzare i risultati e specificare opzioni di configurazione uniche per i nostri siti e applicazioni.

Ad esempio, forse lavori su un sito accessibile tramite più URL, ognuno con i propri dati e stile e forse anche markup che vuoi essere in grado di analizzare. O forse vuoi raccogliere i dati da ogni esecuzione di test e compilarli o analizzarli in modi diversi. Avere la possibilità di scegliere come eseguire un'analisi Lighthouse in base a ciò che funziona meglio per il tuo sito o applicazione rende più semplice monitorare la qualità del sito e individuare dove ci sono problemi con il tuo sito prima che si accumulino o causino troppi problemi per il tuo utenti del sito.

L'esecuzione di Lighthouse in modo programmatico non è la scelta migliore per ogni sito e ti incoraggio a esplorare tutti i diversi metodi che il team di Lighthouse ha creato per utilizzare lo strumento. Se decidi di utilizzare Lighthouse a livello di codice, tuttavia, si spera che le informazioni e il tutorial di seguito ti consentano di iniziare.

Personalizzazione delle opzioni del faro

Il vantaggio di eseguire Lighthouse in modo programmatico non è solo la possibilità di configurare Lighthouse stesso, ma piuttosto tutte le cose che potresti voler o dover fare attorno ai test di Lighthouse. Lighthouse ha un'ottima documentazione per iniziare. Per ottenere il massimo dall'esecuzione a livello di codice, tuttavia, ci sono due punti principali in cui dovrai approfondire e saperne di più su come funziona Lighthouse: configurare le esecuzioni dei test e riportare i risultati dei test.

Configurazione dell'esecuzione del test del faro

La configurazione di un test di Lighthouse è una di quelle attività che possono essere semplici o complesse a piacere.

Quando esegui Lighthouse a livello di codice, sono tre i punti in cui puoi fornire opzioni personalizzate: l'URL che testerai, le opzioni di Chrome e l'oggetto di configurazione di Lighthouse. Puoi vedere tutti e tre questi sono parametri nella funzione per l'esecuzione di Lighthouse dalla documentazione di 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) }); }); }

È possibile utilizzare qualsiasi codice necessario per creare questi parametri. Ad esempio, supponi di avere un sito con più pagine o URL che vorresti testare. Forse vuoi eseguire quel test in un ambiente CI come parte delle tue attività CI, controllando tutte le pagine necessarie ogni volta che l'attività viene eseguita. Utilizzando questa configurazione, puoi utilizzare JavaScript per creare i tuoi URL e creare un ciclo che eseguirà Lighthouse per ciascuno di essi.

Qualsiasi opzione di Chrome di cui potresti aver bisogno può essere specificata in un oggetto che viene passato a Chrome-Launcher. Nell'esempio della documentazione, l'oggetto opts contiene un array che chiamiamo chromeFlags che puoi passare a chrome-launcher e una porta in cui puoi salvare la porta utilizzata da chrome-launcher e quindi passarla a Lighthouse.

Infine, l'oggetto di configurazione Lighthouse ti consente di aggiungere qualsiasi opzione specifica per Lighthouse. Il pacchetto Lighthouse fornisce un oggetto di configurazione predefinito che può essere utilizzato così com'è o esteso e modificato. Puoi usare questo oggetto per fare una moltitudine di cose, incluso specificare quali categorie di test di Lighthouse vuoi testare.

Altro dopo il salto! Continua a leggere sotto ↓

È possibile utilizzare emulatedFormFactor per specificare se si desidera che il test venga eseguito in un emulatore mobile o desktop. Puoi utilizzare extraHeaders per aggiungere eventuali cookie che potresti dover utilizzare nel browser. Ad esempio, un test che esegue solo la categoria di accessibilità su un emulatore desktop che restituisce i risultati come HTML potrebbe avere un oggetto di configurazione simile al seguente:

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

Questo esempio rappresenta una configurazione minima. C'è molto di più che puoi fare. I documenti di configurazione di Lighthouse contengono molte più informazioni. Hanno anche una serie di oggetti di configurazione di esempio per alcune implementazioni più complesse.

Rapporti sui risultati personalizzati

Quando si esegue Lighthouse a livello di codice, è possibile visualizzare i risultati in una o più delle tre opzioni formattate e, e questo è il pezzo più interessante secondo me, è possibile accedere all'oggetto Lighthouse Result (LHR) grezzo.

HTML, JSON, CSV

Lighthouse formatterà automaticamente i risultati in tre modi diversi: HTML, JSON o CSV. Questi sono tutti risultati preconfigurati basati sul modello di rapporto di base di Lighthouse, che è ciò che vedi se esegui un test di Lighthouse all'interno di Chrome DevTools, ad esempio. Nell'oggetto di configurazione lighthouseOptions della sezione precedente, puoi vedere una chiave per output che contiene un array con una singola stringa: html . Questo specifica che voglio solo che i risultati restituiti siano formattati come HTML. Se volessi i risultati sia come HTML che JSON, quell'array sarebbe simile a ['html', 'json'] .

Una volta eseguito, Lighthouse restituirà un oggetto risultati che conterrà due chiavi: report e lhr . Parleremo del contenuto della chiave lhr nella prossima sezione, ma la chiave del report contiene un array con i risultati formattati come hai richiesto. Quindi, ad esempio, se abbiamo richiesto ['html', 'json'] , results.report[0] conterrà i nostri risultati formattati come HTML e results.report[1] conterrà i nostri risultati formattati come JSON.

L'oggetto LHR

L'esecuzione di Lighthouse in modo programmatico ti dà anche accesso a un oggetto dei risultati molto più flessibile: l'oggetto LHR. Questo oggetto contiene i risultati grezzi e alcuni metadati dalla tua esecuzione di Lighthouse. Una documentazione più completa può essere trovata sul repository Github di Lighthouse.

Puoi utilizzare questi risultati in diversi modi, inclusa la creazione di report personalizzati e la raccolta di dati da più esecuzioni per l'analisi.

Esempio: esecuzione di un test di accessibilità per dispositivi mobili e desktop

Diciamo che ho un sito che carica diversi componenti a seconda che l'utente utilizzi uno schermo più piccolo o uno più grande, il che significa che l'HTML per ogni versione del sito sarà leggermente diverso. Voglio assicurarmi che entrambe le versioni del sito ottengano un punteggio di 95 nei test di accessibilità di Lighthouse e che nessun codice venga assegnato al nostro ramo main che non soddisfi tale standard.

Nota : se vuoi vedere un esempio funzionante del codice seguente analizzando la home page di Sparkbox, puoi trovare il repository qui.

Posso configurare Lighthouse per eseguire la categoria di accessibilità due volte, fornendo oggetti di configurazione diversi per ciascuno: uno impostando emulatedFormFactor su desktop e uno impostandolo su mobile . Un modo semplice per farlo è creare un array con entrambi gli oggetti, mostrato di seguito.

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

Quindi, posso creare una funzione che scorrerà questo array ed eseguirà un test Lighthouse per ogni oggetto trovato all'interno dell'array.

Una cosa da notare è che è necessario introdurre un ritardo tra ogni esecuzione, altrimenti Chromium potrebbe confondersi e le corse andranno in errore. Per fare ciò, ho aggiunto una funzione wait che restituisce una promessa quando l'intervallo setTimeout è completato.

 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); } }

In questo caso, sto inviando i risultati a una funzione reportResults . Da lì, salvo i risultati in file locali, stampo i risultati sulla console e invio i risultati a una funzione che determinerà se i test superano o non superano la nostra soglia di accessibilità.

 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); }

Per questo progetto, voglio essere in grado di salvare i risultati JSON in una directory specificata per le nostre esecuzioni di test CI e il file HTML in una directory specificata per le nostre esecuzioni di test locali. Il modo in cui Lighthouse restituisce questi diversi tipi di risultati è in una matrice nell'ordine in cui sono stati richiesti.

Quindi, in questo esempio, nel nostro oggetto lighthouseOptions , il nostro array richiede prima HTML, quindi JSON. Quindi l'array di report conterrà prima i risultati in formato HTML e poi i risultati in formato JSON. La funzione writeToLocalFile salva quindi la versione corretta dei risultati in un file con un nome personalizzato.

 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; }

Voglio anche stampare i risultati sul terminale al termine dei test. Ciò fornisce un modo semplice e veloce per visualizzare i risultati senza dover aprire un file.

 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********************************'); }

E infine, voglio essere in grado di fallire i miei test se i punteggi di accessibilità non soddisfano il mio punteggio di soglia di 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; } } } }

Invito tutti voi a giocarci ed esplorare tutti i diversi modi in cui Lighthouse può aiutare a monitorare la qualità del vostro sito.

Note finali

Anche se ho intenzionalmente mantenuto l'esempio sopra relativamente semplice, spero che ti abbia fornito una buona panoramica di ciò che è possibile ottenere quando si esegue Lighthouse in modo programmatico. E spero che ti ispiri a trovare nuovi modi per utilizzare questo strumento flessibile e potente.

Come ha detto Peter Drucker:

"Se non puoi misurarlo, non puoi migliorarlo."

Essere in grado non solo di misurare, ma anche di monitorare la qualità del nostro sito Web, soprattutto per i siti complessi, farà molto per aiutarci a costruire un Web migliore.

Ulteriori letture su SmashingMag:

Test A/B per esperienze mobile first
Come testare un concetto di design per l'efficacia
L'importanza del test di accessibilità manuale
Apprendimento automatico per sviluppatori front-end con Tensorflow.js
Inizia con la progettazione dell'interfaccia utente con questi suggerimenti per accelerare il flusso di lavoro