Open Wired.it | Perché il nuovo Wired "non va bene"

Wired.it ha aggiornato il proprio sito, risolvendo buona parte delle nostre osservazioni. L'avevamo ormai messo nel cassetto, ma...

O forse sarebbe meglio dire “non andava bene”. Quello che segue è, infatti, un post che avevamo scritto a fine febbraio. Volevamo pubblicarlo prima ma tra una cosa e l’altra è restato in standby e, qualche giorno fa, Wired.it ha aggiornato il proprio sito, risolvendo buona parte delle nostre osservazioni. L’avevamo ormai messo nel cassetto, ma le osservazioni di Massimo Russo sul nuovo Corriere.it (ndr: idea per un nuovo post) ci hanno fatto pensare di pubblicarlo ugualmente per un confronto – “postumo”? – che altro non può fare se non del bene ai progetti futuri. 🙂

– – –

Wired ha lanciato il suo nuovo website.

Lo ha fatto con un annuncio del Direttore, Massimo Russo, che ha spiegato tutti i ragionamenti alla base del nuovo portale. Il suo post è uscito qualche giorno dopo quello di Federico Ferrazza, il Vicedirettore, che ha condiviso molto di ciò che ha appreso dall’esperienza fatta sul digitale (il post ha fatto segnare numeri da record sui social media).

Nel suo post, al primo punto, scrive:

“1. Il successo di un sito (di informazione) passa in gran parte per la sua struttura tecnologica.”

Prima di procedere ad “analizzare” la struttura tecnologica di Wired.it, ecco alcune doverose premesse per fugare alcuni dubbi:

1. Questo post non vuole scatenare polemiche contro Wired.it
2. Questo post non è una critica al nuovo design di Wired.it (in termini di gusti)
3. Sappiamo che quando si lancia un progetto è necessario un fine tuning che si fa quando si è “on air”, perché solo con una prova su strada emergono tutte le problematiche sommerse che si risolvono con un approccio progressivo

Caffeina ha analizzato il codice di frontend di Wired.it. Lo abbiamo fatto con la convinzione che correggere gli errori sia meglio che ignorarli, perché Wired è un magazine che leggiamo, uno dei pochi che parla anche di innovazione, nuove tecnologie, storie di nicchia e non banali. Questo è il nostro “regalo” ai suoi lettori. Le ricadute positive sono – in primis – proprio per gli utenti, che potrebbero migliorare l’esperienza di lettura e di utilizzo del sito. Le ricadute positive per Wired? Beh, se ci saranno per gli utenti, ci saranno anche per Wired. Vorremmo che ci fossero più persone a leggere storie di innovazione, errori ed esperienze capaci di ispirare.

Entriamo quindi nel dettaglio delle problematiche che abbiamo esaminato, fornendo anche alcuni spunti per la loro risoluzione. Se c’è qualche persona che leggendo vuole aggiungere delle osservazioni e dei consigli, noi siamo qui per discutere, confrontarci e integrare il post. 😉

Attenzione, da qui il post diventa piuttosto tecnico: se vuoi puoi andare direttamente alla conclusione

 

Scrolling

Se misuriamo il framerate, questi oscilla tra i 5FPS e i 15FPS (testato su iMac 2012 con Google Chrome).

page1image8600

 Nota: un movimento deve avere almeno 30FPS per risultare fluido all’occhio umano.

Per fare un po’ di benchmarking in Italia, il sito di Repubblica.it (rinnovato di recente) ha un framerate che oscilla tra i 45FPS e i 60FPS.

Disabilitando il Javascript, il framerate medio raggiunge i 40FPS.

Il problema principale di Wired.it è proprio qui, nel javascript: sono stati agganciati troppi eventi allo scrolling della pagina, e conseguentemente viene eseguito del codice troppo pesante per garantire la fluidità dello scrolling della pagina.

page1image10216_1

 

Effettuando un profiling del javascript in esecuzione, si nota che il problema si manifesta nella funzione getBoundingClientRect(); all’interno di questa closure, troviamo alcuni problemi che potrebbero essere risolti immediatamente, come:

Cachare i selettori jQuery
jQuery non possiede una cache interna per gli elementi del DOM che vengono selezionati ; questo significa che ad ogni $(window).scroll() viene ogni volta analizzato il DOM tree, con conseguente caduta di performance. A questo link è possibile vedere la differente performance tra i due approcci: http://jsperf.com/ns-jq-cached/3

Cachare i valori degli offset
Come evidenziato dal profiling javascript, la funzione più pesante risulta essere v.fn.offset, che è una funzione helper di jQuery per calcolare gli offset di un elemento nel DOM rispetto alla finestra corrente.

