Il sito bello che Google non perdona: Core Web Vitals e il problema nato in Figma (non nel server)

Martedì mattina, fine settembre 2025. Sono seduto a uno dei tavolini all'aperto del Gran Caffè Garibaldi, all'angolo dove il Corso Garibaldi incontra Piazza Bovio. Dall'altro lato della strada, la facciata del Teatro Garibaldi, domina la piazza su cui affaccia lo storico Liceo Classico Nevio con la sua terrazza a semicerchio e le finestre ad arco — una di quelle architetture di Santa Maria Capua Vetere che sembrano lì apposta per ricordare che certe strutture reggono i secoli, mentre altre cedono alla prima pioggia. L'aria di fine settembre ha ancora quel calore ostinato che si incolla alla camicia. Il Corso scorre sonnolento oltre il bordo della tenda.

Berto è seduto dall'altra parte del tavolino. Me lo ha presentato Luigi, un cliente storico nell'edilizia con cui lavoro da quasi un decennio — "Umberto, ti mando un amico, sei la persona giusta per lui." Il tipo di telefonata che in Campania vale più di qualsiasi contratto firmato e notarizzato. Berto gestisce una storica azienda di arredamento su misura della zona, uno di quegli imprenditori con le mani segnate dal lavoro e una diffidenza ancestrale verso tutto ciò che passa dentro uno schermo, specie dopo che nel 2012 un finto consulente gli ha spillato dei soldi per una campagna pubblicitaria mai partita. Non è agitato. Berto non si agita mai apertamente. Ha però quella luce fissa negli occhi di chi ha scoperto un ingranaggio inceppato e vuole capire quale pezzo deve cambiare.

Posa il telefono sul tavolino, facendolo scivolare verso di me girato al contrario. "Umberto, guarda questo. È un ragazzo di Maddaloni, fa corsi di cucina online dal suo scantinato. Se cerco 'corso cucina Caserta' lui esce sempre primo. Sempre. Io ho rifatto il sito tre mesi fa. L'ho pagato 3.800 euro a uno studio grafico strutturato. È bello, pulito, ha le foto dei divani in alta risoluzione che sembrano uscire da una rivista di design milanese. Eppure se cerco 'arredamento Caserta' dal telefono, non mi trovo neanche alla terza pagina di Google. Mi hanno truffato un'altra volta?"

Rispondo senza girarci intorno: non è colpa dei testi, non è colpa della strategia SEO e nessuno ti ha fregato intenzionalmente. Il problema è che il tuo bellissimo sito impiega 5,8 secondi per mostrare l'immagine principale da uno smartphone, e l'intera pagina salta tre volte verso il basso mentre i font cercano di caricarsi. Google ha visto questa tortura digitale. Google ha misurato l'esperienza dell'utente. E Google ti ha semplicemente cancellato dalle sue mappe.

La settimana prima ero a Londra, zona Clerkenwell, per un incontro con Bobby — un cliente acquisito sei mesi prima per la gestione dei social e della comunicazione digitale della sua boutique agency di eventi aziendali tra Shoreditch e Southwark. Lavoro ben fatto, numeri in crescita: Bobby è uno di quei britannici che non ti ringraziano finché non vedono i dati muoversi davvero, ma quando succede ti affidano anche il resto. "Since you're handling the communication side already, might as well look at the website too." Eccolo il sito: animazioni in apertura curatissime, scritte che fluttuano, immagini vettoriali che si compongono seguendo lo scroll, una menzione su Awwwards nel mese del lancio. Un trionfo visivo che non aveva prodotto una singola richiesta di preventivo in novanta giorni. PageSpeed Insights: 28 su 100. Il modulo contatti: silenzioso come una domenica mattina a Southwark.

Qui si consuma il grande malinteso della comunicazione digitale contemporanea. I Core Web Vitals non sono un noioso elenco di parametri tecnici da scaricare sui programmatori all'ultimo minuto. Le performance di un sito nascono molto prima del server: nascono nel wireframe, nella scelta di quella specifica hero image, nella decisione di usare quattro varianti di un font personalizzato, nell'animazione pesante che il designer ha inserito su Figma solo perché "faceva atmosfera". Se progetti interfacce visive e non sai cosa misurino sigle come LCP, INP e CLS, stai confezionando un abito d'alta moda con tessuti che si dissolvono alla prima pioggia. Stai consegnando al tuo cliente una vetrina splendida che Google nasconderà in un vicolo cieco.

