Un sito web che converte si basa su scelte tecniche precise, non su un accumulo di funzionalità. Abbiamo selezionato dieci caratteristiche concrete che separano un sito performante da una vetrina statica, sottolineando i punti che la maggior parte delle guide trascura: conformità all’accessibilità, budget per le performance mobile e manutenibilità del codice.
1. Budget per le performance JavaScript lato mobile
Le performance desktop mascherano spesso la realtà del campo. Su mobile, il tempo di parsing ed esecuzione del JavaScript rappresenta il principale collo di bottiglia, molto più del peso delle immagini.
Consigliamo di fissare un budget JavaScript massimo per pagina fin dalla fase di progettazione. Ogni script di terze parti (analytics, chat, pixel pubblicitario) consuma una parte di questo budget. Senza questa disciplina, il cumulo supera rapidamente la soglia accettabile e degrada l’Interaction to Next Paint (INP), la metrica Core Web Vitals che ha sostituito il FID.
Ritrovare un sito veloce dopo il fatto costa più che stabilire i limiti in anticipo. Questo principio si allinea con i consigli pratici su Zone Webmaster che insistono sulla necessità di strutturare le proprie scelte tecniche prima dello sviluppo.
2. Conformità RGAA e European Accessibility Act
Dal 28 giugno 2025, l’European Accessibility Act si applica a diversi servizi destinati ai consumatori: commercio elettronico, banche, trasporti, telecomunicazioni, libri digitali. Le microimprese beneficiano di esenzioni, ma la maggior parte dei siti di e-commerce è interessata.
In Francia, il RGAA 4.1.2 e i suoi 106 criteri suddivisi in 13 tematiche costituiscono il riferimento operativo. La conformità non si limita ad aggiungere attributi alt alle immagini. Richiede un audit strutturato, la pubblicazione di una dichiarazione di accessibilità e, a seconda dello stato dell’organizzazione, un piano pluriennale di miglioramento.
Integrare l’accessibilità fin dalla progettazione (scelta dei contrasti, struttura dei moduli, navigazione da tastiera) riduce il costo rispetto a una remediazione tardiva.
3. Architettura dell’informazione testata prima del mockup
Il sorting delle carte (card sorting) e il test dell’albero (tree testing) sono due metodi rapidi per convalidare la struttura di un sito prima di aprire Figma. Osserviamo ancora troppi progetti in cui l’albero riproduce l’organigramma interno dell’azienda invece di riflettere i percorsi reali dei visitatori.
Un test dell’albero con una decina di partecipanti è sufficiente per identificare i punti morti nella navigazione. Il costo è trascurabile rispetto a una rifacimento del menu dopo il lancio.
4. Interaction to Next Paint come metrica centrale
L’INP misura la reattività globale di una pagina tenendo conto di tutte le interazioni degli utenti, non solo della prima. Un pulsante che impiega diverse centinaia di millisecondi a reagire dopo un clic degrada direttamente la percezione della qualità.
Ottimizzare l’INP passa per il frazionamento del JavaScript in compiti brevi (yield to main thread), la riduzione dei re-render DOM non necessari e l’uso di content-visibility per le sezioni fuori schermo. Questo lavoro si svolge a livello di codice, non in un page builder.
5. Strategia di contenuto orientata all’intenzione di ricerca
Pubblicare contenuti senza mappatura dell’intenzione genera traffico non qualificato. Ogni pagina deve rispondere a un’intenzione precisa: informativa, transazionale o di navigazione.
In pratica, ciò significa che la pagina principale non deve competere con le pagine di categoria per le stesse query. La cannibalizzazione tra pagine è uno dei problemi SEO più frequenti sui siti aziendali di medie dimensioni.
6. Dati strutturati Schema.org fin dalla V1
I dati strutturati non sono un bonus post-lancio. Implementare i tag Schema.org (Organization, Product, FAQ, BreadcrumbList) fin dalla prima versione consente di accedere ai risultati arricchiti nei motori di ricerca senza debiti tecnici da recuperare.
Il markup deve essere convalidato con lo strumento di test dei risultati arricchiti di Google, quindi monitorato nella Search Console per rilevare gli errori non appena si presentano.
7. Politica di cache e CDN adattata al profilo di traffico
Un sito vetrina con contenuti aggiornati mensilmente e un sito e-commerce con un catalogo dinamico non hanno la stessa strategia di cache. Raccomandiamo di definire gli header Cache-Control per tipo di risorsa:
- File statici (CSS, JS, font): cache a lungo termine con fingerprinting nel nome del file per forzare l’invalidazione al momento del deployment.
- Pagine HTML: cache a breve termine o stale-while-revalidate per servire contenuti freschi senza attesa da parte del visitatore.
- Immagini prodotto: cache intermedia tramite CDN con purga manuale possibile in caso di cambiamento visivo.
8. HTTPS, header di sicurezza e Content Security Policy
Il certificato TLS è un prerequisito da anni, ma gli header di sicurezza HTTP sono assenti nella maggior parte dei siti professionali. Content-Security-Policy, X-Content-Type-Options, Referrer-Policy e Permissions-Policy riducono la superficie di attacco senza impatto sulle performance.
Una scansione con uno strumento come Mozilla Observatory rivela in pochi secondi gli header mancanti. La configurazione avviene a livello di server o CDN, non nel CMS.
9. Design system documentato piuttosto che mockup fissi
Un design system (componenti UI riutilizzabili, token di colore, regole di spaziatura) garantisce coerenza visiva nel tempo. Senza di esso, ogni nuova pagina o funzionalità deriva dal design iniziale.
Il design system facilita anche la collaborazione tra i team di design e sviluppo. I componenti documentati riducono i vai e vieni e accelerano le iterazioni dopo il lancio.
- Token di colore e tipografia centralizzati in variabili CSS o design tokens JSON.
- Biblioteca di componenti versionata (pulsanti, schede, moduli) con stati interattivi documentati.
- Regole di spaziatura e griglia applicate tramite utility coerenti, non valori arbitrari.
10. Piano di manutenzione e monitoraggio post-lancio
Un sito web è un servizio, non un deliverable fisso. Senze monitoraggio attivo, le regressioni delle performance e le vulnerabilità di sicurezza si accumulano silenziosamente.
Il piano di manutenzione copre almeno gli aggiornamenti del CMS e delle sue estensioni, il monitoraggio dei Core Web Vitals tramite la Search Console e un audit di accessibilità annuale per mantenere la conformità RGAA. Prevedere un budget ricorrente per questa manutenzione evita rifacimenti completi ogni tre anni.
Queste dieci caratteristiche non funzionano in isolamento. Un sito veloce ma inaccessibile perderà una parte crescente del suo pubblico legale. Un sito accessibile ma non mantenuto accumulerà vulnerabilità. Le performance di un sito web si misurano alla solidità del suo anello più debole.
