Browser headless

Un browser headless è un browser web eseguito senza un'interfaccia visibile, usato per automatizzare attività come screenshot, test ed estrazione dei contenuti tramite codice.

Come funziona

È un motore completo, lo stesso che rende le pagine in Chrome, Firefox o Safari, ma senza finestra grafica. Carica HTML, esegue JavaScript, applica CSS e produce il rendering come un browser visibile. L'output finisce in un buffer fuori schermo invece che su un monitor.

Lo si controlla tramite codice, di solito con librerie come Puppeteer per Chrome e Chromium o Playwright per Chromium, Firefox e WebKit. Uno script può aprire un URL, attendere il caricamento, interagire con la pagina e acquisire screenshot senza mouse o tastiera.

Non dovendo mostrare l'interfaccia, usa meno memoria e funziona su server, pipeline CI e container privi di display.

Dove si usano i browser headless

• Screenshot automatici — per acquisire in scala pagine di prodotti, siti promozionali, documentazione e pagine dei concorrenti.
• Test di regressione visiva — per confrontare immagini prima e dopo una modifica al codice e rilevare cambiamenti indesiderati.
• Web scraping — per caricare pagine ricche di JavaScript non accessibili con semplici richieste HTTP ed estrarne il contenuto reso.
• Generazione PDF — per rendere una pagina ed esportarla come documento mantenendo il layout del browser.
• Test delle prestazioni — per misurare caricamento, dimensioni delle risorse e rendering senza il costo di una finestra visibile.

Acquisizione headless e con interfaccia

Con un browser visibile, acquisire è semplice ma manuale: apri la pagina, ridimensioni la finestra e premi una scorciatoia, come Cmd+Maiusc+3 su Mac o Win+Maiusc+S su Windows. Funziona una volta, ma non scala.

L'acquisizione headless è programmabile. Un solo script può registrare centinaia di pagine in più viewport, in sequenza o in parallelo. Funziona su un server senza monitor, si integra nelle pipeline CI/CD e offre risultati coerenti a prescindere da chi lo esegue.

La resa è quasi identica. Possono differire i font di sistema non installati sul server, le funzioni accelerate dalla GPU che ricadono sul rendering software e le animazioni, per cui serve un'attesa esplicita.

Questa coerenza è il vero vantaggio per i prodotti di acquisizione. Una volta definiti viewport, DPR, condizioni di attesa e cookie, ogni screenshot segue la stessa procedura ed è più facile da confrontare, pubblicare e considerare affidabile rispetto a immagini create a mano su portatili diversi.

Errori comuni

• Non attendere il caricamento. Il browser è rapido e può acquisire prima che immagini lazy-loaded, font web e dati asincroni siano pronti. Attendi un selettore, lo stato di rete inattiva o un elemento preciso.
• Ignorare viewport e densità. La viewport predefinita è spesso piccola, per esempio 800x600. Imposta esplicitamente dimensioni e fattore di scala.
• Non installare i font. I server spesso non includono quelli presenti sul desktop e ricorrono ad alternative che cambiano il testo. Installa i font necessari o usa un'immagine container che li includa.
• Dimenticare banner e popup. Le acquisizioni automatiche visitano le pagine come nuovi utenti. Chiudi gli avvisi nello script, altrimenti copriranno i contenuti.