Nella pagina Contatti c’è una mappa per trovare la sede. Nel piè di pagina, un widget con le ultime recensioni dei clienti. Nella home, una griglia con le foto più recenti del profilo social dell’azienda. Sono elementi che quasi ogni sito aziendale finisce per avere, e che si aggiungono con un copia e incolla: il servizio fornisce un frammento di codice, di solito un iframe o uno script che ne crea uno, e il contenuto compare nella pagina.
La semplicità dell’inserimento nasconde il costo. Ogni iframe è un documento web completo, con il proprio HTML, i propri fogli di stile, i propri script, i propri font e le proprie connessioni verso i server del fornitore. Una mappa interattiva può pesare quanto tutto il resto della pagina messo insieme. In questo articolo vediamo quanto costano davvero questi widget, come incidono sulle Core Web Vitals e quali alternative permettono di offrire le stesse informazioni con una frazione del peso.
Un documento dentro il documento
Un iframe incorpora una pagina web all’interno di un’altra. Il browser la carica come carica qualsiasi pagina: risolve il dominio, apre una connessione, scarica l’HTML, poi i fogli di stile, gli script, le immagini e i dati necessari. Per una mappa interattiva, questo significa la libreria di rendering della mappa, le tessere delle immagini, i font, le icone, i dati di configurazione e spesso strumenti di analisi del fornitore. Per un widget di recensioni, il framework con cui è costruito, i dati delle recensioni, le foto dei profili. Per un feed social, decine di immagini e il codice per gestirle.
I browser moderni, per ragioni di sicurezza, possono eseguire le iframe di altri domini in processi separati, ma questo non le rende gratuite: le risorse passano comunque dalla stessa connessione di rete, il codice gira sullo stesso processore e occupa la stessa memoria del dispositivo. Su uno smartphone di fascia media, una mappa interattiva che si inizializza durante il caricamento della pagina rallenta tutto il resto.
Come incidono sulle Core Web Vitals
L’effetto sull’LCP è indiretto ma concreto: le risorse dei widget competono per la banda con quelle della pagina, e se il widget si trova in alto, come una mappa nella parte iniziale della pagina Contatti, può ritardare l’immagine o il testo principale. Il CLS è colpito quando l’iframe non ha dimensioni riservate: molti widget partono con un’altezza minima e si espandono quando il contenuto arriva, spingendo in basso tutto ciò che segue. L’INP soffre del lavoro che gli script dei widget svolgono durante e dopo il caricamento, proprio quando l’utente inizia a interagire.
C’è un dettaglio che rende questi problemi difficili da individuare. Gli script della pagina non possono vedere cosa succede all’interno delle iframe di altri domini, per cui gli strumenti di misura basati su JavaScript, compresa la libreria web-vitals, non registrano gli spostamenti del layout o le interazioni che avvengono al loro interno. I dati di campo raccolti da Chrome per il Chrome UX Report, invece, possono tenerne conto. Il risultato è che i dati di un sistema di monitoraggio proprio e quelli di Search Console possono divergere, e il widget incorporato è una delle possibili cause.
Il primo intervento: lazy loading e dimensioni
Due interventi minimi andrebbero applicati a qualsiasi iframe, e non richiedono di cambiare il widget. Il primo è l’attributo loading="lazy", che rimanda il caricamento finché l’utente non si avvicina all’iframe scorrendo. Per un widget nel piè di pagina significa che la maggior parte dei visitatori, che non arriva in fondo, non lo carica affatto. WordPress lo aggiunge automaticamente agli iframe dei contenuti dalla versione 5.7, ma non a quelli inseriti nei modelli del tema o da plugin, che vanno verificati.
Il secondo è riservare lo spazio: dimensioni esplicite o una proporzione con aspect-ratio, e per i widget che cambiano altezza un’altezza minima pari a quella tipica del contenuto finale. Così l’iframe può caricarsi quando vuole senza spostare nulla.
<iframe src="https://widget.esempio.com/recensioni?azienda=123"
loading="lazy" width="600" height="420"
title="Recensioni dei clienti"
style="width: 100%; height: auto; aspect-ratio: 600 / 420; border: 0;"></iframe>Questi interventi riducono i danni, ma non eliminano il costo per chi scorre fino al widget, né per i widget posizionati in alto. Per quelli servono alternative più radicali.
Le mappe
La mappa interattiva è il caso più comune e quello con la soluzione più efficace: la facciata. Al posto della mappa, la pagina mostra un’immagine statica della zona con un indicatore sulla sede, e un pulsante per aprire la mappa interattiva. Solo quando l’utente lo tocca, l’immagine viene sostituita dall’iframe. Per la maggior parte dei visitatori, che hanno bisogno solo di vedere dove si trova la sede o di ottenere le indicazioni, l’immagine è sufficiente.
L’immagine può essere generata con i servizi di mappe statiche dei principali fornitori, oppure preparata una volta e ospitata sul proprio sito, dato che la posizione di una sede cambia raramente. Accanto, un link alle indicazioni che su smartphone apre direttamente l’app di navigazione è spesso più utile della mappa stessa: chi deve raggiungere la sede vuole un percorso, non una mappa da spostare con le dita dentro una pagina web.
<div class="mappa-facciata">
<img src="/media/mappa-sede.webp" width="1200" height="675" loading="lazy"
alt="Mappa della zona con la sede in via Roma 10, Milano">
<button type="button" data-src="https://www.google.com/maps/embed?pb=…">
Apri la mappa interattiva
</button>
<a href="https://www.google.com/maps/dir/?api=1&destination=Via+Roma+10+Milano">
Indicazioni stradali
</a>
</div>Poche righe di JavaScript, al clic sul pulsante, creano l’iframe con l’indirizzo indicato nell’attributo data-src e lo sostituiscono all’immagine, con le stesse dimensioni per non spostare nulla. È la stessa tecnica vista per i video nell’articolo su video e Core Web Vitals.
Le recensioni
I widget di recensioni delle piattaforme specializzate mostrano la valutazione media, il numero di recensioni e alcuni commenti recenti. Sono informazioni utili per la fiducia dei visitatori, ma raramente cambiano di ora in ora. Molte piattaforme offrono, oltre al widget, un’interfaccia di programmazione da cui leggere gli stessi dati: il sito può recuperarli periodicamente, per esempio una volta al giorno, memorizzarli e mostrarli come normale HTML, con i propri stili. Il risultato è un blocco di pochi kilobyte, visibile subito, senza spostamenti e senza script esterni.
Quando la piattaforma richiede per contratto l’uso del proprio widget, conviene almeno scegliere la versione più semplice, come un badge con la valutazione invece di un carosello di recensioni, caricarla in modo differito e riservarle lo spazio. E vale la pena verificare se il widget è davvero necessario su tutte le pagine o solo su quelle in cui la fiducia conta di più, come le schede prodotto o la pagina dei servizi.
I feed social
I feed delle piattaforme social incorporati nel sito sono tra i widget più pesanti: decine di immagini ad alta risoluzione, script per i caroselli e le finestre di dettaglio, strumenti di tracciamento. Il loro valore per il visitatore è spesso modesto, e nella maggior parte dei casi un link al profilo social, accompagnato da qualche immagine selezionata, ottiene lo stesso scopo.
Se il feed è considerato importante, l’alternativa è la stessa delle recensioni: recuperare periodicamente le immagini più recenti tramite l’interfaccia della piattaforma, salvarle sul proprio sito in formati moderni e nelle dimensioni giuste, e mostrarle come una normale griglia di immagini con caricamento differito. Esistono plugin per WordPress che fanno esattamente questo; conviene scegliere quelli che memorizzano le immagini localmente invece di caricarle dai server della piattaforma a ogni visita.
Altri widget comuni
Lo stesso ragionamento si applica a molti altri elementi incorporati: calendari di prenotazione, moduli di contatto di servizi esterni, sistemi di commenti, previsioni del tempo, cambi valuta, pulsanti di condivisione con conteggio. Per ciascuno vale la pena porsi tre domande. Serve davvero a tutti i visitatori, o solo a una parte? Può essere mostrato in forma statica e caricato in forma interattiva solo su richiesta? I dati che mostra possono essere recuperati dal server e resi come HTML? Quasi sempre almeno una delle risposte apre la strada a un’alternativa più leggera. Il quadro generale è quello descritto nell’articolo sugli script di terze parti.
Privacy e consenso
C’è un ulteriore motivo per preferire le alternative statiche: molti widget impostano cookie e trasmettono dati di navigazione ai fornitori, e in molte configurazioni del banner dei cookie vengono bloccati finché l’utente non dà il consenso. Il risultato, se gestito male, è un riquadro vuoto o un messaggio di avviso al posto della mappa, seguito da uno spostamento del layout quando il contenuto arriva. Una facciata o un contenuto reso dal server non contattano il fornitore finché non serve, occupano sempre lo spazio corretto e semplificano la gestione del consenso, come abbiamo visto parlando dei consent banner.
Un esempio: la pagina Contatti
Consideriamo la pagina Contatti di uno studio professionale: in alto una mappa interattiva a tutta larghezza, sotto un modulo di contatto, nel piè di pagina un carosello di recensioni e il feed delle ultime foto pubblicate sui social. Da smartphone la pagina trasferisce quasi tre megabyte, apre connessioni verso una dozzina di domini e ha un LCP di oltre quattro secondi, perché l’elemento più grande è la mappa, che deve caricare le proprie tessere prima di essere disegnata. Mentre le recensioni arrivano, il piè di pagina si allunga e sposta il contenuto.
Gli interventi sono tre: la mappa diventa un’immagine statica con i pulsanti per aprirla e per ottenere le indicazioni; le recensioni vengono lette una volta al giorno dal server e mostrate come testo con la valutazione media; il feed social viene sostituito da un link al profilo con tre immagini salvate localmente. La pagina scende sotto i trecento kilobyte, l’LCP diventa l’immagine della mappa, leggera e con priorità alta, e nessun elemento si sposta più. Le informazioni offerte ai visitatori sono esattamente le stesse.
Come individuarli e misurarli
Lighthouse segnala esplicitamente gli incorporamenti di terze parti che potrebbero essere sostituiti da una facciata e riporta il peso delle risorse di ciascun fornitore. Nel pannello Network dei DevTools, raggruppando o filtrando le richieste per dominio, si vede quante risorse arrivano da ciascun servizio e quando vengono caricate rispetto al resto della pagina. Un test con e senza il widget, per esempio bloccando il dominio del fornitore dall’apposita funzione dei DevTools, misura direttamente il suo costo su LCP e tempo di caricamento.
Sul campo, il confronto tra i dati di Search Console e quelli di un eventuale sistema di monitoraggio proprio può rivelare problemi che avvengono dentro le iframe. E conviene chiedersi, per ogni widget, quanti visitatori lo usano davvero: se meno del cinque per cento degli utenti interagisce con la mappa, il restante novantacinque paga il suo costo senza alcun beneficio.
In sintesi
Mappe, recensioni, feed social e altri widget incorporati sono documenti completi dentro la pagina, con le proprie risorse e i propri script, e possono pesare più del resto del sito. Incidono sull’LCP competendo per la banda, sul CLS quando non hanno spazio riservato e sull’INP con il lavoro dei loro script, a volte in modi che gli strumenti di misura della pagina non vedono.
Il minimo indispensabile è il caricamento differito con dimensioni riservate. Le soluzioni migliori sono le facciate, che caricano il widget solo quando l’utente lo chiede, e le alternative rese dal server, che mostrano gli stessi dati come semplice HTML. Offrono le stesse informazioni con una frazione del peso, semplificano la gestione della privacy e, spesso, un’esperienza migliore: un link alle indicazioni stradali è più utile di una mappa da trascinare con le dita.
