Competenza · Siti web
Costruiamo siti renderizzati lato server, con immagini in AVIF e WebP, intestazioni di sicurezza verificate dall’esterno, sitemap generata dai dati e un controllo di accettazione eseguito dopo ogni pubblicazione. Tutto è ispezionabile sulla pagina che state leggendo.
Già costruitoNon possiamo citare un sito cliente senza il suo consenso, ma non ne abbiamo bisogno: la prova è proprio questa pagina. Esegue Next.js 16.2.4 con React 19.1.0, è servita prerenderizzata da cache (`x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`), presenta HSTS con `preload`, `nosniff`, `SAMEORIGIN`, `Referrer-Policy` e una policy di contenuto completa — verificati con `curl -I` il 06.09.2026. La mappa del sito contiene 147 indirizzi, tutti generati dai dati, non scritti a mano. La seconda implementazione, nello stesso deposito: l’infrastruttura del modulo — registro append-only, sonda pubblica di salute, limitazione di frequenza — e lo script di accettazione eseguito dopo la pubblicazione.
Un sito vetrina ha un solo test onesto: potete verificare dall’esterno ciò che l’azienda dice di esso? Per questo questa pagina non elenca tecnologie, ma cose che potete controllare da soli con un comando. Il sito esegue Next.js 16.2.4 e React 19.1.0, e le pagine sono prerenderizzate in fase di build e servite dalla cache — si vede negli header della risposta: `x-nextjs-prerender: 1`, `x-nextjs-cache: HIT`, `s-maxage=31536000`, con una finestra di 300 secondi in cui una pagina vecchia può ancora essere servita mentre si aggiorna.
Il rendering lato server non è una preferenza d’architettura. Un visitatore con connessione debole e un motore di ricerca ricevono lo stesso HTML completo, senza attendere JavaScript. A questo si aggiunge la disciplina delle risorse: le immagini escono in AVIF e WebP, con cache di un anno; i font sono ospitati da noi, non richiesti a un servizio esterno; otto librerie di interfaccia hanno import ottimizzati per non trascinare moduli interi per una sola icona.
Le intestazioni di sicurezza vengono inviate da due punti e verificate nella risposta reale, non solo nella configurazione: trasporto sicuro imposto per due anni con sottodomini e inserimento nella lista di preload, divieto di sniffing del tipo di file, restrizione dall’inquadramento in frame esterni, politica del referrer e una politica di permessi che chiude la camera e lascia il microfono solo per la propria origine — perché le dimostrazioni vocali ne hanno bisogno e, senza questa eccezione, il browser rifiuta in silenzio.
L’ultima parte è quella che ci distingue, ed è sgradevole: pubblichiamo anche ciò che abbiamo misurato male da noi. Il server non offre ancora Brotli né HTTP/2. Il catalogo delle traduzioni viene trasmesso a ogni navigazione e costa circa 70 KB compressi ogni volta. Un pacchetto di 443 KB contiene quattro cataloghi di lingua, di cui solo uno è instradabile. I font includono anche il subset cirillico, sebbene le pagine verificate non contengano alcun carattere cirillico. Queste cifre sono misurate, scritte nel deposito e nell’elenco delle riparazioni. Un fornitore che non ha simili cifre sul proprio sito o non ha misurato, o non vuole dirlo.
Cosa comprende
Le pagine sono prerenderizzate in fase di build e consegnate come HTML completo, non costruite nel browser. Nella risposta reale compaiono `x-nextjs-prerender: 1` e `x-nextjs-cache: HIT`, con `cache-control: s-maxage=31536000` e una finestra di 300 secondi in cui la versione vecchia può ancora essere servita mentre si aggiorna. L’effetto pratico: un visitatore con connessione debole e un crawler ricevono lo stesso contenuto, nella stessa richiesta.
I formati configurati sono AVIF e WebP, con durata minima di cache di 31.536.000 secondi — un anno — e intestazione `immutable` sui file statici, immagini e font. I font sono ospitati da noi in fase di build, non richiesti a un servizio esterno a ogni visita, e sono visualizzati con `swap`, così il testo appare prima del download del font. Esiste anche uno script di compressione in batch, con qualità 80 per WebP e 75 per AVIF, così la sorgente non dipende da ciò che qualcuno ha esportato dall’editor grafico.
Dall’applicazione: trasporto sicuro imposto per 63.072.000 secondi con sottodomini e inserimento nella lista di preload, `X-Content-Type-Options: nosniff`, `X-Frame-Options: SAMEORIGIN`, `Referrer-Policy: strict-origin-when-cross-origin` e una politica di permessi che chiude la camera, lascia il microfono solo per la propria origine e disattiva il raggruppamento per interessi. Dal server web, separatamente: una politica di sicurezza del contenuto completa, con l’elenco esplicito delle origini consentite. Nella consegna si scrive esplicitamente che sono due punti — altrimenti il prossimo che modifica qualcosa cerca quello sbagliato.
La mappa del sito si costruisce da cinque fonti — 13 indirizzi fissi, gli articoli, 19 prodotti, 12 servizi e 100 combinazioni servizio × dominio — e passa attraverso una deduplicazione finale. Risultato: 147 indirizzi, contati sia nel codice sia nel file servito in produzione. Una nuova pagina entra automaticamente; una cancellata scompare. Nessuno mantiene un elenco parallelo che si desincronizza in tre settimane.
Una pulizia di struttura lascia dietro di sé indirizzi che qualcuno ha salvato o pubblicato. Nella configurazione ci sono 43 reindirizzamenti permanenti — 9 guide al blog, 20 articoli orfani, 6 case study rimappati e 8 pagine singole. Ci sono anche 11 pagine che reindirizzano dall’interno dell’applicazione; sono corrette dal punto di vista funzionale, ma più costose di una regola di configurazione, e sono indicate come tali nell’elenco delle riparazioni.
La richiesta viene scritta in un log append-only prima di tentare la consegna, con una seconda riga per l’esito; esiste una sonda pubblica di salute che dice se un lead può raggiungere un operatore umano in questo momento; e le richieste alle interfacce sono limitate a 10 al minuto, con la chiave presa dall’ultimo hop dell’intestazione degli indirizzi reindirizzati, non dal primo — il primo è inviato dal cliente. I motivi sono scritti nel codice, non in una documentazione separata.
Uno script apre ogni pagina prodotto, in gruppi di tre, e fallisce se manca il codice 200, l’ancora delle domande, l’ancora dell’esempio o l’indirizzo canonico. Verifica poi la mappa del sito — che contenga ogni prodotto e non contenga varianti di lingua che non si possono aprire — e `robots.txt`, che non blocchi le risorse necessarie al rendering. Ogni verifica corrisponde a qualcosa che si è già rotto una volta.
L’indirizzo canonico è dichiarato in modo relativo, in un solo punto della configurazione di base, e si risolve per ciascun percorso in parte. La stessa soluzione vale per l’indirizzo di condivisione social, che prima dichiarava la pagina iniziale sulla maggior parte delle pagine. È una riga di codice che sostituisce una convenzione che ogni nuova pagina avrebbe dovuto ricordare da sola — e che, inevitabilmente, non ricorda.
Il repository contiene un file dei difetti noti che spiega, per esempio, perché le varianti linguistiche nell’indirizzo non commutano la lingua, perché la soluzione ovvia peggiora le cose — nel rendering lato server non esistono né local storage né browser, quindi il detector cade sull’inglese e tutte le pagine escono in inglese — e quali sono le due soluzioni reali. Preferiamo che un acquirente tecnico trovi il limite scritto da noi, non scoperto da lui.
Come si presenta
La prima consegna è l’elenco degli indirizzi esistenti e la decisione per ciascuno: rimane, viene reindirizzato oppure scompare. Su questo sito ne sono risultati 43 reindirizzamenti permanenti. È il lavoro che tutti saltano e che produce, qualche mese dopo, pagine di errore nei risultati di ricerca.
Le pagine di prodotto e di servizio si costruiscono dai dati, non da file separati. Da qui derivano la sitemap generata automaticamente, gli indirizzi canonici coerenti e la possibilità di verificare in modo programmatico che ogni pagina abbia ciò che serve. Consegnamo la struttura dei dati, non solo le pagine renderizzate da essa.
Stabiliamo fin dall’inizio quale formato hanno le immagini, cosa viene messo in cache e per quanto, cosa viene renderizzato sul server e cosa resta interattivo nel browser. I contenuti vengono poi inseriti in questo budget. L’ordine inverso produce siti che sembrano bene al lancio e si appesantiscono con ogni pagina aggiunta.
La pubblicazione verifica la memoria libera del server, esegue l’audit di sicurezza delle dipendenze, costruisce da pulito e conferma che il processo è avviato prima di segnalare il successo. Subito dopo, lo script di accettazione apre le pagine e verifica le ancore, gli indirizzi canonici, la sitemap e `robots.txt`. Entrambi vengono consegnati, non restano da noi.
Consegniamo il codice, la procedura di pubblicazione, la procedura di rollback, gli indirizzi di health — e l’elenco scritto di ciò che non è coperto, con cifre. Per questo sito l’elenco include l’assenza di Brotli e di HTTP/2 sul server, il costo del catalogo delle traduzioni a ogni navigazione e il subset di font non utilizzato. Preferiamo che l’elenco venga da noi.
I dati
Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.
Un caso
La situazione
Dopo una ristrutturazione, il sito proprio sembrava a posto: tutte le pagine rispondevano 200, il cruscotto era verde. Ci siamo posti la domanda che poniamo ai clienti: che cosa dice una misurazione fatta dall’esterno, su tutti gli indirizzi insieme, non sulla home page?
Cosa abbiamo costruito
Abbiamo passato in rassegna con richieste dirette ogni indirizzo noto — 249 indirizzi, 23 colonne per indirizzo, senza seguire i reindirizzamenti, con al massimo sei richieste in parallelo — e abbiamo messo il risultato in un file tabellare versionato. Su di esso abbiamo eseguito verifiche separate: la compressione reale dell’HTML, ciò che viene trasmesso a ogni navigazione, ciò che contengono i pacchetti JavaScript, quali font vengono scaricati, quali intestazioni di cache e di trasporto offre il server. Ogni cifra è stata verificata nella risposta reale, non dedotta dalla configurazione.
Cosa è emerso
244 indirizzi rispondono 200 e 5 reindirizzano. 131 pagine non avevano indirizzo canonico, e 219 su 244 dichiaravano la home page come indirizzo di condivisione — entrambe corrette ora con una riga nell’assetto di base, che si applica a ogni route. Il server non offre Brotli né HTTP/2. Il catalogo delle traduzioni, 2.268 chiavi, viene trasmesso a ogni navigazione e costa circa 70 KB compressi ogni volta. Un pacchetto da 443 KB contiene quattro cataloghi di lingua, di cui solo uno è instradabile. I font portano anche il sottoinsieme cirillico, sebbene le pagine verificate non contengano alcun carattere cirillico. Tutte le cifre, con i comandi che le riproducono, sono scritte nel deposito.
Cosa non dice il caso
Si tratta di misurazioni di laboratorio, fatte dall’esterno, con richieste dirette. Non sono dati di campo di visitatori reali e non li presentiamo come tali: le metriche di carico percepito non hanno potuto essere lette nello strumento usato e sono segnate esplicitamente come non misurate. Non abbiamo eseguito la build dell’applicazione durante l’audit, perché più persone lavoravano sullo stesso checkout.
Domande
Next.js 16.2.4 con React 19.1.0 e TypeScript, con Tailwind per gli stili e componenti di interfaccia accessibili basati su primitive Radix. Le pagine sono prerenderizzate alla build e servite dalla cache — si verifica dall’esterno: le intestazioni della risposta contengono `x-nextjs-prerender: 1` e `x-nextjs-cache: HIT`. Non è un elenco di tecnologie che abbiamo letto; è lo stack su cui gira la pagina che state leggendo ora.
Con un solo comando: `curl -I https://www.megapromoting.com/servicii`. Vedrete `strict-transport-security: max-age=63072000; includeSubDomains; preload`, `x-content-type-options: nosniff`, `x-frame-options: SAMEORIGIN`, `referrer-policy: strict-origin-when-cross-origin`, una policy dei permessi che chiude la camera e lascia il microfono solo per la propria origine, più una content security policy con l’elenco esplicito delle origini. I primi cinque provengono dalla configurazione dell’applicazione; l’ultima è inviata dal server web — due luoghi diversi, e lo scriviamo alla consegna.
Da uno script di accettazione eseguito dopo la pubblicazione. Apre ogni pagina di prodotto e fallisce se manca il codice 200, l’ancora delle domande, l’ancora dell’esempio o l’indirizzo canonico; verifica poi che la mappa del sito contenga ogni prodotto e non contenga varianti di lingua che non si aprono, e che `robots.txt` non blocchi le risorse di rendering. Ogni verifica nell’elenco corrisponde a qualcosa che si è già rotto. Lo script viene consegnato insieme al progetto — potete eseguirlo anche voi.
Dipende da cosa misurate, e abbiamo cifre in entrambe le direzioni. Buone: le pagine sono prerenderizzate e servite dalla cache, le immagini escono in AVIF e WebP con cache di un anno, i font sono ospitati localmente. Cattive, misurate sul proprio sito: il server non offre Brotli né HTTP/2 — una richiesta con `Accept-Encoding: br` riceve una risposta non compressa; il catalogo delle traduzioni viene trasmesso a ogni navigazione e costa circa 70 KB compressi ogni volta; un pacchetto di 443 KB contiene quattro cataloghi di lingua, di cui solo uno è instradabile. Non le do un punteggio da laboratorio; le do gli ottetti misurati e l’elenco delle correzioni che ne deriva.
Nessuno, ed è la risposta corretta. Si genera da cinque fonti di dati — indirizzi fissi, articoli, prodotti, servizi e le combinazioni servizio × dominio — e passa attraverso una deduplicazione finale. Ne risultano 147 indirizzi, la stessa cifra nel codice e nel file servito in produzione. Una nuova pagina entra automaticamente. Ciò che manca oggi, per dirlo chiaramente: le voci non hanno una data dell’ultima modifica, e 93 indirizzi che possono essere indicizzati non sono ancora nella mappa. Sono nell’elenco delle correzioni, non nascosti.
Qui devo essere preciso, perché è il limite più chiaro di questo sito. Il cambio di lingua nell’indirizzo non funziona: la configurazione fissa il romeno, quindi il detector non legge mai il parametro. Ho scritto nel repository perché la soluzione ovvia è peggiore — nel rendering lato server non esiste né storage locale né browser, quindi il detector cade sull’inglese e tutte le pagine escono in inglese — e quali sono le due soluzioni reali: route per percorso, con segmento di lingua, oppure risoluzione della lingua lato server in ogni pagina. La prima è raccomandata. Per un nuovo progetto partiamo direttamente con route per percorso; per uno esistente, è un lavoro, non un’impostazione.
Si inventariano e a ciascuno viene assegnata una decisione: resta, viene reindirizzato permanentemente oppure scompare. Nel riordino di questo sito sono risultate 43 redirezioni nella configurazione. Esistono inoltre 11 pagine che reindirizzano dall’interno dell’applicazione — funzionano, ma costruiscono la pagina prima di inviare la risposta di redirezione, cosa che è uno spreco; sono nell’elenco da spostare nella configurazione. Ve lo dico così sapete che tipo di elenco ricevete alla consegna.
Glielo chiedete: `GET /api/health/contact` risponde 200 se un lead può arrivare a una persona adesso e 503 se no, verificando separatamente che il token del canale di notifica sia valido e che il registro delle richieste sia scrivibile. La risposta contiene solo valori logici, mai il token. Esiste perché qui esattamente una volta si è rotto il lavoro: token revocato, route che restituiva 500, richieste perse senza traccia. Ora la richiesta viene scritta nel registro prima di tentare la consegna.
Non promettiamo posizioni nei risultati di ricerca, percentuali di conversione o punteggi di performance che non abbiamo misurato sul vostro progetto. Non consegniamo un sito senza elenco di indirizzi vecchi e senza procedura di ritorno. Non ci assumiamo piattaforme terze a cui non abbiamo accesso. E non presentiamo come pronto qualcosa che ha un limite noto — se ho un limite, lo trovate scritto nel repository prima di trovarlo voi in produzione.
13 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.
Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.