Questo pezzo non è scritto per chi scrive codice. È per chi progetta l'esperienza visiva.

Il contratto invisibile tra design e visibilità

Esiste una filiera silenziosa del fallimento che si ripete identica da Napoli a Londra, senza distinzione di fuso orario o di budget. Tutto comincia con un brief ambizioso: il cliente vuole stupire, vuole un'identità digitale che si distingua dalla massa grigia dei concorrenti. Il designer apre Figma e fa quello che sa fare meglio: crea bellezza. Inserisce transizioni fluide, immagini a schermo intero senza compromessi di risoluzione, elementi grafici che si intersecano in modo spettacolare. Il file viene approvato con entusiasmo. Passa poi sul tavolo del developer, il quale si ritrova a implementare quei sogni visivi in codice HTML, CSS e JavaScript. Il sito viene pubblicato. Il cliente è felice. Tutti sorridono, tranne uno: il crawler di Google.

Il motore di ricerca non si emoziona per un accostamento cromatico indovinato o per una transizione fluida su un monitor da trenta pollici a Shoreditch. Google apre il sito simulando un utente medio connesso da una rete mobile non ottimale, con un dispositivo di fascia media. Misura i tempi di risposta reali, calcola lo stress del processore del telefono e, se i numeri non tornano, penalizza l'indicizzazione in modo silenzioso, definitivo, inappellabile.

I dati dell'HTTP Archive Web Almanac 2025 mostrano che appena il 48% delle pagine su dispositivi mobile e il 56% su desktop supera con successo tutti e tre i Core Web Vitals. Più della metà dei siti web cammina con il freno a mano tirato, regalando una prateria di posizionamento organico a quegli imprenditori che hanno deciso di trattare le performance come un elemento di design primario.

Per capire quanto sia profondo questo pattern, basta spostare lo sguardo oltremanica. Un'analisi settoriale dell'agenzia britannica Warbox Creative ha evidenziato come i brand di moda nel Regno Unito registrino le peggiori performance web tra quattordici segmenti di mercato presi in esame — nonostante più di un terzo dei consumatori britannici effettui la maggioranza dei propri acquisti di abbigliamento online. Le aziende investono milioni di sterline in produzioni fotografiche straordinarie e design di interfaccia curati dai migliori studi di City Road o Hackney. Eppure si ritrovano in mano piattaforme che frustrano l'utente al primo click, perdendo quote verticali di traffico organico. L'estetica fine a se stessa, priva di cultura tecnica, produce solo splendidi deserti digitali.

Perché il problema nasce in Figma, non nel server

Quando un sito fallisce i test di velocità, la reazione istintiva è prendersela con l'hosting. Si dà la colpa al server lento, al database mal configurato. Nella stragrande maggioranza dei casi reali che monitoro, questa è una diagnosi sbagliata. La radice del problema affonda nei primi stadi della progettazione visiva.

Se il designer prevede una sezione hero con un video cinematografico in loop senza alternativa leggera, sta caricando sul groppone dell'utente dai 5 ai 10 megabyte di dati prima ancora che lo stesso possa leggere una singola riga di testo. Se inserisce micro-animazioni continue per ogni elemento che appare sullo schermo, obbliga il browser a usare continuamente il main thread — il filo logico principale del processore — per calcolare le nuove posizioni grafiche.

Mi ricorda sempre il falegname che aveva la bottega sul corso principale di Portici, a due passi dal museo di Pietrarsa. Costruiva scaffali bellissimi, intarsiati a mano, finiture lucide spettacolari. Un cliente gli commissionò una libreria da studio giuridico — l'artigiano la realizzò senza chiedere quanti faldoni e quanti codici di diritto avrebbe dovuto sostenere. Il problema non emerse quando la libreria venne montata, liscia e perfetta. Emerse tre settimane dopo, quando il cliente ci appoggiò l'intera enciclopedia giuridica e i montanti centrali iniziarono a imbarcarsi, spaccando le cerniere. Smontare, rinforzare e riparare costò il doppio rispetto a un calcolo strutturale fatto all'inizio. Nel web design accade esattamente lo stesso.

