Che cosa vede chi scarica la mappa del codice del tuo sito

Se il sito pubblica il codice già trasformato, la domanda è che cosa diventa leggibile per chi scarica anche la mappa: il testo di partenza, solo i nomi, o soltanto un indirizzo. Il 3 novembre 2026 ho letto la pagina sulle misure, la pagina su INP, la specifica ECMA-426, due pagine di MDN e una pagina di Chrome. Non dicono la stessa cosa. Non ho pubblicato una mappa e non ho misurato un sito. Nessuna di queste pagine dice che avere la mappa basti a entrare nel sito o a prenderne il controllo. Non lo aggiungo.

Le pagine già online

La pagina sulle misure risponde a che cosa misurare prima di cambiare server. Non nomina una mappa del codice, né un file che rimandi al testo di partenza. Non la riscrivo. Che cosa misurare sul tuo sito prima di cambiare server. La risposta letta il 3 novembre 2026 porta la data 07:14:13 GMT. In pagina la data è 3 novembre 2026. Non le unisco.

La pagina su INP, nella risposta dello stesso giorno alle 07:14:12 GMT, ha come titolo visibile INP: cos'è e come migliorare la reattività del sito. Non nomina una mappa del codice. Non la riscrivo. INP: cos'è e come migliorare la reattività del sito. Un secondo prima della pagina sulle misure. Non unisco i due secondi.

La specifica è una bozza datata, e un documento che si aggiorna

L'indirizzo https://tc39.es/source-map/ ha risposto 200 il 3 novembre 2026 alle 07:14:13 GMT. Last-modified 31 ottobre 2026 alle 11:33:36 GMT. Il corpo è solo un rinvio verso https://tc39.es/ecma426/. Non è il testo della specifica. Non lo tratto come la specifica.

La pagina ECMA-426 ha last-modified 2 novembre 2026 alle 20:17:44 GMT. La risposta letta il 3 novembre 2026 porta la data 07:14:34 GMT, ventuno secondi dopo il rinvio. Non unisco i ventuno secondi, né le 20:17 del 2 novembre con le 07:14 del 3. Indirizzo: https://tc39.es/ecma426/.

In testa la pagina scrive Draft ECMA-426 / October 20, 2026, e più sotto ECMA-426, prima edizione. In un altro punto dice che il documento a quell'indirizzo è la specifica più accurata e aggiornata, e che contiene l'ultima istantanea pubblicata più le modifiche che entreranno nella prossima. Il 20 ottobre 2026, la prima edizione, e la frase sull'istantanea più le modifiche future, sono tre scritti. Non li unisco.

L'introduzione dice che lo standard definisce il formato usato per riportare il codice tradotto alle fonti originali. Elenca due scopi. Il primo è il debug al livello del sorgente, con una corrispondenza nei due sensi. Il secondo è rendere di nuovo leggibili, lato server, le tracce di stack del codice reso oscuro. Sono due scopi del formato. Non sono una frase su che cosa succede a un sito se la mappa è pubblica, e non dicono che la mappa basti a entrare nel sistema. Non lo aggiungo.

La stessa introduzione racconta tre formati. Il primo, chiamato v1, è di Joseph Schorr, per il debug del JavaScript ottimizzato, e la pagina dice che il formato stesso non dipende dal linguaggio. Il secondo, v2, scambia un po' di semplicità per ridurre la dimensione. Il terzo, v3, nasce da suggerimenti di Pavel Podivilov. Poi la pagina dice che il formato non ha più numeri di versione, ed è fissato sempre a 3. Nel 2023-2024 il formato è diventato uno standard Ecma più preciso. Un'altra frase aspetta altre iterazioni da TC39-TG4. v1, v2, v3, il fissato a 3, il 2023-2024 e il gruppo che itererà, restano frasi distinte. Non le unisco.

Lo scopo, sezione 1, dice che lo standard definisce il formato usato da strumenti di sviluppo per migliorare il debug del codice compilato verso JavaScript, WebAssembly e CSS. È lo scopo. I due scopi dell'introduzione non sono questa frase. Non li unisco. La conformità dice che un documento conforme è un documento JSON con la struttura della specifica. Non copio la grammatica della codifica.

Il testo originale è un campo, e può non esserci

