Page Speed: ottimizzazione completa del caricamento

La Page Speed è uno degli investimenti con il maggiore impatto contemporaneamente su SEO e conversione. Amazon ha calcolato che ogni 100 ms di latenza aggiuntiva costano l'1% delle vendite. Google usa la velocità come fattore di posizionamento dal 2010 per il desktop, dal 2018 per il mobile e nel 2021 ha introdotto i Core Web Vitals come segnale diretto della Page Experience.

zoom_in

Cos’è la Page Speed e come si misura

La Page Speed non è un numero unico — è un insieme di metriche, ciascuna misura un aspetto diverso dell'esperienza di caricamento. Google PageSpeed Insights combina dati di laboratorio (Lighthouse) e dati sul campo di utenti reali (Chrome User Experience Report). Il punteggio finale da 0 a 100 è una somma ponderata di diverse metriche e non va usato come unico obiettivo di ottimizzazione.

Per la SEO contano i dati sul campo (CrUX): Google usa il 75° percentile degli utenti reali di Chrome quando valuta i Core Web Vitals. Lighthouse aiuta a diagnosticare i problemi, ma non è un input diretto dell'algoritmo di posizionamento.

Metriche chiave di velocità

Ogni metrica affronta un aspetto specifico dell'esperienza utente. Capirne le differenze è la base di una diagnosi corretta.

Diagnosi: da dove partire con l’ottimizzazione

Ottimizzare alla cieca è fatica sprecata. La sequenza corretta: misura prima, identifica il collo di bottiglia, correggi, misura di nuovo.

1. Apri PageSpeed Insights e testa 5–10 pagine chiave: home, categorie, schede prodotto, landing page. Guarda i dati sul campo, non solo il punteggio Lighthouse.
2. In Google Search Console vai su Core Web Vitals — mostra quali URL hanno valutazioni «Scarsa» o «Da migliorare» per LCP, INP e CLS con dati di utenti reali.
3. Esegui WebPageTest per l’analisi profonda: waterfall di caricamento, filmstrip, TTFB, impatto della CDN. Scegli la regione di test più vicina al tuo pubblico principale.
4. Usa Chrome DevTools → Performance → registra un caricamento della pagina. Il flame chart mostra quale script occupa il main thread e blocca il rendering.
5. Controlla Coverage (DevTools → Coverage): il CSS/JS non usato è un candidato diretto alla rimozione o al caricamento differito.

Server e ottimizzazione del TTFB

Il TTFB (Time to First Byte) è la fondazione di tutta la velocità. Se il server risponde lentamente, ogni ottimizzazione successiva lavora contro un tetto artificiale. Obiettivo: TTFB < 200 ms in ambienti con CDN, < 400 ms per i server dinamici.

Hosting e infrastruttura

Scelta dell’hosting

L'hosting condiviso, con risorse spartite tra migliaia di siti, limita fisicamente il TTFB. Un VPS o un server dedicato con Nginx/Caddy e caching adeguata porta il TTFB a 20–80 ms per i contenuti statici.

CDN (Content Delivery Network)

Cloudflare, BunnyCDN, Fastly — risponde il nodo edge più vicino invece del server di origine. Per contenuti statici o in cache il TTFB scende a 10–50 ms. Per i contenuti dinamici dipende dalla configurazione della cache edge.

HTTP/2 e HTTP/3 (QUIC)

HTTP/2 elimina l’head-of-line blocking e supporta il multiplexing. HTTP/3 su QUIC accelera ulteriormente l’apertura della connessione (0-RTT) ed è resiliente alla perdita di pacchetti sulle reti mobili.

Geolocalizzazione del server

La distanza fisica tra utente e server aggiunge ~1 ms ogni 100 km (andata e ritorno). Per un pubblico principalmente europeo, un server a Francoforte o Amsterdam è sensibilmente più veloce di US-East.

Compressione e codifica

• Attiva Brotli (br) — risparmia il 15–25% rispetto a gzip con velocità di decompressione comparabile. Supportato da tutti i browser moderni.
• Mantieni gzip come fallback per i client più vecchi. Minimo: livello di compressione 6.
• Configura la compressione per HTML, CSS, JS, JSON, XML, SVG. Le immagini e i file binari sono già compressi — applicarvi gzip non ottiene nulla.
• Usa l’header Vary: Accept-Encoding così la CDN memorizza in cache versioni separate per client diversi.

Caching lato server

Le pagine dinamiche (PHP, Node.js, Python) interrogano il database a ogni richiesta. Una cache permette di servire l’HTML pronto senza ricalcolarlo.

• Full-page cache: Nginx FastCGI Cache, Varnish, Redis — conserva l’HTML pronto e lo serve senza toccare l’applicazione.
• Object cache: Redis o Memcached per cachare i risultati delle query al database, le sessioni e i dati calcolati.
• Regole di invalidazione: la cache va svuotata quando il contenuto cambia (webhook del CMS, scadenza basata su TTL).
• Stale-while-revalidate: servi subito la cache non aggiornata e rigenerala in background — gli utenti non aspettano la rigenerazione.

Ottimizzazione degli asset: immagini, font, CSS

Immagini

