CDN e LCP in WordPress: ottimizzazione automatica

I Core Web Vitals sono diventati metrica standard per misurare l'esperienza utente di un sito web. Google li usa nel ranking e gli utenti li percepiscono direttamente: una pagina lenta o che "salta" è una pagina che si abbandona. Per WordPress, dove il 60-80% del peso pagina è di solito immagini, l'ottimizzazione visuale è la leva più impattante.

In questa guida vediamo come misurare i Core Web Vitals e come ottimizzare immagini in modo serio: formati moderni, lazy loading, preload, plugin di compressione.

Le tre metriche

LCP: Largest Contentful Paint

Quanto tempo serve per mostrare l'elemento più grande visibile (di solito hero image o titolo). Target: < 2,5 s.

Cosa lo rallenta:

• Hero image pesante o non ottimizzata
• Hosting lento (TTFB alto)
• CSS render-blocking
• Web font che ritardano il rendering

CLS: Cumulative Layout Shift

Quanto la pagina "salta" durante il caricamento (immagini senza dimensioni, banner che spuntano, font che cambiano forma). Target: < 0,1.

Cosa lo causa:

• Immagini senza attributi width e height
• Pubblicità che si carica e sposta i contenuti
• Web font che cambiano dimensione testo
• Iframe (YouTube, mappe) senza dimensioni fisse

INP: Interaction to Next Paint

Tempo tra un click/tap e l'aggiornamento dello schermo. Ha sostituito FID nel 2024. Target: < 200 ms.

Cosa lo rallenta:

• JavaScript pesante che blocca il main thread
• Plugin con script lenti (slider, popup, chat)
• Tag manager con troppi script in cascata

Misurare i Core Web Vitals

Tre strumenti complementari:

1. PageSpeed Insights (pagespeed.web.dev): per pagina singola, dati real-user (CrUX) e lab.
2. Google Search Console (sezione "Esperienza" → "Core Web Vitals"): aggregato su tutto il sito, tendenze nel tempo.
3. Chrome DevTools Lighthouse: simulazione locale, utile per debug specifici.

PageSpeed mostra anche suggerimenti specifici (riduci dimensione immagini, elimina render-blocking, riduci il CSS non utilizzato). Affrontali in ordine di impatto stimato.

Ottimizzazione immagini: il flusso ideale

1. Carica originali ben dimensionati

Mai caricare un JPG da 4000px se la massima visualizzazione è 1600px. Ridimensiona prima del caricamento, o lascia che WordPress generi srcset automatico (lo fa di default per le dimensioni registrate dal tema).

2. Plugin di compressione + WebP/AVIF

I quattro più usati:

• ShortPixel: cloud, quote mensile gratuita poi a credito. Qualità eccellente.
• Imagify: cloud, da WP Rocket team. Tre livelli (normal, aggressive, ultra).
• Smush: cloud + locale. Versione gratuita ok, Pro per ottimizzazione massima.
• EWWW Image Optimizer: locale (gratis) o cloud (a pagamento). Storico.

Configurazione tipica:

• Compressione lossy (qualità 75-85%): impercettibile, dimezza il peso
• Generazione automatica WebP per ogni JPG/PNG (servito via <picture> o htaccess)
• Eventuale generazione AVIF (più recente, supportato dai plugin Pro)
• Bulk optimize iniziale per le immagini esistenti

3. Lazy loading

WordPress 5.5+ aggiunge loading="lazy" alle immagini automaticamente. I plugin di cache estendono a iframe e video.

Importante: la hero image della prima vista NON deve essere lazy-loaded. Aggiungi loading="eager" o (meglio) <link rel="preload"> per accelerare il LCP.

4. Preload del LCP

Nel <head>:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

Dice al browser di scaricare l'immagine LCP in priorità. Plugin come Perfmatters automatizzano. WP Rocket include funzione "Preload critical images".

5. Dimensioni esplicite

Ogni <img> deve avere width e height. WordPress lo fa automaticamente per immagini caricate via libreria, ma controlla per immagini inserite via HTML diretto o page builder. Senza dimensioni, CLS peggiora.

CSS, JS e font: l'altra metà del lavoro

Le immagini non bastano se altre risorse rallentano.

Eliminare render-blocking CSS

CSS critico inline nell'<head>, il resto caricato in modo asincrono. WP Rocket, LiteSpeed, Perfmatters automatizzano (modalità "Optimize CSS Delivery").

Defer JavaScript

