Il 6 agosto 2026, Cloudflare ha rilasciato Kitesurf — un browser progettato non per le persone, ma per gli agenti. All'interno non c'è Chromium: il motore è costruito su Rust, compilato in WebAssembly e funziona interamente in isolati V8 su Workers. L'azienda afferma che per compiti tipici degli agenti consuma da 3 a 7 volte meno CPU e memoria rispetto a Chromium. Quattro mesi prima, l'open source Obscura — anch'esso Rust, anch'esso "per agenti" — ha raccolto oltre 22.000 stelle su GitHub, e Cloudflare ha riconosciuto apertamente che il primo prototipo di Kitesurf era un port di Obscura su Workers.
Il mercato dei motori per l'automazione si è fratturato: da un lato ci sono runtime leggeri per agenti che risparmiano risorse; dall'altro, pesanti build di Chromium che possono fare tutto, incluso superare i controlli anti-bot. Analizziamo i fatti su cosa offre realmente ciascuna classe e dove finisce il risparmio.
Su quali criteri confrontare
I benchmark dei motori amano misurare velocità e memoria, ma per lo scraping in produzione e per gli agenti sono importanti quattro assi indipendenti, e un guadagno nel primo non dice nulla sugli altri:
- Costo di avvio — CPU e memoria per pagina. Questo si traduce direttamente in costi per l'infrastruttura con migliaia di sessioni parallele.
- Completezza della piattaforma web — quanti siti moderni vengono renderizzati correttamente. Qui si misura la copertura dei Web Platform Tests (WPT).
- Superamento dell'anti-bot — la sessione sopravvivrà a un handshake TLS, a una sfida JS e a un controllo comportamentale.
- Controllo dell'uscita in rete — potete gestire da quale IP e da quale ASN il sito vede la richiesta.
Kitesurf: risparmio contro completezza
Kitesurf è composto da moduli: rendering e parsing di HTML/CSS su Blitz, motore CSS Stylo da Firefox, runtime JS Boa su Rust, shaping del testo tramite Parley. Secondo l'azienda, lo sviluppo ha richiesto 12 settimane.
I numeri del benchmark di Cloudflare contro Chromium:
- CPU per screenshot — 380 ms contro 1173 ms (3,1 volte meno);
- CPU per estrazione HTML — 229 ms contro 877 ms (3,8 volte meno);
- memoria per screenshot — 57,8 MiB contro 271 MiB (4,7 volte meno);
- memoria per estrazione HTML — 39,4 MiB contro 273,7 MiB (7 volte meno);
- ma per quanto riguarda il tempo di esecuzione, Kitesurf è più lento: 1148 ms contro 637 ms per lo screenshot e 820 ms contro 472 ms per l'HTML — da 1,7 a 1,8 volte.
È uno scambio onesto: pagate in latenza, ma ottenete la possibilità di mantenere su una sola macchina molte più sessioni parallele. Secondo gli standard web, il motore si comporta abbastanza bene per la sua età — al momento dell'annuncio, circa 215.000 test WPT superati, ora la documentazione riporta più di 235.000. Copertura per sezioni: DOM 97%, HTML 96%, Selection 99%, SVG 97%, Encoding 99%, CORS 95%, XHR 95%, URL 83%. Wikipedia, Hacker News e tipiche SPA vengono renderizzate.
Kitesurf si connette in modo familiare: endpoint CDP (quindi, Puppeteer e Playwright), MCP per agenti, endpoint REST Quick Actions per screenshot ed estrazione HTML. È sufficiente aggiungere il parametro browser=kitesurf. La beta è gratuita, ma con limiti sull'account; promettono di aprire il codice sorgente.
Cosa non può fare Kitesurf — ed è scritto nella sua stessa documentazione
La lista delle limitazioni è breve, ma copre tutta la linea di difesa dei siti moderni. Kitesurf non supporta:
- riproduzione video;
- rendering WebGL;
- handshake della sfida bot con veri fingerprint TLS;
- sessioni autorizzate lunghe che richiedono uno stato costante.
Il terzo punto è cruciale. Cloudflare stessa scrive: se il compito si scontra con una sfida bot, utilizzate il normale Chromium in Browser Run. Cioè, l'azienda che impone queste sfide su milioni di siti avverte onestamente che il suo browser leggero non le supera. Non è una mancanza della beta, ma una conseguenza dell'architettura: il fingerprint TLS (JA3/JA4) nasce nello stack di rete, non nel renderer, e il motore Rust nell'isolato Workers si comporta fisicamente in modo diverso rispetto al vero Chrome.
Un effetto collaterale del motore non standard è l'unicità. Gli script anti-bot sono stati calibrati per anni sugli artefatti di Chromium: ordine delle proprietà, specificità degli errori, tempistiche delle API. Un motore che non ha questi artefatti non appare "più pulito" — appare diverso, e "diverso" nel punteggio anti-bot costa di più rispetto a "come tutti". Abbiamo già analizzato questo effetto nella recensione dei browser stealth del 2026: i benchmark sulla pulizia del fingerprint JS e i risultati su obiettivi reali divergono, perché gli obiettivi reali considerano un insieme di segnali.
Obscura: la stessa classe, ma sul vostro server
Obscura è il principale rappresentante open source della classe. Il repository è stato creato il 13 aprile 2026, licenza Apache-2.0, a fine agosto — oltre 22.000 stelle. All'interno c'è un vero V8, all'esterno — CDP, quindi è anche una sostituzione drop-in per headless Chrome per Puppeteer e Playwright.
La chiave architettonica: Obscura non ha una pipeline di layout e rendering, non disegna affatto l'immagine. Da qui i numeri del benchmark dell'autore — la mediana su 33 scenari dà circa 21 volte la velocità e circa un settimo della memoria rispetto a headless Chrome. Con un caricamento continuo di pagine React in quattro worker, sono 40 pagine al secondo con 112 MB di memoria contro 3 pagine al secondo con 4,2 GB su Chrome. Copertura WPT per il "nucleo" (DOM, HTML, URL, fetch) — 83,3%, cioè 318.916 test superati su 382.891.
La differenza pratica con Kitesurf non è nella velocità, ma nel dove tutto questo gira. Obscura la implementate voi stessi — e decidete voi attraverso quale uscita di rete passa. Kitesurf vive in una rete esterna, e questo ci porta al punto principale.
Chi possiede il vostro IP in uscita
Di risparmio CPU hanno scritto tutti, di uscita in rete — quasi nessuno. Tuttavia, Kitesurf viene eseguito su Workers, il che significa che le richieste escono dalla rete Cloudflare, con il suo ASN. Non c'è gestione dell'IP in uscita o possibilità di collegare un proxy proprio nella documentazione di Kitesurf. Gli sviluppatori del Browser Rendering vicino si scontrano con lo stesso problema: il tentativo di impostare un proxy upstream tramite proxyServer in BrowserContext fallisce con net::ERR_PROXY_CONNECTION_FAILED, e indirizzi egress fissi per Workers non sono normalmente previsti.
Per lo scenario target di Cloudflare, questo è normale: l'agente visita pagine aperte, scatta screenshot, estrae HTML. Ma non appena l'obiettivo è un po' protetto, si ottiene la peggiore delle combinazioni di segnali:
- l'IP appartiene a un grande ASN cloud, quindi è già segnato come server;
- il fingerprint TLS non corrisponde a nessun vero browser;
- non potete cambiare né l'uno né l'altro, perché non possedete né lo stack di rete né l'uscita.
Questa situazione spiega perché la conversazione sugli agenti nel 2026 si sposta sempre più non verso l'ottimizzazione del runtime, ma verso la questione dell'accesso legale e pagato — dagli agenti firmati a richieste a pagamento, di cui abbiamo parlato nell'analisi dei portafogli per bot e HTTP 402. Se un sito non vi lascia entrare, il motore più economico del mondo non aiuterà: semplicemente non riuscite a ottenere la pagina che non vi è stata data.
Cosa scegliere per il compito
Kitesurf — quando gli obiettivi sono aperti e numerosi: monitoraggio di pagine pubbliche, estrazione di HTML per RAG-index, screenshot di massa, bypass economici della documentazione per agenti. Inoltre, beta gratuita e zero problemi con l'infrastruttura. Non portatelo dove ci sono login, anti-bot o requisiti di geo specifici.
Obscura — lo stesso profilo di carico, ma quando è necessario il controllo: il proprio hosting, la propria uscita di rete, le proprie patch. È adatto come cavallo da lavoro per un parco di parsing, dove il costo della pagina è importante e l'aspetto della pagina non conta affatto. Lavora bene con i proxy, perché gestite l'intero processo.
Chromium normale sotto Playwright o Puppeteer — quando sono necessari video, WebGL, sessioni autorizzate complesse e rendering reale. Costoso in termini di risorse, ma prevedibile.
Build stealth di Chromium (Camoufox, nodriver, patchright, e tra le novità — CloakBrowser, che ha raccolto più di 30.000 stelle da febbraio 2026) — quando l'obiettivo è protetto e non ci sono altre opzioni. Le risorse sono leggermente superiori a quelle di Chromium nudo, ma si mantiene l'essenziale: un vero stack di rete, in cui è possibile inserire l'uscita necessaria.
E il denominatore comune per le ultime tre opzioni: il motore decide come apparite a livello di browser, mentre i proxy residenziali decidono come apparite a livello di rete. Per obiettivi aperti e compiti interni bastano anche indirizzi server — sono più economici e veloci. Per siti con vera protezione, il costo della pagina non si calcola in base ai megabyte di memoria, ma in base alla percentuale di risposte riuscite.
Conclusione
Kitesurf e Obscura rappresentano una risposta onesta e, a giudicare dai numeri, riuscita a un reale problema: utilizzare Chromium per estrarre HTML è davvero uno spreco, e il rapporto di Apify e The Web Scraping Club lo conferma — il 65,8% degli specialisti nel 2025 ha utilizzato più proxy rispetto all'anno precedente, e il 58,3% ha aumentato il budget per essi. Le spese per l'automazione stanno crescendo, e un risparmio da 3 a 7 volte in memoria è un argomento significativo.
Ma il risparmio funziona fino al primo obiettivo protetto. Un motore leggero non supera la sfida bot — così è scritto nella documentazione di Cloudflare stessa. Il runtime cloud non permette di gestire l'IP in uscita. Pertanto, lo stack degli agenti del 2026 è composto da due strati indipendenti: un motore economico per pagine aperte in massa e un browser completo con uscita di rete controllata per tutto il resto. Cercare di chiudere entrambi gli strati con un unico strumento si traduce in un sovrapprezzo per Chromium dove basterebbe Rust, oppure in una conversione nulla per il parser dove manca l'IP.
```