Le immagini sono in genere la categoria più pesante del payload della pagina. Un'ottimizzazione corretta porta un risparmio di traffico del 30–70% e incide direttamente sull'LCP.

Usa l’elemento <picture> per servire il formato giusto: AVIF ai browser che lo supportano, WebP come fallback, JPEG/PNG per i browser legacy. Il componente Image di Next.js lo gestisce automaticamente.

Font

• Ospita i font in autonomia: servi i .woff2 dal tuo dominio — elimina la risoluzione DNS, l’handshake TCP e la dipendenza dalla CDN di Google Fonts.
• Preload dei font critici: <link rel="preload" as="font" type="font/woff2" crossorigin> nella <head> — il browser inizia a caricare prima che il CSS sia analizzato.
• font-display: swap — il browser mostra il font di sistema mentre quello personalizzato carica. Elimina il FOIT (testo invisibile).
• Subsetting dei font: carica solo i glifi necessari (latino + cirillico). Strumenti: glyphhanger o fonttools.
• Usa i variable font — un file invece di più pesi (regular, bold, italic). Risparmia il 30–50% del peso totale dei font.

CSS

Critical CSS inline

Gli stili above-the-fold vengono incorporati direttamente nella <head> dentro un tag <style> — il browser renderizza la prima schermata senza aspettare un file CSS esterno. Il resto del CSS carica in modo asincrono.

Minificazione

Rimozione di spazi, commenti e accorciamento delle proprietà. Cssnano o LightningCSS. Risparmio tipico: 10–30% della dimensione originale.

Rimozione del CSS inutilizzato

PurgeCSS, UnCSS o il meccanismo integrato del framework (Tailwind purge). Particolarmente importante con Bootstrap o Material UI — trascinano dentro migliaia di regole inutilizzate.

Evita @import nel CSS

Il @import nel CSS crea richieste sequenziali: il browser carica il file, scopre il @import e solo allora inizia a caricare il file successivo. Usa tag <link> per il caricamento parallelo.

JavaScript: render-blocking e main thread

JavaScript è il principale avversario della Page Speed sui siti moderni. Blocca il rendering, occupa il main thread e ritarda l'interattività. Obiettivo: JS minimo nel critical path, uso massimo di defer/async/dynamic import.

Strategie di caricamento

Bundle e code splitting

• Code splitting: dividi il JS in chunk — carica solo ciò che serve alla pagina corrente. In Next.js avviene automaticamente per pagina.
• Dynamic import: import('module') per i componenti non necessari al caricamento iniziale (modali, tab, filtri).
• Tree shaking: metti nel bundle solo il codice davvero usato. Webpack e Rollup lo fanno per i pacchetti ESM. Controlla: ci sono dipendenze CommonJS che rompono il tree shaking?
• Analisi dei bundle: bundlephobia.com per controllare le dimensioni dei pacchetti npm, @next/bundle-analyzer per Next.js — mostra esattamente cosa occupa spazio.
• Evita le librerie monolitiche grandi: moment.js (67 KB) → day.js (2 KB), lodash → singole utility, jQuery → JS nativo.

SPA e rendering lato server

Le SPA client-side (React senza SSR, Angular, Vue con CSR) restituiscono HTML vuoto e generano il contenuto nel browser. Il risultato è un LCP alto e un Time to Interactive scarso.

SSR (Server-Side Rendering)

L'HTML completo viene generato sul server. Il browser riceve subito il contenuto pronto. LCP, FCP e Lighthouse Score migliorano sensibilmente. Richiede l'idratazione lato client — considera il TTI (Time to Interactive).

SSG (Static Site Generation)

L'HTML viene generato al build. Massima velocità di TTFB e LCP. Adatto ai contenuti che cambiano raramente: blog, documentazione, landing page.

PPR (Partial Prerendering)

Novità di Next.js 15: shell statica della pagina con parti dinamiche in streaming. L' shell statica viene servita all'istante dalla CDN, mentre i dati dinamici arrivano in streaming appena pronti.

Caching: browser e CDN

Una cache configurata correttamente è l'ottimizzazione più economica e ad alto impatto per i visitatori di ritorno. Obiettivo: tutti gli asset statici in cache per 1 anno; HTML — cache minima o nessuna.

• Hash basato sul contenuto (fingerprinting): Webpack, Vite e Next.js aggiungono automaticamente un hash del contenuto ai nomi dei file. Quando il codice cambia — nuovo hash, la vecchia cache non viene più usata.
• ETag e Last-Modified: se il client ha già la risorsa, il server risponde 304 Not Modified senza corpo. Meno traffico, ma resta un round trip di rete.
• Service Worker: una cache programmabile nel browser. Abilita strategie complesse (Cache-First, Network-First, Stale-While-Revalidate) per le PWA e il supporto offline.
• CDN Cache-Control: usa s-maxage per controllare la cache della CDN indipendentemente dal max-age del browser. La CDN cacha più a lungo, il browser meno.

Script di terze parti: il principale colpevole nascosto

Gli script di terze parti (analytics, chat bot, pixel, A/B test, widget) sono spesso la causa principale di TBT e INP scarsi. La pagina commerciale media carica 15–30 script di terze parti.

FAQ