Bottoni dei social network, widget per le statistiche, contatori, tracciatori e chi ne ha più ne metta. Oggi sembra che nessun sito possa farne a meno. Il problema insito in questo trend sta nel fatto che gli sviluppatori (ci sono passato anch’io) copiano ed incollano codice di terze parti senza spesso rendersi conto di cià che si sta realmente facendo.
Parliamo di performance. Sia che si includa un widget nella sezione head o body di una pagina, un browser deve eseguire un lookup della risorsa specificata. Se il sito di terze parti non risponde, il browser rimane in attesa. E tutto il resto della vostra pagina viene rallentato. Questo fino a quando il browser non chiude la richiesta con un timeout.
Il risultato è quello di avere un rendering a scatti. Spesso vediamo siti in cui le varie parti finiscono di essere rappresentate a salti, con intervalli apparentemente casuali. àˆ un effetto che per un utente può risultare molto fastidioso.
La soluzione c’è, e consiste nel sostituire i widget con i loro iframe corrispondenti. Molti servizi, come Facebook e Twitter, offrono questa possibilità . Questo tipo di elemento non viene elaborato come uno script, perché tutto quello che fa è caricare contenuto HTML. I browser infatti rappresentano nel DOM il contenuto di un iframe come un nuovo documento HTML.
Se l’iframe non è disponibile, i browser visualizzeranno un errore HTTP nel luogo in cui è posizionato l’iframe. Ma questo avviene in tempi molto più rapidi di quanto non avvenga con uno script, e soprattutto si tratta di messaggi che non richiedono l’interpretazione della console JavaScript.
Ricordiamoci che l’elaborazione HTML è notevolmente più veloce di quella di uno script. Il problema maggiore di questa soluzione sta unicamente nel tipo di sito che andremo a sviluppare. Se si tratta di un sito istituzionale che deve superare i requisiti della legge Stanca sull’accessibilità , non si possono usare gli iframe con alcune DTD, come per esempio XHTML 1.0 Strict.
In questo caso siamo per forza di cose costretti ad usare soluzioni alternative. Una soluzione che mi permetto di consigliare è quella di intercettare tramite header HTTP il validatore del W3C, il cui user-agent è il seguente e fornirgli una versione del documento priva di iframe. I requisiti infatti dicono che il documento deve essere valido, e a noi interessa quindi solo il validatore del W3C.
In tutti gli altri casi, ossia nel 95% dei siti web, possiamo usare questa soluzione alternativa ai widget JavaScript, fermo restando il fatto che abbiamo effettivamente riscontrato dei benefici nell’uso degli iframe. Se infatti il vostro sito ha poco traffico e non notate problemi significativi, potete continuare a usare gli script.
Quello che ho proposto in questa sede vale come extrema ratio da un punto di vista dello sviluppo lato client. Infatti da un punto di vista lato server potete sempre verificare che l’URL degli script che caricate sia effettivamente vivo e funzionante e quindi agire di conseguenza.