TL;DR: Kitesurf riduce CPU e memoria per screenshot ed estrazione HTML, ma oggi non sostituisce Chromium nei flussi complessi. Per una PMI il test sensato è un processo read-only, con un corpus reale di pagine, metriche di accuratezza e un fallback esplicito. Il vantaggio non è “avere un altro browser”: è poter assegnare a ogni task il motore meno costoso che lo esegue bene.
Un agente AI che deve leggere un listino, verificare una pagina WordPress o produrre uno screenshot non lavora direttamente sul web. Gli serve un motore capace di scaricare HTML, eseguire JavaScript, costruire il DOM, applicare CSS e restituire un risultato utilizzabile. Nella maggior parte degli stack quel motore è Chromium. Funziona bene, ma porta con sé componenti pensati per una persona: interfaccia grafica completa, compatibilità estesa, rendering accurato e stato di sessione.
Il 6 agosto 2026 Cloudflare ha presentato Kitesurf, un browser headless costruito per gli agenti e disponibile gratuitamente durante la beta dentro Browser Run. La proposta è netta: eliminare il lavoro che il modello non usa, isolare ogni pagina e spendere meno CPU e memoria. I numeri iniziali sono interessanti. Il punto, però, è capire quali task spostare e quali lasciare su Chromium.
Il costo nascosto di un agente che usa il web
Quando si stima il costo di un’automazione AI si guardano quasi sempre i token. Per gli agenti browser è una misura incompleta. Vanno conteggiati anche tempo del browser, memoria per sessione, concorrenza, retry e minuti persi su pagine incompatibili. Un flusso economico sul modello può diventare costoso se apre una nuova istanza Chromium per ogni URL e la lascia viva fino al timeout.
Cloudflare distingue due modalità operative in Browser Run. Le Quick Actions eseguono operazioni stateless come screenshot, PDF o estrazione di contenuto. Le Browser Sessions danno controllo diretto tramite Puppeteer, Playwright o Chrome DevTools Protocol (CDP). La prima categoria è adatta a task brevi e ripetibili. La seconda serve quando bisogna navigare, mantenere stato o interagire con l’interfaccia.
Questa distinzione viene prima della scelta del modello AI. Se il lavoro consiste nel leggere il titolo, il prezzo e la disponibilità di cento pagine, partire da una sessione completa è spesso uno spreco. Se invece occorre autenticarsi, attraversare più schermate e verificare il risultato di un’azione, una singola chiamata di estrazione non basta.
La mia take è questa: il browser non deve essere una dipendenza unica dello stack. Va trattato come un livello di esecuzione con almeno due profili. Uno leggero per task brevi e read-only; uno completo per le pagine che richiedono compatibilità, stato o controllo visuale preciso.
Cosa cambia nell’architettura di Kitesurf
Kitesurf non è un fork alleggerito di Chrome. Gira su Cloudflare Workers e usa componenti separati. L’Engine espone le API HTTP e il WebSocket CDP e conserva lo stato della sessione. PageScript crea un isolate con un nuovo globalThis e il DOM della pagina. PageRenderer trasforma la scena calcolata in PNG, JPEG o PDF. Il parsing HTML e CSS usa parti di Blitz e Stylo; l’esecuzione di alcuni casi con eval passa oggi da Boa JS, perché Workers non offre ancora eval nativo.
La separazione non è solo una scelta di performance. Kitesurf considera ogni caricamento come input non attendibile. Solo il worker SandboxOutbound può accedere alla rete: applica CORS, filtra le risposte e mantiene i cookie di ogni pagina in un contenitore separato. Gli altri componenti ricevono le risorse necessarie senza un accesso generale all’esterno.
L’altro principio è ridurre lo stato. Il renderer, per esempio, non conserva la pagina. Se una chiamata RPC si blocca, l’Engine può terminare quel componente, avviarne uno nuovo e ripetere il rendering. Per carichi a raffica questa caratteristica conta: una funzione usa risorse per il tempo del task e poi sparisce, invece di tenere un browser caldo senza lavoro.
Per chi gestisce automazioni web, il risultato pratico è una superficie più piccola da pagare e riavviare. Non elimina la complessità del sito visitato. La sposta dentro componenti isolati, con un degrado previsto: un errore dovrebbe produrre un elemento mancante o un frame vuoto, non abbattere l’intera sessione.
I benchmark: meno risorse, più attesa
Cloudflare ha confrontato Kitesurf con un pool Chromium già caldo usando le mediane di cinque esecuzioni su un corpus di 14 URL. Nei test pubblicati, uno screenshot usa 380 millisecondi di CPU con Kitesurf contro 1.173 con Chromium. L’estrazione HTML usa 229 millisecondi contro 877. La memoria scende da 271,0 a 57,8 MiB per lo screenshot e da 273,7 a 39,4 MiB per l’HTML.
Il risparmio dichiarato è quindi compreso tra 3,1 e 3,8 volte sulla CPU e tra 4,7 e 7 volte sulla memoria. Il tempo a parete racconta l’altra metà: Kitesurf impiega 1.148 millisecondi per lo screenshot contro 637 di Chromium, e 820 contro 472 per l’estrazione HTML. In questi test il motore leggero è circa 1,7-1,8 volte più lento.
Non è una contraddizione. Chromium parte da un pool caldo e usa un JIT maturo; Kitesurf paga rasterizzazione ed encoding in un runtime più giovane. CPU, memoria e latenza misurano costi diversi. Se un job notturno deve elaborare migliaia di URL entro alcune ore, densità e costo possono contare più di mezzo secondo. Se un operatore aspetta la risposta davanti allo schermo, la latenza pesa di più.
Questi dati non sono ancora una garanzia sul proprio sito. Sono benchmark del fornitore, su un corpus limitato e con un prodotto nato da dodici settimane. Vanno usati per formulare un’ipotesi, non per compilare un business case definitivo.
Dove provarlo e dove tenere Chromium
Cloudflare indica Kitesurf per estrazione di contenuto, screenshot, PDF e pagine compatibili che non richiedono fedeltà grafica perfetta. Il motore implementa un sottoinsieme di CDP e, al lancio, passa oltre 215.000 Web Platform Tests. Supporta già bene aree importanti per gli agenti, tra cui DOM, HTML, CSS, selezione, SVG e XHR.
I limiti sono altrettanto chiari. Kitesurf non è la scelta giusta per video, WebGL, challenge bot che dipendono da fingerprint TLS realistici o sessioni autenticate lunghe e persistenti. In questi casi Cloudflare consiglia Browser Run con Chromium. Anche un layout che deve essere confrontato pixel per pixel merita il motore completo finché la fedeltà di rendering non è stata misurata sul proprio corpus.
Per una PMI vedo quattro candidati utili:
- controllare ogni notte title, prezzi, disponibilità o messaggi di errore su pagine pubbliche;
- generare screenshot o PDF di conferma per un archivio operativo;
- estrarre HTML da pagine JavaScript per alimentare un controllo successivo;
- verificare un sito WordPress dopo deploy e purge della cache, senza modificare contenuti.
Non partirei invece da acquisti, invio di form, modifiche nel back office o accesso a dati clienti. Per un primo pilot bisogna isolare la qualità del browser, non confonderla con permessi di scrittura e conseguenze reali. Lo stesso criterio vale per gli agenti WordPress: conviene iniziare dalle automazioni read-only.
Un pilot pratico in sette passaggi
1. Definisci un solo output. Per esempio: “restituisci status HTTP, titolo visibile, prezzo e screenshot”. Un risultato ambiguo rende impossibile distinguere un errore di rendering da un errore del modello.
2. Costruisci un corpus reale. Usa da 30 a 50 URL che rappresentino il lavoro: WordPress semplice, pagina Elementor pesante, e-commerce con JavaScript, pagina con consenso cookie e almeno un caso volutamente incompatibile. Salva l’output corretto atteso.
3. Esegui lo stesso test sui due motori. Kitesurf si seleziona aggiungendo browser=kitesurf agli endpoint Browser Run. Mantieni identici URL, timeout, viewport, formato e logica di estrazione. Cambiare più variabili insieme invalida il confronto.
4. Misura cinque valori. Tasso di task completati, correttezza dei campi, tempo a parete, consumo riportato e numero di retry. Per gli screenshot aggiungi una revisione visuale: testo tagliato, font errato o consenso cookie possono produrre un file tecnicamente valido ma inutile.
5. Definisci il fallback prima del test. Se manca un selettore, lo screenshot è vuoto o il task supera il timeout, riprova una sola volta con Chromium. Registra il motivo del fallback. Dopo una settimana saprai quali famiglie di pagina possono usare il motore leggero senza tentativi inutili.
6. Chiudi e limita le sessioni. La documentazione sui limiti di Browser Run ricorda che una sessione non chiusa continua a consumare tempo fino al timeout. Usa try/finally, un tetto di concorrenza e un budget giornaliero. Il risparmio del motore non compensa una coda senza controllo.
7. Decidi con una soglia. Un esempio ragionevole per il pilot: Kitesurf resta il percorso predefinito se completa almeno il 98% dei task read-only corretti e riduce il costo totale stimato, fallback inclusi. La soglia va adattata al rischio. Un report interno può tollerare un retry; un documento destinato a un cliente richiede controlli più stretti.
Isolamento del browser non significa agente sicuro
Kitesurf isola componenti, rete e cookie, ma non decide se l’obiettivo dell’agente è corretto. Una pagina può contenere istruzioni ostili pensate per deviare il modello. OWASP descrive l’Excessive Agency come il rischio che un sistema esegua azioni dannose in risposta a output inattesi, ambigui o manipolati, anche tramite prompt injection indiretta.
Per questo il pilot dovrebbe usare un token separato, permessi minimi, allowlist dei domini e nessuna credenziale nel prompt. L’HTML letto dal browser è dato non attendibile: non deve poter cambiare le istruzioni di sistema, allargare l’ambito del task o chiedere nuovi segreti. Ogni passaggio che modifica dati, invia messaggi o conferma un ordine richiede un gate esplicito e, nei flussi sensibili, approvazione umana.
Il browser isolato limita l’impatto di una pagina ostile sul runtime. Il principio di minimo privilegio limita l’impatto di una decisione sbagliata dell’agente. Servono entrambi. La guida sandbox o backup per gli agenti AI entra nel dettaglio di questa differenza.
La decisione operativa
Kitesurf merita un test adesso, non una migrazione generale. La compatibilità è ancora in crescita, il prodotto è in beta e i benchmark pubblicati arrivano dal fornitore. Allo stesso tempo l’architettura risponde a un problema reale: usare un browser umano completo per ogni micro-task di un agente è costoso e difficile da scalare.
Il criterio giusto non è chiedere se Kitesurf sia “migliore di Chromium”. Bisogna chiedere quale motore completa quel task con il costo totale più basso, senza scendere sotto la soglia di accuratezza. Se il pilot produce una mappa affidabile delle compatibilità, il routing diventa semplice: Kitesurf per estrazione, screenshot e PDF su pagine note; Chromium per stato persistente, rendering complesso e fallback.
Questa è la parte utile per una PMI. Non sostituire uno stack con un altro. Separare i task, misurare il risultato e pagare la complessità solo dove serve.