Michael JohnsonOgni agente di IA deve davvero avviare un Chromium completo se deve solo leggere una pagina o acquisire uno screenshot? Il 12 novembre 2026 Cloudflare ha reso open source Kitesurf, un motore sperimentale per automatizzare attività nel browser. Può essere eseguito localmente o distribuito nel proprio account Cloudflare; il compromesso principale è un minor consumo di CPU e memoria a fronte di tempi di esecuzione più lunghi e di una compatibilità limitata con i siti web.
È un’opzione utile per chi sviluppa automazioni per il browser: si può esaminare e adattare il motore mantenendo la familiare interfaccia Chrome DevTools Protocol (CDP). Tuttavia, prima di spostare tutti i flussi di lavoro su Kitesurf, conviene verificare le pagine necessarie. Nel confronto pubblicato da Cloudflare, Chromium completava le attività di test più rapidamente, mentre Kitesurf non supporta ancora alcune importanti funzionalità del web.
Che cosa è cambiato il 12 novembre
Kitesurf era stato presentato per la prima volta il 6 ottobre 2026 come componente di Browser Run, disponibile in beta. All’epoca Cloudflare aveva illustrato l’architettura e i risultati dei propri test; il 12 novembre l’azienda ha pubblicato il codice con licenza Apache 2.0. Ora è possibile esaminare il motore, compilarlo localmente e distribuirlo sull’infrastruttura del proprio account. Questo rende l’implementazione più accessibile, ma non trasforma di per sé il browser sperimentale in un sostituto di Chromium.
Il progetto offre due modalità di esecuzione. Per lo sviluppo locale servono Node.js 22 o versioni successive, pnpm 9.15.4 e Bazelisk; le istruzioni del progetto suggeriscono di clonare il repository, installare le dipendenze e avviare la compilazione con pnpm run dev. Per distribuirlo su Cloudflare è necessario il piano Workers Paid: il motore utilizza Dynamic Workers per isolare le pagine. Chi lo ospita autonomamente deve configurare un sistema di autenticazione separato: Kitesurf non ne integra uno e un Worker accessibile pubblicamente potrebbe consentire a terzi di usare le risorse di calcolo e le richieste in uscita del proprio account.
Come fa il browser a funzionare senza Chromium
Un normale browser headless avvia un motore di grandi dimensioni, progettato per siti web e interfacce utente. Kitesurf assembla le funzionalità necessarie per l’automazione a partire da diversi componenti Workers: uno accetta le connessioni CDP e conserva lo stato della sessione, processi isolati separati gestiscono la pagina e un altro componente si occupa del rendering. Per interagire con gli strumenti per sviluppatori, Kitesurf supporta CDP: è quindi possibile collegarvi client compatibili come Puppeteer.
I componenti basati su Rust elaborano HTML e CSS, il JavaScript della pagina viene eseguito in un ambiente Workers isolato e un renderer separato genera l’immagine. Cloudflare descrive l’instradamento delle richieste di rete tramite un componente dedicato: carica le risorse del sito, applica le policy di rete e conserva separatamente i cookie delle pagine. L’isolamento è parte integrante dell’architettura del browser: gli agenti devono visitare siti arbitrari che eseguono codice di cui non ci si può fidare automaticamente.
L’architettura è adatta a carichi di lavoro del tipo «avviare un’attività, elaborare una pagina, terminare». Se il renderer si blocca, lo si può arrestare e ricreare, perché non conserva lo stato della pagina. Questo approccio potrebbe essere più pratico per picchi di automazione rispetto a processi pesanti sempre attivi. Si tratta di una motivazione architetturale del progetto, non di una garanzia di risparmio specifico su qualsiasi sistema.
Come si riduce il consumo di risorse
Nel confronto pubblicato in precedenza, Cloudflare ha usato le mediane di cinque esecuzioni di Browser Run su un insieme di 14 URL. Per acquisire uno screenshot, Kitesurf consumava 57,8 MiB di memoria contro i 271 MiB di un pool Chromium già avviato; per estrarre l’HTML, 39,4 MiB contro 273,7 MiB. Questi dati descrivono una configurazione e un insieme di pagine specifici dell’azienda: è quindi meglio considerarli come una misurazione di un particolare tipo di carico di lavoro, non come un fattore universale valido per tutti i siti.
Sulle stesse attività, Chromium era più rapido: acquisire uno screenshot richiedeva 637 ms contro i 1.148 ms di Kitesurf, mentre estrarre l’HTML richiedeva 472 ms contro 820 ms. In altre parole, il vantaggio di Kitesurf riguarda soprattutto il consumo di risorse, non la rapidità di risposta. Per la raccolta massiva e di breve durata di pagine, il risparmio di memoria può essere più importante di qualche secondo di latenza; per un agente interattivo che deve reagire rapidamente, la differenza nei tempi può pesare di più. Cloudflare ha pubblicato la metodologia e i risultati delle misurazioni.
Quando scegliere Kitesurf e quando Chromium
Kitesurf è adatto ad attività singole: estrarre HTML, costruire il DOM, acquisire uno screenshot o generare un PDF su un sito compatibile. La compatibilità con CDP permette di valutare questa alternativa nello stack di automazione già esistente, mentre il codice sorgente consente di esaminarne il comportamento e i requisiti di distribuzione. Per un piccolo esperimento si può iniziare con una compilazione locale; per eseguirlo su Cloudflare occorre considerare il piano a pagamento e proteggere l’istanza con l’autenticazione.
Per siti che usano video o WebGL, sessioni autenticate di lunga durata, interazioni affidabili con sistemi anti-bot o requisiti di rendering accurato, la documentazione di Cloudflare consiglia il browser standard Browser Run basato su Chromium. Kitesurf non supporta ancora la riproduzione video, WebGL o sessioni prolungate con stato persistente; il supporto agli standard e la qualità del rendering sono ancora in fase di sviluppo.
È utile distinguere la conformità agli standard dalla compatibilità effettiva. I test Web Platform Tests verificano singoli requisiti degli standard web, ma non indicano se uno specifico sito complesso si caricherà correttamente né se l’agente riuscirà a completare una sequenza di azioni. La verifica pratica consiste nel provare proprio le pagine e gli scenari necessari, confrontando i risultati con Chromium, anziché dedurre la compatibilità dal numero complessivo di test superati.
Indicazioni pratiche per il team
Considerate Kitesurf come un’opzione specializzata per l’esecuzione di attività nel browser. Per prima cosa scegliete alcune pagine reali e misurate tre aspetti: l’accuratezza dei dati estratti o degli screenshot, i tempi di esecuzione e il consumo di risorse. Verificate poi separatamente l’autenticazione, le restrizioni di rete e il comportamento delle sessioni. Se l’attività è breve, il sito è compatibile e memoria e CPU contano più della latenza, vale la pena provare Kitesurf. Se invece sono importanti un rendering accurato, funzionalità web avanzate o la persistenza dello stato, Chromium resta il punto di partenza più adatto.
La pubblicazione del codice sorgente non cambia la scelta tra un motore specializzato e leggero e un browser completo; rende invece possibile verificare e distribuire autonomamente la prima opzione. Ora i team possono valutarla più facilmente sulle proprie pagine e infrastrutture, senza affidarsi soltanto alle tabelle del fornitore.