LCP, INP, CLS: tre sigle che determinano se esisti su Google

Voglio smontare il gergo tecnico e tradurre questi parametri in dinamiche umane e concrete. Tre pilastri: la velocità con cui le cose appaiono sullo schermo, la prontezza del sito nel rispondere ai comandi dell'utente, la stabilità visiva degli elementi grafici. Li spiego come li spiegherei a Berto davanti a quel caffè a Santa Maria Capua Vetere — senza perdere un briciolo della precisione che l'algoritmo richiede.

LCP — Largest Contentful Paint: il piatto che arriva in ritardo

L'LCP misura il tempo necessario perché l'elemento principale visibile sopra la linea di piega della pagina — la porzione di schermo visibile senza scorrere verso il basso — venga renderizzato completamente. Nella maggior parte dei layout moderni coincide con l'immagine hero, il titolo principale o il video di sfondo.

Le scelte estetiche che distruggono l'LCP sono prevedibili: immagini hero esportate in JPEG nativo ad alta risoluzione senza compressione (4-8 megabyte per file non è inusuale), font di terze parti caricati con @import nel CSS principale — un metodo che blocca la visualizzazione di qualsiasi testo finché l'intero foglio di stile non è scaricato.

Un caso reale documentato dalla piattaforma ufficiale di Google, web.dev, mostra come il team di Vodafone Italia sia riuscito a migliorare le performance del proprio portale riducendo l'LCP del 31%. Non hanno cambiato i server: hanno implementato Server Side Rendering per l'HTML critico, eliminato il JavaScript non necessario che bloccava il caricamento e ottimizzato i formati delle immagini di prodotto. Risultato diretto e misurabile: +8% sulle vendite dello store online. La velocità non è un vezzo tecnico. È una metrica di business.

Ricordo sempre un ristorante di Napoli nel 2024 — un locale splendido, primo su TripAdvisor, clientela consolidata. Sito commissionato a professionisti, fotografie dei piatti a pieno schermo da 6 megapixel l'una, Playfair Display importato da Google Fonts senza ottimizzazione. Lighthouse: LCP a 7,2 secondi su rete mobile, punteggio PageSpeed 23 su 100. Per chiunque cercasse dove cenare a Napoli senza digitare il nome esatto del locale, quel ristorante era semplicemente invisibile.

INP — Interaction to Next Paint: il cameriere che non risponde

A marzo 2024, Google ha mandato definitivamente in pensione la vecchia metrica FID, sostituendola con l'INP. Non un semplice aggiornamento nominale: una rivoluzione nel modo in cui l'algoritmo valuta l'interattività. Mentre il FID misurava solo il ritardo della primissima interazione, l'INP monitora la reattività di tutti i click, i tap e le pressioni dei tasti durante l'intera sessione. Le release notes ufficiali del Chrome User Experience Report mostrano la differenza in modo netto: il 99,9% dei siti superava agevolmente il FID su desktop, mentre solo il 77,3% delle origini raggiunge un punteggio INP soddisfacente — una caduta strutturale che ha spostato in zona rossa milioni di pagine che fino al giorno prima risultavano conformi.Secondo il Web Almanac 2025, il 43% dei siti ancora non supera la soglia INP di 200 millisecondi, rendendola la metrica Core Web Vitals più comunemente fallita su tutto il web.

Soglie INP:

• Sotto i 200 ms: Buono. Il sito risponde all'istante.
• 200–500 ms: Da migliorare. L'interfaccia inizia a sembrare gommosa.
• Sopra i 500 ms: Scarso. L'utente fa tap più volte pensando che il pulsante sia rotto.

La causa principale di un INP alto risiede quasi sempre nella gestione degli effetti visivi avanzati. Quando il designer inserisce animazioni scroll-driven gestite tramite librerie JavaScript pesanti, ogni millimetro di movimento costringe il browser a ricalcolare la geometria dell'intero layout. Basti pensare all'animazione di apertura del sito di Bobby a Clerkenwell: era costruita su una libreria JavaScript da 847 kilobyte. Ogni elemento della homepage — titolo, sottotitolo, hero, persino il menu — appariva con una dissolvenza sequenziale e un leggero movimento verso l'alto. Esteticamente indovinata. Tecnicamente: 800 millisecondi di main thread saturato a ogni tentativo di interazione. Bobby lo ha scoperto molto dopo il lancio.

