Google+

Résumé

Google+ devient entièrement réactif.

Adopter une approche responsive

Des chats zombies aux calculatrices vintage, les utilisateurs se retrouvent sur Google+. Jusqu'à récemment, Google+ proposait deux versions différentes de son site Web : une pour les ordinateurs de bureau et une pour le Web mobile, conçue pour les anciens navigateurs.

défis

Le maintien de deux sites s'accompagne de défis uniques. Le fait d'avoir des versions distinctes du site signifiait que chaque fonctionnalité devait être implémentée deux fois. Cela entraînait beaucoup de code en double et des efforts supplémentaires pour optimiser deux expériences, l'une pour le Web pour ordinateur et l'autre pour le Web mobile. De plus, comme les lignes entre les appareils devenaient de plus en plus floues (avec les ordinateurs de bureau compatibles avec l'écran tactile et les appareils mobiles puissants dotés d'un écran de plus en plus grand), les conceptions différentes pour les ordinateurs de bureau et les mobiles étaient de moins en moins logiques.

À mesure que nous ajoutions des fonctionnalités, notre ancien site pour ordinateur devenait lent et encombré. Plus tôt cette année, notre page d'accueil pesait environ 5 Mo et a généré environ 250 requêtes HTTP. Elles n'étaient tout simplement pas performantes. Les images du site étaient lourdes et non optimisées, ce qui ralentissait encore davantage la page. Notre flux était donc presque inaccessible sur les réseaux lents et instables, et l'expérience de ces utilisateurs était au mieux décevante. De plus, l'obligation de prendre en charge les anciens navigateurs sur le Web mobile nous a empêchés d'utiliser JavaScript sur l'ensemble du site et nous a empêchés de mettre en œuvre des fonctionnalités très interactives. Nous ne pouvions pas compter sur les progrès des navigateurs Web mobiles.

Solution

Nous avons commencé par nous concentrer sur le responsive design: une implémentation qui fonctionnait sur les mobiles, les tablettes, les ordinateurs de bureau, etc. Nous avons examiné en détail chaque fonctionnalité, page, bibliothèque JavaScript et classe CSS. Nous voulions créer un système qui garantirait que le site ne téléchargerait que ce qui était absolument nécessaire pour être fonctionnel, sauf si l'utilisateur en demandait davantage. Le défi consistait à créer un site Web qui fonctionnait correctement sur un téléphone mobile plus lent avec une connexion mobile, tout en offrant une excellente expérience immersive sur des navigateurs plus rapides et des écrans plus grands.

Cet ensemble de contraintes nous obligeait à examiner chaque modification de code à l'avenir. Pour ce faire, nous avons établi une règle des 6^5 afin de nous assurer qu'au chargement initial de la page, nous ne téléchargions pas plus de 60 Ko de code HTML, 60 Ko de JavaScript et 60 K de CSS, que nos animations étaient toujours à 60 FPS et que nous ayons une latence moyenne de 0,6 s.

Pour ce faire, nous avons choisi les frameworks JavaScript et CSS qui incorporent la modularité et le chargement différé dès le départ. Nous nous assurons donc que les utilisateurs ne téléchargent JavaScript et CSS que lorsqu'ils utilisent la fonctionnalité qui les requiert. Pour ce faire, nous utilisons une approche basée sur des modèles, combinée à notre système de compilation et de modules, pour que tout fonctionne sans effort de la part des développeurs.

Avec ce nouveau framework, nous avons commencé à prototyper une nouvelle implémentation de Google+ sur le Web. Nous avons commencé à interdire les "mauvaises" choses et à définir des règles de développement strictes. L'une de nos principales règles était que toutes nos pages devaient être affichées à la fois côté serveur et côté client. Avec le rendu côté serveur, nous nous assurons que l'utilisateur peut commencer la lecture dès que le code HTML est chargé, et qu'aucun code JavaScript n'a besoin d'être exécuté pour mettre à jour le contenu de la page. Une fois que la page est chargée et que l'utilisateur a cliqué sur un lien, nous ne voulons pas effectuer un aller-retour complet pour tout afficher à nouveau. C'est là que le rendu côté client devient important. Il nous suffit d'extraire les données et les modèles, et d'afficher la nouvelle page sur le client. Cela implique de nombreux compromis. Nous avons donc utilisé un framework qui facilite le rendu côté serveur et côté client, sans avoir l'inconvénient d'avoir à tout mettre en œuvre deux fois : sur le serveur et sur le client.

Parmi les autres règles, citons l'interdiction des animations de hauteur et de largeur, ce qui entraînerait une remise en page dans le navigateur et aurait un impact négatif sur les performances. Pour les manipulations et animations DOM, nous avons planifié les tâches à synchroniser avec la fréquence d'actualisation du rendu du navigateur. Nous regroupons également toutes les tâches de mesure afin d'éviter les calculs de style répétés coûteux. Nous avons également beaucoup utilisé les outils du profileur Chrome pour nous assurer que tout fonctionnait comme prévu au fur et à mesure. De plus, nous avons créé des outils qui calculent l'effet des modifications de code sur l'empreinte JS afin d'éviter d'augmenter considérablement la taille de nos pages.

Cela nous a pris un certain temps, mais cela aurait été beaucoup plus difficile si nous n'avions pas la capacité d'identifier et d'éliminer les problèmes au fur et à mesure de notre développement.

Nous avons lancé la version Web mobile de cette implémentation responsive en février 2015. Cela nous a permis d'examiner les nouvelles conceptions et notre nouveau processus. Nous avons utilisé les données de ce lancement pour valider ce qui fonctionnait et ce qui n'avait pas fonctionné. Nous avons itéré sa conception et commencé à l'étendre pour prendre en charge d'autres appareils. En novembre 2015, nous avons lancé cette nouvelle implémentation sur tous les appareils.

Résultats

Sans compromettre les performances, Google+ a pu développer une application Web complexe dotée d'une interface utilisateur riche. Le site est désormais plus rapide et plus simple à utiliser.