Google+

Riepilogo

Google+ diventa completamente reattivo.

Massima reattività

Google+ è il luogo in cui le persone si riuniscono intorno a interessi comuni, dai gatti zombie alle calcolatrici vintage. Fino a poco tempo fa, Google+ disponeva di due versioni diverse del sito web: una per computer e una per il web mobile, progettata per i browser meno recenti.

sfide

La gestione di due siti ha comportato un insieme unico di sfide. La presenza di versioni separate del sito significava che ogni funzionalità doveva essere implementata due volte. Questo ha comportato una grande quantità di codice duplicato e ulteriori sforzi per ottimizzare due esperienze per il web desktop e il web mobile. E mentre i confini tra i dispositivi diventavano sempre più sfocati, con computer desktop che supportano dispositivi touch e dispositivi mobili potenti con schermi sempre più grandi, i diversi design per computer desktop e dispositivi mobili erano sempre meno sensati.

Con l'aggiunta di nuove funzionalità, anche il nostro sito desktop legacy è diventato lento e gonfio. All'inizio di quest'anno la nostra home page pesava circa 5 MB e ha prodotto circa 250 richieste HTTP. Semplicemente non aveva un buon rendimento. Le immagini sul sito erano pesanti e non ottimizzate, rallentando ulteriormente la pagina. Di conseguenza, il nostro stream era quasi inaccessibile su reti lente e instabili e l'esperienza per questi utenti è stata al massimo deludente. Inoltre, il requisito di supportare i browser precedenti sul web mobile ci ha impedito di affidarci a JavaScript in tutto il sito e ci ha impedito di implementare funzionalità altamente interattive. Non potevamo fare affidamento sui progressi nei browser web mobile.

Soluzione

Abbiamo iniziato con l'attenzione al reattivo design, un'implementazione che funzionava su dispositivi mobili, tablet, computer desktop e non solo. Abbiamo esaminato attentamente ogni singola funzionalità, pagina, libreria JavaScript e classe CSS. Volevamo creare un sistema che assicurasse che il sito scaricasse solo ciò che era assolutamente necessario per funzionare, a meno che l'utente non ne avesse richiesto di più. La sfida consisteva nel creare un sito web che funzionasse correttamente su un cellulare più lento dotato di rete cellulare, ma che offrisse comunque un'esperienza ottima e immersiva su browser più veloci e schermi più grandi.

Questo insieme di vincoli ci ha costretto a esaminare ogni singola modifica al codice in futuro. Per raggiungere questo obiettivo, abbiamo stabilito una regola 6^5 per garantire che al caricamento iniziale della pagina non fossero scaricati più di 60 kB di HTML, 60 kB di JavaScript e 60 kB di CSS, le animazioni erano sempre a 60 fps e una latenza media di 0, 6 secondi.

Per raggiungere questo obiettivo, abbiamo scelto framework JavaScript e CSS che creavano modularità e caricamento lento sin dall'inizio. Ci assicuriamo quindi che gli utenti scarichino JavaScript e CSS solo quando effettivamente utilizzano la funzionalità che lo richiede. Ciò avviene tramite un approccio basato su modelli che, in combinazione con il nostro sistema di build e moduli, consente di far funzionare tutto senza sforzi gli sviluppatori.

Con questo nuovo framework, abbiamo iniziato a realizzare la prototipazione di una reimplementazione di Google+ sul web. Abbiamo iniziato a non consentire le cose "cattive" e a stabilire regole rigide per lo sviluppo. Una delle nostre regole principali era che tutte le nostre pagine dovevano essere visualizzate sia lato server che lato client. Con il rendering lato server ci assicuriamo che l'utente possa iniziare a leggere non appena il codice HTML viene caricato e che non sia necessario eseguire JavaScript per aggiornare i contenuti della pagina. Una volta che la pagina è stata caricata e l'utente fa clic su un link, non vogliamo eseguire un round trip completo per eseguire di nuovo il rendering di tutto. È a questo punto che il rendering lato client diventa importante: dobbiamo solo recuperare i dati e i modelli e visualizzare la nuova pagina sul client. Questo comporta molti compromessi, quindi abbiamo utilizzato un framework che semplifica il rendering lato server e lato client senza lo svantaggio di dover implementare tutto due volte: sul server e sul client.

Altre regole includevano il divieto di animazione di altezza e larghezza che causava la modifica dei layout del browser e incideva negativamente sulle prestazioni. Per le manipolazioni e le animazioni DOM, abbiamo pianificato le attività da eseguire in sincronizzazione con la frequenza di aggiornamento del rendering del browser. Inoltre, raggruppiamo insieme tutte le attività di misurazione in modo da evitare costosi calcoli di stile ripetuti. Inoltre, abbiamo fatto molto affidamento sugli strumenti di profiler di Chrome per assicurarci che tutto funzionasse come previsto durante il processo. Inoltre, abbiamo creato strumenti che calcolano l'effetto delle modifiche al codice sull'impronta JS per assicurarci di non aumentare drasticamente le dimensioni delle nostre pagine.

Questo processo richiedeva un po' di tempo, ma sarebbe stato molto più difficile se non avessimo potuto identificare ed eliminare i problemi durante lo sviluppo.

Abbiamo lanciato la versione per web mobile di questa implementazione adattabile a febbraio 2015. Questo ci ha permesso di esaminare i nuovi design e il nuovo processo. Abbiamo utilizzato i dati di questo lancio per verificare cosa ha funzionato e cosa no. Abbiamo eseguito un'iterazione del design e abbiamo iniziato ad ampliare il supporto per supportare più dispositivi. Nel novembre 2015 abbiamo lanciato questa nuova implementazione su tutti i dispositivi.

Risultati

Senza sacrificare le prestazioni, Google+ è riuscita a creare un'app web complessa con una ricca UI. Il sito ora è più veloce e snello che mai.

	Prima	Dopo
Peso totale della home page, compresso con gzip (con immagini)	22.600 kB	327 kB
Conteggio delle richieste	251	45
HTML (non compresso con gzip)	1100 kB	362 kB
JavaScript e CSS (compresso con gzip)	2768 kB	111 kB
Tempo medio di caricamento completo della pagina (latenza)	12 secondi 0,7 secondi fino al primo byte	3 secondi 0,1 secondi sul primo byte