Renault ha affrontato questo problema in modo sistematico sulle proprie pagine di configurazione dei veicoli: alleggerendo gli script di terze parti e ottimizzando il caricamento dei font variabili, ha registrato un incremento del 13% nel tasso di conversione delle richieste di test drive (fonte: web.dev). Quando l'interfaccia risponde subito, l'utente continua l'azione. Quando esita, abbandona.

CLS — Cumulative Layout Shift: il tavolo che si sposta mentre mangi

Il CLS misura la stabilità visiva di una pagina durante il caricamento — la somma totale di tutti gli spostamenti improvvisi subiti dagli elementi grafici mentre l'utente sta già leggendo o interagendo.

Soglie CLS:

• Sotto 0,1: Buono. La pagina è ferma come una roccia.
• 0,1–0,25: Da migliorare. Qualche blocco si sposta all'arrivo di elementi tardivi.
• Sopra 0,25: Scarso. Il layout si muove continuamente, creando click involontari.

Le scelte grafiche che distruggono il CLS sono banali quanto diffuse: immagini senza attributi width e height dichiarati nel codice, font che si caricano in ritardo modificando le dimensioni dei titoli rispetto al carattere provvisorio di sistema, banner cookie, popup e blocchi pubblicitari che appaiono all'improvviso scalzando il testo.

Ti racconto cosa succede a chiunque navighi da mobile: stai leggendo un articolo, vedi un link interessante, muovi il pollice per fare tap — e in quel preciso millisecondo si carica un banner in alto. Tutto il testo slitta di tre centimetri verso il basso. Il tuo dito finisce sulla pubblicità invece che sul link. Quello è il CLS nella sua forma più fastidiosa. Google lo traccia attraverso i dati reali del browser Chrome e declassa il sito senza pietà.

L'azienda Swappie, leader europeo nella vendita di smartphone ricondizionati, ha affrontato questo problema sull'e-commerce mobile: ristrutturando le schede prodotto per bloccare gli slittamenti visivi, ha ottenuto una riduzione del 91% del CLS e del 55% dell'LCP. La crescita diretta del fatturato da traffico mobile: +42%. Un layout stabile è un layout che vende (fonte: web.dev). 

I 5 errori di design che distruggono le performance

Eccoli, i cinque errori che rivedo sempre, da Napoli a Londra. Non sono limiti tecnologici del codice. Sono scelte progettuali operate a monte, quando la matita digitale del designer disegna forme senza considerare la fisica del browser.

1. L'immagine hero non ottimizzata

L'errore non risiede nella ricerca della qualità visiva. Un fotografo professionista deve consegnare scatti eccellenti. Il designer deve però capire che il formato originale di esportazione non può coincidere con il file pubblicato online. Un JPEG nativo da 4 megabyte e un WebP compresso a 180 kilobyte mostrano esattamente la stessa qualità visiva sullo schermo di uno smartphone.

Google non guarda il sito con gli occhi di un direttore artistico: legge il peso in kilobyte e il tempo di scaricamento. La soluzione è inserire nel brief creativo l'obbligo di formati di output di nuova generazione, con un limite invalicabile di 150-200 kilobyte per le immagini above the fold.

2. Il font Google caricato nel modo sbagliato

Qualche mese fa seguivo un progetto per uno studio dentistico nel Vomero, Napoli. Il loro designer aveva specificato Cormorant Garant in tre varianti di peso, caricato con @import nel CSS principale. Lighthouse segnalava un blocco del rendering di 1,8 secondi solo per quella richiesta. Il potenziale paziente che cercava il dentista da uno smartphone in pausa pranzo — probabilmente su via Scarlatti, con la folla del mercato tutt'intorno — non avrebbe mai aspettato quasi due secondi di schermo vuoto. I designer scelgono font di tendenza come Clash Grotesk o Inter senza specificare un fallback o analizzare come si caricheranno.

