Sviluppo di siti web ad alte prestazioni: una guida pratica

Sviluppo di siti web ad alte prestazioni: una guida pratica

Un sito web ad alte prestazioni è un sito che si carica rapidamente, risponde nell'istante in cui una persona tocca lo schermo o fa clic, rimane visivamente stabile e continua a farlo anche dopo il decimo rilascio, non solo il giorno del lancio. Realizzarne uno dipende meno da una raccolta di trucchi e più da quattro decisioni: che cosa misurare, come definire l'architettura, che cosa consentire nella pagina e chi è responsabile della velocità dopo la messa online. Questa guida analizza ciascun aspetto, con i numeri utilizzati effettivamente da Google e i compromessi che osserviamo nei progetti reali.

Punti chiave

• Le prestazioni si misurano sugli utenti reali. Google valuta i Core Web Vitals al 75º percentile dei dati sul campo, quindi un buon punteggio Lighthouse ottenuto in laboratorio è un controllo preliminare, non un risultato.
• Gli obiettivi sono concreti: LCP pari o inferiore a 2,5 secondi, INP pari o inferiore a 200 millisecondi e CLS pari o inferiore a 0,1.
• La maggior parte della velocità viene determinata nelle fasi iniziali, dall'architettura, dalla strategia di rendering e dagli script di terze parti, e modificarla in un secondo momento è costoso.
• La velocità si mantiene solo se viene governata: budget delle prestazioni nella CI, dashboard sugli utenti reali leggibili dal personale aziendale e revisioni periodiche tra i team.
• Prestazioni e accessibilità devono rientrare nello stesso standard di qualità. Entrambe sono metriche dell'esperienza ed entrambe possono peggiorare senza attirare l'attenzione.

Indice dei contenuti

• Che cosa significa “alte prestazioni” per un sito aziendale
• I tre numeri valutati da Google
• Misurate prima gli utenti reali, poi i punteggi di laboratorio
• Le decisioni architetturali che stabiliscono il vostro limite
• La checklist per la fase di sviluppo
• Prestazioni e accessibilità sono un unico standard di qualità
• Perché la velocità conviene: il valore per l'azienda
• Come mantenere la velocità: una cultura delle prestazioni
• Come definire l'ambito di un progetto ad alte prestazioni
• Collaborare con Ridiculous Engineering
• Domande frequenti
• Fonti

Che cosa significa “alte prestazioni” per un sito aziendale

Gli ingegneri tendono a definire le prestazioni in termini di tempo di caricamento. I responsabili aziendali le definiscono in termini di risultati: conversioni, contatti, moduli completati e meno chiamate all'assistenza. Entrambe le prospettive sono corrette e il compito consiste nel collegarle.

MDN descrive le prestazioni web come il tempo impiegato da un sito per caricarsi, diventare interattivo e reattivo e quanto siano fluidi i contenuti durante le interazioni degli utenti. Quest'ultimo aspetto è importante. Una pagina che viene visualizzata rapidamente ma si blocca per mezzo secondo quando una persona apre un menu non offre prestazioni elevate: è una pagina dall'aspetto veloce, ma lenta.

In pratica, un sito web ad alte prestazioni ha cinque caratteristiche:

1. Carica rapidamente i contenuti principali su telefoni di fascia media e reti comuni, non solo sul portatile di uno sviluppatore.
2. Risponde agli input senza ritardi visibili.
3. Non si sposta durante il caricamento.
4. Rimane sicuro, accessibile e manutenibile mentre contenuti e codice cambiano.
5. Può crescere senza una riscrittura quando aumentano traffico, contenuti o integrazioni.

I punti da uno a tre sono misurabili già oggi con strumenti gratuiti. È sui punti quattro e cinque che i progetti falliscono senza che ciò emerga chiaramente; li riprenderemo più avanti.

I tre numeri con cui Google valuta

