navigator.cpuPerformance in Chrome 152: nuovo segnale di rilevamento per anti-detect e scraping

Il 25 agosto 2026, Chrome 152 è arrivato nel canale stabile su Windows, Mac, Linux, ChromeOS e Android — e ha portato la proprietà navigator.cpuPerformance. Un numero da 0 a 4 che il sito legge in modo sincrono, senza permessi e senza un singolo ciclo di calcolo. È stato concepito come un suggerimento per le videochiamate e le trasmissioni: a un dispositivo debole viene assegnato 240p senza sfocature di sfondo, a uno potente — 1080p con effetti. Due settimane dopo il rilascio, l'industria dello scraping discute di un'altra questione: i sistemi anti-bot hanno ora un segnale economico e stabile sull'hardware su cui gira il tuo browser.

Cosa restituisce esattamente il browser

La proprietà non restituisce gigahertz né il modello del processore, ma un "tier" di prestazioni. Secondo la nota esplicativa WICG, i tier sono quattro più zero:

• 0 — non è stato possibile classificare il dispositivo;
• 1 — praticamente inutilizzabile per compiti pesanti;
• 2 — debole, ma funzionante;
• 3 — confortevole per scenari normali;
• 4 — performante, con margine per il multitasking.

La specifica vieta esplicitamente di rivelare il fornitore, il nome del modello e il numero di core, richiede HTTPS e pone come obiettivo la privacy: ogni tier deve coprire una quota significativa di dispositivi su Internet — circa centinaia di modelli diversi di CPU, affinché il valore non riduca l'audience a pochi.

L'implementazione reale in Chromium si è rivelata più semplice della specifica. Nella analisi di Zyte è stato mostrato che la classificazione si basa principalmente sul numero di core logici e su una tabella incorporata di aumenti e diminuzioni: la frequenza non viene presa in considerazione, anche se la specifica lo consente. Gli aumenti vengono dati a AMD Ryzen, core Intel Gracemont, Apple silicon e Intel Core Ultra; le diminuzioni — a Intel Atom e processori dell'era Core 2. La classificazione grossolana appare così: macchine a singolo core e molto deboli rientrano nel primo tier, due–quattro core danno il secondo, quattro–dieci core o chip moderni a risparmio energetico — il terzo, mentre otto o più core su Core Ultra, Apple serie M e tutto ciò che ha dieci core o più — il quarto.

Perché questo è un segnale di rilevamento, e non solo un altro byte di entropia

Di per sé, il valore è debole: cinque opzioni corrispondono a circa 2,3 bit di entropia, meno di quanto offra la lingua dell'interfaccia. Il pericolo risiede in altre tre proprietà.

È gratuito. Per misurare la reale velocità di esecuzione di JS, lo script di rilevamento deve occupare il processore per decine di millisecondi, e questo è evidente nel profiler. Qui — lettura sincrona della proprietà, zero costi, zero tracce.

È stabile. Il valore non dipende dal carico della macchina al momento del controllo: è una classe di hardware, non l'attuale utilizzo. Tra sessioni, riavvii e cambi di IP rimane lo stesso — il che significa che è idoneo come parte di un identificatore di profilo a lungo termine.

È verificabile per coerenza. Questo è il punto principale. I moderni motori anti-bot raramente bannano in base a un singolo campo — cercano contraddizioni interne nel set. Un dispositivo che dichiara il quarto tier deve confermarlo con un navigator.hardwareConcurrency plausibile, un navigator.deviceMemory ragionevole, una stringa GPU-renderer moderna e una velocità di esecuzione JS corrispondente. Un profilo che restituisce un tier 4 e allo stesso tempo esegue un benchmark come una macchina virtuale dual-core viene catturato da un triviale controllo incrociato.

A parte, si ottiene quasi un confine pronto "data center contro utente reale": un'istanza cloud tipica su due vCPU riporta onestamente il primo tier, mentre i laptop e i telefoni consumer vivono nel terzo-quarto. Per uno scraper che gira su una VPS economica in modalità headless e si presenta come un normale Chrome su Windows, questa è una combinazione scomoda.

In cosa si differenzia da hardwareConcurrency, che è sempre esistito

Una domanda ragionevole: il numero di core il sito lo leggeva già tramite navigator.hardwareConcurrency, e la quantità di memoria — tramite navigator.deviceMemory. Cosa è cambiato?

È cambiata la connessione. hardwareConcurrency è un numero grezzo, e viene sostituito da tempo e ovunque: si può impostare otto invece di trenta due, e la questione è chiusa. cpuPerformance è una grandezza derivata, calcolata dallo stesso browser secondo una tabella incorporata. Non appena nel set appaiono due campi, uno dei quali è calcolato dall'altro, qualsiasi modifica unilaterale rompe il legame tra di essi. Si sono impostati quattro core, ma il tier è rimasto quarto — secondo la logica di implementazione, tale combinazione richiede o Apple silicon, o Core Ultra, o dieci core; quindi, o il numero di core mente, o la stringa GPU mente, e al rilevatore basta notare il semplice fatto di non corrispondenza, senza scoprire dove sia la menzogna.

Proprio per questo, le vecchie checklist "quali campi sostituire nel profilo" diventano obsolete non per un singolo punto, ma per interi blocchi: la domanda corretta ora non è "cosa sostituire", ma "quale configurazione di hardware coerente otteniamo in totale".

Chi è più colpito

Solo Chromium — e questo non è un attenuante. WebKit ha preso posizione "contro" su questa API, Mozilla non ha dichiarato una posizione pubblica, quindi in Safari e Firefox la proprietà probabilmente non ci sarà. Ma la stragrande maggioranza dell'automazione di produzione — Playwright, Puppeteer, nodriver, Patchright, browser agenti — è costruita proprio su Chromium. Cioè, il segnale arriva esattamente nella nicchia in cui è meno atteso.

