Il y a six mois, Google a présenté une version mise à jour de son service de messagerie. Malgré le fait que de nombreux utilisateurs n'étaient pas satisfaits de la refonte, y compris sur Habré , c'est maintenant l'interface principale pour les utilisateurs.
Entre autres lacunes, les gens se plaignent de la dégradation des performances de la nouvelle version, en particulier sur les ordinateurs faibles. Voyons pourquoi cela se produit et ce qui peut être si difficile dans l'interface de messagerie. Dans cet article, nous utiliserons les outils de développement de Google Chrome, donc cet article sera également un rappel des opportunités qui y sont disponibles.
Données source
Tout d'abord, vous devez comprendre à quoi nous avons affaire. Google Chrome Devtools dispose d'un outil Lighthouse intégré qui crée un rapport de performances simple et compréhensible pour votre site. Dans ce document, Gmail obtient un deuce pour les performances (sur un maximum de 100 points!)
Pour être honnête, ce n'est pas le résultat que vous attendez d'un produit Google. Néanmoins, examinons cette situation plus en détail. Désactivez le cache et chargez l'interface Gmail avec devtools activé. L'onglet Réseau affichera toutes les demandes de téléchargement de cette page. Il s'est avéré 6,9 Mo. C'est une taille impressionnante, étant donné que même Youtube, un autre service récemment mis à jour, ne charge que 2 Mo de ressources.
Il convient de noter ici que les services modernes, notamment Gmail, utilisent Service Workers pour améliorer la mise en cache des ressources. Par conséquent, pour des mesures précises d'un démarrage à froid, la désactivation du cache ne suffit pas; vous devez également réinitialiser les techniciens de maintenance, qui détiennent également des ressources. Ce n'est qu'après cela que le numéro de téléchargement à partir de zéro sera réel.
Essayons maintenant de regarder le chargement de la page au ralenti. La documentation de Google Chrome explique comment procéder. Nous obtenons un ensemble de captures d'écran des différentes étapes du chargement de la page:
Ici, vous pouvez voir que la page est plus ou moins chargée à la 9ème seconde.
Avec le rechargement lors de l'utilisation du cache, la situation est meilleure. La page ne fait que 250 Ko de requêtes, mais cela ne la rend pas plus rapide, nous voyons toujours l'écran de démarrage pendant près de 10 secondes. Le point n'est clairement pas le nombre de demandes, quelque chose d'autre rend la page plus lente.
Nous bloquons les ressources
Regardez maintenant la liste des scripts téléchargeables:
Peut-être que certains d'entre eux ne sont pas si nécessaires au fonctionnement normal de l'interface? Essayons de les désactiver un par un et testons la page sans eux. Cela se fait facilement en utilisant la fonctionnalité intégrée de devtools .
Empiriquement, il s'est avéré que les demandes de https://mail.google.com/_/scs/* sont essentielles au fonctionnement de l'interface, mais les demandes suivantes peuvent être bloquées:
En plus de ces demandes, mon AdBlock a installé des demandes déjà bloquées sur https://play.google.com/log , nous ne les prenons pas en compte, car elles n'ont pas été faites avant même le début des expériences avec les verrous.
Nous ajoutons ces scripts à la liste noire et constatons que le chargement de la page a commencé en 4 secondes, mais vous pouvez toujours lire et écrire des lettres.
Nous regardons dans le profileur
Nous avons donc minimisé le chargement des ressources autant que possible, mais la page prend encore beaucoup de temps à charger. Nous devons voir ce qui se passe pendant ces 4 secondes. Ici, le profileur intégré à Chrome viendra à notre aide. Il nous montre cette photo:
Ici, vous pouvez voir que pendant tout ce temps, le navigateur a été occupé par l'exécution de Javascript. Il est intéressant qu'une chose aussi importante et difficile se produise dans ce code. Heureusement, Javascript se charge dans le navigateur presque inchangé et peut être lu.
Considérez le code restant
Lisons le code Javascript à notre disposition. Voici l'occasion de formater le code minifié pour le rendre plus lisible.
Selon les résultats de la visualisation, les éléments suivants ont été trouvés:
- Le code est très obscurci. Très probablement, le compilateur de fermeture Google a été utilisé en mode avancé . Autrement dit, les développeurs de Gmail ont tiré le meilleur parti des technologies de minification modernes.
- Les mesures de performances sont collectées dans le code, les développeurs doivent donc être conscients de la lenteur du chargement de l'interface utilisateur.
- Les sources contiennent des polyfills pour Promise, Map, Set et d'autres API modernes qui pourraient ne pas se charger dans les navigateurs modernes.
- Code Gmail écrit dans Google Closure Libary
Au dernier point, il vaut la peine de s'arrêter plus en détail. La bibliothèque de fermeture est un cadre de développement d'interface qui est apparu en 2009 et n'a pas beaucoup changé depuis lors. Par exemple, Ajax via ActiveXObject y est toujours pris en charge: ce qui n'est nécessaire que pour IE6 et inférieur, bien que Gmail actuel ne prenne officiellement en charge que IE 10+.
De plus, l'interface de fermeture est basée sur une hiérarchie de classes dans la «meilleure» tradition GWT - une approche avec beaucoup d'abstractions verbeuses qui affectent évidemment les performances de rendu. Les frameworks d'interface utilisateur modernes (React ou Vue, par exemple) offrent des abstractions beaucoup plus légères - des composants - qui sont beaucoup moins chers à rendre.
D'où la longue initialisation: des milliers de classes sont créées dans le code et de nombreuses abstractions sont initialisées avant de réellement commencer à nous rendre l'interface Gmail.
Ainsi, malgré l'apparence mise à jour, Gmail tire un héritage d'anciennes technologies, dont la gravité ne peut pas être cachée derrière la coque extérieure.
Conclusions
J'espère qu'après cet examen, il sera un peu plus clair pourquoi Gmail ralentit. Malheureusement, il n'est pas en notre pouvoir de faire en sorte que Google accélère son service, mais vous pouvez au moins en tirer quelques leçons pour vos applications:
- Les projets hérités rencontrent généralement du code inutile, comme des hacks pour les navigateurs hérités. Passez en revue vos sources et débarrassez-vous des choses qui ne sont plus pertinentes.
- Les abstractions ne sont pas gratuites. Si vous souhaitez résoudre un problème en utilisant un modèle architectural élégant, pensez d'abord à un outil trop lourd, il existe peut-être une option plus simple.
- Ne téléchargez pas d'éléments secondaires sur la page de manière native. Dans ce cas, le widget Hangouts peut ne pas bloquer la chaîne, interférer avec le chargement des principales ressources Gmail, mais se charger en arrière-plan, après avoir rendu la fonctionnalité principale.
- Ne négligez pas la technologie moderne. Ils peuvent contenir des solutions fondamentalement nouvelles pour vos tâches, plus productives et plus pratiques. Il est étrange de voir en 2018 une refonte du service de Google, qui n'utilise pas de composants web , pour lequel Google se noie si activement lors de conférences .
- N'oubliez pas de faire attention aux mesures de performance de vos projets. Pour cela, il existe maintenant de nombreux outils pratiques, à la fois basés sur un navigateur et pour le lancement dans CI .