Core Web Vitals e PageSpeed: Guida Pillar Definitiva all'Ottimizzazione • Meteora Web Agency

Il tuo sito carica in 4 secondi? Allora stai perdendo il 30% dei visitatori prima ancora che vedano la homepage. Google lo sa, e dal 2021 misura ufficialmente la velocità con i Core Web Vitals. Noi, di Meteora Web, seguiamo aziende dal 2017: ogni millisecondo guadagnato sul tempo di caricamento si traduce in fatturato. In questa guida pillar ti portiamo dal problema – un sito lento e penalizzato – alla soluzione pratica: ottimizzare LCP, INP, CLS, interpretare Lighthouse e PageSpeed Insights, e intervenire su WordPress o su qualsiasi stack.

Capire i Core Web Vitals: cosa misurano e perché contano

I Core Web Vitals sono un insieme di metriche reali (basate sui dati degli utenti, non su test sintetici) che Google utilizza come segnale di ranking. Non sono opzionali. Se il tuo sito non li soddisfa, perdi posizioni in SERP e, peggio, perdi clienti. Le metriche attuali sono tre.

LCP – Largest Contentful Paint

Misura il tempo impiegato dall’elemento più grande (immagine, video, blocco di testo) a diventare visibile. Soglia: entro 2,5 secondi per essere “buono”. Oltre 4 secondi è “scarso”. L’LCP è spesso il collo di bottiglia principale: immagini massive, font lenti, server lento.

INP – Interaction to Next Paint

Sostituisce il vecchio FID (First Input Delay). Misura la reattività complessiva della pagina: quanto tempo passa dal primo click/tocco fino al successivo aggiornamento visivo. Soglia: sotto 200 millisecondi è buono. L’INP soffre quando il main thread è bloccato da JavaScript pesante o mal gestito.

CLS – Cumulative Layout Shift

Quantifica quanto la pagina “balla” durante il caricamento. Immagini senza dimensioni, annunci che appaiono all’improvviso, font che cambiano layout: tutto causa spostamenti. Soglia: CLS inferiore a 0,1. Per esperienza, risolvere il CLS è spesso il fix più veloce e a impatto immediato.

Perché conviene: migliorare i Core Web Vitals non è solo SEO – è esperienza utente. Un sito che carica in 1 secondo converte il doppio di uno che carica in 5. Noi lo vediamo tutti i giorni nei progetti che seguiamo.

Ottimizzare LCP: immagini, font e server response

Immagini: formati moderni e compressione

L’immagine più grande è spesso la causa principale di un LCP alto. Soluzioni concrete:

Formati moderni: WebP e AVIF. Converti tutte le immagini. Un cliente e-commerce aveva immagini da 2-3 MB: ottimizzandole in WebP abbiamo ridotto il peso del 60% senza perdita di qualità.
Compressione: usa strumenti come Squoosh, ShortPixel o il plugin Imagify per WordPress. Non serve una compressione al massimo – un livello 80% è quasi indistinguibile ma dimezza il peso.

Responsive con srcset: carica immagini dimensionate al viewport effettivo. Esempio:

<img src="foto-800.webp" srcset="foto-400.webp 400w, foto-800.webp 800w, foto-1200.webp 1200w" sizes="(max-width: 600px) 400px, 800px" alt="Descrizione">

Preload key image: se l'LCP è un'immagine hero, aggiungi un <link rel="preload" as="image" href="hero.webp"> nel <head>.

Font: font-display swap e preload

I font caricati da Google Fonts o da server esterni bloccano spesso il rendering. Regola d’oro: font-display: swap nella regola @font-face. Così il browser mostra il testo con un font di fallback e lo sostituisce appena caricato. Esempio:

@font-face {
  font-family: 'MiaFont';
  src: url('/fonts/miafont.woff2') format('woff2');
  font-display: swap;
}

Inoltre, preconnecta il dominio dei font: <link rel="preconnect" href="https://fonts.googleapis.com"> e <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>. Subsetting (scaricare solo i caratteri usati) riduce ulteriormente il peso.

