Strumenti web per siti duraturi: icone, font, link

Un sito dura se le sue fondamenta sono verificabili: icone con licenza chiara e alternative testuali, scale tipografiche definite in unità relative, immagini compresse senza perdita visibile, metriche di caricamento misurate sul campo e link controllati con regolarità. Non serve un framework nuovo ogni anno, servono scelte documentate e strumenti che le mantengano in ordine. Chi lavora su piccoli siti trova in guide come strumenti web affidabili un riferimento pratico per queste decisioni, dal design alla manutenzione.

Come si sceglie un set di icone con licenza e accessibilità?

La prima verifica riguarda la licenza, non l'estetica. Un set di icone può essere distribuito con licenza permissiva (MIT, Apache 2.0, CC0), con licenza che richiede attribuzione (CC BY) o con licenza che vieta l'uso commerciale (CC BY-NC). Se il sito ha anche solo un banner pubblicitario o un link affiliato, un set NC è fuori discussione. Leggi il file LICENSE nella repository, non la pagina di presentazione: a volte la pagina dice "free" e il file dice altro.

Il secondo controllo è tecnico. Le icone decorative, cioè quelle che accompagnano un testo già comprensibile, vanno marcate con aria-hidden="true" e focusable="false" se sono SVG inline. Le icone che sostituiscono un testo, per esempio il cestino che significa "elimina", hanno bisogno di un'etichetta accessibile: <button aria-label="Elimina"> oppure un <title> dentro l'SVG. Un'icona sola, senza etichetta, è invisibile a chi usa uno screen reader.

Il terzo punto è la coerenza. Mescolare icone con spessori diversi (1.5px e 2px) e angoli diversi si nota subito, soprattutto nelle barre di navigazione. Scegli un set con griglia coerente, esporta in SVG, e imposta fill="currentColor" così l'icona eredita il colore del testo e funziona anche in modalità scura. Se il set non ha una versione per il tema scuro, non è un problema: currentColor risolve senza duplicare i file.

Infine, la dimensione. Un'icona da 16px con dettagli fini diventa una macchia. Verifica il set a 16, 24 e 32px prima di adottarlo: se a 16px non si distingue, serve una variante semplificata o un'icona diversa.

Che cosa misurano davvero i Core Web Vitals?

I Core Web Vitals sono tre metriche che descrivono l'esperienza reale di caricamento, non la velocità del server. La prima è LCP (Largest Contentful Paint): misura quando l'elemento più grande visibile nella viewport, di solito un'immagine hero o un blocco di testo, è renderizzato. La soglia "buona" è entro 2,5 secondi. La seconda è INP (Interaction to Next Paint), che dal marzo 2024 ha sostituito il FID: misura il ritardo tra un'interazione dell'utente (clic, tap, pressione di un tasto) e il momento in cui la pagina risponde visivamente. La soglia è 200 millisecondi. La terza è CLS (Cumulative Layout Shift): misura quanto gli elementi si spostano durante il caricamento, con soglia 0,1.

Il punto che sfugge spesso: questi valori si misurano sul campo, con dati reali degli utenti (CrUX), non solo in laboratorio con Lighthouse. Un sito può avere 100 in Lighthouse e un LCP scarso sul campo, perché l'utente reale ha una connessione lenta, un dispositivo vecchio o un'estensione che rallenta il rendering. Per questo conviene guardare entrambi: il laboratorio serve a capire cosa ottimizzare, il campo dice se l'ottimizzazione ha funzionato.

Le cause più comuni di LCP alto sono immagini non compresse, font bloccanti e server lenti a rispondere. Per INP, il colpevole è quasi sempre JavaScript che occupa il thread principale. Per CLS, immagini senza width e height dichiarati e banner inseriti dopo il caricamento. Sono problemi risolvibili senza riscrivere il sito.

Come comprimere le immagini senza rovinarle

