Cloudflare Workers ha un'unica regola tassativa che cambia tutto: 10ms di CPU per request sul piano standard. Non wall time — solo CPU effettiva. Sembra poco, ma in realtà è abbondante se sai cosa stai facendo.
Cosa conta
Solo computazione attiva: parsing, JSON manipulation, crypto. Le fetch() verso altri servizi non contano (sono I/O wait). Quindi un Worker che fa "fetch backend → trasforma → return" ha quasi tutto il tempo coperto dall'I/O.
I tre killer di CPU
1. Regex catastrofico
Una regex con backtracking esponenziale può bruciare 10ms su un input di 200 caratteri. Quando il debug è "il Worker time-out su una richiesta", quasi sempre la causa è regex. Usa regex linear-time o, ancora meglio, parser dedicati.
2. JSON.parse di payload enormi
Parsare un JSON da 500 KB costa ~5-8ms. Se devi fare anche una trasformazione, sei al limite. Considera streaming JSON parse o splitting upstream.
3. Crypto sincrono
Hash di password con bcrypt o scrypt sono pesanti. Per quei casi, fanno parte di Workers Unbound (CPU illimitata, leggermente più caro), oppure si delegano a un servizio dedicato.
Quando passare a Workers Unbound
Se la tua logica è davvero CPU-bound (encoding video edge, ML edge, parsing complesso), Workers Unbound ha CPU senza limite ma fattura per CPU time effettivo. È comunque più economico di Lambda per la maggior parte dei casi che abbiamo visto.
L'osservabilità
Cloudflare Analytics mostra il CPU time medio per Worker. Se vedi che si avvicina a 8-9ms, è il momento di rivedere la logica o promuovere a Unbound. Aspettare i timeout in produzione è la strada peggiore.