25 Apr Come Migliorare le Prestazioni di un Sito Web nel 2026: LCP, INP, CLS e Stack Tecnico
Velocità e SEO: il collegamento che molti ignorano
La velocità di un sito web non è un dettaglio tecnico per developer entusiasti — è un fattore di ranking diretto e un elemento che incide concretamente sul tasso di conversione. Il 53% degli utenti mobile abbandona una pagina che impiega più di tre secondi a caricarsi (Google/SOASTA Research, Think with Google). Ogni secondo di ritardo nel tempo di risposta è associato a un calo del 7% nelle conversioni (Akamai). Google ha incorporato i Core Web Vitals — LCP, INP e CLS — come segnali di ranking dal 2021, e li ha progressivamente resi più rilevanti nelle release successive degli algoritmi.
Il punto di partenza per migliorare le performance di un sito è misurare prima di intervenire. Google PageSpeed Insights, GTmetrix e WebPageTest forniscono dati reali sulle metriche attuali e indicano dove sono i colli di bottiglia. Lavorare senza questi dati è come sistemare un motore ad occhio: si può fare qualcosa, ma non si sa se si sta risolvendo il problema vero.
LCP: il caricamento che Google misura
L’LCP (Largest Contentful Paint) misura il tempo necessario per renderizzare l’elemento visivo più grande nella viewport — quasi sempre l’hero image o il titolo H1 principale. Il target di Google è sotto 2,5 secondi. Sopra i 4 secondi è considerato scarso. Le cause più comuni di un LCP alto su WordPress sono: immagine hero non ottimizzata (il caso più frequente), server lento con TTFB elevato, CSS o JavaScript render-blocking che ritardano il caricamento, e mancanza di preload delle risorse critiche.
La soluzione parte dall’immagine hero: formato WebP o AVIF, dimensione corrispondente al contenitore reale, attributo fetchpriority=”high”. Poi si agisce sul server: hosting con PHP 8.3, OPcache configurato correttamente, e caching a livello di pagina (WP Rocket o LiteSpeed Cache). Il preload delle font critiche nel tag head del documento elimina il flash di testo non stilizzato che contribuisce all’LCP percepito. Su siti WordPress con queste ottimizzazioni applicate sistematicamente si riesce quasi sempre a portare l’LCP sotto 2 secondi.
INP: la metrica che ha sostituito FID nel 2024
INP (Interaction to Next Paint) misura il tempo tra un’interazione dell’utente (clic, tap, pressione di tasto) e il momento in cui il browser mostra la risposta visiva. Ha sostituito FID come metrica Core Web Vitals nel marzo 2024. Il target è sotto 200 millisecondi. Valori sopra 500ms sono considerati scarsi.
Su WordPress, le cause più frequenti di un INP alto sono JavaScript eccessivo nel main thread. Plugin pesanti come certi builder di form, slider, chat widget e strumenti di marketing automation aggiungono listener di eventi che appesantiscono il thread principale. La strategia di remediation è identificare quali script contribuiscono di più con Chrome DevTools (tab Performance → Long Tasks) e intervenire: differire il caricamento degli script non critici con defer o async, caricare i widget di terze parti (chat, cookie banner, pixel di tracking) solo dopo l’interazione dell’utente tramite façade, e rimuovere JavaScript inutilizzato con Perfmatters o Asset CleanUp.
CLS: la stabilità visiva che frustra gli utenti
CLS (Cumulative Layout Shift) misura quanto il contenuto della pagina si sposta visivamente durante il caricamento. Un pulsante che si sposta un attimo prima che l’utente clicchi è un esempio classico. Il target è sotto 0,1. Le cause più comuni su WordPress: immagini senza attributi width e height dichiarati nell’HTML (il browser non sa quanto spazio riservare finché l’immagine non è caricata), font web che sostituiscono i fallback system font con dimensioni diverse, e annunci o widget che si caricano in ritardo e spingono giù il contenuto.
La correzione più impattante è aggiungere width e height a tutte le immagini nel HTML — anche se poi vengono ridimensionate via CSS. Questo dice al browser esattamente quanto spazio riservare prima che l’immagine sia scaricata, eliminando il layout shift. Su WordPress, i plugin di ottimizzazione immagini moderni come Imagify gestiscono questo automaticamente. Per i font, la property CSS font-display: swap riduce l’impatto del cambio tra font di sistema e font web caricato.
Hosting, CDN e caching: l’infrastruttura che determina il punto di partenza
Il TTFB (Time To First Byte) è il tempo che il server impiega a rispondere alla prima richiesta. Se il TTFB supera i 500 millisecondi, hai un problema di hosting o di configurazione server che nessuna ottimizzazione frontend risolverà completamente. Un hosting condiviso economico può avere TTFB di 1-2 secondi nei momenti di carico. Un hosting gestito di qualità come Kinsta o Serverplan con PHP 8.3 e OPcache configurato ha TTFB tipicamente sotto i 200 millisecondi.
Cloudflare come CDN è lo standard de facto nel 2026 per la distribuzione dei contenuti statici. Il piano gratuito di Cloudflare è sufficiente per la maggior parte dei siti: offre caching degli asset statici nei datacenter globali, compressione Brotli automatica, protezione DDoS di base e HTTPS. Le regole di Page Rules di Cloudflare permettono di configurare il caching in modo granulare: mettere in cache le pagine statiche, bypassare il cache per le pagine del carrello WooCommerce e per le sessioni autenticate, forzare HTTPS redirect. WP Rocket ha un’integrazione nativa con Cloudflare via API che sincronizza la pulizia del cache tra i due sistemi.
JavaScript e CSS: meno è meglio
Un WordPress medio con 20-30 plugin attivi carica spesso 30-50 file JavaScript e CSS separati. Ogni file è una richiesta HTTP con il suo overhead. La minificazione (rimozione di spazi e commenti) riduce il peso dei singoli file. La concatenazione (unione di più file in uno) riduce il numero di richieste. Entrambe le ottimizzazioni sono disponibili in WP Rocket, LiteSpeed Cache e Autoptimize.
L’ottimizzazione più impattante però è l’eliminazione: caricare solo gli script necessari su ogni pagina, non tutti i plugin su tutte le pagine. Perfmatters ha una funzionalità chiamata Script Manager che mostra per ogni URL del sito quali script vengono caricati e permette di disabilitarli selettivamente. Un plugin di galleria che carica il suo JavaScript sulla homepage quando le gallerie ci sono solo nelle pagine portfolio è un esempio classico di script inutile che rallenta il sito senza motivo.
Database e query: il collo di bottiglia invisibile
Su siti WordPress vecchi o con molto traffico, il database MySQL è spesso un collo di bottiglia silenzioso. Tabelle gonfe di revisioni dei post, opzioni transient scadute e log accumulati rallentano ogni query. WP Rocket e WP-Optimize includono funzionalità di database cleanup schedulato: rimozione delle revisioni post oltre un certo numero, pulizia dei transient scaduti, ottimizzazione delle tabelle del database.
Per siti con molto traffico o con WooCommerce, il caching degli oggetti con Redis o Memcached riduce drasticamente il numero di query al database. Invece di ricalcolare ogni query ad ogni richiesta, i risultati vengono memorizzati in memoria RAM e restituiti istantaneamente per le richieste successive. Kinsta e Cloudways supportano Redis nativamente. Su hosting condivisi è raramente disponibile, il che è uno dei motivi per cui le performance di WooCommerce su hosting economici degradano rapidamente al crescere del catalogo.