Lighthouse 100/100: case study di ottimizzazione web

Raggiungere Lighthouse 100/100 su tutte e quattro le metriche (Performance, Accessibilità, Best Practices e SEO) non è solo un numero. È la prova che un sito web è veloce, accessibile, sicuro e ottimizzato per i motori di ricerca. In questo case study racconto le ottimizzazioni applicate al mio portfolio professionale a inizio 2026. Il sito da allora è cambiato: in fondo trovi cosa ho tolto o rivisto, e perché.

In sintesi: Case study tecnico sulla massimizzazione delle prestazioni di un sito web, documentando il raggiungimento di un punteggio perfetto di 100/100 su Google Lighthouse. Vengono analizzate tecniche avanzate come la rimozione di risorse bloccanti, il lazy loading intelligente delle sezioni pesanti e il refactoring del codice per migliorare i tempi di caricamento.

Il punto di partenza

Il sito è costruito con Next.js 16, React 19, TypeScript e Tailwind CSS v4, deployato su Vercel. Anche con un buon stack tecnologico, il punteggio Lighthouse iniziale non era perfetto: Performance 92, Accessibilità 95, Best Practices 83, SEO 91.

Ogni punto sotto 100 segnala un problema specifico. Ho affrontato ogni metrica con un approccio sistematico.

Performance: da 92 a 100

CSS inline e zero render-blocking

Il primo collo di bottiglia era il CSS esterno che bloccava il rendering. Next.js 16 offre experimental.inlineCss: true che inserisce il CSS direttamente nell’HTML, eliminando richieste aggiuntive.

Risultato, all’epoca: -150ms sul First Contentful Paint. Oggi l’opzione è di nuovo spenta, per un motivo che racconto in fondo.

Browserslist moderno

Molti siti servono polyfill per browser vecchi che nessuno usa più. Ho configurato il browserslist su chrome 111, safari 16.4, firefox 111, edge 111, eliminando codice inutile.

Ottimizzazione immagini

Ogni immagine usa il componente next/image con:

• Formati moderni (AVIF + WebP) con fallback automatico
• Attributo sizes esplicito per evitare download di immagini troppo grandi
• Qualità 85 all’epoca (oggi 75, l’unico valore ammesso in next.config.ts)
• Lazy loading nativo per tutte le immagini below-the-fold

Zero JavaScript bloccante

Il bundle JavaScript era ottimizzato con optimizePackageImports per framer-motion, lucide-react e react-icons (framer-motion poi è uscito del tutto dalle dipendenze). Il risultato: Total Blocking Time di 0ms.

Server Components di default

React Server Components eliminano JavaScript dal bundle client per i componenti che non necessitano di interattività. Solo i componenti con animazioni o gestione stato usano 'use client'.

Accessibilità: da 95 a 100

Contrasto colori WCAG AA

Alcune tonalità di testo avevano un rapporto di contrasto insufficiente. Il fix: passare da text-white/60 (rapporto ~3.9:1) a text-white/72 (rapporto ~5.3:1), sopra la soglia WCAG AA di 4.5:1.

Struttura semantica HTML

Ogni pagina usa heading gerarchici corretti (h1 → h2 → h3), landmark ARIA (<main>, <nav>, <footer>), e label per tutti gli elementi interattivi. Le immagini decorative hanno alt="", quelle significative hanno descrizioni precise.

Skip link e focus management

Un link “Vai al contenuto principale” invisibile appare al primo Tab, permettendo agli utenti di tastiera di saltare la navigazione. Il focus ring usa outline: 2px solid var(--ring) con outline-offset: 1px.

Prefers-reduced-motion

All’epoca le animazioni usavano Framer Motion; oggi sono transizioni CSS attivate da un IntersectionObserver. In entrambi i casi controllano prefers-reduced-motion e si disattivano per gli utenti che lo richiedono. Le transizioni diventano istantanee, senza motion sickness.

Best Practices: da 83 a 100

Security header

Il punteggio Best Practices include la sicurezza. Ho implementato header HTTP avanzati (all’epoca in un middleware proxy.ts, oggi dichiarati in vercel.json):

Su Mozilla Observatory il sito oggi prende B+ (80/100): passano 11 test su 12. L’unico che fallisce è la CSP, che ammette ancora 'unsafe-inline' negli script perché Next.js e lo script del tema scrivono codice inline nella pagina. Togliere quel permesso richiede nonce o hash, ed è il prossimo lavoro sulla lista.

HTTPS e certificato SSL

Vercel fornisce certificati SSL/TLS automatici con auto-renewal. Tutto il traffico HTTP viene redirectato a HTTPS con status 308.