Tutti i <script> non critici devono avere attributo defer o async. Gestito da plugin di cache.

Web font

Serve in formato woff2. Aggiungi:

<link rel="preload" href="font.woff2" as="font" crossorigin>

Usa font-display: swap per evitare che il testo resti invisibile durante caricamento.

Plugin di terze parti

Chat (Tawk.to, Intercom), tag manager pesanti, slider con animazioni complesse: ogni script aggiunto pesa su INP. Audita periodicamente: ogni plugin attivo serve davvero?

Hosting e CDN

L'hosting determina il TTFB (Time To First Byte). Sotto 600 ms è target. Hosting condivisi a basso costo difficilmente lo raggiungono. Hosting WordPress dedicati (SiteGround, Kinsta, WP Engine, Cloudways) hanno TTFB sotto 200 ms.

CDN (Cloudflare, BunnyCDN, KeyCDN) servono asset statici dal server più vicino. Cloudflare ha piano gratuito che basta per la maggior parte dei progetti.

Il CDN come leva sull'LCP

Un CDN non rende le immagini più leggere: le avvicina. Sul Largest Contentful Paint agisce su quattro fronti diversi, e conviene tenerli separati perché non si attivano tutti insieme e non dipendono dalle stesse impostazioni.

Il TTFB del documento. L'LCP non può cominciare prima che il browser abbia ricevuto l'HTML e capito qual è l'elemento più grande da disegnare. Se il CDN serve dalla cache al bordo anche le pagine, e non solo gli asset, il TTFB scende e tutta la catena che segue parte prima. Se invece il CDN è attivo solo su immagini, CSS e JavaScript, l'HTML continua a uscire dal server di origine e il TTFB resta quello dell'hosting.

La prossimità del nodo. Ogni richiesta verso un'origine lontana paga la latenza di rete più l'handshake TLS. Servita da un nodo nella stessa area geografica del visitatore, la stessa immagine arriva prima senza aver cambiato un solo byte. È il motivo per cui il guadagno si vede soprattutto sugli utenti distanti dall'origine e quasi per niente su chi naviga a pochi chilometri dal datacenter.

La cache dell'immagine al bordo. La prima richiesta su un nodo è un miss e viene inoltrata all'origine; dalla seconda in poi l'immagine è già lì. Chi misura una sola volta subito dopo l'attivazione sta misurando il caso peggiore. Vale la pena controllare l'header di cache della risposta (cf-cache-status, x-cache o equivalenti) prima di trarre conclusioni.

Il formato negoziato al volo. I CDN con trasformazione immagini leggono l'header Accept del browser e restituiscono AVIF o WebP a chi li supporta, JPEG agli altri, partendo sempre dallo stesso file caricato nella libreria media. Alcuni ridimensionano anche in base alla larghezza richiesta. Il vantaggio operativo è che la libreria resta pulita e non serve un bulk optimize.

Quando conviene e quando non cambia nulla

Un CDN sposta l'ago quando il pubblico è distribuito su più regioni o all'estero, quando l'origine sta lontano dai visitatori, quando le pagine sono ricche di immagini e quando l'hosting ha un TTFB alto per costruzione, come capita sui piani condivisi economici.

Non cambia quasi nulla, invece, in almeno quattro casi, e sono frequenti: il pubblico è tutto nella stessa area dell'origine, tipico di un'attività locale, e il TTFB è già sotto i 200 ms; l'elemento LCP è un blocco di testo e non un'immagine, quindi il collo di bottiglia sta nel CSS o nei font; l'immagine LCP è già leggera e servita in WebP; oppure il rendering è bloccato da un JavaScript di terze parti, che il CDN consegna più in fretta ma che continua a occupare il main thread per lo stesso tempo.

Il caso limite da ricordare è questo: un CDN non compensa una hero image da 2 MB. La consegna prima, e basta. L'ordine di lavoro corretto resta immagine ben dimensionata e compressa, poi distribuzione.

Come si misura la differenza prima e dopo

Senza un prima e un dopo presi nello stesso modo, l'effetto del CDN resta un'opinione. La sequenza che usiamo è questa.