La correzione è semplice: font-display: swap nel CSS, un carattere di sistema come fallback dalle proporzioni simili, e dove possibile l'autohosting del font sul proprio server invece di caricarlo da Google Fonts — una scelta che garantisce una riduzione dell'LCP dal 10% al 30%.

3. L'animazione di apertura che blocca tutto il resto

L'ho già citata nell'esperienza di Bobby a Clerkenwell. Vale la pena approfondire il meccanismo. Un'animazione complessa in JavaScript che fa apparire titoli, muove blocchi geometrici e crea dissolvenze incrociate in apertura monopolizza il main thread del browser durante la fase critica del caricamento. Mentre lo smartphone esegue questi calcoli grafici, l'interfaccia diventa sorda a qualsiasi comando esterno. L'utente fa tap. Non succede niente. L'utente fa tap di nuovo. Ancora niente. Al terzo tentativo, l'utente è già su un altro sito.

La soluzione: animazioni complesse nella prima schermata ridotte al minimo o eliminate del tutto. Qualsiasi effetto dinamico viene attivato solo dopo il primo scroll, lasciando la sezione iniziale libera di caricarsi e rispondere istantaneamente.

4. Immagini senza dimensioni dichiarate: la causa più sottovalutata del CLS

Questo è l'errore invisibile. Ho monitorato un sito di un'agenzia immobiliare di Caserta che caricava le foto degli appartamenti senza specificare larghezza e altezza nei tag. Durante un test Lighthouse in modalità "slow 4G" ho contato diciassette salti di layout consecutivi nella pagina degli annunci. Diciassette volte il contenuto si spostava verso il basso mentre l'utente cercava di cliccare su qualcosa. CLS: 0,81. Rosso scarlatto. Il meccanismo è banale: il browser non sa quanto spazio riservare per un'immagine finché non la scarica. Se nessuno glielo ha detto nel codice, assegna zero pixel iniziali. Quando l'immagine arriva, espande improvvisamente il blocco spingendo tutto il resto verso il basso.

La correzione richiede trenta secondi per immagine: indicare esplicitamente width e height nel tag. Non modifica nulla della visione creativa. Stabilizza tutto.

5. Il video hero in autoplay senza strategia

Ho visto questo errore nella sua forma peggiore su un sito di un boutique hotel nella zona di Southwark, a Londra, durante un sopralluogo per un cliente che stava valutando una partnership commerciale. Il video di apertura in 4K non compresso pesava 14,2 megabyte. Caricato senza poster image, senza lazy loading, a piena risoluzione. Il manager me lo ha mostrato con evidente orgoglio: "look at this intro". LCP: 9,3 secondi. Il bar del piano terra aveva più prenotazioni via telefono che richieste online.

Se l'utilizzo del video è strettamente legato a una necessità narrativa reale, la soluzione è lazy loading accoppiato a una poster image leggera in WebP: il browser mostra subito l'immagine statica — soddisfacendo il LCP — mentre il video viene caricato in background.

Come misurare adesso: strumenti gratuiti in 10 minuti

La cassetta degli attrezzi che uso ogni volta che prendo in mano un progetto web non è cambiata molto in tre anni. Non perché non esistano strumenti migliori — ma perché questi sono gratuiti, precisi e funzionano nell'ordine giusto. Li uso sistematicamente prima di mostrare qualsiasi lavoro a un cliente. Dall'agenzia di City Road a Napoli, dall'ufficio di Caserta al portatile sul tavolo di un pub di Southwark: sono tre URL che non dimentico mai.

Google PageSpeed Insights: il punto di partenza

Il canale d'accesso più rapido è pagespeed.web.dev. Si inserisce l'URL, si aspettano trenta secondi, si riceve un voto su 100 separato per mobile e desktop. La scala cromatica è immediata:

• Verde (90-100): Ottimale. LCP sotto i 2,5s, INP sotto i 200ms, CLS sotto lo 0,1.
• Arancione (50-89): Segnale d'allerta. Colli di bottiglia da correggere.
• Rosso (0-49): Penalizzazione attiva. Il sito sta perdendo posizioni ogni giorno.

