Lingue

Percorso critico di rendering

La pipeline del browser dai byte ai pixel visibili — DOM, CSSOM, albero di rendering, layout e disegno — il motivo per cui CSS e JavaScript possono bloccare il rendering, le tre leve di ottimizzazione e gli effetti su FCP, LCP e sul rendering di Googlebot. L'hub delle risorse che bloccano il rendering.

Prima pubblicazione: 26 giu 2026 · Ultimo aggiornamento: 31 ago 2026 · Avanzato
AIScritto daAI v2

Il percorso critico di rendering (CRP) è il lavoro ordinato per dipendenze che il browser esegue prima di poter disegnare il primo pixel: analizza l'HTML nel DOM, il CSS nel CSSOM, li combina nell'albero di rendering, calcola il layout e disegna. È un modello mentale, non una sequenza rigida. Il CSS applicabile blocca il disegno finché il CSSOM non è pronto; JavaScript sincrono blocca l'analisi del DOM. Ottimizzare il CRP significa ridurre il numero di risorse critiche, la lunghezza del percorso e i byte critici. FCP segue il completamento del CRP come tappa, non come diagnosi completa, e un CRP lungo può ritardare LCP. Anche Googlebot usa un Chromium headless senza stato e con cache fredda, quindi le risorse bloccanti ne rallentano il rendering, senza che ciò dimostri un'equivalenza esatta o un effetto sul ranking. CSS e JS critici non vanno bloccati in robots.txt.

In breve — Il CRP porta dai byte al primo disegno: HTML → DOM, CSS → CSSOM, DOM + CSSOM → albero di rendering → layout → disegno. Il CSS blocca il rendering finché il CSSOM non è pronto; JavaScript sincrono blocca la costruzione del DOM. Riduci risorse critiche, lunghezza del percorso critico e byte critici. FCP segue il completamento come tappa, non come diagnosi; un ampio intervallo TTFB→FCP segnala possibili risorse bloccanti e un CRP lungo può ritardare LCP. WRS di Googlebot usa Chromium headless senza stato e con cache fredda: le risorse bloccanti lo rallentano e CSS/JS critici non vanno esclusi in robots.txt. Leve: CSS critico inline, CSS non critico asincrono, JS con defer e preload soltanto per risorse confermate nel percorso.

La pipeline in cinque passaggi, dai byte ai pixel

Ogni pagina segue questo modello in ordine di dipendenza, ma non come cinque fasi rigide eseguite una sola volta. Il browser analizza e mostra progressivamente l’HTML, sovrappone attività e ripete parti del lavoro quando arrivano HTML, CSS o modifiche al DOM. È un modello per ragionare sulle dipendenze.

1. HTML → DOM. web.dev descrive: «Bytes → characters → tokens → nodes → object model». Il browser traduce i byte in caratteri, token, oggetti e infine in un albero, il Document Object Model usato per le elaborazioni successive.

2. CSS → CSSOM. I byte CSS diventano caratteri, token, nodi e l’albero CSS Object Model. CSSOM e DOM sono strutture indipendenti, costruite separatamente.

3. DOM + CSSOM → albero di rendering. I due alberi si combinano e mantengono il contenuto visibile. display: none rimuove un elemento dall’albero; visibility: hidden lo mantiene nel layout ma non lo disegna.

4. Layout. Calcola posizione e dimensioni di ogni oggetto, producendo il box model.

5. Disegno. Usa l’albero finale per renderizzare i pixel.

6. Compositing e visualizzazione. I livelli disegnati vengono combinati e mostrati. Proprietà come transform e opacity possono ripetere soltanto questo passaggio, senza nuovo layout o disegno, e sono quindi meno costose da animare.

Prova a sostegno di questa affermazione The browser constructs the DOM and CSSOM, combines them into a render tree, performs layout, and paints pixels. Ambito: web.dev explanation of the browser's critical rendering path. Attendibilità: alta · Verificato: web.dev: Constructing the object model

Il CRP è la parte da completare prima del primo disegno: ottimizzarlo significa capire le elaborazioni che trasformano i byte HTML, CSS e JavaScript in pixel.

Due blocchi, due meccanismi diversi

Il CSS blocca il rendering quando è applicabile. Il browser non mostra contenuti finché non costruisce il CSSOM. Un <link> con media="print" durante una normale visita non blocca, pur venendo scaricato. L’applicabilità può però cambiare con media query, viewport o DOM, richiedendo altro lavoro. Un solo foglio lento e applicabile nel <head> può trattenere il primo disegno.

JavaScript blocca la costruzione del DOM. Quando il parser incontra uno script, si ferma e lo esegue; se è esterno, ne attende anche il download. Uno scanner secondario continua comunque a scoprire e recuperare immagini, script e CSS. async rimuove il blocco del download ma può interrompere il thread principale quando arriva; defer attende la fine dell’analisi e conserva l’ordine, risultando spesso più sicuro.

