Ottimizzazione velocita sito
1 secondo in più di caricamento = 7% di conversioni perse. Google usa la velocità come fattore di ranking. Un sito lento costa doppio: perdi posizioni e perdi clienti.
Cosa sono i Core Web Vitals
Dal 2021 Google misura la velocità con tre metriche precise. Non basta avere un sito 'abbastanza veloce', bisogna superare le soglie di Google.
I Core Web Vitals sono le tre metriche che Google usa ufficialmente come fattore di ranking dal 2021:
LCP (Largest Contentful Paint), quanto ci mette a caricare l'elemento principale della pagina (spesso l'immagine hero o il titolo H1). Soglia "buono": entro 2,5 secondi. Sotto questa soglia, Google ti penalizza nel ranking.
CLS (Cumulative Layout Shift), quanto "salta" il contenuto della pagina mentre carica. Il layout shift succede quando immagini senza dimensioni definite o font che cambiano spostano i contenuti. È fastidioso per l'utente e penalizzato da Google. Soglia "buono": sotto 0,1.
INP (Interaction to Next Paint), quanto ci mette la pagina a rispondere all'interazione dell'utente (click, scroll). Misura la reattività percepita. Soglia "buono": sotto 200ms.
La maggior parte dei siti web italiani non supera queste soglie. Non perché siano mal costruiti, ma perché nessuno ha fatto un'ottimizzazione tecnica sistemática. Immagini non compresse, JavaScript di terze parti che blocca il rendering, CSS ridondante, nessuna strategia di caching: sono problemi comuni che si accumulano nel tempo. Combina l'ottimizzazione della velocità con sviluppo web solido e SEO tecnico per risultati completi.
Come ottimizziamo la velocità
Intervento tecnico sistematico, non patch superficiali.
Analisi tecnica completa
Misuriamo le performance reali con Google PageSpeed Insights, GTmetrix e WebPageTest. Analizziamo LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), FID/INP (interattività), TTFB (Time to First Byte), total blocking time. Identifichiamo i colli di bottiglia specifici, non tutti i siti sono lenti per le stesse ragioni.
Ottimizzazione immagini
Le immagini sono responsabili del 60-80% del peso delle pagine web. Convertiamo in formato WebP (30-35% più leggero di JPEG), implementiamo compressione adattiva, aggiungiamo lazy loading per immagini below-the-fold, definiamo dimensioni esplicite per eliminare il layout shift. Per siti con molte immagini, l'impatto è immediato.
Ottimizzazione CSS, JS e rendering
Minifichiamo e comprimiamo CSS e JavaScript. Eliminiamo CSS non utilizzato (spesso il 70-90% di framework come Bootstrap non viene usato). Spostiamo JS non critico in caricamento asincrono o differito. Implementiamo critical CSS inline per eliminare il render-blocking. Rimuoviamo plugin e script di terze parti inutili.
Server, caching e CDN
Configuriamo caching HTTP aggressivo per asset statici (immagini, CSS, JS: 1 anno). Abilitiamo compressione Gzip/Brotli sul server. Configuriamo headers di cache corretti. Per siti con traffico significativo o audience distribuita geograficamente, valutiamo l'adozione di una CDN per ridurre la latenza.
Risultati concreti e misurabili
Miglioramento del ranking Google, La velocità è un fattore di ranking diretto. Passare da "da migliorare" a "buono" nei Core Web Vitals sblocca posizionamenti che la penalizzazione stava frenando. Non è l'unico fattore SEO, ma è uno dei più controllabili tecnicamente.
Aumento del conversion rate, Siti più veloci convertono di più. Non è teorico: ogni secondo risparmiato nel caricamento riduce il bounce rate e aumenta le pagine per sessione. Su mobile, dove la connessione è più lenta e la pazienza più bassa, l'impatto è ancora maggiore.
Riduzione del costo Google Ads, Il Quality Score degli annunci Google dipende anche dalla velocità della landing page. Un sito più veloce ottiene Quality Score più alti, CPC più bassi, posizioni migliori con lo stesso budget. L'ottimizzazione della velocità si ripaga anche sui costi pubblicitari.
Esperienza utente misurabile, Bounce rate, tempo sul sito, pagine per sessione: tutte le metriche di engagement migliorano con un sito veloce. Gli utenti che non aspettano sono utenti che esplorano, che si fidano, che convertono.
Ottimizzazione velocità sito: Core Web Vitals, immagini e caching
LCP, CLS e INP: come misurare e correggere ogni Core Web Vital
I Core Web Vitals sono metriche di performance Google misurate in due modalità: dati "di campo" (esperienze reali degli utenti, raccolti da Chrome UX Report, visibili in Google Search Console) e dati "di laboratorio" (simulazione in PageSpeed Insights, utile per il debugging ma non quello che Google usa per il ranking). La differenza è importante: un sito può sembrare veloce nel laboratorio ma lento per gli utenti reali su connessioni mobili 4G in Italia. Come diagnosticare e correggere ciascun CWV: LCP (Largest Contentful Paint), come migliorarlo: il primo passo è identificare quale elemento è l'LCP (PageSpeed Insights lo mostra nella sezione "Opportunità"); solitamente è l'immagine hero, il background di un container, o un blocco di testo grande; per immagini: fetchpriority="high" nel tag <img> dell'LCP (istruzione al browser di caricarla con priorità massima), preload con <link rel="preload" as="image" href="hero.webp"> nell'<head>, formato WebP con dimensioni ottimizzate; per font: font-display: swap per evitare che il testo sia invisibile durante il caricamento del font. CLS (Cumulative Layout Shift), come eliminarlo: causa principale: immagini senza attributi width e height espliciti, quando il browser non conosce le dimensioni, non riserva lo spazio e il layout "salta" quando l'immagine carica; soluzione: aggiungere sempre width e height a ogni tag <img>; altra causa: web font che cambia le dimensioni del testo quando carica (font-display: swap con font dalle dimensioni molto diverse dal fallback), soluzione: size-adjust CSS per normalizzare le dimensioni; banner e notifiche che si inseriscono sopra il contenuto dopo il caricamento iniziale, soluzione: riservare lo spazio con min-height o usare posizionamento fixed/sticky. INP (Interaction to Next Paint), come ottimizzarlo: causa principale: JavaScript pesante che blocca il thread principale durante le interazioni; strumenti diagnostici: Chrome DevTools → Performance Tab → "Long Tasks" (task >50ms bloccano la responsività); soluzioni: code splitting (carica il JavaScript solo quando serve), web workers per operazioni computazionali pesanti, defer/async per script non critici.
Ottimizzazione immagini avanzata: WebP, AVIF, responsive images e lazy loading
L'ottimizzazione delle immagini è tipicamente la singola azione con il maggiore impatto sulla velocità del sito, le immagini rappresentano il 40-60% del peso totale di una pagina web media. Il processo di ottimizzazione completo a più livelli: (1) Scelta del formato corretto: WebP (supporto browser >95%), ideale per fotografie e immagini con sfumature (25-35% più leggero di JPEG a parità di qualità percepita), ideale per sostituire JPEG; AVIF (supporto >85%), ancora più efficiente di WebP (40-50% più leggero di JPEG) ma encoding più lento (non adatto per immagini generate dinamicamente); SVG, per illustrazioni, icone e grafici (infinitamente scalabile, peso minimo); tag <picture> con <source type="image/avif"> + <source type="image/webp"> + <img> JPEG come fallback garantisce compatibilità universale. (2) Compressione adattiva: l'obiettivo non è la massima compressione possibile ma il miglior rapporto qualità/peso per il contesto (immagine tiny hero vs. thumbnail in lista prodotti hanno esigenze diverse); strumenti: Squoosh (web tool gratuito), ImageMagick (automazione server-side), Cloudinary (CDN con ottimizzazione automatica su-the-fly). (3) Responsive images con srcset: il browser usa la densità di pixel del display e la larghezza della viewport per scegliere la dimensione immagine ottimale; <img srcset="img-400.webp 400w, img-800.webp 800w, img-1600.webp 1600w" sizes="(max-width: 768px) 100vw, 50vw" src="img-800.webp">, un utente mobile da 390px scarica img-400.webp invece di img-1600.webp; risparmio di peso: 60-75% su mobile. (4) Lazy loading: loading="lazy" su tutte le immagini below the fold, il browser le carica solo quando l'utente sta per vederle; attenzione: NON usare lazy loading sulle prime 2-3 immagini visibili above the fold (impatta negativamente il LCP). (5) CDN per asset statici: servire le immagini da un CDN globale (Cloudflare, CloudFront, Fastly) riduce la latenza del 30-60% per utenti geograficamente distanti dal server.
Caching, GZIP/Brotli e server response time: ottimizzazioni lato server
Le ottimizzazioni lato server per la velocità del sito impattano il Time to First Byte (TTFB), il tempo che passa tra la richiesta dell'utente e il primo byte di risposta del server; un TTFB >600ms è considerato "scarso" da Google, un TTFB <200ms è "buono". Le ottimizzazioni server-side fondamentali: (1) HTTP caching per asset statici: configurare header Cache-Control: public, max-age=31536000, immutable per tutti gli asset con hash nel nome file (CSS, JS, immagini con fingerprint); questo consente al browser di cachecare l'asset per 1 anno senza richieste al server; per HTML e risorse senza fingerprint: Cache-Control: public, max-age=300 (5 minuti) per bilanciare cache e freschezza. (2) Compressione Brotli e GZIP: Brotli (più efficiente di GZIP del 20-26% per testi e HTML) va abilitato nel server (nginx: brotli on; brotli_comp_level 6;); GZIP come fallback per browser che non supportano Brotli; impatto: file HTML e CSS compressi riducono il peso del 70-80%. (3) Page caching per siti WordPress: plugin come WP Rocket o W3 Total Cache generano versioni statiche HTML delle pagine dinamiche PHP; invece di rieseguire PHP + query MySQL per ogni visita, il server serve l'HTML pre-generato; riduzione del TTFB da 800-1500ms a 50-150ms. (4) Database query optimization: le pagine lente spesso sono rallentate da query SQL non ottimizzate (N+1 problem, query senza indici, join su tabelle grandi); strumenti diagnostici: slow query log di MySQL/PostgreSQL, query analyzer integrato in database admin; soluzione: aggiunta di indici sulle colonne più filtrate, caching delle query pesanti con Redis o Memcached, paginazione delle query sui dataset grandi. (5) Aggiornamento PHP: PHP 8.2-8.3 è il 40-50% più veloce di PHP 7.4 per applicazioni WordPress, un aggiornamento del runtime può migliorare il TTFB senza toccare il codice. INLOGICO effettua l'analisi del TTFB con WebPageTest prima e dopo ogni intervento server-side per misurare il delta. Vedi come questi interventi si integrano nel restyling sito web per una performance ottimale dal lancio.
FAQ di Ottimizzazione
Google ha soglie precise per i Core Web Vitals: LCP sotto 2,5 secondi (buono), CLS sotto 0,1, INP sotto 200ms. Superare queste soglie significa rientrare nel gruppo 'buono' e non essere penalizzati nel ranking. Sotto le soglie Google applica una penalizzazione progressiva, non ti esclude, ma ti abbassa.
I dati sono chiari: ogni secondo di ritardo nel caricamento riduce le conversioni del 7% (Amazon). Su mobile l'impatto è ancora maggiore: il 53% degli utenti abbandona una pagina che impiega più di 3 secondi. INLOGICO misura il conversion rate prima e dopo l'ottimizzazione, i dati parlano.
Dipende dal tipo di intervento. Alcune ottimizzazioni (immagini, configurazione server, caching, CDN) non richiedono modifiche al codice. Altre (eliminazione CSS/JS inutilizzato, critical CSS, lazy loading programmatico) richiedono intervento sullo sviluppo. INLOGICO opera direttamente sul codice, non abbiamo bisogno di intermediari.
Tutti i CMS hanno margini di ottimizzazione, anche significativi. WordPress con builder visuale (Elementor, Divi) è spesso il caso peggiore: plugin pesanti, CSS ridondante, JavaScript bloccante. Shopify è mediamente più veloce out-of-the-box ma ha limitazioni sulla personalizzazione del server. INLOGICO ha esperienza su tutti i principali CMS.
Il TTFB si misura con PageSpeed Insights, WebPageTest o GTmetrix: è il tempo tra la richiesta dell'utente e il primo byte di risposta del server. Google considera buono un TTFB sotto 800 ms, ottimale sotto 200 ms. Un valore alto indica server lento, caching assente o query database non ottimizzate. È il primo parametro da correggere prima di qualsiasi ottimizzazione frontend.
Parliamo di Ottimizzazione
Compila i dati e ti contatteremo entro 24 ore.
Iniziamo con Ottimizzazione
Un sito lento perde posizioni e clienti ogni giorno. Analizziamo le performance gratuitamente e ti diciamo cosa frena il tuo sito e come risolverlo.