Il contrasto colpisce maggiormente l'emulazione dei profili mobili. Se un profilo anti-detect si presenta come uno smartphone Android, e cpuPerformance sotto di esso risponde "4", perché il browser è fisicamente in esecuzione su un desktop con Ryzen, non è una piccola imprecisione, ma una coppia di segnali mutuamente esclusivi. Lo stesso vale per gli scenari di farm, dove decine di profili con diversi "dispositivi" vivono su una sola macchina host e quindi danno lo stesso tier.

Cosa cambia per lo stack di parsing

Alcune conseguenze pratiche per chi esegue browser headless in massa.

• I contenitori ereditano l'host. Il browser in Docker vede i core della macchina host, non i limiti del cgroup — quindi, dieci contenitori su un server potente daranno dieci tier massimi identici. La varietà di profili che hai faticosamente disegnato nell'user-agent è assente a livello hardware.
• Una VPS economica è ora più evidente. Due vCPU — è il primo tier, e il primo tier su Chrome desktop su Windows non si incontra spesso con persone reali. Prima un server debole era semplicemente lento; ora è anche etichettato.
• Il segnale è gratuito per il sito. Controlli pesanti come i benchmark temporali i siti li includono selettivamente, perché costano tempo all'utente. La lettura della proprietà non costa nulla, quindi verrà aggiunta al set di base anche da quelle piattaforme che prima si limitavano alla reputazione IP e agli header.
• Si affiancherà a Compute Pressure. Nelle note di rilascio di Chrome si suggerisce esplicitamente di combinare la nuova API con Compute Pressure API — quindi la combinazione "classe di hardware più carico osservato" è stata originariamente concepita come uno scenario standard, e gli anti-bot non dovranno inventare nulla.

Vale la pena rivedere l'assunzione che sia sufficiente raccogliere una volta un "buon" profilo e riutilizzarlo per anni. I browser aggiungono tali proprietà senza annunci per gli utenti finali: tra il rilascio di Chrome 152 e le prime analisi pubbliche sono passate settimane, durante le quali i profili hanno tranquillamente restituito un nuovo campo, senza sospettare nulla. Ha senso controllare il set di campi una volta per ciclo di rilascio, e non una volta all'anno.

Cosa fare praticamente

1. Prendi il valore attuale. Nella console del profilo: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory e la stringa del renderer WebGL. Registra il tutto in blocco, e non campo per campo — ti controlleranno proprio in base alla combinazione.
2. Confronta il tier con la legenda del profilo. La legenda mobile — primo–terzo tier, laptop economico — secondo–terzo, desktop di punta — quarto. Un tier 4 sotto le spoglie di un vecchio Android o un tier 1 sotto le spoglie di un MacBook della serie M sono entrambi sospetti.
3. Non modificare la proprietà direttamente. La sostituzione tramite Object.defineProperty viene catturata dai segni di ridefinizione del getter e dalla discrepanza con la reale velocità di esecuzione. Se devi cambiare, fallo a livello di compilazione del browser o tramite meccanismi integrati.
4. Ricorda il legittimo override. Chrome offre all'utente un'opzione nelle impostazioni (Performance → Speed → Override CPU performance tier), e agli amministratori una politica aziendale. È utile sapere da entrambi i lati: il valore può essere non solo "reale", ma anche impostato manualmente, e un override identico su un pool di profili diventa di per sé un'etichetta.
5. Distingui i profili su hardware diverso. Se tutti i tuoi profili risiedono su un unico server, il tier sarà lo stesso per tutti — indipendentemente dai dispositivi che simulano. Questo è il caso in cui un parco di diverse macchine con configurazioni diverse risolve onestamente il problema, mentre una patch no.

Per maggiori dettagli su un segnale simile — nell'analisi dell'impronta basata sulla quantità di memoria del dispositivo, e per i browser stealth che lavorano con tali proprietà out-of-the-box, c'è il benchmark di nodriver, Camoufox e Patchright.

Dove si collocano i proxy

Direttamente: i proxy non riparano l'impronta del browser. cpuPerformance viene calcolato lato client, e nessun IP lo cambierà. Ma l'anti-bot prende decisioni sulla somma dei livelli, e proprio all'intersezione dei livelli di solito si verifica il fallimento.

La catena tipica, per cui crollano i setup economici, appare così: IP da una nota rete di hosting, primo tier del processore, segni headless in JS — tre segnali indipendenti, ognuno dei quali è tollerabile singolarmente, ma insieme si sommano in un verdetto inequivocabile. Rimuovere il livello di rete da questa somma è più economico e affidabile che combattere con i campi del browser: con un IP residenziale la richiesta appare come traffico di un normale provider domestico, e l'ipotesi "data center" per il rilevatore svanisce da sola. Per le leggende mobili la logica è la stessa — un proxy mobile deve supportare il profilo mobile, altrimenti la contraddizione si sposta semplicemente dal processore alla rete.

In breve

Chrome 152 ha aggiunto non tanto una nuova impronta, quanto una nuova riga nella tabella dei controlli incrociati. Due bit e poco più di per sé non rivelano nessuno — ciò che rivela è la non coerenza: il dispositivo dichiarato deve corrispondere alla classe del processore, alla quantità di memoria, alla scheda grafica, alla velocità di esecuzione e alla rete da cui è arrivata la richiesta. Questa settimana, l'audit dei profili dovrebbe iniziare con una riga nella console e la domanda "esiste davvero un hardware del genere per chi ci facciamo passare?".