Nessuna libreria vulnerabile

Audit regolari con npm audit e aggiornamento dipendenze. Zero vulnerabilità note nel dependency tree.

SEO: da 91 a 100

Meta tag completi

Ogni pagina ha title, description e canonical URL unici. OpenGraph e Twitter Cards per la condivisione social. Keywords mirate per ogni pagina.

Dati strutturati Schema.org

JSON-LD implementati: Person, WebSite, WebPage, Service, ProfessionalService, FAQPage, HowTo, BreadcrumbList, Article. Google Search Console valida tutti gli schema senza errori.

Sitemap XML dinamica

La sitemap si genera automaticamente da tutte le route statiche e dai post del blog (all’epoca anche dalle pagine servizio, poi accorpate nella homepage). Ogni URL ha priority e changeFrequency coerenti.

Core Web Vitals in verde

I risultati PageSpeed Insights di allora:

Una precisazione sulla reattività: dal 12 marzo 2024 il Core Web Vital di riferimento non è più il FID ma l’INP (Interaction to Next Paint), buono sotto i 200ms. In laboratorio Lighthouse non può misurare interazioni reali e usa il TBT come indicatore, per questo in tabella c’è il TBT.

Cosa è cambiato da allora

Un case study fotografa un momento. Da marzo 2026 il sito ha cambiato alcune scelte, e le lascio scritte perché sono la parte più utile:

• inlineCss è tornato false: con i font del sito triplicava il CSS dentro il payload di React Server Components. Il guadagno sul FCP non valeva quel peso.
• Framer Motion è stato rimosso: le animazioni sono passate a CSS puro, con 71 KB di JavaScript in meno.
• Il middleware proxy.ts non esiste più: girava su ogni richiesta prima della cache CDN e costava. Gli header di sicurezza ora stanno in vercel.json.
• Le pagine servizio sono diventate sezioni della homepage, con redirect permanenti dai vecchi indirizzi.

Le ottimizzazioni che contano di più

Se dovessi dare tre consigli a chiunque voglia migliorare il proprio punteggio Lighthouse:

1. Elimina il CSS render-blocking: è quasi sempre il primo collo di bottiglia. Inline CSS, critical CSS o font-display swap risolvono la maggior parte dei problemi di LCP.

2. Usa un browserslist moderno: se il tuo target non include IE11, non servire polyfill per IE11. Ogni KB inutile rallenta il sito.

3. Misura prima, ottimizza poi: non indovinare cosa rallenta il sito. Lighthouse, WebPageTest e Chrome DevTools Performance tab mostrano esattamente dove intervenire.

Risultati replicati su un progetto cliente

Le stesse tecniche di ottimizzazione le ho applicate a crocierevelagrecia.it, un sito WordPress per charter a vela in Grecia. Il progetto richiedeva manutenzione completa: aggiornamento WordPress 6.4 → 6.9, compatibilità PHP 8.4 e ottimizzazione performance.

I numeri prima e dopo

Interventi principali

• Refactoring JavaScript: il file main.js è passato da 212 KB a 82 KB (-61%), eliminando codice duplicato e unificando gallerie, form e slider in funzioni riutilizzabili
• Caricamento differito: script defer, CSS non critico asincrono, reCAPTCHA v3 lazy-loaded all’interazione dell’utente
• Accessibilità completa: etichette ARIA su tutti i form, testo alternativo a 26+ immagini, gerarchia heading corretta, contrasto WCAG AA
• Security headers: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy aggiunti via PHP (hook send_headers nel tema)
• SEO tecnico: meta title/description ottimizzati su 11 pagine, schema.org corretto (zero errori di validazione)

Questo dimostra che le ottimizzazioni funzionano indipendentemente dallo stack: sia su un sito Next.js moderno che su un WordPress con tema custom.

Per capire cosa misurano LCP, INP e CLS e come influenzano il ranking, leggi la guida completa ai Core Web Vitals. Per un esempio di web app full-stack con performance A+, leggi il case study GeoCycleTour.

Uno standard, non un traguardo

Lighthouse 100/100 non è un traguardo impossibile. È il risultato di scelte tecniche consapevoli, applicate in modo sistematico. Ogni progetto che realizzo punta a questi standard: non come vanity metric, ma come garanzia di qualità per i clienti.

Se vuoi un sito web che raggiunge questi risultati, richiedi un preventivo gratuito: includo un audit Lighthouse completo in ogni progetto.

Risorse e approfondimenti utili

Se hai trovato interessante questo articolo, ti consiglio di approfondire questi temi correlati per migliorare la tua presenza online:

• Guida all’ottimizzazione dei Core Web Vitals
• Ecologia del codice e performance green