121 test Core Web Vitals: le mie ipotesi migliori erano sbagliate
Unire i CSS ha peggiorato il TBT da 76 a 372 ms. Differire l'AJAX da 64 a 265 ms. Il vero colpevole era lo stack pubblicitario. Report di 9 serie di test.
👁 117 letture
Abbiamo ottimizzato questo sito per diversi giorni, eseguendo una serie di misurazioni Lighthouse dopo ogni modifica invece di un singolo test. Il risultato è stato umiliante: due delle nostre ipotesi migliori si sono rivelate dannose, e abbiamo trovato il vero colpevole solo quando abbiamo smesso di credere a un singolo risultato. 121 misurazioni in nove serie. Ecco cosa ne è uscito.
Tre conclusioni in un paragrafo
1. Una singola misurazione Lighthouse non significa nulla - lo stesso URL ci ha dato risultati da 60 a 96 punti senza alcuna modifica al codice. 2. Unire i file CSS in uno solo, cioè il consiglio di ogni guida, ha peggiorato il TBT da 76 a 372 ms. 3. Il colpevole della variabilità non era il nostro codice, ma lo stack pubblicitario - dopo aver bloccato i domini pubblicitari il risultato si è stabilizzato su 77/77 con una variazione FCP dello 0,7% invece del 22%.
Lista aggiornata dei corsi AI
Elenco aggiornato automaticamente una volta al giorno: prezzi, numero di lezioni e valutazioni direttamente dal catalogo del venditore. Novità e bestseller in cima.
Apri l’elenco →
Regola zero: misura una serie, non un singolo test
Sembra banale, ma quasi nessuno lo fa - ed è per questo che quasi tutte le “ottimizzazioni” su internet sono casuali.
Abbiamo eseguito Lighthouse dieci volte di seguito sullo stesso URL invariato. I risultati sono variati da 60 a 96 punti. Se avessimo modificato qualcosa nel codice e ottenuto un test a 96 dopo la modifica e 60 prima, avremmo dichiarato successo. Se fosse uscito il contrario, avremmo annullato una buona correzione.
Consiglio: minimo cinque test per variante, confronta le mediane e indica sempre l’intervallo completo. Se gli intervalli prima e dopo si sovrappongono, non hai un risultato - hai rumore.
Ipotesi 1, respinta: unire i CSS in un unico file
Il consiglio classico: meno richieste HTTP, quindi unisci i fogli di stile. Abbiamo costruito un bundle da diversi file CSS del tema, verificato la correttezza dei percorsi relativi e l’ordine degli import, e implementato. Misurazione:
| Indicatore sulla pagina articolo | Prima | Dopo l’unione |
|---|---|---|
| TBT (blocco del thread principale) | 76 ms | 372 ms |
| Tempo styleLayout | 700 ms | 1018 ms |
Perché non ha funzionato: cinque fogli separati sono cinque brevi attività di parsing che il browser può intercalare con altre. Un foglio da 69 KB è un’unica attività lunga che non può essere interrotta - e le attività lunghe sono esattamente ciò che misura il TBT. Abbiamo ridotto il numero di richieste e peggiorato la percezione di fluidità.
Consiglio: con HTTP/2 il numero di richieste ha smesso di essere un problema. Unire i file è un consiglio dei tempi di HTTP/1.1 e oggi può fare danni.
Ipotesi 2, respinta: differire le richieste in background
La pagina negozio inviava diverse richieste AJAX all’avvio. Le abbiamo differite tramite requestIdleCallback con timeout di 3000 ms - soluzione da manuale. Misurazione:
- TBT del negozio: 64 ms → 265 ms
- L’avvio delle richieste si è spostato dall’intervallo 183-1329 ms a 383-2411 ms
Perché non ha funzionato: il timeout di 3000 ms ha fatto sì che il browser eseguisse tutte le richieste differite in un’unica serie - e proprio nella finestra in cui viene calcolato il TBT. Invece di distribuire il lavoro, l’abbiamo concentrato in un unico collo di bottiglia.
Consiglio: requestIdleCallback con timeout breve non è “fallo dopo”. È “fallo dopo, ma sicuramente”. Senza timeout o con uno molto lungo si comporta diversamente.
Cosa ha funzionato e perché
Una riga che ha eliminato 70 ms di ricalcolo forzato del layout
Uno script leggeva la posizione di un elemento e la modificava immediatamente. Questo causava un ricalcolo forzato del layout - il browser deve interrompere tutto e calcolare la geometria della pagina. Lighthouse indicava 70-75 ms in una singola riga.
La correzione è una riga:
if (window.requestAnimationFrame) requestAnimationFrame(luogo); else luogo();
La lettura si sposta al momento in cui il browser ricalcola comunque il layout. Il costo scende a zero e il codice fa esattamente la stessa cosa.
Rimuovere dal percorso critico ciò che la pagina non usa
Il foglio dei template pesava 75.094 byte e si caricava su ogni sottopagina, nonostante la maggior parte delle pagine non usasse nessuno di quei template. La versione base è 9.708 byte - cioè l’87% del peso era sprecato. Allo stesso modo jQuery, caricato nonostante l’assenza di qualsiasi consumatore.
Consiglio: prima di iniziare a minificare, verifica se il file è effettivamente necessario su quella pagina. La rimozione batte la compressione ogni giorno.
Il vero colpevole: lo stack pubblicitario
Dopo aver respinto entrambe le ipotesi, abbiamo posto una domanda diversa: da dove viene la variazione 60-96 punti. Abbiamo bloccato i domini pubblicitari e di consenso e ripetuto la serie:
| Con pubblicità | Senza pubblicità | |
|---|---|---|
| Punteggio performance | 60-96, bipolare | stabile 77/77 |
| Variazione FCP | 22% | 0,7% |
| TBT | variabile | 0 |
| Peso dello stack | 445-467 KB | |
La conclusione è stata brutale: per diversi giorni abbiamo ottimizzato il codice che era responsabile di una frazione del problema. La variabilità proveniva da script esterni, su cui non abbiamo controllo e che non possiamo rimuovere perché finanziano il sito.
Consiglio, il più importante di tutto l’articolo: prima di ottimizzare qualsiasi cosa, misura quanto del risultato proviene da te e quanto da script esterni. Fai una serie con i domini di terze parti bloccati. Se la differenza è grande, il tuo tetto reale è molto più basso di quanto pensi - ed è meglio saperlo prima di tre giorni di lavoro che dopo.
Due trappole degli strumenti in cui siamo incappati
Pingdom può mentire sulla compressione
Il report sosteneva che il server non comprimesse le risposte. Abbiamo verificato direttamente: il server invia br e zstd, e quando si richiede esplicitamente gzip, restituisce la home page in 71.306 byte invece di 289.394 non compressi. Lo strumento semplicemente non dichiarava il supporto per algoritmi più recenti. Anche gli header di scadenza erano a posto.
Pulire l’intera cache può rovinare l’aspetto
Il plugin puliva ad ogni pubblicazione l’intera cache insieme ai file CSS minificati. Nella finestra tra la cancellazione e la ricostruzione la pagina linkava a un foglio che non esisteva - e per un momento si visualizzava come HTML puro. Con una decina di articoli al giorno succedeva regolarmente.
Consiglio: dopo la pubblicazione di un articolo pulisci in modo mirato - solo l’articolo, la home page, le sue categorie e il feed RSS. Un nuovo articolo non cambia il contenuto del file CSS, quindi non c’è motivo di cancellarlo.
Lista di controllo se vuoi ripeterlo sul tuo sito
- Fai dieci misurazioni sulla pagina invariata. Registra la mediana e l’intervallo. Questo è il tuo rumore.
- Ripeti la serie con i domini esterni bloccati. La differenza è il tetto delle tue possibilità.
- Solo ora cambia una cosa alla volta e misura con una serie, non con un singolo test.
- Se gli intervalli prima e dopo si sovrappongono - annulla la modifica. Assenza di prova non è prova.
- Inizia rimuovendo, non minificando. Un file che non c’è è sempre il più veloce.
- Cerca i ricalcoli forzati del layout. Possono valere 70 ms per una riga di correzione.
Da dove vengono questi numeri
Tutti i valori provengono da 121 misurazioni Lighthouse in nove serie, eseguite su questo sito nei giorni 18-19 settembre 2026 su quattro tipi di pagine: home, articolo, recensione e negozio. Entrambe le ipotesi respinte sono state implementate in produzione, misurate e annullate. Questo non è un elenco di consigli altrui - è un report di ciò che ha funzionato e cosa no per noi.
More on this from NITIDO
magazine·Il modello rifiuta di leggere documenti: test su tre providerTest del contesto: zero risposte corrette. Non era un problema di memoria, ma content_filter per ogni documento oltre ~2000 token su AWS, API dirette e Google.