Ragionamento Proporzionale per le Prestazioni Web

Lighthouse ti fornisce un numero. Non ti dice se quel numero è il problema. Converti ogni fase in una percentuale del totale. La percentuale maggiore è il tuo collo di bottiglia. Non la fase che supera una certa soglia assoluta. Questo cambia quali correzioni migliorano effettivamente i tuoi Core Web Vitals.

Ultima revisione a cura di Arjen Karel nel marzo 2026

Il problema con le soglie assolute

Lighthouse dice "Render Delay è di 350ms". Cosa ci fai con questo dato?

Se il tuo LCP totale è di 700ms, sì, 350ms di Render Delay sono metà del problema. Risolvilo.

Ma se il tuo LCP totale è di 4.200ms e il TTFB è di 3.800ms, quei 350ms di Render Delay rappresentano l'8% del totale. Azzerarlo fa risparmiare 350ms. Hai ancora un LCP di 3.850ms che non supera il test. Il 90% del problema è il tuo server.

I numeri assoluti senza contesto portano a sprechi di energie. Convertili in percentuali e il collo di bottiglia diventerà evidente.

Risolvi prima la percentuale più grande

Sia l'LCP che l'INP si suddividono in fasi. Ogni fase consuma una porzione del totale. La porzione più grande è il tuo collo di bottiglia. Risolvi prima quella.

Non è complicato. Ma è sorprendente quanti strumenti per le prestazioni, e ora anche agenti IA, saltino questo passaggio e ottimizzino tutto ciò che supera una soglia fissa.

Esempio LCP

LCP sulle pagine prodotto mobile: 3.820ms (scarso). La suddivisione in fasi da parte di utenti reali:

• TTFB: 420ms (11%)
• Load Delay: 2.100ms (55%)
• Load Time: 680ms (18%)
• Render Delay: 620ms (16%)

Azzerare il 16% di Render Delay fa risparmiare 620ms. Risolvere il problema del 55% di Load Delay fa risparmiare oltre 2.000ms. Entrambi sono problemi reali. Uno è il collo di bottiglia.

Un Load Delay al 55% significa che il browser ha ricevuto l'HTML ma non ha richiesto l'immagine hero per oltre due secondi. Il browser non riesce a trovare l'immagine. Non si trova nell'HTML dove il preload scanner può vederla. Aggiungi un suggerimento di preload e dimezzerai quasi l'LCP.

Esempio INP

INP sulla pagina di checkout: 350ms (richiede miglioramenti). La suddivisione in fasi:

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

Senza percentuali, un agente ottimizza l'Input Delay perché 70ms superano una certa soglia. Mostragli le percentuali e punterà alla Presentation. È lì che se ne va il 57% del tempo.

Risolvere la Presentation (DOM di grandi dimensioni, CSS containment mancante, repaint oneroso) porta l'INP da 350ms a sotto i 200ms. Questo ti porta da "richiede miglioramenti" a "buono". Risolvere l'Input Delay da 70ms a 0ms (improbabile, ma ipotetico) fa risparmiare 70ms. Fallisci comunque a 280ms. Stesso sforzo, risultato diverso.

Cosa succede quando gli agenti saltano questo passaggio

Un agente IA senza contesto proporzionale fa ciò che gli dice lo strumento. Lighthouse segnala un TBT lungo. L'agente ottimizza il TBT. La modifica è tecnicamente corretta. L'impatto nel mondo reale è minimo perché il TBT era il 20% del problema e il collo di bottiglia del 57% rimane intatto.

Vedo costantemente questo schema nelle correzioni delle prestazioni generate dall'IA. La correzione affronta un sintomo. Il collo di bottiglia rimane. I dati sul campo non migliorano. Lo sviluppatore si chiede perché un'ottimizzazione "corretta" non abbia fatto nulla.

Un approccio ti fa perdere tempo. L'altro risolve il problema reale.

Come farlo senza CWV Superpowers

Puoi farlo manualmente. Per l'LCP: apri Chrome DevTools, esegui una traccia delle prestazioni, trova l'indicatore LCP nella timeline e misura le quattro fasi. Converti ciascuna in una percentuale dell'LCP totale. Risolvi prima la percentuale più alta.

Per l'INP: usa l'estensione Chrome Web Vitals o un PerformanceObserver con il tipo di voce event. Registra l'interazione INP, ottieni le durate delle tre fasi, convertile in percentuali.

Oppure lascia che CWV Superpowers lo faccia automaticamente con dati sul campo da migliaia di sessioni reali invece di una singola traccia di laboratorio.