Nella sezione del formato, il campo version deve essere sempre il numero 3, intero. La mappa può essere rifiutata se il valore è un altro. Questa frase sta nel formato. La frase della storia, che il formato non ha più numeri di versione ed è fissato a 3, sta nell'introduzione. Non decido che siano la stessa frase.

Il campo file è un nome facoltativo del codice generato a cui la mappa è associata. La pagina non specifica se sia un indirizzo, un percorso relativo o solo un nome base. I generatori scelgono l'interpretazione per il loro contesto. Non scelgo io per un sito.

Il campo sourceRoot è una stringa facoltativa. Serve a ricollocare i file sorgente su un server, oppure a togliere valori ripetuti nelle voci di sources. Il valore viene messo davanti alle singole voci. Ricollocare, e togliere i ripetuti, sono due usi nella stessa frase. Non li separo in una regola che la pagina non scrive.

Il campo sources è l'elenco delle fonti originali usate dalle corrispondenze. Ogni voce è una stringa, un indirizzo anche relativo, oppure null se il nome della fonte non è noto. Il campo sourcesContent è un elenco facoltativo di stringhe con il contenuto della fonte, cioè il sorgente originale, usato quando la fonte non può essere ospitata. L'ordine è lo stesso di sources. Le voci possono essere null se alcune fonti originali vanno recuperate per nome. Testo presente nella voce, e voce nulla perché il testo va cercato per nome, sono due casi. Non dico che ogni mappa contenga il testo originale.

Il campo names è un elenco facoltativo di nomi di simboli, che le corrispondenze possono usare. Il campo mappings è una stringa con i dati di corrispondenza codificati. La codifica sta nella sezione 9.2. Non la copio.

Il campo ignoreList è un elenco facoltativo di indici di file da considerare codice di terzi, per esempio un framework o codice generato da un bundler. Serve agli strumenti per evitare codice che chi sviluppa probabilmente non vuole vedere o attraversare passo passo, senza una configurazione preventiva. Riguarda il campo sources. Alcuni browser possono usare anche il campo deprecato x_google_ignoreList, se ignoreList non c'è. Il nome attuale e il nome deprecato sono due campi. Non li unisco.

L'indirizzo della mappa non è il testo

Se un file è servito via HTTP o HTTPS con un'intestazione sourcemap, il valore è l'indirizzo della mappa collegata. Una nota dice che le revisioni precedenti raccomandavano il nome x-sourcemap. Ora è deprecato, e ci si aspetta sourcemap. Nome vecchio e nome atteso sono due frasi. Non le unisco.

Il codice generato dovrebbe includere un commento, o il costrutto equivalente, di nome sourceMappingURL, con l'indirizzo della mappa. La specifica definisce il commento per JavaScript, CSS e WebAssembly. Le altre lingue dovrebbero seguire una convenzione simile. Per una lingua ci possono essere più modi di trovare il commento. Il collegamento è non ambiguo se tutti i modi danno lo stesso risultato. Se uno strumento consuma file che collegano la mappa in modo non ambiguo e produce un file che collega una mappa, deve farlo in modo non ambiguo. La nota fa un esempio in cui l'analisi del codice trova un nome di mappa, e senza analisi il risultato è vuoto. È l'esempio della nota. Non lo copio, e non lo tratto come il caso normale.

La pagina dell'intestazione SourceMap su MDN ha last-modified 3 novembre 2026 alle 00:53:28 GMT. In pagina l'ultima modifica è il 21 novembre 2025. La risposta letta il 3 novembre 2026 porta la data 07:14:14 GMT. Il 21 novembre 2025, le 00:53 del 3 novembre 2026 e le 07:14 non sono lo stesso orario. Non li unisco. Indirizzo: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/SourceMap.

Dice che l'intestazione di risposta SourceMap dà la posizione della mappa per la risorsa. Dice che ha la precedenza sull'annotazione nel codice, e che se ci sono entrambe si usa l'indirizzo dell'intestazione. Nella sintassi mostra anche X-SourceMap come deprecato. La precedenza è questa pagina. La specifica, nella frase che ho letto, dice che il valore dell'intestazione sourcemap è l'indirizzo della mappa, e non scrive questa precedenza. Non gliela assegno. Il nome SourceMap di MDN e il nome sourcemap della specifica restano due scritture. Non le unisco in un solo carattere.

