Al keynote di Config 2026 Figma ha mostrato aurore, vetro smerigliato e cromature generate dalla scheda grafica a partire da una descrizione a parole. Si chiamano shader: piccoli programmi che dicono alla scheda grafica come colorare ogni singolo pixel, e che da quest’anno si possono generare scrivendo cosa si vuole vedere. Ho guardato quelle demo pensando la cosa più banale del mondo: le voglio sul mio sito. Il mio sito è un WordPress del 2020 con tema Salient, su un hosting economico dove non posso installare nulla, che blocca le modifiche automatiche e con un editor che cancella il codice degli effetti se lo incollo nel contenuto. Ieri sera l’aurora era live nella hero, la sezione in cima alla home.
Per anni questo genere di effetti è stato territorio di studi con un creative developer in organico e budget a cinque cifre. I siti premiati su Awwwards, la vetrina dei siti più spettacolari del web, li guardavamo da lontano. Config 2026 ha spostato la conversazione: se uno shader si genera descrivendolo, resta un solo ostacolo vero, portarlo dentro sistemi reali con i loro vincoli reali.
Si decide guardando i pixel muoversi
Come si decide se un effetto merita la produzione? Io ormai giudico solo pixel che si muovono. Ho fatto costruire a Claude Code tre mock in un unico file HTML che si apre nel browser: un’aurora liquida che si increspa al passaggio del mouse, un titolo che sembra cromo fuso, e delle immagini di copertina mostrate in mezzatinta, come i puntini di una stampa su giornale, che tornano a colori quando ci passi sopra col cursore. Aperti, guardati, verdetto in pochi secondi. L’aurora mi ha convinto subito; gli altri due aspettano il loro turno in una cartella. Qualche giorno fa, con lo stesso metodo, avevo bocciato un effetto tipografico con una parola sola: tremenda. Descrivere un’animazione a parole è un esercizio di fantasia per entrambi, per me e per chi la deve costruire. Il mock costa dieci minuti e trasforma la decisione in un sì o un no istantaneo.
Innestare senza rompere niente
La seconda scelta è quella che mi sta più a cuore: come entra uno shader del 2026 in un WordPress che cancella il suo codice dal contenuto? Per innesto. Lo shader disegna dentro un canvas, un’area della pagina che il browser affida alla scheda grafica. Se lo incollo nel contenuto, l’editor lo elimina. Allora la pagina resta com’era, e quel canvas lo aggiunge un piccolo script del tema mentre la pagina si carica. Il vecchio gradiente statico resta lì sotto come rete di sicurezza: se il browser del visitatore non supporta WebGL, la tecnologia che fa girare lo shader, ricompare da solo e nessuno si accorge di niente. Chi ha attivato nel sistema l’opzione “riduci le animazioni”, spesso per motivi di accessibilità, vede un fotogramma fermo. Quando la hero esce dallo schermo, lo shader si mette in pausa. È progressive enhancement: si parte da una pagina che funziona ovunque e si aggiunge il meglio solo dove il browser lo regge. Lo insegnavamo nel 2008, e oggi tiene in piedi un effetto da keynote su un hosting da pochi euro al mese.
Il wow come metodo
La distanza tra “visto al keynote” e “live in produzione” si è accorciata fino a stare dentro un pomeriggio. Quello che la tiene corta ha poco di magico. Ogni passaggio, dal mock alla pagina pubblicata, si può controllare prima di andare avanti. Ogni cosa nuova ha sotto una versione vecchia pronta a riapparire. E se qualcosa va storto, un comando riporta il sito a com’era prima. Il wow oggi dipende dal metodo più che dal budget, e un metodo lo può mettere in piedi chiunque abbia la pazienza di verificare ogni passo.
Voi come decidete se un effetto merita la produzione? Guardate un mock che si muove o vi fidate ancora delle descrizioni?
Ciao ciao!
