Come Superare i Core Web Vitals con Next.js (2026)

Meno della metà del web mobile supera la soglia di performance di Google. Nel 2025, solo il 48% delle origini mobili ha soddisfatto tutti e tre i Core Web Vitals, rispetto al 36% di due anni prima (HTTP Archive Web Almanac, 2025). Questo divario è un'opportunità. Se i tuoi concorrenti sono lenti, un sito Next.js veloce vince sia il posizionamento che la conversione. Il framework ti fornisce la maggior parte degli strumenti, ma una build predefinita fallisce ancora molti audit. Questa guida mostra esattamente come colmiamo questo divario.

Punti chiave

• Una pagina supera il test quando LCP è di 2,5s o meno, INP è di 200ms o meno e CLS è di 0,1 o meno, misurati al 75° percentile degli utenti reali (web.dev, 2025).
• Solo il 48% delle origini mobili ha superato tutti e tre i vitali nel 2025, e LCP è l'anello più debole con il 62% (Web Almanac, 2025).
• La velocità è denaro: un sito e-commerce che si carica in 1 secondo converte circa 2,5 volte meglio di uno che si carica in 4 secondi (Portent, 2022).
• Next.js vince sulle correzioni che contano di più: i componenti Image e Font, i Server Components e il lazy loading con dynamic().

Cosa sono i Core Web Vitals nel 2026?

I Core Web Vitals sono tre metriche che Google utilizza per valutare l'esperienza reale della pagina: caricamento, interattività e stabilità visiva. Un URL supera il test solo quando tutti e tre rientrano nella fascia "buona" al 75° percentile delle visualizzazioni di pagina (web.dev, 2025). Una metrica lenta fa fallire l'intera pagina, quindi non puoi scambiare un ottimo punteggio di layout con un caricamento lento.

Il cambiamento più grande riguarda l'interattività. Interaction to Next Paint (INP) ha sostituito First Input Delay il 12 marzo 2024 (web.dev, 2024). FID misurava solo il ritardo prima che il tuo primo tocco venisse registrato. INP misura la latenza completa di ogni interazione durante la visita, quindi riporta la peggiore. È un test molto più difficile, e il JavaScript pesante lato client è ciò che di solito lo rompe.

Ecco gli obiettivi a cui mirare. Qualsiasi cosa nella fascia intermedia è un avvertimento, e la fascia scarsa è un fallimento.

Le soglie del 2026

• LCP (caricamento): buono è 2,5s o meno, necessita di lavoro è da 2,5 a 4,0s, scarso è oltre 4,0s.
• INP (interattività): buono è 200ms o meno, necessita di lavoro è da 200 a 500ms, scarso è oltre 500ms.
• CLS (stabilità visiva): buono è 0,1 o meno, necessita di lavoro è da 0,1 a 0,25, scarso è oltre 0,25.

Perché i Core Web Vitals sono importanti per SEO e fatturato?

Sono importanti perché le pagine lente perdono denaro e posizionamenti allo stesso tempo. Portent ha misurato 5,6 milioni di sessioni e ha riscontrato che la conversione B2C è scesa dal 3,05% con un caricamento di 1 secondo allo 0,67% con 4 secondi, un calo di circa 0,3 punti per ogni secondo aggiunto (Portent, 2022). Dal lato SEO, Google conferma che buoni Core Web Vitals "si allineano con ciò che i nostri sistemi di ranking principali cercano di premiare" (Google Search Central, 2025).

L'effetto sul fatturato si moltiplica. Nello studio di Google e Deloitte su 37 marchi e 30 milioni di sessioni, un singolo miglioramento della velocità mobile di 0,1 secondi ha aumentato le conversioni al dettaglio dell'8,4% e il valore medio degli ordini del 9,2% (web.dev, 2020). Un decimo di secondo sembra banale finché non lo moltiplichi per un quarto del traffico.

Per uno sguardo più approfondito su come questo si lega alla ricerca, la nostra guida alla SEO tecnica per sviluppatori copre il lato dell'indicizzazione e del rendering. La velocità è uno dei pilastri di un sistema più ampio.

Quanti siti superano effettivamente i Core Web Vitals?

La maggior parte no, e il mobile è dove faticano di più. Il Web Almanac 2025 ha stimato il tasso di superamento complessivo al 48% su mobile e al 56% su desktop, con LCP la metrica più difficile con il 62% di buoni risultati su mobile contro il 77% per INP e l'81% per CLS (Web Almanac, 2025). L'INP su desktop è quasi risolto al 97%, ma i telefoni con CPU lente e reti instabili raccontano una storia diversa.

