Lento per Errore vs Lento per Scelta: Un Framework per le Web Performance

Lento per errore vs lento per scelta.

Quando mi assumi per sistemare o parlare dei Core Web Vitals, a un certo punto, mi sentirai parlare di lento per errore vs lento per scelta. Penso che sia una distinzione fondamentale da fare e in questo articolo ti spiegherò come questo ti aiuterà a migliorare i Core Web Vitals.

Ultima revisione di Arjen Karel a Marzo 2026

Quando qualcuno mi chiede una consulenza e di sistemare i Core Web Vitals c'è sempre qualcosa che non va. La lentezza deriva sempre da anti-pattern. Ad esempio un'immagine 'Largest Contentful Paint in lazy loading', 'Immagini grandi e non ottimizzate', 'Slider', 'JavaScript bloccante' e così via.

Non ci vuole molto per introdurre un anti-pattern. A volte tutto ciò che devi fare per creare un anti-pattern è installare un plugin o dimenticare le best practice per un breve periodo.

Ora mi piace classificare questi anti-pattern in 'lento per errore' e 'lento per scelta' perché il modo in cui procedo per risolverli è completamente opposto.

Solo il 48% delle origini mobile supera tutti e tre i Core Web Vitals secondo il 2025 Web Almanac. Nella mia esperienza, la maggior parte di questi fallimenti deriva da problemi 'lenti per errore' che possono essere risolti in poche ore.

Lento per errore

Adoro gli anti-pattern 'lenti per errore'. Hai fatto qualcosa che ha rallentato la pagina. Hai commesso un errore. Non sapevi che c'è un modo molto più veloce per farlo. Non preoccuparti, posso correggere gli errori.

Quindi classificare questi 'errori' ha senso. Mi darà un elenco di miglioramenti ad alto impatto e facili da risolvere che posso inviare al tuo devteam (o risolvere io stesso). Di solito c'è bisogno di pochissima discussione. Migliorare questi anti-pattern ha semplicemente senso da tutti i punti di vista. Una volta che sono stati risolti, i Core Web Vitals miglioreranno.

Ecco alcuni esempi di anti-pattern in cui mi imbatto quotidianamente. Quando spiego cosa e perché di solito ottengo 'ohh, non sapevo che questo avrebbe rallentato la pagina'.

1. Immagini non lazy

L'anti-pattern più comune sono le immagini non in lazy loading. Le immagini che non vengono caricate in modalità lazy verranno messe in coda per il download durante le prime fasi del caricamento della pagina. Questo utilizzerà risorse di rete e CPU. Non ha senso assegnare risorse preziose a immagini che non sono nemmeno visibili giusto? Scopri di più su come posticipare le immagini fuori schermo.

L'errore opposto è altrettanto comune: caricare in lazy loading l'immagine LCP. Circa il 15% dei siti lo fa, e questo rende il caricamento dell'immagine più importante sulla pagina più lento invece che più veloce.

2. Font di terze parti

I web-font sono fantastici. Personalizzeranno e miglioreranno l'aspetto della pagina. Sfortunatamente, l'utilizzo di un fornitore di terze parti come Google Fonts non ottimizzerà i font per la tua situazione specifica.

I font di terze parti richiederanno un foglio di stile aggiuntivo che blocca il rendering, una nuova connessione a un server web (mentre hai già questa connessione davvero veloce al tuo server di origine) e probabilmente aggiungeranno più font al browser di quelli che usi effettivamente.

Avrebbe più senso ospitare i tuoi font localmente, precaricarli e assegnare una strategia di caricamento dei font personalizzata a ciascun file di font. Ecco un'altra vittoria rapida proprio lì!

3. Script di terze parti

Anche se non c'è nulla di sbagliato negli script di terze parti, causano molti problemi a causa del modo in cui vengono aggiunti alle pagine. Mi imbatto in script di terze parti non importanti (come i pixel di tracciamento di Facebook, i pulsanti dei social media, i widget di valutazione ecc.) che in realtà bloccano l'intera pagina.