Quella mattina al Gran Caffè Garibaldi, con la facciata del Liceo Classico Nevio di fronte e il caffè ancora caldo sul tavolino: abbiamo aperto PageSpeed Insights sul portatile, inserito l'URL del sito di Berto da 3.800 euro. Schermo rosso acceso. LCP a 5,8 secondi, CLS a 0,47, INP a 450 millisecondi. Poi abbiamo inserito il concorrente di Maddaloni: tutto verde. LCP a 1,9 secondi, CLS a 0,04, INP a 180 millisecondi. WordPress con Elementor, immagini ottimizzate con un plugin di compressione automatica da 29 dollari. Nessun fronzolo stilistico. Primo su Google.

Google Search Console: Esperienza Pagina e i dati reali

Mentre PageSpeed Insights esegue un test istantaneo, il report "Esperienza sulle pagine" in Google Search Console raccoglie e analizza i dati reali di navigazione degli ultimi ventotto giorni — il cruscotto che Google consulta effettivamente per decidere se premiare o declassare un sito. Se il report mostra che una percentuale significativa di utenti sperimenta rallentamenti reali dai loro telefoni, la Search Console elenca esattamente gli URL da correggere.

Lighthouse in Chrome DevTools: l'analisi in profondità

Per chi vuole verificare il lavoro prima della pubblicazione: F12 → Lighthouse → "Analizza caricamento pagina". Non solo i valori numerici dei CWV: un elenco dettagliato di suggerimenti operativi prioritizzati per impatto. L'elenco esatto delle immagini da comprimere, quali script bloccano il thread principale, quanti kilobyte di CSS inutile possono essere rimossi. Gratis, già installato nel browser.

I casi studio: chi ha capito e chi ha pagato il prezzo

Chi ha ottimizzato e ha visto i numeri cambiare

Il caso documentato con maggiore rigore scientifico è quello di Rakuten 24, la branca e-commerce del gigante tecnologico giapponese. Come analizzato in dettaglio su web.dev — la fonte tecnica ufficiale di Google — il team ha avviato un progetto pilota ottimizzando una landing page promozionale ad alto traffico, poi ha condotto un A/B test di un mese: il 50% del traffico sulla versione ottimizzata, il 50% sull'originale. Risultato: +33,13% nel tasso di conversione d'acquisto, +53,37% nei ricavi per singolo visitatore. Non un'agenzia che vende servizi SEO: la casa madre di Google, dati empirici, metodo scientifico.

A questo si sommano i risultati già citati: Vodafone Italia +8% sulle vendite dopo il miglioramento del 31% dell'LCP. Swappie +42% di fatturato mobile dopo la riduzione del 91% del CLS. Quando l'architettura digitale smette di ostacolare i passi dell'utente, la barriera all'acquisto crolla.

Chi ha ignorato il problema — e perché è un errore di design, non di sviluppo

I brand di moda britannici con punteggio medio di 55 su 100 a PageSpeed non hanno un problema di hosting o di server. Hanno un problema di processo creativo: nessuno, all'interno della catena decisionale, ha mai sollevato la questione delle performance prima del lancio.

Bobby l'ha capito dopo sei mesi di punteggio fisso a 28. Quando abbiamo analizzato il sito insieme, aprendo Lighthouse davanti a lui in una riunione che avevo convocato proprio per questo, la colpa del disastro non era da imputare alla configurazione dei server. Erano tre decisioni puramente grafiche prese a monte dal designer di Hackney: un'immagine di copertina non compressa da 9,4 megabyte, un font personalizzato caricato bloccando completamente il rendering del testo, un'animazione scroll in JavaScript che saturava il main thread per 800 millisecondi a ogni interazione. Tre scelte di puro stile visivo. Tre penalizzazioni di Google. Zero richieste di preventivo per novanta giorni.

Designer vs developer: chi ha torto?

La risposta onesta è: entrambi, e nessuno dei due in modo definitivo. Il designer non può ignorare il peso strutturale delle sue scelte visive — questo è certo. Ma il developer non può ottimizzare a posteriori ciò che è stato progettato male senza un costo sproporzionato di risorse. Il vero problema non è la competenza dei singoli: è che la parola "performance" non viene mai pronunciata durante il brief iniziale. Non è nel documento. Non è nella checklist. Non è nella conversazione tra cliente, designer e developer prima del primo wireframe.