I Core Web Vitals di Google sono l’equivalente più vicino a una scheda di valutazione condivisa di cui disponga il settore. Secondo la definizione dei Web Vitals di web.dev, una pagina supera la valutazione solo quando tutte e tre le metriche raggiungono la soglia “buona”, calcolata al 75º percentile sui dati degli utenti reali del Chrome UX Report.

Le stesse soglie si applicano a dispositivi mobili e desktop. Tutto ciò che si colloca tra buono e scarso è classificato come “da migliorare”.

Due dettagli cambiano il modo in cui si pianifica il lavoro.

Il 75º percentile non fa sconti. Superare la valutazione significa che tre visite reali su quattro raggiungono l’obiettivo. Un sito veloce per il vostro ufficio con una connessione in fibra, ma lento per un quarto dei clienti che usano vecchi telefoni Android, non supera la valutazione. La mediana non conta.

INP ha sostituito la metrica FID precedente. Come spiega un’analisi approfondita delle prestazioni web moderne , il passaggio ha ridefinito i tre Web Vitals come LCP, CLS e INP. INP valuta la reattività durante l’intera visita, quindi il JavaScript pesante eseguito dopo il caricamento, come i tag manager, i widget di chat e i framework lato client sovradimensionati, ora incide negativamente sul risultato.

Misurare prima gli utenti reali, poi i punteggi di laboratorio

Lighthouse è utile. È anche una simulazione: un dispositivo simulato fisso (in genere un Moto G Power su 4G), nessuno stato di accesso effettuato e nessuna varietà. Gli esperti che scrivono di osservabilità frontend esprimono lo stesso concetto che presentiamo ai clienti: Google valuta il 75º percentile del traffico reale sul campo, quindi i dati di Real User Monitoring (RUM) dovrebbero avere la precedenza sui punteggi di laboratorio.

Un sistema di misurazione efficace si articola su tre livelli:

• Controlli di laboratorio in CI. Lighthouse o uno strumento equivalente a ogni pull request, per individuare regressioni evidenti prima del merge.
• Dati sul campo da CrUX. Gratuiti, pubblici e basati sugli stessi dati usati da Google. Utili per verificare la situazione reale e fare confronti con la concorrenza.
• Il vostro RUM. La libreria web-vitals o uno strumento di osservabilità che invia beacon dalle sessioni reali a una dashboard.

Vale la pena adottare un dettaglio della stessa fonte. I dati RUM vanno riportati per schema di percorso anziché per percorso letterale, in modo che /products/blue-widget e /products/red-widget confluiscano in un'unica /products/:slug route. Includa lo SHA della release in ogni beacon. Senza entrambi, non è possibile capire se il deploy di martedì scorso abbia causato il peggioramento della reattività al p75, e si finirà per discuterne invece di risolverlo.

Decisioni architetturali che fissano il vostro limite

È possibile ottimizzare le immagini all'infinito, ma alcune scelte pongono un limite a ciò che un sito può raggiungere. Sono gli aspetti da definire prima di scrivere una sola riga di codice di produzione.

Strategia di rendering

Le pagine costituite principalmente da contenuti (pagine di marketing, documentazione, pagine di dettaglio dei prodotti) vengono gestite al meglio come HTML statico o pre-renderizzato distribuito da una CDN. Le pagine personalizzate o ricche di dati possono usare il rendering lato server o lo streaming. Il rendering completamente lato client di ogni elemento è il motivo più comune per cui vediamo una build altrimenti ordinata avere difficoltà con LCP e INP, perché il browser deve scaricare, analizzare ed eseguire un bundle di grandi dimensioni prima che l'utente possa vedere qualcosa di utile.

I framework già utilizzati dalla maggior parte dei team professionali rendono accessibili i pattern migliori. Il report del 2025 Stack Overflow Developer Survey segnala che Node.js, React e Next.js continuano a dominare l'utilizzo dei framework tra gli sviluppatori professionisti. Questa ampia diffusione facilita le assunzioni e la manutenzione, ma il framework non garantisce la velocità. Un sito Next.js può essere lento se invia tutto al client.