Server: TTFB e caching

Il Time To First Byte (TTFB) deve essere sotto 200 ms per contribuire a un LCP buono. Come ridurlo:

CDN: Cloudflare, BunnyCDN, o il CDN del tuo hosting. Distribuisce i contenuti statici da server vicini all’utente.
Caching: attiva cache delle pagine (es. Redis, Varnish) e delle risorse statiche con header di cache lunghi.
Hosting performante: se sei su un server condiviso con 50 siti, il TTFB sarà alto. Noi spesso consigliamo VPS gestiti o hosting ottimizzati per WordPress come Kinsta, WP Engine o hosting italiani con server in Italia.

Ottimizzare INP: ridurre il blocco del main thread

L'INP misura la capacità della pagina di rispondere alle interazioni. Un main thread bloccato da JavaScript rende il sito lento al tatto.

JavaScript: ridurre il carico

Code splitting: carica solo il JS necessario alla prima interazione. Con webpack, Vite o Laravel Mix è automatico.
Defer e async: usa defer per script che non modificano il DOM critico; async per script indipendenti.
Lazy load dei widget: slider, popup, mappe – caricali dopo l’interazione.
Rimuovere JS non usato: Google Chrome DevTools mostra il “Coverage”: elimina CSS e JS non utilizzati.

Event handler ottimizzati

Non usare eventi JavaScript per animazioni CSS: lascia fare al browser con transition e animation. Per gestione di click, evita librerie pesanti: vanilla JS è spesso sufficiente.

Web Workers per task pesanti

Se devi elaborare dati o fare calcoli, spostali in un Web Worker. Il main thread resta libero per gestire il click dell’utente.

Ottimizzare CLS: layout shift zero

Attributi width/height per immagini e video

Questa è la fix più semplice e potente. Ogni <img> deve avere width e height specificati (anche via CSS). Esempio: <img src="foto.jpg" width="800" height="600" alt="...">. I moderni CSS aspect-ratio fanno lo stesso: aspect-ratio: 16/9.

Spazio riservato per annunci e embed

I banner pubblicitari che caricano in ritardo spostano il contenuto sottostante. Riserva uno spazio con min-height uguale alle dimensioni previste. Se l’annuncio non viene mostrato, lo spazio rimane vuoto.

Evitare inserimenti dinamici sopra il fold

Non aggiungere elementi sopra la piega dopo il caricamento iniziale (es. popup, cookie banner che appaiono con animazioni). Se necessario, falli apparire in sovrapposizione con position: fixed – non spostano il layout.

Lighthouse e PageSpeed Insights: come usarli

Interpretare il report

Lighthouse è uno strumento sintetico (esegue test da un server fisso). PageSpeed Insights (PSI) combina Lighthouse con i dati di campo (CrUX). Non fermarti al punteggio verde: guarda le sezioni “Opportunità” e “Diagnostica”. Ogni opportunità ha una stima di risparmio in secondi – priorizza quelle con impatto maggiore.

Differenze tra lab e field data

I dati di campo (CrUX) sono la verità: provengono dagli utenti reali. Se il lab test è 90/100 ma il CrUX mostra LCP > 4 secondi, hai un problema di rete o di caching che il sintetico non rileva. Noi confrontiamo sempre i due per capire dove intervenire.

Prioritizzare le fix

Prima: migliorare LCP (immagini, server, font)
Poi: ridurre il tempo di esecuzione JS (INP)
Infine: eliminare gli shift (CLS)

Lazy loading e criticità delle immagini

Native lazy loading vs Intersection Observer

Il loading="lazy" nativo è supportato da tutti i browser moderni. Non serve JavaScript. Esempio: <img src="foto.jpg" loading="lazy" alt="...">. Per supporto legacy (browser vecchi) puoi usare Intersection Observer come fallback. Importante: non mettere lazy loading sulle immagini above the fold – caricare immediatamente l’LCP è critico.

Effetto del lazy loading sulle metriche