La compressione si fa in due passaggi. Prima si sceglie il formato: JPEG per le fotografie, WebP o AVIF per quasi tutto il resto, PNG solo quando serve trasparenza e non si può usare altro. AVIF comprime meglio di WebP ma richiede più tempo di codifica e non è supportato ovunque, quindi la pratica comune è servire AVIF con fallback WebP tramite <picture>.

Poi si ridimensiona. Un'immagine da 4000px di larghezza mostrata in un contenitore da 800px è uno spreco: il browser scarica pixel che non userà. Esporta alla dimensione massima di visualizzazione, moltiplicata per 2 se vuoi coprire gli schermi retina, e non oltre. Per le immagini responsive, genera più varianti con srcset e sizes.

La qualità va verificata a occhio, non solo con il numero. Un JPEG a qualità 75 è spesso indistinguibile da uno a 95 su una fotografia, ma pesa la metà. Strumenti come Squoosh o ImageOptim permettono di confrontare prima e dopo. Attenzione al testo nelle immagini: la compressione lossy lo rovina prima di tutto il resto, quindi se l'immagine contiene scritte, valuta SVG o PNG.

Come si controllano i link di un sito in modo automatico?

Il controllo manuale dei link non regge oltre poche decine di pagine. La soluzione è uno script che parte dalla homepage, segue i link interni, raccoglie tutte le URL e verifica lo stato HTTP di ciascuna. Gli strumenti pronti esistono: linkchecker, lychee, htmltest, oppure servizi online che fanno la stessa cosa senza installare nulla.

Lo script va eseguito a intervalli regolari, per esempio una volta a settimana, e deve distinguere tra tipi di errore. Un 404 è un link rotto e va corretto o rimosso. Un 301 è un redirect permanente: va aggiornato il link diretto, non lasciato passare. Un 403 può essere un blocco temporaneo del server remoto, non un link morto. Un timeout non è un errore finché non si ripete.

Oltre ai link esterni, conviene controllare i link interni e i frammenti (#sezione). Un'ancora che punta a un ID rimosso non dà errore HTTP ma non porta da nessuna parte. Lo stesso vale per i link nelle mappe del sito e nei feed RSS, che spesso invecchiano senza che nessuno se ne accorga.

Il risultato del controllo va in un file di report, non letto a mano ogni volta. Se il sito è su un repository Git, si può aggiungere un'azione che esegue il controllo a ogni push e fallisce se trova 404. Così il problema si vede subito, non sei mesi dopo.

Documentare le scelte per non rifarle

Ogni decisione presa sopra ha una data e una motivazione. Il set di icone è stato scelto perché ha licenza MIT e varianti a 16px. La scala tipografica usa clamp() con valori minimi e massimi testati su mobile. Le immagini sono in AVIF con fallback WebP. I Core Web Vitals sono monitorati sul campo. I link sono controllati ogni lunedì.

Scrivere queste righe in un file README o in una pagina interna del progetto costa mezz'ora e ne fa risparmiare molte. Chi eredita il sito, che sia un collega o il committente stesso, capisce perché le cose sono fatte in un certo modo e non le disfa per ignoranza. Un sito duraturo non è quello che non cambia mai, è quello che cambia senza rompersi.

Per le verifiche di conformità e per i riferimenti tecnici sulle metriche di caricamento, la fonte da tenere aperta è la documentazione ufficiale di web.dev, che raccoglie le definizioni aggiornate di LCP, INP e CLS.

Chi assembla e ripara PC conosce il valore di un metodo: si misura, si annota, si corregge. Lo stesso criterio vale per il risparmio, dove le decisioni prese a sensazione costano quanto un componente scelto male. Un piano di accumulo si costruisce con versamenti regolari, ribilanciamenti a soglia e una lettura attenta del ciclo economico, non con le previsioni del momento. Prima di scegliere un prodotto conviene capire come investire con metodo: orizzonte, perdita sostenibile e liquidità sono i parametri da fissare, esattamente come si fa con i watt di un alimentatore.

Fonti: web.dev