1. Registra la baseline con PageSpeed Insights su 3-5 pagine, mobile e desktop, annotando non solo il valore di LCP ma anche le sue quattro componenti (tempo fino al primo byte, ritardo di scoperta della risorsa, tempo di download, ritardo di rendering). È lì che si vede quale parte il CDN può davvero toccare.
2. Aggiungi una misura da lontano con WebPageTest, scegliendo almeno due località diverse: una vicina all'origine e una nel mercato più distante che ti interessa.
3. Fotografa gli header dell'immagine LCP in DevTools, scheda Network: content-type, stato della cache e dimensione trasferita. Sono i tre numeri che cambieranno.
4. Attiva il CDN, svuota la cache del plugin e quella del CDN, poi ricarica due volte la pagina prima di misurare, così il nodo ha l'immagine in cache.
5. Ripeti le stesse misure a 24 o 48 ore di distanza, negli stessi orari, perché i dati di laboratorio oscillano e un singolo test non fa tendenza.
6. Guarda i dati di campo dopo qualche settimana, in Search Console alla sezione Core Web Vitals: sono aggregati su 28 giorni e sono gli unici che contano per il ranking.

Quanto si guadagni dipende da dove eri prima, da dove sono i tuoi visitatori e da quale delle quattro componenti dominava: può essere trascurabile su un sito locale già veloce e sensibile su un sito con pubblico distante e TTFB alto. Il senso della procedura è proprio smettere di indovinare.

Ottimizzazione automatica delle immagini: tre approcci a confronto

"Ottimizzazione automatica" indica tre cose tecnicamente diverse, che si somigliano solo nell'esito. Cambia dove avviene l'elaborazione, e da lì discende tutto il resto.

Tre differenze pratiche che la tabella non dice.

La libreria media. I primi due approcci riscrivono o affiancano i file dentro wp-content/uploads/, quindi lo spazio occupato cresce e i backup diventano più pesanti. Il terzo lascia l'originale intatto e produce le varianti solo in transito: se domani cambi idea sul formato, non devi rifare niente.

La reversibilità. La compressione lossy applicata ai file è definitiva, salvo tenere da parte gli originali (alcuni plugin lo fanno, ma occupa il doppio dello spazio). La trasformazione al bordo si spegne e si riaccende cambiando un'impostazione.

La dipendenza. Il file ottimizzato localmente resta tuo anche se cambi fornitore. Con la trasformazione al bordo, se disattivi il CDN torni a servire gli originali non ottimizzati: è una cosa da sapere prima, non da scoprire durante un disservizio.

Se devi decidere in fretta: parti dal report PageSpeed e guarda quale componente dell'LCP è la più grossa. Se è il tempo di download dell'immagine, il problema è il peso e si risolve con la compressione, locale o cloud che sia. Se è il tempo fino al primo byte o il ritardo di scoperta della risorsa, la compressione non ti darà granché e la leva giusta è la distribuzione. Poi misura di nuovo, come nella sequenza qui sopra.

Errori comuni

• Hero image con lazy loading: LCP peggiora di 1-2 secondi.
• Immagini sovradimensionate (4000px mostrate a 800px): srcset le seleziona, ma originali pesano sul server.
• Compressione troppo aggressiva (qualità 50%): immagini sgranate, esperienza peggiore della performance migliorata.
• Doppia compressione: 2 plugin attivi insieme corrompono immagini. Solo uno alla volta.
• WebP non servito ai browser che lo supportano: verifica con DevTools → Network che le richieste tornino con type image/webp.
• Iframe YouTube non lazy: aggiungono 300-500 KB di JS al primo caricamento. Plugin "WP YouTube Lyte" o lazy iframe risolvono.
• CSS critico generato a inizio progetto e mai aggiornato: dopo cambi al tema, il critical CSS è obsoleto e può rompere il rendering.

Roadmap pratica per migliorare

1. Misura baseline con PageSpeed Insights (mobile + desktop)
2. Installa plugin di compressione, esegui bulk optimize iniziale, attiva WebP
3. Verifica che la hero image abbia width, height e (idealmente) preload
4. Attiva plugin di cache con CSS optimization e JS defer
5. Pulisci plugin inutili (riduci INP)
6. Considera CDN se utenti distribuiti
7. Misura di nuovo, confronta, itera

In sintesi

I Core Web Vitals si migliorano con un set di interventi coerenti, non con una sola magic bullet. Le immagini sono di solito la leva con maggior impatto: WebP/AVIF + dimensioni corrette + lazy loading selettivo + preload del LCP portano già miglioramenti misurabili.

Quando ottimizziamo un sito esistente, partiamo dal report PageSpeed e affrontiamo i suggerimenti in ordine di impatto. La prima fase (immagini + cache) di solito porta da "Scarso" a "Buono" sui Core Web Vitals nel 70% dei casi. Il resto è lavoro di affinamento su CSS, JS e font.