Il messaggio è strategico. Se LCP fallisce più spesso, la tua prima ora di ottimizzazione dovrebbe essere dedicata all'immagine hero e ai font, non alla micro-ottimizzazione di un gestore di pulsanti. Risolvi prima il problema più evidente.

Come risolviamo LCP in Next.js?

LCP fallisce quando l'elemento più grande, di solito un'immagine hero o un titolo, impiega troppo tempo a essere renderizzato. Poiché solo il 62% dei siti mobili lo supera, è qui che si trovano i maggiori guadagni (Web Almanac, 2025). Il componente Image di Next.js è la singola correzione più importante: serve formati moderni, genera dimensioni responsive e ti permette di contrassegnare l'hero in modo che si carichi per primo.

Imposta priority sull'unica immagine above the fold. Questo dice a Next.js di precaricarla invece di caricarla in lazy-loading, il che su un'immagine hero fa la differenza tra superare e fallire.

import Image from 'next/image';

export function Hero() {
  return (
    <Image
      src="/hero.webp"
      alt="Product dashboard"
      width={1200}
      height={630}
      priority
      sizes="(max-width: 768px) 100vw, 1200px"
    />
  );
}

I font sono la seconda trappola LCP. Un web font a caricamento tardivo blocca la visualizzazione del testo e può spostare il titolo. next/font ospita il file autonomamente al momento della build, rimuove la richiesta di rete a Google e applica font-display: swap per te.

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'], display: 'swap' });

export default function RootLayout({ children }) {
  return <html className={inter.className}><body>{children}</body></html>;
}

Infine, renderizza il contenuto above-the-fold sul server. I Server Components inviano HTML che il browser può visualizzare immediatamente, senza attesa di idratazione. Mantieni l'hero, il titolo e la copia principale come output renderizzato dal server e spingi l'interattività ai margini. Nelle nostre build, spostare un hero fuori da un componente client e aggiungere priority porta regolarmente l'LCP mobile sotto i 2,5s da solo.

Come risolviamo INP in Next.js?

INP fallisce quando JavaScript blocca il thread principale mentre un utente sta cercando di interagire. La soluzione è semplice da enunciare e più difficile da realizzare: spedire meno JavaScript. Ogni componente che mantieni sul server è codice che il browser non deve mai analizzare, e questo migliora direttamente la latenza di interazione (web.dev, 2024).

Carica in lazy-loading qualsiasi elemento pesante che non sia necessario per il primo rendering. Un widget di chat, un carosello, una mappa o un editor ricco dovrebbero caricarsi su richiesta con dynamic(), non nel bundle iniziale.

import dynamic from 'next/dynamic';

const CommentEditor = dynamic(() => import('./CommentEditor'), {
  ssr: false,
  loading: () => <div className="editor-skeleton" />,
});

Per gli aggiornamenti di stato costosi, dì a React che non sono urgenti. Avvolgere un aggiornamento di filtro o ricerca in useTransition mantiene l'input reattivo mentre la lista si ri-renderizza in background, il che è esattamente ciò che INP premia.

'use client';
import { useState, useTransition } from 'react';

export function Filter({ items }) {
  const [isPending, startTransition] = useTransition();
  const [query, setQuery] = useState('');

  return (
    <input
      onChange={(e) => {
        const value = e.target.value;
        startTransition(() => setQuery(value));
      }}
    />
  );
}

Ogni funzionalità interattiva deve essere inclusa nel bundle al caricamento? Quasi mai. Controlla i tuoi componenti client e di solito scoprirai che un terzo di essi può essere spostato sul server. Per un'analisi completa dell'architettura, il nostro servizio di sviluppo Next.js esiste proprio per questo tipo di refactoring.

Come risolviamo CLS in Next.js?

CLS fallisce quando gli elementi si muovono dopo essere stati renderizzati, e i colpevoli abituali sono immagini senza dimensioni, font a caricamento tardivo e banner iniettati. La regola è riservare spazio per tutto prima che arrivi. Quando passi width e height al componente Image di Next.js, esso genera una casella CSS con rapporto d'aspetto che mantiene stabile il layout prima che il file si carichi.

La stessa logica si applica agli embed e agli annunci. Avvolgi qualsiasi iframe di terze parti in un contenitore con un min-height fisso in modo che il contenuto sottostante non salti quando l'embed si idrata.

<div style={{ minHeight: 400, position: 'relative' }}>
  <Image src="/chart.webp" alt="Quarterly results" fill sizes="100vw" />