Questa operazione può diventare molto molto esosa, specialmente se invocata su molti elementi e ad ogni scrolling.

Return istantaneo
Agendo direttamente sull’evento che gestisce lo scroll, senza disabilitare il javascript (inserendo un istruzione di return), otteniamo un aumento del framerate stabile sui 30FPS .
FF4FCEDF-1340-4752-A85C-5C7B4B62DF79

 

jQuery

Analizzando il traffico network, si nota subito una cosa stranissima:

  • jquery-1.8.3.min.js (more)
  • jquery.js?ver=1.10.2 (more)
  • jquery.min.js?ver=3.7.1 (more)

Ci sono 3 librerie jQuery caricate, due delle quali della stessa versione, e caricate ognuna da domini differenti. Sicuramente non influisce in modo grave sul sito, ma si tratta di un mancato accorgimento che non ottimizza le performance.

 

48 script

Gli script (a meno che non venga specificato il contrario con l’opzione defer oppure async) sono scaricati in modo sequenziale: il download non avviene in parallelo, e questo significa che ognuno di essi introduce un ritardo nel caricamento degli altri, in maniera progressiva. Per semplificare: caricando uno scriptalla volta, e avendone 48 da caricare, l’utente ha l’impressione che il sito o il suo computer siano molto lenti.

In più, la maggior parte di questi script vengono inclusi nel tag head della pagina, andando a bloccare la stessa. 48 script sono davvero tanti, come è possibile vedere qui:

Js 5 48script

Nota: la maggior parte di questi sono plugin di jQuery.

Tutti questi script andrebbero uniti in pochi file Javascript (uno, massimo tre), manualmente o con l’utilizzo di tool, come Grunt.

Questo porterebbe immediatamente due vantaggi:

  • Il file verrebbe cachato dal browser e non dovrebbe essere scaricato ad ogni singola connessione (più velocità sul server, più velocità per l’utente)
  • Non vi sarebbe un overhead del caricamento sequenziale degli script come descritto sopra

Ci fermiamo qui. Pensiamo che si potrebbe lavorare ancora e migliorare la UI/Ux in diverse aree del sito, ma senza le informazioni di brief e le informazioni sul dietro le quinte preferiamo non esprimere dubbi, perché saranno state prese delle scelte frutto di ragionamenti e constraint che si incontrano inevitabilmente durante lo sviluppo.

In più abbiamo riscontrato alcuni potenziali rischi che possono compromettere la piattaforma. Di questi, però, preferiamo non discutere pubblicamente, ma ci farebbe piacere comunicarli direttamente a Wired per aiutarli a migliorare la sicurezza.

 

Conclusioni

Federico Ferrazza scrive, in chiusura dell’articolo:

36. Sarò la persona più felice della Terra (vabbè, adesso non esageriamo) quando in tutte le redazioni – oltre ai curatori dei contenuti (anche dal punto di vista social) e al reparto (foto)grafico – ci saranno dei programmatori/sviluppatori. Sono fondamentali quanto i primi due, ma è ovvio che servono dei giornalisti in grado di dialogarci (cioè di capire quello che dicono e di fare richieste sensate).

Anche noi abbiamo imparato che persone con background diversi devono dialogare. Ai risultati migliori, i più difficili da raggiungere, ci si arriva senz’altro grazie alle qualità dei singoli, ma solo se inserite in un contesto di vero gioco di squadra.

Noi non abbiamo giornalisti, ma persone che si occupano di Marketing, insieme a chi lavora sul Design o sulla Tecnologia. Mondi diversi e professionalità agli antipodi, come sappiamo.

Ciò che dice Federico è vero: anche noi abbiamo imparato che ciò che va fatto è lavorare in modo da fondere competenze eterogenee nel rispetto dell’importanza di ogni professionalità.

Affrontare i problemi senza preconcetti, fidandosi dei propri compagni di squadra, reciprocamente. Mentalità aperta, lavoro di team, confronto costruttivo: sono questi gli ingredienti che permettono di crescere e raggiungere obiettivi ambiziosi.

Se volete, facciamo quattro chiacchiere: tiziano.tassi@caffeinalab.com


Tiziano Tassi

Tiziano è uno dei Founder di Caffeina. Ha studiato all'Università di Parma e a Euromed a Marsiglia, per lavorare poi in una Digital Agency e in L'Oréal Italia nel Digital Marketing. E' professore di Internet Marketing e Politiche di Comunicazione presso l'Università Cattolica del Sacro Cuore e chiamato come testimone aziendale in corsi di Laurea e Master in diverse Università italiane ed è docente di Digital Marketing in Francia per KEDGE, Audencia Nantes e INSEEC.