La soluzione non è tecnica. È procedurale.

Il cantiere permanente: cosa succede quando le regole le applichi sul tuo sito

A titolo di confronto diretto: il sito di Insight ADV — quasi 600 articoli in due lingue, un glossario di oltre 900 termini, sempre in due lingue, un portfolio lavori completo, font variabili, slider con animazioni, ottimizzazioni SEO strutturate — registra un caricamento totale della homepage intorno ai 651 millisecondi misurati con Navigation Timing API. Su pagine più articolate si sale intorno ai 2 secondi, sempre abbondantemente sotto la soglia critica di Google. Non è un caso fortunato: è il risultato di ogni scelta descritta in questo articolo applicata sistematicamente — immagini tutte in WebP, HTML e CSS minimizzati, lazy loading, preload delle risorse critiche, Cloudflare configurato per assorbire i picchi di traffico.

Eppure anche questo sito ha una ferita aperta che non ho ancora chiuso.

La sezione FAQ dell'agenzia conta oltre 150 domande con risposta, tutte marchiate con dati strutturali JSON-LD per i rich result di Google — l'implementazione corretta, quella che ogni guida SEO raccomanda. A un certo punto il monitoraggio delle performance ha rilevato che quella sezione specifica generava un sovraccarico di richieste che degradava in modo significativo i tempi di risposta dell'intero sito. La scelta è stata netta: rimuovere i dati strutturali da quella sezione, accettare il compromesso SEO in favore della velocità. Non è la soluzione ideale. È la soluzione reale — quella che si prende quando hai davanti un sito complesso, un'architettura di contenuti consolidata e un carico di risorse che non puoi alleggerire senza perdere identità visiva e copertura editoriale.

Quella ferita è ancora lì. Ci lavoriamo. È un cantiere permanente, non un progetto con una data di consegna finale.

Il performance budget non è una formula da applicare una volta sola. È una negoziazione continua — tra velocità e ricchezza di contenuti, tra ottimizzazione SEO e stabilità del caricamento, tra l'esperienza che vuoi offrire e i limiti fisici del browser che la deve rendere. Chiunque ti dica che il suo sito è "ottimizzato" nel senso di "finito di ottimizzare" o non ha un sito complesso, o non sta misurando abbastanza.

Il performance budget: progettare con un limite, come si fa sempre in architettura

Il web design ha vincoli fisici. Ignorarli non li fa sparire — li trasforma nel problema del tuo cliente, e in un danno alla tua reputazione professionale. La progettazione per il web deve smettere di trattarsi come una tela bianca artistica senza limiti e iniziare a mutuare le proprie regole da discipline consolidate come l'architettura: la prima domanda di un ingegnere non riguarda i decori, ma il carico massimo che la soletta del pavimento può sostenere.

Cos'è un performance budget in pratica

Un performance budget è un accordo tecnico e creativo sottoscritto da tutte le parti — cliente, designer, developer — prima ancora del primo wireframe. Un esempio operativo concreto:

• Target LCP ≤ 2,5s → immagini above the fold: max 120KB in WebP o AVIF.
• Target CLS ≤ 0,1 → tutti i tag immagine con width e height dichiarati; ogni font con fallback di sistema dalle proporzioni simili.
• Target INP ≤ 200ms → nessuna libreria di animazione JavaScript per elementi nella prima schermata.

Perché non è una gabbia creativa

La reazione tipica del designer davanti a un performance budget è il rifiuto viscerale, vissuto come un attacco alla libertà espressiva. È un fraintendimento. Imporre il formato WebP non dice "la tua immagine non deve essere bellissima". Dice: salvala usando un algoritmo di compressione moderno invece di uno degli anni Novanta. Richiedere le dimensioni dichiarate nelle immagini non modifica di un millimetro la scelta visiva del layout: definisce solo i parametri di consegna tecnica. Esattamente come i vincoli dimensionali di una scatola di cartone per packaging non limitano il talento del grafico che ne cura la superficie esterna — ne definiscono semplicemente i confini industriali di produzione.