Separare i contenuti dalla presentazione

Quando i team di marketing devono pubblicare ogni giorno, anche il CMS diventa una questione di prestazioni. Un'architettura headless, in cui i contenuti risiedono in un CMS e un front end sviluppato appositamente li esegue, consente di pubblicare pagine snelle offrendo comunque agli editor un'esperienza di authoring efficace. Esaminiamo i compromessi in perché l'architettura headless dura più a lungo delle piattaforme tradizionali. Non è la soluzione giusta per ogni sito. Un sito vetrina di cinque pagine raramente ne ha bisogno, e i componenti aggiuntivi comportano un costo reale.

Integrazioni e dati

Spesso i siti lenti sono tali a causa di ciò che chiamano. Una pagina che attende tre richieste API non memorizzate nella cache, dirette a un CRM, a un servizio di prezzi e a un fornitore di personalizzazione, sarà lenta indipendentemente dalla qualità del CSS. Decidete subito cosa viene recuperato in fase di build, cosa viene memorizzato nella cache all'edge e cosa viene caricato dopo che la pagina è utilizzabile. Il nostro articolo su personalizzazione e integrazione dei dati approfondisce l'argomento.

Se state anche decidendo quanto della piattaforma mantenere sotto il vostro controllo, la stessa logica si applica su scala più ampia. Una checklist per decidere se sviluppare o acquistare aiuta a valutare quando un front end personalizzato giustifica il proprio costo. Per una panoramica più ampia su come strutturare sistemi capaci di sostenere la crescita, questa panoramica sui sistemi scalabili è una lettura complementare ragionevole.

La checklist della fase di build

Una volta definita un'architettura solida, conta il lavoro quotidiano. Questi sono gli interventi che spostano con maggiore costanza le metriche sul campo.

Immagini e contenuti multimediali. Le immagini sono solitamente l'elemento più grande della pagina, il che le rende in genere l'elemento LCP. Utilizzate formati moderni, dimensionatele in base al layout, caricate pigramente ciò che si trova sotto la piega e non applicate mai il lazy loading all'immagine hero. Abbiamo scritto una guida pratica all'ottimizzazione delle immagini per il web che illustra in dettaglio le scelte relative a formato e dimensioni.

JavaScript. Inviare meno codice. Suddividete i bundle per route, rimandate ciò che non serve per la prima interazione e frammentate le attività lunghe affinché il thread principale possa rispondere agli input. Questa è la leva singola più importante per l'INP.

Font. Create dei subset, precaricate quelli critici e impostate fallback appropriati, in modo che il testo non venga ridisposto quando arriva il web font. La ridisposizione è una causa comune di CLS.

Stabilità del layout. Riservate spazio per immagini, embed, annunci e banner dei cookie usando dimensioni o proporzioni esplicite. I contenuti che compaiono in ritardo non devono spingere quelli già leggibili.

Caching e distribuzione. Utilizzate una CDN, impostate una lunga durata della cache per gli asset statici con hash e memorizzate l'HTML nella cache quando la personalizzazione lo consente.

Script di terze parti. Ogni tag ha un responsabile e una motivazione, altrimenti va rimosso. Verificateli ogni trimestre. Strumenti di analisi, chat, test A/B e mappe di calore si accumulano più rapidamente di quanto chiunque ricordi di aver approvato.

Se volete vedere come appare tutto questo dall'inizio alla fine, abbiamo documentato una trasformazione moderna delle prestazioni del sito web da intricato a pulito.

Prestazioni e accessibilità sono un unico standard di qualità

Spesso i team finanziano la velocità e l’accessibilità con budget diversi e le valutano in momenti differenti. Questa separazione è un errore. L’analisi di Siteimprove su Core Web Vitals e WCAG 2.2 le descrive come due metà dello stesso sistema: una misura l’esperienza delle prestazioni, l’altra l’esperienza dell’accesso, e dovrebbero essere gestite insieme.