MDN dice che l'indirizzo può essere relativo all'indirizzo della richiesta, oppure assoluto. Un'altra frase dice che gli strumenti di sviluppo usano la mappa per ricostruire il sorgente originale a partire dal JavaScript ottimizzato restituito nella risposta, così si può fare debug del codice originale invece del formato ottimizzato per l'invio. Ricostruire a partire dal JavaScript ottimizzato della risposta non è la frase della specifica sul campo che contiene il testo quando la fonte non è ospitata. Non le unisco. La disponibilità di base, da gennaio 2020, è un'altra frase della stessa pagina MDN. Non è una data della specifica.

Il glossario stampa un esempio senza quel campo

Il glossario Source map di MDN ha last-modified 3 novembre 2026 alle 00:51:52 GMT, un minuto e trentasei secondi prima dell'intestazione. In pagina l'ultima modifica è il 15 dicembre 2025 alle 10:27:52 UTC. La risposta letta il 3 novembre 2026 porta la data 07:14:14 GMT, lo stesso secondo della pagina dell'intestazione. Il 15 dicembre 2025, le 00:51:52 e le 07:14:14 non sono lo stesso orario. Non li unisco. Indirizzo: https://developer.mozilla.org/en-US/docs/Glossary/Source_map.

Dice che una mappa è un file JSON che mette in corrispondenza il codice minificato o trasformato ricevuto dal browser e la forma originale non modificata, così il codice originale si può ricostruire e usare nel debug. Elenca tre motivi della trasformazione: consegnare in modo più efficiente unendo e minificando i file, sostenere browser vecchi traducendo le funzioni moderne, usare linguaggi che il browser non esegue, con gli esempi TypeScript e Sass. Tre motivi. Non li unisco in un solo motivo, e non sono il campo del testo della specifica.

Dice che i browser trovano la mappa tramite l'intestazione SourceMap oppure tramite un'annotazione sourceMappingURL nel codice generato. Elenca le due vie. Non scrive la precedenza dell'intestazione. Quella precedenza sta sull'altra pagina MDN. Non la sposto qui.

Nell'esempio, un file di mappa è generato e collegato da un commento in fondo al CSS. La prosa dice che la mappa contiene non solo le corrispondenze fra l'SCSS originale e il CSS generato, ma anche il codice sorgente SCSS originale in forma codificata. Il JSON stampato sotto quella frase elenca version, sourceRoot, sources, names, mappings e file. names è una lista vuota. Il campo del testo originale non compare in quel JSON. La prosa della forma codificata, e il JSON senza quel campo, stanno sulla stessa pagina. Non decido che la stringa delle corrispondenze sia il testo originale. La specifica tiene le corrispondenze codificate e il testo originale in due campi. Non li unisco, e non copio la stringa dell'esempio.

Chrome esegue il codice ridotto

La pagina di Chrome sul debug con le mappe ha last-modified 13 aprile 2015 alle 07:00:00 GMT. In pagina scrive Last updated 2015-04-13 UTC, senza un'ora. La risposta letta il 3 novembre 2026 porta la data 07:14:15 GMT. Il 13 aprile 2015 senza ora, le 07:00:00 del last-modified, e le 07:14 del 2026, non sono lo stesso orario. Non aggiungo l'ora alla data in pagina. Indirizzo: https://developer.chrome.com/docs/devtools/javascript/source-maps.

Dice che le mappe dei preprocessori fanno caricare a DevTools i file originali oltre a quelli minificati. Chrome esegue il codice minificato, ma il pannello Sources mostra il codice scritto. Si possono mettere punti di interruzione e andare passo passo nei file sorgente, e errori, log e punti di interruzione si mappano da soli. È l'apparenza di fare debug del codice come è stato scritto, rispetto al codice servito ed eseguito dal browser. Eseguire il minificato, e mostrare lo scritto, sono due frasi. Non dico che il visitatore esegua il testo originale. Non è il campo sourcesContent della specifica.

Per usare le mappe nel pannello, la pagina chiede preprocessori che le producano, e di verificare che il server web possa servire le mappe. Elenca esempi, e dice che l'elenco non è chiuso: traduttori, compilatori, minificatori, bundler e server di sviluppo. Fra i bundler nomina anche Vite. Il piè di pagina resta al 13 aprile 2015. Non decido se il nome Vite sia più nuovo di quella data. Non uso l'elenco come una raccomandazione del 2026.