Usare lazy loading su immagini sotto la piega riduce il peso totale e migliora LCP (perché il browser non scarica tutto subito). Ma se lo applichi anche alla hero image, blocchi l’LCP. Regola: no lazy loading per l’immagine principale.

Critical CSS e rendering path

Cos'è il Critical Rendering Path

Il percorso che il browser segue per mostrare la pagina: HTML → CSSOM → Render Tree → Paint. Ogni file CSS esterno blocca il rendering. Il Critical CSS consiste nell’inlineare il CSS necessario per la parte sopra la piega direttamente nel <head>, e caricare il resto in modo asincrono.

Estrarre e inlineare il CSS critico

Puoi usare strumenti come Critical (npm), o plugin per WordPress (WP Rocket, Autoptimize, Flying Pages). Noi preferiamo automatizzare con un build tool (es. Laravel Mix con plugin).

Strumenti e automazione

npm install critical
npx critical --base . --src index.html --dest css/critical.css --width 1300 --height 900

Poi lo includi inline: <style>...contenuto di critical.css...</style>. Il resto del CSS lo carichi con media="print" onload="this.media='all'".

Ottimizzare i web fonts

font-display: swap, optional, block

swap è la scelta migliore per performance: mostra subito il fallback. optional è ancora meglio: se il font non arriva in 100ms, lascia il fallback definitivo. block blocca il testo finché il font non carica – pessimo per LCP.

Preconnect e preload

Aggiungi nel <head>:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" href="/fonts/miafont.woff2" as="font" type="font/woff2" crossorigin>

Subsetting e formato woff2

Usa solo woff2 (migliore compressione). Subsetting: scarta i glifi non usati (es. solo caratteri latini). Google Fonts permette di specificare il subset: ?subset=latin,latin-ext. Noi spesso auto-hosting i font per eliminare chiamate esterne e avere controllo completo sulla cache.

Performance su WordPress: plugin e strategie

Gestiamo WordPress da quasi 10 anni. Ecco cosa funziona davvero.

Caching

Installa un plugin di caching completo: WP Rocket (premium), Flying Press, o WP Fastest Cache. Attiva page cache, object cache (se hai Redis), e minify HTML/CSS/JS.

Ottimizzazione immagini

Imagify, ShortPixel o WebP Express convertono automaticamente in WebP. Imposta la qualità tra 70-80% e attiva il lazy loading nativo.

Database

Usa WP-Optimize o Advanced Database Cleaner per rimuovere revisioni, spam, transients scaduti. Un database pulito riduce il tempo di query.

Plugins consigliati e da evitare

Consigliati: WP Rocket, Perfmatters, Asset CleanUp (per disabilitare script per pagina).
Da evitare: page builder pesanti (Elementor con molti widget può essere lento – ottimizza con caching specifico). Plugin di slider non ottimizzati.

Un consiglio da chi ha gestito sistemi ERP: ogni plugin è un costo in termini di performance. Valuta se serve davvero. Noi abbiamo visto siti con 50 plugin inutili – dopo averli ridotti a 15, il tempo di caricamento è calato del 40%.

In sintesi — cosa fare adesso

Testa il tuo sito con PageSpeed Insights. Prendi nota delle metriche campo (CrUX) e delle opportunità.
Risolvi l'LCP per primo: ottimizza l'immagine hero (WebP + preload + width/height), riduci TTFB, imposta font-display swap.
Riduci il JavaScript: elimina script inutili, differisci i restanti, lazy load widget.
Stabilizza il layout: aggiungi dimensioni a tutte le immagini, riserva spazio per annunci.
Automatizza il Critical CSS e carica i font in modo efficiente.
Se hai WordPress: installa un plugin di caching performante, ottimizza immagini e pulisci il database.

Ogni secondo recuperato è un cliente in più. Noi lo misuriamo ogni giorno. Se vuoi un audit tecnico su misura, ci trovi a Sciacca – ma lavoriamo con tutta Italia. Parti dai dati, fallo adesso.

Core Web Vitals e PageSpeed La Guida Pillar Definitiva per l'Ottimizzazione della Performance Web