Martin Splitt annunciò la mediana di 5 secondi, non un timeout fisso

Il fantasma dei 5 secondi

Se fate SEO da qualche anno, lo avete sentito ripetere fino allo sfinimento: Google abbandona il rendering dopo 5 secondi. È diventato un assioma, un numero inciso nel marmo degli audit tecnici. Avete ottimizzato ogni millisecondo, sforbiciato JavaScript, rimandato i pixel non essenziali. E se vi dicessi che stavate correndo contro un fantasma?

Partiamo dal dato che ha generato tutto. Martin Splitt di Google annunciò al Chrome Dev Summit 2019 che il tempo mediano di rendering di GoogleBot era di 5 secondi. Mediana. Non soglia. Non timeout. Non limite fisso. Eppure, in pochi mesi, quel numero è diventato il nuovo dogma: se la pagina non viene renderizzata entro 5 secondi, Google la scarta. Un’interpretazione che ha plasmato audit, tool e checklist per anni.

La scorsa settimana, il 23 luglio 2026, un'analisi approfondita pubblicata su Tame the Bots ha messo nero su bianco ciò che molti sospettavano: Google non interrompe il rendering dopo 5 secondi. Il dato citato nel 2019 era una mediana — il che implica che metà delle pagine venivano renderizzate in meno di 5 secondi e metà in più. Un concetto statistico elementare che per anni è stato appiattito in una regola binaria.

Ma se il limite non è fisso, cosa governa davvero il rendering? E perché Google ha scelto proprio ora di chiarirlo?

L'orologio virtuale di Google

La risposta tecnica arriva direttamente dal Web Rendering Service (WRS), il motore che esegue JavaScript e costruisce il DOM delle pagine per l’indicizzazione. Al Chrome Dev Summit, Martin Splitt non ha descritto un timer a scadenza fissa, ma un sistema molto più sofisticato: il WRS utilizza un orologio virtuale che Google può controllare, anziché l’orologio hardware del server. Questo significa che il tempo di rendering non è un countdown inesorabile, ma una risorsa gestita dinamicamente in base alla coda di crawling e alle risorse disponibili.

Già nel 2019, la documentazione ufficiale di Google avvertiva che una pagina poteva restare in coda per il rendering per pochi secondi, ma che poteva volerci di più. Un’ammissione esplicita che la rigidità dei 5 secondi non era contemplata nel modello operativo del motore. Il WRS ha sì scadenze di rendering per pagina, come riportato da un'analisi tecnica su The HQ Digital, che possono causare l’abbandono del rendering se le risorse critiche impiegano troppo tempo — ma non esiste una cifra fissa valida per tutte le pagine.

I dati emersi nell’analisi di Tame the Bots lo confermano: il limite di rendering del WRS può estendersi fino a circa 30 secondi per l’indicizzazione reale. Un test documentato ha mostrato una pagina indicizzata dopo che sono state effettuate solo 10 chiamate di rete, equivalenti a circa 30 secondi di elaborazione. Non stiamo parlando di una tolleranza di qualche secondo in più, ma di un ordine di grandezza completamente diverso rispetto al numero che ha terrorizzato interi team SEO.

La gestione asincrona del rendering è ulteriormente confermata dal comportamento di scansione: come spiega anche Screaming Frog, Google esegue inizialmente il crawling dell’HTML statico e rinvia il rendering JavaScript a un secondo momento, quando le risorse computazionali sono disponibili. Questo significa che la pagina entra in un circuito a due fasi — prima il crawl, poi la renderizzazione differita — e che il tempo totale può variare enormemente in base al carico del sistema e alla complessità della pagina.

Ora sappiamo che il rendering può durare fino a 30 secondi e che Google gioca con il tempo attraverso un orologio virtuale. Ma per chi ottimizza siti JavaScript, questo cambia tutto. E solleva una domanda scomoda: quante pagine abbiamo sacrificato sull’altare di un limite che non esisteva?

E adesso cosa testiamo?

Se il limite non è più il riferimento, i vecchi audit basati su Screaming Frog o sulla soglia arbitraria dei 5 secondi vanno ripensati. Non perché fossero inutili, ma perché misuravano la performance contro un obiettivo sbagliato. Una pagina che impiega 7 secondi a renderizzare non è automaticamente un problema — e una che ne impiega 3 non è automaticamente al sicuro.

Il punto non è quanto velocemente la pagina viene renderizzata in un test di laboratorio, ma se Google riesce effettivamente a completare il rendering con le risorse che decide di allocare in quel momento. Il WRS ha un orologio virtuale manipolabile: può accelerare o rallentare, a seconda della priorità che assegna alla pagina e della disponibilità della coda. Questo introduce una variabile che nessun tool lato client può replicare fedelmente.

La conseguenza operativa è chiara: smettiamo di ottimizzare per un numero magico e iniziamo a porci domande migliori. Le risorse critiche sono accessibili in modo affidabile? Il JavaScript lato client è strutturato per essere eseguito in modo incrementale o blocca il rendering fino al completamento? Stiamo testando con dati reali di Search Console o ci stiamo affidando esclusivamente a simulazioni di terze parti?

La vera incognita resta: come misuriamo il tempo effettivo di rendering sulle nostre pagine? E se Google ci stesse dando più risorse di quante ne stiamo usando — mentre noi continuiamo a tagliare funzionalità per rientrare in un timeout immaginario?

La prossima volta che un audit SEO vi dice “la pagina non è indicizzata perché il rendering supera i 5 secondi”, sapete che non è sufficiente. Non è un falso problema — è una diagnosi incompleta. Ma la vera domanda è un’altra: avete mai misurato quanto tempo impiega davvero Google a renderizzare le vostre pagine, o state ancora correndo contro un fantasma?