Note e appunti
Adattare il design alla qualità dell'energia.
Un sito web di qualunque dimensione è sempre parte di un sistema più grande, tanto per dipendenze da tecnologie esterne, software e hardware, quanto per integrazioni con CMS, CDN e molto altro, in questo articolo però parlo della dipendenza del web da qualcosa di molto più radicale, l'elettricità.
La rete elettrica che alimenta i nostri dispositivi cambia composizione nel corso della giornata: più solare nelle ore centrali, più gas nelle ore di punta serali, per alcuni paesi anche più carbone in certi mesi dell'anno. Questa variazione è misurabile in tempo reale. E la domanda che alcuni progettisti hanno iniziato a porsi è: un sito web dovrebbe potersi adattare?
Il problema delle immagini non è solo estetico
Le immagini rappresentano la quota più pesante del payload di una pagina web media. Secondo i dati del Web Almanac 2025, la home page mediana su mobile pesa 2,56 MB, di cui 911 KB sono immagini, la voce singola più pesante, seguita da 632 KB di JavaScript. Il peso totale è cresciuto del 7,8% anno su anno e del 202,8% rispetto al 2015.
Il modello Sustainable Web Design stima che i dispositivi degli utenti finali rappresentino il 54% del consumo energetico complessivo associato a una sessione web. Non i server. Non la rete. Il device in mano all'utente. E il frontend è la variabile principale che determina quanto quel device lavora.
Di fronte a questo dato, le strategie tradizionali di ottimizzazione delle immagini (compressione, lazy loading, formati moderni) sono necessarie ma non sufficienti. Intervengono sul quanto, non sul quando e sul perché.
Grid-aware: il sito che legge il contesto energetico
Green Web Foundation ha sviluppato un toolkit open-source chiamato Grid-aware Websites che permette a qualsiasi sito di interrogare le API di Electricity Maps e ricevere un segnale in tempo reale sulla carbon intensity della rete elettrica locale dell'utente: bassa, media, alta, misurata in relazione alla media mobile degli ultimi dieci giorni.
Il toolkit non applica autonomamente nessuna modifica al sito. Restituisce un flag. La decisione progettuale su cosa fare con quel flag rimane integralmente nelle mani del team che progetta il sito. Questa scelta non è tecnica: è filosofica, ed è corretta.
La rivista Branch, pubblicata da ClimateAction.tech e Green Web Foundation, ha implementato questo approccio nel redesign di Issue 9 (2025), definendo quattro stati visivi distinti in risposta alla carbon intensity della rete locale dell'utente. In modalità alta intensità carbonica, le immagini non vengono caricate automaticamente: viene invece enfatizzato l'alt text descrittivo, con la possibilità per l'utente di scegliere se caricare il contenuto visivo.
Questo è il precedente documentato che rende il pattern di cui parliamo non speculativo, ma operativo.
Il pattern: la thumbnail tipografica come risposta progettuale
La congiunzione che propongo è tra due tecniche che esistono separatamente e non sono ancora state formalizzate come design pattern unitario.
La prima è la tecnica grid-aware appena descritta. La seconda è una proprietà del CSS poco sfruttata a scopi progettuali: quando un elemento <img> non carica, smette di comportarsi come un replaced element e i suoi pseudo-elementi ::before e ::after diventano attivi. Il testo dell'attributo alt viene renderizzato dal browser come testo ordinario, e come tale è pienamente stilizzabile con CSS tipografico.
Questo significa che con un CSS appropriato è possibile trasformare l'assenza dell'immagine in una presenza tipografica progettata: un blocco testuale con font, peso, colore, dimensione, spacing definiti dal designer. Non un placeholder vuoto, non un'icona di errore. Un contenuto.
La pipeline operativa del pattern combinato è la seguente: il flag grid-aware segnala alta carbon intensity; il frontend risponde non servendo il src dell'immagine o impostando un src deliberatamente assente; il CSS intercetta lo stato broken dell'<img> e porta in primo piano l'alt text come artefatto tipografico visibile e stilizzato.
A titolo illustrativo, il CSS che governa lo stato broken è questo:
img[data-grid-high] {
display: block;
font-family: var(--font-system);
font-style: italic;
font-size: var(--size-step-1);
line-height: 1.5;
text-wrap: balance;
max-width: 42ch;
color: var(--color-text-secondary);
border-inline-start: 3px solid currentColor;
padding-inline-start: 1em;
}Il risultato è una thumbnail che non trasferisce byte di immagine, non richiede richieste HTTP aggiuntive. Esiste solo come testo nell'HTML e come regola nel foglio di stile.
Perché questo è un argomento per i committenti, non solo per i developer
Esistono tre ragioni per cui questo pattern dovrebbe interessare chi commissiona un sito, non solo chi lo costruisce.
Prima ragione: accessibilità strutturale. Il pattern obbliga a scrivere alt text significativi fin dall'inizio del processo di produzione dei contenuti. Non come requisito di conformità da soddisfare ex post, ma come contenuto primario che il sito mostrerà in determinate condizioni. Questo trasforma la qualità dell'alt text da dettaglio tecnico a decisione editoriale con visibilità diretta sull'esperienza utente. Il 95,9% dei siti web analizzati dal rapporto WebAIM Million 2025 presenta fallimenti WCAG rilevabili. L'alt text mancante o inadeguato è tra le cause più frequenti. Un vincolo progettuale che rende l'alt text visibile è un meccanismo di accountability molto più efficace di qualsiasi checklist.
Seconda ragione: differenziazione di posizionamento. Il mercato della sostenibilità digitale è oggi prevalentemente occupato da certificazioni (badge di hosting verde, carbon offset, report di emissioni). Sono strumenti necessari ma per lo più invisibili all'utente finale. Un sito che cambia visivamente in risposta alla rete elettrica locale rende percepibile la propria sensibilità ambientale senza dichiararlo. È la differenza tra un'etichetta e un comportamento.
Terza ragione: resilienza tecnica. Il pattern introduce per definizione una degradazione elegante. Un sito progettato con stati grid-aware espliciti è un sito che ha già risolto il problema del "cosa mostrare quando qualcosa non funziona". La modalità alta carbon intensity è funzionalmente identica a una modalità di connessione lenta, di dispositivo datato, di immagine non disponibile. Progettare per la rete elettrica è, lateralmente, progettare per la resilienza.
Il confine tra persuasione e manipolazione
Vale la pena nominare esplicitamente una tensione. Un sito che altera la propria presentazione visiva in risposta a dati esterni deve essere trasparente con l'utente su cosa sta accadendo e perché. Il modello Branch lo risolve con una status bar permanente e visibile che indica la modalità attiva e consente all'utente di cambiarla manualmente.
Questa scelta non è solo etica, è progettualmente corretta. Un utente che capisce perché vede testo invece di un'immagine ha un'esperienza cognitivamente coerente. Un utente che non capisce ha un'esperienza degradata percepita come errore. La trasparenza è parte del design pattern, non un'aggiunta opzionale.
Dove siamo
Il pattern è documentato come implementazione in produzione su Branch. Non esiste tuttavia ancora come astrazione formalizzata: nessun catalogo di design pattern lo nomina, nessuna linea guida di sustainable web design lo prescrive, nessun sistema di riferimento condiviso lo descrive come pratica replicabile. Green Web Foundation ha dichiarato l'intenzione di costruire un catalogo UX/UI di pratiche grid-aware nel corso del 2025, ma al momento della pubblicazione di questo articolo non è ancora disponibile.
Il territorio è aperto. Per chi progetta siti con ambizioni di sostenibilità verificabile e accessibilità strutturale, questo è un momento utile per sperimentare prima che diventi prassi consolidata.
Un'ultima nota sul limite Safari
C'è un'eccezione da dichiarare, e riguarda Safari.
Su macOS, WebKit non renderizza l'alt text di un'immagine broken se supera una singola riga. Il bug è aperto su WebKit Bugzilla. Da anni. Il numero è 5566, nel caso qualcuno volesse portargli dei fiori.
Il paradosso è geometrico: le WCAG chiedono ai progettisti di scrivere alt text descrittivi, completi, contestualmente utili. WebKit decide unilateralmente che oltre una certa lunghezza quel testo non si vede. Il risultato è che l'unico browser che penalizza la buona pratica è quello prodotto dall'azienda che più di ogni altra si racconta come garante dell'esperienza utente.
Su iOS 26 il comportamento è già corretto: l'alt text appare per intero, senza VoiceOver attivo. La soluzione esiste, quindi. È solo ferma da qualche parte tra Cupertino e il branch desktop.
Nel frattempo, chi implementa questo pattern su produzione deve tenere conto del limite e valutare un fallback esplicito lato CSS. Non è un problema del pattern: è un debito tecnico di piattaforma che ricade, come di consueto, su chi costruisce.
Riferimenti: