Una favicon mi ha ricordato che un restyling non parte mai davvero da zero

Il sito nuovo mostrava ancora un colore vecchio

Qualche giorno dopo la pubblicazione di un restyling ho notato la favicon nella scheda del browser. Era quella prevista, ma conservava ancora i colori del vecchio marchio. Nel resto del sito la nuova identità era presente. In quel piccolo spazio, invece, era sopravvissuta la precedente.

Non impediva a una pagina di aprirsi, non rendeva il sito più lento e non bloccava alcuna funzione. Proprio per questo è il genere di dettaglio che può passare inosservato durante i controlli concentrati sugli aspetti più importanti del progetto.

L’ho corretta. Avrei potuto considerare chiuso l’episodio in pochi minuti, perché l’impatto tecnico era minimo. Mi è sembrato più utile fermarmi su ciò che quella favicon rappresentava: non un problema del nuovo codice, ma una traccia del progetto precedente rimasta dentro il passaggio al nuovo sito.

Era un errore piccolo. Restava comunque un errore, e il fatto che fosse piccolo non lo rendeva invisibile al marchio.

Ricostruire tutto non significa partire dal vuoto

Quando realizzo un sito nuovo posso definire dall’inizio struttura, file, immagini, metadati e comportamenti. Non significa che il lavoro sia automaticamente perfetto, ma il perimetro nasce insieme al progetto e ogni elemento ha una collocazione precisa.

Nel mio lavoro un restyling non consiste nel cambiare qualche colore sopra il sito esistente. Significa riprogettare e ricostruire il sito con lo stesso metodo usato per un progetto nuovo. La differenza è che, prima della nuova struttura, esiste già una storia: un dominio attivo, contenuti, file, icone, risultati indicizzati, materiali del marchio e talvolta configurazioni stratificate negli anni.

Alcuni elementi devono essere conservati. Altri vanno trasformati. Altri ancora devono scomparire. La difficoltà non è soltanto produrre correttamente ciò che viene dopo, ma riconoscere tutto ciò che apparteneva a prima e decidere che cosa farne.

Una favicon non decide la qualità del sito. Fa parte della sua coerenza

Non voglio attribuire a una favicon un’importanza che non ha. I vecchi colori non compromettevano la sicurezza, la SEO, la responsività o l’usabilità del sito. Non cancellavano il lavoro svolto e non modificavano il funzionamento delle pagine.

La favicon, però, compare nella scheda del browser, nei preferiti e in altri punti in cui il sito viene riconosciuto attraverso uno spazio molto piccolo. È un dettaglio, ma è anche una firma. Se conserva il vecchio marchio mentre tutto il resto ne presenta uno nuovo, il racconto non è completamente coerente.

Per questo distinguo la gravità dalla correttezza. Non tutti gli errori hanno lo stesso peso e sarebbe poco serio trattarli come equivalenti. Un problema di sicurezza richiede una priorità diversa da un colore rimasto in un’icona. Ma anche il secondo va riconosciuto e corretto, senza nasconderlo dietro il fatto che il sito funzioni.

Puntare al 100 non significa dichiararsi infallibili

Nei siti che realizzo punto al massimo risultato possibile per prestazioni, accessibilità, buone pratiche e SEO. Tengo la sicurezza, la responsività e l’usabilità dentro il progetto fin dall’inizio. Sono obiettivi concreti, accompagnati da controlli e strumenti precisi.

Un punteggio Lighthouse misura determinate condizioni in un momento preciso. Non controlla che il colore di una favicon corrisponda al marchio, non conosce tutte le intenzioni del progetto e non certifica l’assenza di qualsiasi imperfezione umana. Confondere un risultato misurato con una garanzia universale renderebbe quel numero meno serio, non più autorevole.

Per me puntare al 100 significa non accontentarmi consapevolmente di un problema evitabile. Significa anche continuare a osservare dopo la pubblicazione, perché il sito reale vive su browser, dispositivi e percorsi che nessun singolo controllo può esaurire.

Il rigore non consiste nel sostenere che nulla possa sfuggire. Consiste nel non ignorare ciò che emerge.

La pubblicazione non è il momento in cui smetto di guardare

Durante lo sviluppo i controlli servono a impedire che problemi noti arrivino online. Dopo la pubblicazione cambia il contesto: il sito viene caricato dalla sua destinazione definitiva, incontra cache, cronologie e comportamenti reali del browser e mostra particolari che, dentro il flusso di lavorazione, potevano avere meno evidenza.

Questo non deve diventare una giustificazione per pubblicare senza verificare. È il motivo per cui considero il controllo successivo parte del lavoro, non un’attività facoltativa da svolgere soltanto se qualcuno segnala un problema.

La favicon con i vecchi colori ha aggiunto una domanda molto semplice al modo in cui osservo un restyling: esistono ancora segni della precedente identità nei punti meno visibili del progetto? Non soltanto nelle pagine principali, ma anche negli elementi che accompagnano il sito e lo fanno riconoscere.

Una procedura utile non nasce perché chi lavora non può sbagliare. Nasce perché affidarsi soltanto all’attenzione del momento non è sufficiente quando il progetto contiene molte parti e una storia da migrare.