Vai al contenuto principale

Standard che si possono verificare

Dire di tenere alla qualità è facile. Questa pagina elenca gli standard che applico come software engineer — dall'architettura di un backend a un sistema agentico — e usa questo sito come il pezzo che puoi controllare tu, subito, senza fidarti di me.

Guarda le misure

Il campione verificabile

Un sito è l'unica parte del mio lavoro che puoi auditare senza il mio permesso: è pubblica, ed esistono strumenti standard per misurarla. Per questo la uso come campione. Non è il perimetro di quello che faccio — è la parte che si può controllare.

Rilevate con Lighthouse su www.andrealosavio.com/it, profilo mobile, il 17 agosto 2026.

100
Accessibilità
100
Best Practices
100
SEO

Core Web Vitals

LCP
1,07 s
CLS
0,00
TTFB
36 ms

Largest Contentful Paint, Cumulative Layout Shift, Time To First Byte. Le soglie considerate buone sono rispettivamente 2,5 s, 0,1 e 800 ms.

La categoria Performance di Lighthouse non compare qui perché il suo punteggio dipende dal throttling di rete e CPU della macchina che esegue il test: pubblicare un numero senza le stesse condizioni sarebbe fuorviante. Trovi al suo posto le metriche grezze, che sono confrontabili.

Rimisuralo tu

Apri DevTools su una qualsiasi pagina di questo sito, scheda Lighthouse, profilo mobile, e premi Analizza. Nessuna delle affermazioni di questa sezione richiede di fidarsi di me.

19 pagine prerenderizzate al build, generate in 244 ms.

Gli standard, area per area

Ogni voce è una scelta di progettazione, non un'intenzione.

Quello che puoi verificare qui

Misurabile con strumenti pubblici, su questo dominio, in un minuto.

Accessibilità

  • Skip link verso il contenuto principale come primo elemento focalizzabile
  • Ogni controllo senza testo visibile espone un aria-label tradotto
  • Nome accessibile che contiene sempre l'etichetta visibile (WCAG 2.5.3)
  • Focus visibile su ogni elemento interattivo, mai rimosso
  • prefers-reduced-motion rispettato a livello globale
  • Ruoli ARIA solo dove servono: mai sovrascrivere la semantica nativa

Performance

  • Pagine prerenderizzate staticamente e servite dalla cache CDN
  • Cumulative Layout Shift a zero: nessun salto di contenuto in caricamento
  • Immagini in WebP, nessun asset oltre i 72 KB
  • Font self-hosted e precaricati, senza richieste a domini terzi
  • Traduzioni caricate per rotta: una pagina non spedisce cataloghi che non usa
  • Rendering lato server dove l'interattività non serve, per non pagare l'idratazione

SEO e leggibilità per le macchine

  • URL canonico e hreflang da un'unica sorgente, senza segnali in conflitto
  • Dati strutturati JSON-LD collegati in un unico grafo di entità con @id stabili
  • Sitemap multilingua con alternates dichiarati per ogni URL
  • llms.txt pubblico e mantenuto, conforme alle raccomandazioni
  • Contenuto presente nell'HTML servito, non generato dopo l'idratazione
  • Redirect 301 permanenti da ogni vecchio indirizzo, per non perdere storia

Quello che un sito non può mostrare

La parte del lavoro che vive dietro un'API, dentro un'app o in un sistema agentico — dove Lighthouse non arriva e conta come è progettata.

Architettura & API

  • Confini espliciti tra moduli: ogni unità ha uno scopo dichiarabile in una frase
  • Validazione degli input al bordo del sistema, prima di ogni logica di business
  • Errori tipizzati e distinti per destinatario: cosa vede l'utente, cosa vede chi mantiene
  • Stato di dominio separato dallo stato di trasporto, per poter cambiare l'uno senza l'altro
  • Decisioni architetturali prese per vincoli reali, non per moda tecnologica
  • Scelte reversibili quando il costo dell'errore è alto e il contesto è incerto

Dati & persistenza

  • Schema come fonte di verità, con migrazioni versionate e reversibili
  • Vincoli di integrità nel database, non solo nel codice applicativo
  • Indici progettati sulle query reali, non aggiunti a posteriori sui sintomi
  • Query N+1 trattate come difetti di progettazione, non come problemi di carico
  • Caching con invalidazione esplicita: mai una cache di cui non si sa quando scade
  • PostgreSQL, MongoDB o Redis scelti per il modello di accesso, non per abitudine

AI engineering & sistemi agentici

  • Output strutturati e validati: nessuna risposta di un modello entra nel sistema senza schema
  • Tool e function calling con contratti espliciti e fallimenti gestiti
  • Orchestrazione multi-agent con deleghe e responsabilità dichiarate
  • Gestione del contesto come risorsa finita: cosa entra, cosa si riassume, cosa si scarta
  • Modelli intercambiabili dietro un confine, inclusi quelli locali via Ollama
  • Costi e latenza trattati come requisiti di progetto, non come sorprese a fine mese

Mobile & cross-platform

  • Un'unica base di codice React Native ed Expo, senza divergenze fra le piattaforme
  • Convenzioni native rispettate dove l'utente se le aspetta
  • Stato offline previsto in progettazione, non aggiunto quando arrivano le segnalazioni
  • Aggiornamenti e rilasci automatizzati, con versioni tracciabili
  • Prodotti reali in store, non solo prototipi: Fast Memo, oltre 1.000 download in 7 lingue
  • Componenti open-source estratti e mantenuti quando hanno valore oltre il progetto

Sicurezza, delivery & manutenibilità

  • Segreti solo lato server: nessuna chiave raggiungibile dal client, mai
  • Difesa a strati sugli endpoint pubblici: origine, rate limit, CSRF, validazione, in quest'ordine
  • Nessun input utente riecheggiato nelle risposte di errore
  • TypeScript in modalità strict, senza eccezioni e senza indebolire la configurazione
  • Pipeline CI che blocca su tipi, lint e build prima di ogni rilascio
  • Codice che si spiega da sé: nomi espliciti al posto dei commenti, costanti condivise contro la divergenza

Vuoi questo livello di cura sul tuo prodotto?

Applico gli stessi standard ai progetti dei clienti, dal backend all'app mobile ai sistemi AI. Se ti serve qualcuno che tratti la qualità come un requisito e non come un extra, parliamone.