La revisione del sito aziendale richiede molto tempo per la parte visiva della homepage, ma le funzionalità di statistica, assistenza clienti, pixel, A/B, chat e SDK per le mappe vengono semplicemente “collegate per prima cosa” in cima alla pagina. Google web.dev, nel documento “Performance dei JavaScript di terze parti”, sottolinea che i script di terze parti non solo rallentano la pagina, ma influenzano anche la privacy, la sicurezza e il comportamento della pagina; poiché non rientrano nel tuo ritmo di rilascio, i problemi risultano ancora più difficili da risolvere. Gli script sincroni bloccano l’analisi del documento; se il server di terze parti va offline, la pagina potrebbe rimanere in attesa fino al timeout della richiesta. Il test di guasto unico eseguito da WebPageTest, citato da web.dev, stima questo intervallo tra 10 e 80 secondi. Per i siti B2B che raccolgono lead, questo è un danno maggiore alla conversione rispetto alla mancanza di due immagini prodotto.
I. Prima gestisci l’inventario, poi parla delle tecniche di ottimizzazione
Il primo intervento suggerito da web.dev non riguarda la modifica del codice, bensì la governance: scegli fornitori con meno codice, stabilisci budget prestazionali per le terze parti, evita di collegare contemporaneamente due sistemi di gestione dei tag o due piattaforme di analisi, effettua audit periodici ed elimina i pixel senza proprietario. Molte aziende hanno sul proprio sito sia la vecchia analisi di Baidu, sia nuove piattaforme di analisi, sia pixel pubblicitari aggiunti privatamente dal reparto vendite, sia widget di assistenza online scaduti; ognuno di essi carica framework propri, stabilisce connessioni proprie e adotta strategie di caching estremamente scadenti. Per quanto riguarda le strategie di caricamento, tranne i script indispensabili per il rendering critico, tutti gli altri dovrebbero utilizzare async o defer; web.dev riporta come il Telegraph, dopo aver impostato il defer su tutti gli script, inclusi quelli pubblicitari e di analisi, abbia ridotto mediamente di circa 4 secondi il tempo di caricamento degli annunci. Per le fonti che si intende utilizzare, preconnect è preferibile rispetto alla sola pre‑risoluzione DNS, poiché consente di risparmiare un ulteriore handshake TLS.
1.1 Le pagine di marketing e quelle dei form non dovrebbero condividere la stessa politica di trust
OWASP, nella discussione sulla catena di approvvigionamento front-end, sottolinea che lo stesso frammento di analisi, quando viene inserito nella pagina della storia del marchio e quando invece viene collocato nel form di contatto, presenta rischi completamente diversi. L’incidente del 2025, in cui pacchetti come chalk e debug sono stati dirottati, con un totale di circa 2,6 miliardi di download settimanali, dimostra che la compromissione dell’account di un maintainer può diffondersi lungo l’intera rete di dipendenze. Anche se il sito ufficiale non incorpora direttamente queste librerie tramite npm, basta utilizzare tag automaticamente aggiornati o indirizzi CDN “ultima versione” perché la superficie di attacco rimanga comunque presente.
II. Il CSP deve usare numeri casuali, anziché ampliare indefinitamente la whitelist
La guida all’implementazione del CSP di MDN colloca le politiche rigorose basate su nonce o hash prima di quelle basate su whitelist di domini. Una whitelist tende a crescere sempre di più, finché non include anche domini insicuri, rendendo di fatto inefficace la politica. strict-dynamic serve a risolvere il problema dei “primi script fidati che poi chiamano altri script”, evitando di inserire mezzo internet nella lista di script-src. connect-src limita invece dove i script possono inviare i dati—questo è fondamentale per impedire che il codice di analisi dirottato trasmetta anche i campi del form. Gli script inline non possono essere fissati tramite SRI; occorre affidarsi al nonce che cambia ad ogni risposta. Solo le librerie statiche e con versione fissa sono adatte all’SRI.
| Aspetto di controllo | Cosa risolve | Raccomandazioni per l’implementazione sul sito ufficiale |
|---|---|---|
| Inventario e budget | Fornitori ripetuti, pixel senza proprietario | Nomina trimestrale dei responsabili; fuori budget, disattivazione del servizio |
| Modalità di caricamento | Blocco del rendering, timeout puntuali | Default defer, assistenza clienti e pixel posticipati all’interazione |
| CSP con nonce + strict-dynamic | XSS e inserimento arbitrario di script | Prima Report-Only, poi obbligatorio per le pagine dei form |
| connect-src / Permissions-Policy | Trasmissione dei dati e abuso delle capacità del browser | Pagina dei form: vietati clipboard, fotocamera e altre funzionalità non pertinenti |
| SRI e fissaggio della versione | CDN con file sostituiti | Vietato l’uso di librerie pubbliche “latest” prive di hash |
III. La revisione dovrebbe partire dal budget degli script, non dai mockup visuali
I Core Web Vitals sono già stati ampiamente discussi, ma spesso il vero punto debole dei siti aziendali non è il CSS interno, bensì quello delle terze parti. web.dev ricorda inoltre che stabilire una connessione verso una fonte di terze parti è di per sé costoso: HTTPS richiede DNS, redirect e numerosi round-trip; se una stessa pagina richiama molteplici fonti, significa affidare la prima schermata alla più lenta tra esse. Quando XYN Tech realizza un sito ufficiale, considera la lista dei tag come un deliverable di pari livello rispetto alla struttura delle sezioni: ogni script deve indicare chiaramente l’uso, il dominio di uscita dei dati, se compare nelle pagine dei form e, in caso di errore, se la pagina resta comunque inviabile. Nella pagina del form di consultazione, per default non vengono caricati banner né pixel non necessari; il componente di chat viene inserito solo dopo il clic, così da non lasciare la sorte della homepage all’usabilità del fornitore dell’assistenza clienti. Permissions-Policy può disabilitare l’accesso di iframe di terze parti a clipboard, fotocamera e USB, particolarmente utile per le pagine che consentono upload di file o presentazioni online.
- Usa gli strumenti di sviluppo per elencare tutte le fonti di terze parti e segnalare le funzionalità duplicate.
- Stabilisci budget separati per gli script della homepage e della pagina dei contatti (in kilobyte e in termini di tempo di blocco del thread principale).
- Attiva endpoint di reporting per il CSP: verifica prima le false positività settimanali, poi imponi la conformità.
- Nel contratto, richiedi ai colleghi del marketing di far passare ogni nuovo pixel attraverso una procedura di modifica, anziché modificare privatamente i template.
Il gestore dei tag è spesso visto come una porta di accesso per “aggiungere pixel in futuro senza rivolgersi allo sviluppo”. Per il team di sicurezza, ciò equivale a consegnare il potere di pubblicazione degli script al backoffice marketing. La condizione accettabile è che solo account controllati possano pubblicare, che ogni pubblicazione sia quantificata e che i contenitori di produzione blocchino per default i tag non approvati. Altrimenti, appena il CSP si irrigidisce, il gestore dei tag torna a permettere script arbitrari. La governance degli script di terze parti non offre margini per mostrare abilità: si tratta di riacquisire il controllo su chi può eseguire codice sotto il nostro dominio. Se la prossima revisione del sito ufficiale prevede solo la valutazione visiva, includi anche uno screenshot del pannello di rete nei materiali di review: quei barra di richieste di terze parti dai colori variopinti rappresentano il rumore di fondo comune a conversione e sicurezza. Prima elimina i pixel senza proprietario, poi valuta se sostituire la piattaforma di marketing con una più robusta.