</div>

I font causano i sottili spostamenti. next/font riduce questo problema abbinando una metrica di fallback al tuo web font, in modo che il passaggio dal testo di sistema al font caricato si muova a malapena. In combinazione con le immagini dimensionate, questo è ciò che mantiene CLS comodamente sotto l'obiettivo di 0,1. CLS è il vitale più facile da superare una volta che si prende l'abitudine di "riservare lo spazio".

Come misuriamo e monitoriamo i risultati?

Gli strumenti di laboratorio mentono un po', quindi misura gli utenti reali. Lighthouse e PageSpeed Insights ti danno una lettura veloce in un ambiente controllato, ma Google si basa sui dati sul campo del Chrome User Experience Report, raccolti da visitatori reali di Chrome in 28 giorni. Il tasso di superamento mobile è aumentato ogni anno, dal 36% nel 2023 al 48% nel 2025, e l'asticella continua a salire (Web Almanac, 2025).

Per raccogliere i tuoi dati sul campo, l'hook useReportWebVitals trasmette ogni metrica dalle sessioni reali al tuo endpoint di analisi. Vercel Speed Insights lo incapsula per te, ma l'hook grezzo funziona ovunque.

'use client';
import { useReportWebVitals } from 'next/web-vitals';

export function WebVitals() {
  useReportWebVitals((metric) => {
    navigator.sendBeacon('/api/vitals', JSON.stringify(metric));
  });
  return null;
}

La nostra scoperta: i punteggi di laboratorio e sul campo divergono maggiormente su INP, perché Lighthouse funziona su una macchina veloce senza interazioni reali. Affidati al numero CrUX per INP e considera il punteggio di Lighthouse solo come un test di fumo.

Pronto a superare il tuo audit?

I Core Web Vitals premiano i siti che rispettano il tempo dell'utente, e Next.js è costruito per questo. Se il tuo stack attuale ti sta ostacolando, o desideri una build che si carichi velocemente per impostazione predefinita, noi progettiamo, costruiamo e ottimizziamo siti Next.js end-to-end. Consulta i nostri prezzi o contattaci per discutere i tuoi numeri.

Domande Frequenti

Quali sono le soglie dei Core Web Vitals nel 2026?

Una pagina supera il test quando LCP è di 2,5 secondi o meno, INP è di 200 millisecondi o meno e CLS è di 0,1 o meno. Google misura ogni metrica al 75° percentile delle visualizzazioni di pagina degli utenti reali (web.dev, 2025), quindi un pugno di caricamenti veloci non salverà una coda lenta.

Next.js supera automaticamente i Core Web Vitals?

No. Next.js ti fornisce i componenti Image e Font, i Server Components e lo streaming, ma una build predefinita può comunque fallire. Devi impostare la priority dell'immagine, riservare spazio per il layout e ridurre il JavaScript client. Il framework rimuove le parti difficili, non il lavoro.

Cosa ha sostituito First Input Delay?

Interaction to Next Paint ha sostituito First Input Delay il 12 marzo 2024 (web.dev, 2024). INP misura la latenza di ogni interazione durante una visita, non solo la prima, il che rende il JavaScript pesante molto più visibile nel punteggio.

I Core Web Vitals influenzano il ranking di Google?

Sì, come parte dei segnali di esperienza della pagina. Google afferma che buoni vitali si allineano con ciò che i suoi sistemi di ranking principali premiano (Google Search Central, 2025). L'effetto è più forte sulle query mobili competitive dove molti risultati sono altrimenti simili.

Quale Core Web Vital è il più difficile da superare su mobile?

Largest Contentful Paint. Solo il 62% delle origini mobili ha raggiunto un buon LCP nel 2025, contro il 77% per INP e l'81% per CLS (Web Almanac, 2025). Immagini hero lente e font che bloccano il rendering sono la causa abituale, ed è per questo che il componente Image è la prima soluzione.

Conclusione

Superare i Core Web Vitals non è fortuna, è una checklist. Risolvi LCP con il componente Image, priority e next/font. Risolvi INP spedendo meno JavaScript tramite Server Components e dynamic(). Risolvi CLS riservando spazio per ogni immagine ed embed. Quindi misura gli utenti reali con CrUX e l'hook useReportWebVitals, perché i dati sul campo sono ciò che Google valuta effettivamente. Metà del web mobile fallisce ancora questa soglia. Una build Next.js pulita è il modo per finire nella metà più veloce. Quando sei pronto per il lancio, le nostre ultime guide e il nostro team sono qui per aiutarti.