Prova a sostegno di questa affermazione CSS is render-blocking by default, while parser-blocking scripts stop DOM construction until execution completes. Ambito: Default stylesheet and synchronous script behavior in the critical rendering path. Attendibilità: alta · Verificato: web.dev: Render-blocking CSS web.dev: Adding interactivity with JavaScript

Le tre leve di ottimizzazione

web.dev indica tre variabili:

  • Riduci il numero di risorse critiche: eliminale, rinviane il download o rendile asincrone.
  • Riduci la lunghezza del percorso critico: meno round trip nella catena di dipendenze.
  • Riduci i byte critici: minimizza, comprimi e suddividi.

In pratica: inserisci nel <head> il CSS critico above-the-fold; carica il resto in modo asincrono; limita il CSS non critico con media query; applica defer al JavaScript non essenziale; usa preload per risorse confermate. La mia guida LCP di Ahrefs descrive lo stesso meccanismo come riordino del download e CSS critico inline.

preload e fetchpriority fanno lavori diversi. preload anticipa il recupero di una risorsa non ancora scoperta; fetchpriority cambia soltanto la priorità di una richiesta già prevista. Un preload con URL, tipo as o credenziali errati può essere inutilizzato o duplicato; troppe priorità alte annullano il vantaggio. Verifica sempre con waterfall o trace prima e dopo.

Il legame con i Core Web Vitals

  • FCP segue il completamento del CRP, ma è una tappa, non una diagnosi. Un CRP lungo tende a produrre FCP tardivo, ma FCP non identifica la fase colpevole e un FCP rapido non dimostra che ogni dipendenza sia pronta.
  • LCP può ereditare il ritardo. Abby Hamilton osserva che il CRP incide spesso soprattutto su LCP. Un grande intervallo TTFB→FCP può segnalare molte risorse bloccanti, ma la causa va confermata con waterfall o trace.
  • TBT/INP risentono di JavaScript. Gli script critici competono per il thread principale e i task lunghi danneggiano l’interattività.

LCP è un segnale di ranking, ma risultati sul campo ed effetti specifici richiedono dati CrUX/Search Console, non soltanto un test di laboratorio.

Come influisce su Googlebot

Il Web Rendering Service (WRS) elabora le app JavaScript nelle fasi scansione, rendering e indicizzazione, usando una versione evergreen di Chromium headless. Le risorse bloccanti ne rallentano quindi il rendering come in un browser reale. È una deduzione dall’architettura condivisa, non la prova che ogni ritardo sia identico per ogni utente o provochi direttamente un danno a indice o ranking.

Tre conseguenze:

  • La coda aggiunge ritardo. Le pagine attendono da pochi secondi a più tempo.
  • WRS è senza stato e con cache sostanzialmente fredda. Come spiego nella mia guida JavaScript SEO, ogni pagina viene caricata come una nuova visita. WRS può ignorare header di cache e usare risorse CSS/JS non aggiornate; non puoi affidarti a una cache calda.
  • Non bloccare risorse critiche in robots.txt. WRS deve recuperare CSS e JS per costruire il contenuto. Come spiego nella mia guida JavaScript SEO, impedirglielo può mostrare a Google una pagina rotta.

Bing non pubblica una serie equivalente sul CRP, ma ogni crawler basato su browser segue lo stesso principio e il budget di rendering di Bingbot è più limitato.

Caso limite: un disegno anticipato non dimostra che il contenuto sia pronto

Le app renderizzate sul client possono disegnare rapidamente una shell, uno skeleton o uno stato di caricamento e soddisfare FCP mentre il contenuto reale attende bundle, esecuzione e dati. Il CRP è terminato per la shell, non per il contenuto.

HTML server-rendered o statico evita in gran parte il problema. Su pagine JS controlla nel filmstrip o nella trace ciò che è davvero visibile al momento di FCP e quando appare il contenuto principale: sono due domande diverse.

Dove i professionisti SEO incontrano il CRP

Il punto più comune è l’audit «Elimina le risorse che bloccano il rendering» di PageSpeed Insights/Lighthouse. Espandilo per vedere risorse proprietarie e di terze parti. In WebPageTest esamina ciò che precede «Start Render»; in DevTools usa Coverage per CSS/JS inutilizzato. Un’unica trace è soltanto un campione: terze parti, consenso, service worker e cache calda o fredda cambiano tempi e scoperte tra esecuzioni.

Argomenti correlati

  • Risorse che bloccano il rendering — come trovare CSS e JavaScript bloccanti in PageSpeed Insights, Lighthouse e WebPageTest, usare async e defer, inserire CSS critico inline, applicare media query e correggere l’avviso passo per passo.

Per le metriche, consulta Core Web Vitals, Largest Contentful Paint (LCP) e First Contentful Paint (FCP). Per il rendering di Googlebot, consulta JavaScript SEO e Come funziona la Ricerca.

Aggiungi una nota dell’esperto

Fissa una citazione dell’esperto

Persona nuova? Crea il suo profilo non rivendicato in /admin/experts/ → Fissa una citazione dell’esperto prima.