Bun WebView accelera il browser: il limite che manca nel tuo repo Replit

Un browser dentro il runtime cambia il conto dell’infrastruttura

Bun 1.4 aggiunge Bun.WebView, con supporto all’automazione del browser tramite WebKit su macOS o Chromium controllato via Chrome DevTools Protocol. In una prova riportata da Simon Willison nella ricerca su Bun.WebView e un’API JSON, un servizio che apre pagine web ed esegue JavaScript richiedeva circa 192–256 MB di memoria per eseguire Chrome su pagine complesse.

Il fatto interessante non è solo la nuova API. È il cambio di profilo: una normale richiesta HTTP può diventare l’avvio o il controllo di un browser completo, con DOM, JavaScript, immagini, font, redirect e richieste secondarie. Il costo non è più soltanto “una funzione che restituisce JSON”. È un processo pesante dentro il tuo servizio.

Per chi ha costruito rapidamente un prodotto con un coding agent, questa distinzione conta. Un endpoint che funziona in sviluppo può diventare il punto attraverso cui una singola richiesta occupa tutta la memoria disponibile, blocca i worker e rallenta anche le richieste degli altri utenti.

Cosa significa se il tuo codice l’ha scritto Replit

Immagina di avere usato Replit per creare un servizio che:

1. riceve un URL dall’utente;
2. apre la pagina in un browser automatizzato;
3. esegue uno script JavaScript;
4. restituisce testo, screenshot o dati strutturati.

Il buco tecnico concreto è una resource exhaustion: il flusso non impone limiti sufficienti a memoria, CPU, durata, numero di pagine o processi browser.

Nel caso felice, l’utente invia una pagina semplice e riceve risposta in pochi secondi. Nel caso reale, l’URL può puntare a una pagina con script molto pesanti, molte risorse incorporate, iframe annidati, immagini enormi o codice JavaScript che continua a lavorare. Anche senza parlare di attacchi sofisticati, più richieste contemporanee possono moltiplicare i browser aperti fino a saturare il container.

Replit può aiutarti a passare rapidamente da idea a servizio funzionante. Questo non è un difetto del tool e non significa che il progetto sia da buttare. Significa che il repository deve rendere espliciti i limiti operativi che l’agente potrebbe non aver modellato: una richiesta utente non può avere accesso illimitato a un processo costoso.

Il rischio cresce ancora se il browser viene creato dentro ogni richiesta, se non viene chiuso in un blocco finally, se gli errori lasciano processi orfani o se i job lunghi vengono eseguiti direttamente nel processo web principale.

Perché ora ti serve un audit

Un audit VibeInspect serve a rispondere a una domanda precisa: il tuo servizio ha un limite verificabile prima che una pagina pesante lo costringa a rivelare il contrario?

Per questo flusso, l’audit deve ricostruire il percorso completo tra input, browser e risposta. Non basta vedere che l’endpoint restituisce un risultato corretto.

Le verifiche importanti includono:

• esiste un timeout totale per ogni richiesta?
• esiste un limite separato per navigazione, script JavaScript e attesa delle risorse?
• il codice limita il numero di redirect, iframe, tab e popup?
• il browser viene riutilizzato in modo controllato oppure viene creato senza un tetto per ogni richiesta?
• quante istanze Chromium possono essere attive contemporaneamente?
• una coda protegge il processo web dal lavoro pesante?
• CPU e memoria hanno limiti osservabili nel deployment?
• il browser viene sempre chiuso quando la pagina fallisce o supera il tempo massimo?
• un processo figlio rimasto vivo può continuare a consumare risorse dopo la risposta?
• immagini, download e corpi delle risposte hanno un limite di dimensione?
• una pagina può eseguire JavaScript arbitrario con accesso a rete e filesystem non necessari?
• il servizio degrada con un errore controllato oppure esaurisce i worker?

Queste domande trasformano un’impressione in evidenze. Un audit può mostrare, per esempio, che il timeout dell’API è di 30 secondi ma il processo browser non viene terminato quando il client HTTP scade. Oppure che il codice limita il numero di richieste concorrenti, ma crea comunque una nuova istanza Chromium per ogni job accodato.

Può anche emergere un problema di architettura: il server web attende direttamente l’elaborazione invece di consegnare il lavoro a un worker isolato. In quel caso una pagina lenta non rallenta soltanto una richiesta: può occupare il processo che dovrebbe servire tutti gli altri utenti.

Quando il problema è tecnico e vuoi file, righe ed evidenze, il piano coerente è Diagnostic. Non ti serve un’opinione generica sulla qualità del codice: ti serve un verdetto sulla capacità del flusso di restare dentro i limiti del runtime.

Cosa un linter non vede

Un linter può segnalare import inutilizzati, promesse non gestite o alcuni pattern sospetti. Non sa, da solo, quanta memoria consumerà Chromium quando cinque utenti aprono contemporaneamente pagine complesse.

Non vede necessariamente che:

• browser.newPage() viene chiamato dentro ogni richiesta senza pool o limite globale;
• il timeout interrompe la funzione ma non il processo browser sottostante;
• il codice chiude la pagina solo nel percorso di successo;
• un Promise.all() lancia decine di navigazioni contemporaneamente;
• gli script della pagina possono continuare dopo che il client ha chiuso la connessione;
• il servizio scarica immagini o file senza controllare la dimensione prima di conservarli in memoria;
• una coda accumula lavoro più velocemente di quanto i worker riescano a smaltirlo;
• il container ha un limite di memoria, ma il processo non gestisce correttamente l’errore quando lo raggiunge;
• i retry riaprono la stessa pagina dopo un timeout, trasformando un errore singolo in un moltiplicatore di carico.

Il linter osserva soprattutto il codice locale. L’esaurimento delle risorse è un difetto di comportamento distribuito tra handler HTTP, processo browser, code, worker, retry, runtime e configurazione di deployment.

Anche una demo riuscita non basta. Dimostra che il caso felice funziona, non che il servizio sopravvive a una pagina lenta, a un errore di Chromium o a più richieste simultanee. Il nemico è l’assenza di un limite esplicito.

Cosa fare questa settimana

Scegli un solo endpoint del tuo repo Replit che apre pagine web, esegue JavaScript o genera screenshot.

Poi verifica:

1. quante istanze browser possono essere attive nello stesso momento;
2. qual è il timeout totale e quali processi vengono terminati allo scadere;
3. se esistono limiti per redirect, risorse, download e script;
4. se il browser viene chiuso anche su eccezioni, cancellazioni e timeout;
5. se il lavoro gira in un worker separato dal processo web;
6. cosa succede con due, cinque e dieci richieste concorrenti;
7. se esiste una coda con capacità massima e backpressure;
8. quanto pesano memoria e CPU durante una pagina complessa;
9. se retry e fallback possono duplicare il lavoro;
10. quali log permettono di collegare richiesta, browser, pagina e consumo di risorse.

Se non sai rispondere, non significa che Replit abbia generato codice inutile. Significa che ti manca un verdetto sui limiti operativi del tuo servizio.

Carica lo ZIP del repository su VibeInspect.ai e scegli Diagnostic: per una resource exhaustion servono evidenze su concorrenza, timeout, processi browser, cleanup e configurazione. Spedire veloce è utile. Spedire senza sapere quante risorse può consumare una singola richiesta è il rischio che resta da misurare.