È relativamente facile e ha senso posticipare e programmare questi script fino a quando il browser non ha svolto il lavoro più importante. Alla fine non ho cambiato nulla di critico per il sito, sembra ancora lo stesso e si carica molto più velocemente. Ho solo cambiato l'ordine in cui vengono fatte le cose.

4. Immagini di sfondo

Dal punto di vista dei Core Web Vitals le immagini di sfondo hanno poco senso. Le immagini di sfondo non hanno supporto nativo per il lazy loading, non sono responsive e hai poco controllo sul loro timing e priorità.

Con poche e semplici correzioni possiamo trasformare queste immagini di sfondo in immagini normali che possiamo caricare in modalità lazy, rendere responsive e regolarne la priorità. Questo sicuramente migliorerà il Largest Contentful Paint.

5. Fogli di stile di grandi dimensioni

I fogli di stile bloccano il rendering. Ciò significa che mentre il browser sta caricando i fogli di stile, la pagina rimarrà vuota. Ci sono molte cose che puoi fare per risolvere questo problema. Ad esempio, rimuovere gli stili inutilizzati, suddividere il foglio di stile, migliorare il caching del browser o aggiungere Critical CSS.

Una volta migliorati i fogli di stile, i tuoi Largest Contentful Paint e First Contentful Paint miglioreranno drasticamente!

Lento per scelta

Il lento per scelta è la parte di cui dovresti preoccuparti. Hai fatto scelte strutturali che hanno rallentato la pagina. Di solito comportano scelte di progettazione dell'UX o codice JavaScript che modifica la parte visibile della pagina a tal punto che non ci sono buoni workaround.

Il problema del 'lento per scelta' è che non è immediatamente risolvibile apportando piccole modifiche. Richiede più pianificazione e la riscrittura di alcune funzionalità principali del sito.

La prima cosa che devo fare è capire l'intenzione: Perché hai fatto questo? Quali sono state le considerazioni e cosa intendevi esattamente ottenere? E poi, all'interno di quei parametri, trovare un'alternativa migliore!

Ecco alcuni esempi degli errori 'lenti per scelta' più comuni.

1. Slider

Di solito gli slider funzionano così: quando la pagina esegue il rendering, un JavaScript inietterà lo slider nella pagina. Senza questo JavaScript la pagina sembrerà completamente diversa. Ciò causerà un Largest Contentful Paint più lungo, probabilmente un Layout Shift e molto probabilmente problemi con l'Interaction to Next Paint (INP).

Non c'è una soluzione rapida. Posticipare il JavaScript migliorerà le metriche di paint ma ritarderà lo slider e causerà un Layout Shift. Rendere critico lo script dello slider risolverà il Layout Shift ma rallenterà le metriche di paint.

La soluzione è migliorare progressivamente la pagina. Assicurati prima che lo slider venga renderizzato senza JavaScript e poi migliora la pagina e trasforma l'immagine dello slider già presente in un vero e proprio slider.

La cosa divertente è: solo circa l'1% dei visitatori fa effettivamente clic su uno slider. 9 volte su 10 quando spiego questo, il proprietario del sito suggerisce immediatamente di rimuovere lo slider. Ecco perché è importante chiedere quali siano le intenzioni e le considerazioni di questi slider. Di solito 'erano semplicemente lì'.

2. Zoom del prodotto

Lo zoom del prodotto funziona così: nel tuo webshop medio passi il mouse sopra l'immagine di un prodotto e puoi ingrandire una parte del prodotto. I 'zoom del prodotto' di solito hanno lo stesso problema degli slider. Un pezzo di codice JavaScript prenderà le tue immagini, le nasconderà e poi le riscriverà sulla pagina come immagini ingrandibili. Questo causerà un Largest Contentful Paint più lungo, probabilmente un Layout Shift e molto probabilmente problemi con l'Interaction to Next Paint (INP).

La differenza rispetto allo slider è che nessun product owner dirà mai: "oh, basta rimuovere questa funzionalità". È importante e aumenta le conversioni.