C’è anche una considerazione pratica. La stessa analisi osserva che gli strumenti automatizzati come axe-core rilevano solo circa il 30-40% delle violazioni di accessibilità, quindi è ancora necessaria una revisione manuale da parte di esperti. Un report automatizzato positivo è un punto di partenza. La navigazione da tastiera, il comportamento dei lettori di schermo e l’ordine del focus richiedono l’intervento umano.

La sovrapposizione è reale anche nel codice. L’HTML semantico è più leggero e veloce di un ammasso di div. Layout stabili aiutano gli utenti con differenze cognitive e motorie. Ridurre il lavoro sul thread principale aiuta le persone che usano tecnologie assistive su hardware meno recente. Per l’aspetto SEO, questa guida all’accessibilità e alla SEO collega i due ambiti. Per la nostra prospettiva sul design, consultate il web design accessibile per un mondo digitale inclusivo.

Perché la velocità conviene: il caso aziendale

I responsabili finanziano raramente “un LCP migliore”. Finanziano ricavi, lead e costi di acquisizione più bassi. L’esempio pubblico più significativo che conosciamo è Farfetch. Secondo il case study di web.dev, il retailer ha correlato i Core Web Vitals alle metriche aziendali, ha creato un “Performance Business Case Calculator” per orientare le decisioni di prodotto e lo ha utilizzato per costruire una cultura delle prestazioni tra i team. La lezione riguarda meno una singola percentuale e più il metodo: collegate ogni metrica di velocità a un KPI che i vostri dirigenti già monitorano.

Siate onesti anche riguardo ai limiti. I risultati variano in base al sito e al tipo di pagina. Un’ analisi di Blue Triangle sull’LCP afferma lo stesso: la velocità influisce sulle attività online, ma l’entità dell’impatto dipende dal design e da altri fattori. Verificate i vostri dati prima di promettere un aumento dei ricavi al consiglio di amministrazione. Il nostro articolo su come creare siti web che convertono analizza il ruolo della velocità accanto a messaggi e UX.

Mantenerlo veloce: una cultura delle prestazioni

La storia più comune è questa: un sito viene lanciato velocemente, poi rallenta nell’arco di diciotto mesi, man mano che si accumulano campagne, plugin e funzionalità. Nessuno ha deciso di renderlo lento. Nessuno si è assunto la responsabilità di mantenerlo veloce.

I professionisti citati in precedenza descrivono una “cultura delle prestazioni” basata su tre abitudini, e concordiamo con tutte:

1. Budget di prestazioni automatizzati applicati nella CI. Una pull request che porta il bundle o l’LCP oltre un limite concordato interrompe la build, proprio come accade con un test non superato.
2. Dashboard RUM leggibili dal business. Mostrate i dati sul campo al marketing e al team di prodotto, non solo all’ingegneria.
3. Revisioni periodiche tra ingegneria, prodotto e marketing. La velocità è una metrica condivisa, collegata ai KPI aziendali, non un’attività riservata al team tecnico.

Una disciplina di testing coerente è di supporto. Ambienti instabili o incoerenti producono risultati fuorvianti sulle prestazioni e sulle regressioni, motivo per cui pubblichiamo anche una guida alla gestione degli ambienti di test.

Come definire l’ambito di un progetto ad alte prestazioni

Se state pianificando un progetto, iniziate da domande che rendano il brief realistico:

• Quali pagine generano ricavi o lead e quali sono le loro metriche attuali sul campo?
• Quali dispositivi e reti utilizzano i vostri visitatori reali?
• Quali integrazioni fanno parte del percorso critico di una visualizzazione di pagina?
• Chi modifica i contenuti, con quale frequenza e come potrà pubblicarli senza compromettere le prestazioni?
• Quali sono i requisiti di accessibilità e conformità?
• Chi si occupa dei budget delle prestazioni dopo il lancio?