Nelle impostazioni, la pagina dice di accertarsi che sia segnata la voce delle mappe JavaScript. Una nota dice che si potrebbe voler segnare anche le mappe CSS. Due voci. Non le unisco in un solo interruttore.

Non sono la stessa frase

Sulla specifica il testo originale è un campo facoltativo, nello stesso ordine delle fonti, e una voce nulla vuol dire che quel testo va recuperato per nome. I nomi dei simboli sono un altro campo. Le corrispondenze sono una stringa codificata, e non ne copio la codifica. L'intestazione sourcemap e il commento sourceMappingURL sono due modi di indicare l'indirizzo della mappa. La specifica non scrive la precedenza.

Sulla pagina MDN dell'intestazione, se ci sono entrambi si usa l'indirizzo dell'intestazione. La ricostruzione parte dal JavaScript ottimizzato della risposta. Gennaio 2020 è la disponibilità di base, non una data della specifica.

Sul glossario le due vie sono elencate senza precedenza. La prosa dell'esempio parla di sorgente originale in forma codificata, e il JSON stampato non mostra il campo del testo. La lista dei nomi, in quell'esempio, è vuota. Vuota non è la stessa frase di un campo assente.

Sulla pagina Chrome del 2015 il browser esegue il minificato e il pannello mostra lo scritto. Non ricavo da queste pagine una regola unica su che cosa vede chi scarica la mappa di qualunque sito.

Esempio ipotetico

bottega.example è un nome di scuola. Non l'ho aperto. Non so se pubblica una mappa, né se il campo del testo originale è pieno, nullo o assente. prova.bottega.example è l'altro nome. Non l'ho aperto. Non so se il codice generato ha un commento, se la risposta ha un'intestazione, o se non ha nessuno dei due.

Non assegno a questi nomi il numero 3, gennaio 2020, il 13 aprile 2015, il 20 ottobre 2026, il 21 novembre 2025 o il 15 dicembre 2025. Non assegno una precedenza, una lista di nomi vuota, né un testo originale. I campi restano quelli delle pagine lette.

Che cosa questa pagina lascia stare

Non ho pubblicato una mappa. Non ho aperto la sezione 9.2 sulla codifica, oltre il rinvio. Non ho copiato la stringa dell'esempio del glossario. La copertina è nuova, perché la pagina è nuova. Avere la mappa non è, su queste pagine, una frase su come entrare nel sito. Non la trasformo in quella frase.

Non ho riscritto la pagina sulle misure, la pagina su INP, la pagina sul file caricato, la pagina sulla rotazione della chiave, la pagina sul timer, la pagina sul disco, la pagina sul primo byte, la pagina sugli spostamenti, la pagina su Server-Timing, la mappa di DNS, hosting e CDN, la pagina sulla connessione lunga, la pagina sul lavoro lungo, la pagina sulla copia di prova, la pagina sulla chiave, la pagina sulla compressione, la pagina sulla cartella e la pagina sul lucchetto. Gli indici della base dati non sono questa pagina. Non li ho scritti.

Fonti lette il 3 novembre 2026. Pagine già online, non riscritte: le misure, risposta delle 07:14:13 GMT. INP, risposta delle 07:14:12 GMT. Rinvio da tc39.es/source-map/, last-modified 31 ottobre 2026 alle 11:33:36 GMT, risposta delle 07:14:13 GMT. ECMA-426, last-modified 2 novembre 2026 alle 20:17:44 GMT, risposta delle 07:14:34 GMT, data in pagina 20 ottobre 2026, https://tc39.es/ecma426/. MDN SourceMap, last-modified 3 novembre 2026 alle 00:53:28 GMT, ultima modifica in pagina 21 novembre 2025, risposta delle 07:14:14 GMT, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/SourceMap. Glossario, last-modified alle 00:51:52 GMT, ultima modifica in pagina 15 dicembre 2025 alle 10:27:52 UTC, stessa risposta delle 07:14:14 GMT, https://developer.mozilla.org/en-US/docs/Glossary/Source_map. Chrome, last-modified 13 aprile 2015 alle 07:00:00 GMT, Last updated 2015-04-13 UTC in pagina, risposta delle 07:14:15 GMT, https://developer.chrome.com/docs/devtools/javascript/source-maps. L'indirizzo sourcemaps.info/spec.html ha risposto 404 alle 07:14:13 GMT. Non è una fonte.