La soluzione è la stessa della correzione dello slider. Lo script di zoom non dovrebbe nascondere le immagini originali ma estendere la funzionalità dell'immagine del prodotto. Sfortunatamente, la funzionalità di zoom di solito non si risolve facilmente e richiederà un po' di lavoro per renderla perfetta.

3. jQuery inline / dipendenze JavaScript inline

Il jQuery inline è un problema che è iniziato come un 'lento per errore' ma è peggiorato nel tempo. Circa il 50% dei siti che guardo soffre di questo problema. jQuery viene ancora eseguito su circa il 70% di tutti i siti web secondo W3Techs, quindi questo non sparirà a breve. Poiché gli script inline dipendono da uno script precedente (di solito jQuery) non puoi più posticipare jQuery. Questo ritarderà tutte le metriche di paint.

La soluzione è semplice: basta spostare questi script su uno script esterno. Ora puoi posticipare sia jQuery che lo script personalizzato.

Allora perché l'ho inserito nella categoria 'lento per scelta'? Quando chiedo di intenti e considerazioni, di solito ottengo un 'oh, non lo so'. Ed è questo il vero problema. C'è una mancanza di conoscenza su come funziona JavaScript. Posso essere abbastanza certo che questo errore verrà ripetuto in futuro. Ciò significa che la soluzione non è la stessa della correzione. Dovrò formare il devteam sulle dipendenze e i tempi di JavaScript.

4. Immagini di grandi dimensioni (hero)

Un altro problema di 'lento per scelta' sono le immagini di grandi dimensioni. Alcuni siti hanno solo bisogno di 'stupire il pubblico' con un sacco di immagini a grandezza naturale. Immagina di vendere poster. Probabilmente vorrai servire immagini grandi e di alta qualità ai tuoi visitatori. Queste immagini, non importa quanto le ottimizzi, richiederanno sempre più tempo per essere scaricate rispetto ad immagini più piccole.

A questo punto (supponendo che le immagini siano tutte ottimizzate) l'unica cosa che posso fare è vedere se c'è un po' di margine di manovra. Abbiamo davvero bisogno di immagini 4k o basterebbe anche il full-hd? Guarda come correggere le immagini hero lente per tecniche pratiche.

5. Mappe interattive

Un altro problema che incontro di frequente sono le mappe interattive. Quando una pagina ha una mappa interattiva, l'intera intenzione di questa pagina è far interagire il visitatore con la mappa. Ovviamente ci vorrà del tempo prima che quella mappa si carichi.

Non c'è modo di aggirare questo problema. Dovremo accettare una certa lentezza. Ma ci sono cose che possiamo fare. Possiamo assicurarci che le mappe vengano caricate con la massima priorità. Di solito queste pagine non sono ottimizzate per l'esecuzione anticipata di JavaScript. In questo caso è stata la scelta sbagliata. Abbiamo bisogno che lo script venga scaricato ed eseguito il prima possibile! Ho scritto una guida completa su come incorporare Google Maps senza perdere PageSpeed.

6. API lente

I problemi lenti per scelta derivanti da API lente si trovano di solito nei siti SPA come React, Next.js o Angular. Le API lente di solito causano grandi Layout Shift perché i componenti vengono renderizzati troppo in ritardo rispetto all'interazione dell'utente. Problemi come questo di solito richiedono un approccio multi-team.

Può essere utile distinguere tra lento per errore e lento per scelta quando si tratta di Core Web Vitals. I lenti per errore sono solitamente risolti facilmente mentre i lenti per scelta richiedono un approccio multidimensionale più accurato. Una volta classificati e risolti i problemi 'lenti per errore', configura il Real User Monitoring per monitorare l'impatto. I dati sul campo ti dicono se le tue correzioni hanno effettivamente migliorato l'esperienza (UX) per i visitatori reali. I problemi 'lenti per scelta' spiccheranno quindi chiaramente nei tuoi dati perché sono ciò che rimane.