Per avere un contesto sui budget dei progetti più grandi, il nostro articolo sui budget per l'ingegneria del software personalizzato fornisce intervalli realistici. Le soluzioni adeguate sono migliori di quelle massime: un sito statico ben realizzato con un CMS headless spesso offre prestazioni superiori rispetto a una piattaforma elaborata, il cui funzionamento costa il triplo.

Lavorare con Ridiculous Engineering

Se desiderate affidare questo lavoro a un team senior che collabori direttamente con voi, è proprio ciò che facciamo. Ridiculous Engineering è una società di consulenza di ingegneria del software con sede in Colorado, con quartier generale a Lafayette, che progetta, realizza e modernizza siti web e applicazioni web tenendo presenti gli obiettivi aziendali, non solo il punteggio Lighthouse. Il nostro servizio di progettazione e sviluppo di siti web comprende architettura, ingegneria front-end, attività su CMS headless e UX, mentre la nostra pratica di UX e accessibilità mantiene il design inclusivo all'interno della stessa prospettiva. Se il vostro sito fa parte di un sistema più ampio, consultate il nostro lavoro di sviluppo software personalizzato oppure parlate con noi di una revisione delle prestazioni.

Domande frequenti

Come si misurano le prestazioni di un sito web?

Iniziate dai dati sul campo: il Chrome UX Report e il vostro monitoraggio degli utenti reali, valutati rispetto alle soglie dei Core Web Vitals al 75° percentile. Utilizzate Lighthouse nella CI come rapido controllo delle regressioni, non come valutazione finale. Segmentate per percorso e rilascio, così potrete collegare una modifica a una specifica distribuzione.

Qual è un buon punteggio Core Web Vitals?

Secondo web.dev, un buon risultato significa un LCP pari o inferiore a 2,5 secondi, un INP pari o inferiore a 200 millisecondi e un CLS pari o inferiore a 0,1, tutti al 75° percentile. Una pagina deve soddisfare tutti e tre i requisiti per superare la valutazione. Le soglie sono le stesse per dispositivi mobili e desktop.

Quanto costa assumere uno sviluppatore per un sito web?

Dipende dall'ambito, dalle integrazioni e dal livello di esperienza del team. Come riferimento per il costo della manodopera, il Bureau of Labor Statistics degli Stati Uniti indica uno stipendio annuo mediano di 92.650 $ per gli sviluppatori web a maggio 2025; si tratta dello stipendio e non comprende i costi generali dell'agenzia, la progettazione, il controllo qualità e la gestione del progetto. I costi dei progetti variano notevolmente, quindi chiedete a qualsiasi fornitore di specificare in dettaglio cosa è incluso.

Posso imparare da solo lo sviluppo web?

Sì, per progetti personali e siti di piccole dimensioni; i fondamenti di HTML, CSS e JavaScript sono ampiamente disponibili. Realizzare un sito destinato alla produzione con requisiti rigorosi di prestazioni, sicurezza e accessibilità è un lavoro diverso, ed è in questo ambito che gli ingegneri esperti giustificano il proprio compenso. La maggior parte dei team aziendali trae vantaggio dall'affidare l'architettura a un team senior e dal sottoporla a revisione.

Fonti

• web.dev: Web Vitals
• web.dev: caso di studio Farfetch
• Osservabilità del frontend e Web Vitals
• La scienza delle prestazioni web moderne
• Siteimprove: Core Web Vitals e WCAG
• Copertura del sondaggio sugli sviluppatori Stack Overflow 2025 (Habr)
• Blue Triangle: caso di studio su Core Web Vitals e LCP
• MDN: prestazioni web
• Bureau of Labor Statistics degli Stati Uniti: Occupational Outlook Handbook

Consigliato

• Padroneggiare l’arte delle immagini per il web: come sceglierle e ottimizzarle per il successo nel 2024
• Dalla complessità alla chiarezza: una trasformazione moderna delle prestazioni del sito web
• Costruire il web moderno: il segreto per realizzare siti web che convertono
• La necessità della velocità: padroneggiare la rapida adozione tecnologica