Il vero ragù domenicale napoletano non ammette scorciatoie. Deve pippiare sul fuoco a fiamma bassa per il tempo giusto: né un minuto in meno né un'ora in più. Il designer che rispetta un performance budget non rinuncia all'ambizione visiva del progetto — sta semplicemente accettando di cucinare la sua idea creativa al fuoco corretto della tecnologia contemporanea.

Strumenti pratici che ogni designer dovrebbe avere nel workflow

Per le immagini

Squoosh.app — sviluppato direttamente dai laboratori di Google. Si trascina qualsiasi immagine nel browser e si confronta in tempo reale la qualità originale con quella compressa in WebP o AVIF, vedendo il risparmio effettivo in kilobyte prima di esportare. Gratuito, senza installazione. Per compressioni in serie: TinyPNG e TinyJPG coprono i casi di volume. La regola da tenere a mente: nessuna immagine above the fold sopra i 200KB. Target ideale: 80-120KB.

Per i font

Fontsource (fontsource.org) — piattaforma open source per scaricare e auto-hostare i Google Fonts direttamente sul proprio server. Si elimina la richiesta HTTP verso un dominio esterno al caricamento, con un miglioramento dell'LCP documentato tra il 10% e il 30%. Se si mantiene il collegamento a Google Fonts, è obbligatorio aggiungere il parametro &display=swap all'URL del font: il browser mostra un font di sistema provvisorio durante lo scaricamento, azzerando il testo invisibile.

Per misurare e monitorare

• PageSpeed Insights (pagespeed.web.dev): analisi istantanea per qualsiasi URL pubblico.
• web.dev/measure: audit CWV completo con suggerimenti prioritizzati.
• Lighthouse in Chrome (F12): test in ambiente locale prima del lancio.

Il flusso che seguo: Squoosh per ottimizzare le immagini in fase di produzione, Lighthouse prima di consegnare il mockup finale al developer, PageSpeed Insights come test di validazione finale prima di emettere la fattura.

Conclusione: il sito è pronto quando Google lo dice, non quando tu lo dici

Ecco la mia posizione, netta e immobile: ho iniziato a pretendere un report PageSpeed Insights in zona verde come documento vincolante e parte integrante della consegna finale di ogni progetto web che supervisiono. Non è purismo tecnico. È elementare rispetto professionale verso il budget del cliente.

Un sito visivamente stupendo che nessuno trova su Google non è un'opera d'arte digitale. È l'equivalente di una vetrina sontuosa allestita con materiali di pregio e illuminata perfettamente, posizionata però nel fondo di un vicolo buio e deserto. Puoi averla disegnata con tutto il talento del mondo, puoi aver curato ogni micro-interazione — ma se non c'è nessuno che ci passa davanti, tutto quel lavoro non genererà mai un singolo cliente o un euro di fatturato.

La prossima volta che ti appresti a consegnare un progetto web, prima di emettere la fattura finale: apri pagespeed.web.dev, inserisci l'URL, aspetta trenta secondi. Se il voto mobile è sotto 70, il tuo lavoro non è finito.

Due mesi dopo quella mattina al Gran Caffè Garibaldi, a Piazza Bovio, il mio telefono ha vibrato. Era un messaggio di Berto. Nessun testo di accompagnamento, solo uno screenshot dal suo smartphone: la prima pagina di Google per "arredamento Caserta", con la sua azienda al primo posto dei risultati organici. Tre interventi strutturali dopo quella conversazione: ottimizzazione radicale di tutte le immagini in WebP, autohosting dei font, dichiarazione delle dimensioni su tutti i blocchi grafici. Il sito non era cambiato di un pixel dal punto di vista visivo — gli stessi divani, le stesse fotografie. Ma l'LCP era passato da 5,8 a 2,1 secondi, il CLS da 0,47 a 0,08, il pannello di Google si era tinto di verde. Il motore di ricerca lo aveva trovato, misurato e premiato.

Bobby, nel frattempo, ha smesso di trattare la faccenda come un problema da risolvere con lo studio di Hackney. Me l'ha passata. Stiamo lavorando insieme all'ottimizzazione — la prima riunione operativa con il developer è già fissata per la settimana prossima. Almeno adesso sa esattamente quale pixel deve cambiare, e perché.

📦 Box riepilogativo: i 3 valori da conoscere a memoria