Spähen unter der Haube von neu gestaltetem Gmail

Vor einem halben Jahr kündigte Google eine aktualisierte Version der Google Mail-Oberfläche an. Trotz mehrfacher Beschwerden von Personen ist dies jetzt die Standardschnittstelle.

Unter anderem stellten die Mitarbeiter Leistungsprobleme mit der neuen Schnittstelle fest, insbesondere bei Low-End-Computern. Mal sehen, wie das passieren kann und was in der Weboberfläche des E-Mail-Clients so schwer sein kann. Wir werden die DevTools von Google Chrome verwenden, daher wird dieser Artikel auch eine gute Erinnerung an die von ihnen bereitgestellten Funktionen sein.

Ersteinrichtung

Schauen wir uns zunächst die Leistung von Google Mail an. In Chrome Devtools ist das Tool Lighthouse integriert, mit dem Sie einen übersichtlichen Bericht zu verschiedenen Aspekten Ihrer Website, einschließlich der Leistung, anzeigen können. Der Google Mail-Leistungsfaktor beträgt 2 von 100:

Um ehrlich zu sein, ist dies nicht das Ergebnis, das Sie von einem Google-Produkt erwarten können. Schauen wir uns diese Situation dennoch genauer an. Nach dem Deaktivieren des Caches und dem erneuten Laden der Seite werden auf der Registerkarte Netzwerk alle Anforderungen zum Laden dieser Seite angezeigt. Für mich waren es insgesamt 6,9 Mb. Dies ist eine Menge, insbesondere wenn man bedenkt, dass Webpack Sie beispielsweise standardmäßig warnt, wenn Ihre Assets eine Größe von mehr als 244 KB haben. Hier haben wir 27 mal mehr.

Erwähnenswert ist hier, dass moderne Webdienste (einschließlich Google Mail) Service Worker für die erweiterte Zwischenspeicherung von Assets verwenden. Um eine angemessene Anzahl für die Kaltstart-Nutzdaten zu erhalten, sollten Sie nicht nur den Cache deaktivieren, sondern auch die Service-Worker zurücksetzen, die auch einige Ressourcen im Cache haben. Danach zeigen Ihre Zahlen die volle Größe des Vermögens.

Betrachten wir nun das Laden der Seite in Zeitlupe. In der Dokumentation zu Google Chrome finden Sie eine Erklärung dazu. Wir erhalten eine Reihe von Screenshots, die die Seite in verschiedenen Ladestufen zeigen:

Es zeigt, dass die Seite nach 9 Sekunden mehr oder weniger verwendbar ist.

Das erneute Laden der Seite mit aktiviertem Cache und aktivierten Service-Mitarbeitern zeigt ein besseres Bild. Es gibt nur 250 KB an Anfragen, aber die Seite wird dadurch nicht schneller. Wir müssen noch 9 Sekunden lang einen Ladebildschirm sehen. Es gibt noch etwas, das das Laden der Seite verlangsamt, nicht die Netzwerkkompromisse.

Einige Ressourcen blockieren

Wenn wir uns die Liste der Ressourcen ansehen, wird es eine Menge davon geben:

Vielleicht werden einige von ihnen nicht wirklich für die Seitenarbeit benötigt? Versuchen wir, Ressourcen zu blockieren und sehen, wie sich dies auf die Seite auswirkt. Es ist einfach, mit der eingebauten Dev-Tools-Funktion zu tun.

Es stellte sich heraus, dass Anforderungen an "https: //mail.google.com / _ / scs / *" für die Google Mail-Oberfläche von entscheidender Bedeutung sind. Einige andere können jedoch blockiert werden:

  • www.gstatic.com/og/* - Google API Client Library, um API-Anfragen von verschiedenen Google-Diensten zu stellen
  • ssl.gstatic.com/inputtools/* - Google Input Tools - Bildschirmtastatur-Widget
  • hangouts.google.com - eingebettetes Hangout-Widget

Nach dem Blockieren dieser Skripte wird die Seite in 4 Sekunden geladen, die wesentlichen Funktionen wie Lesen und Schreiben von E-Mails funktionieren jedoch weiterhin. Wenn in der Google Mail-Benutzeroberfläche auch Leistungsprobleme auftreten, kann das Blockieren dieser URLs eine Lösung für Sie sein.

Profiling

Zu diesem Zeitpunkt haben wir einige Ressourcen abgeschnitten, aber die Seite wird immer noch langsam geladen. Wir sollten schauen, was in diesen 4 Sekunden passiert. Chrome verfügt über einen integrierten Javascript-Profiler, der uns das folgende Bild zeigt:

Anscheinend war der Browser die ganze Zeit damit beschäftigt, Javascript auszuführen. Es ist interessant zu beobachten, um welche Art von Code es sich handelt. JavaScript wird in der Regel in einer verkleinerten Form ohne Formatierung und mit entstellten Funktions- und Variablennamen an Clients gesendet.

Den Quellcode entminimieren

Versuchen wir, den minimierten Code zu verstehen. Wir werden Ressourcen herunterladen und sie über Prettier, ein Code-Formatierungs-Tool, weiterleiten. Alternativ können Sie eine integrierte Funktion von Chrome DevTools verwenden.

Code wird lesbarer, aber es ist immer noch sehr schwer zu verstehen, was diese Funktionen ohne Originalnamen tun. Glücklicherweise bleiben die Zeichenfolgen erhalten und wir können diese Hinweise verwenden, um den Quellcode wiederherzustellen. Es gibt einige Zeichenfolgen wie closure_uid_ oder type_error: TrustedResourceUrl. Wir können im Internet nach ihnen suchen, in der Hoffnung, ein Open-Source-Framework zu finden, von dem sie stammen.

Die Suche würde uns zur Google Closure Library führen. Es scheint, als hätten wir einige verkleinerte Teile dieses Frameworks gesehen. Ein weiterer Vergleich zeigt einige Übereinstimmungen zwischen dem minimierten Code und den Quellen der Closure Library:

Zwei if-Anweisungen, eine kurze und eine lange, dann eine Zuweisung und schließlich ein Funktionsaufruf. Dies muss derselbe Code sein.

Weitergehend treffen wir auch Zeichenfolgen wie GwtExecutor, ListenableFuture, DaggerComponentFactory, die wie Teile des Java-Stacks aussehen und möglicherweise mit Javascript kompiliert wurden. Ein verwandtes Google-Posteingangsprojekt wird auf der Seite "Projekte mit GWT" angezeigt. Möglicherweise hat es Code für die Hauptoberfläche von Google Mail freigegeben.

Dieser Technologie-Stack ist sehr unerwartet. Angesichts der Tatsache, dass Google aktiv für Webkomponenten und deren Framework (Polymer) wirbt, ist es sehr überraschend, dass 2018 ein Google-Projekt neu gestaltet wurde, in dem diese nicht verwendet werden.

Stattdessen haben wir einen sehr alten Technologie-Stack mit vielen Artefakten aus vergangenen Tagen, in denen alle Browser nicht den Standards entsprachen und Sie für jeden Browser eine spezielle Behandlung schreiben mussten. Die Reste davon sind in der Ausgabe 2018 des Google Mail-Codes noch vorhanden:

  • AJAX über ActiveXObject, ein Hack für IE6, da es keine XMLHttpRequest-Unterstützung hatte
  • Ereignis-Listener über attachEvent wurden für IE8 und niedriger benötigt und verfügten nicht über die Standardmethode addEventListener.

Dieser Code ist ohne praktischen Grund im Paket enthalten, da Google Mail offiziell nur IE10 + unterstützt. Es gibt keine Kunden für diese Hacks.

Zusätzlich zum Overhead für ältere Komponenten verfügt dieser Stack über ein veraltetes Komponentenparadigma. Es basiert auf der Klassenhierarchie - ein Ansatz mit einer großen Anzahl von Abstraktionen, die für jede Komponente erstellt werden und das Rendern erheblich verlangsamen, wenn sich Hunderte von Komponenten auf einer Seite befinden. Moderne UI-Frameworks machen keine langen Vererbungsketten, ihre Klassen sind leicht und die Rendering-Arbeit wird vom Framework-Kern ausgeführt. Dies reduziert den Overhead von Komponenten, sodass Sie mehr Komponenten ohne Leistungseinbußen haben können.

Dies trägt definitiv zu einer langsamen Seiteninitialisierung bei: Während des Ladens einer Seite werden Tausende von Klassen instanziiert, was das Rendern der Seite verlangsamt.

Somit trägt der Code von Google Mail trotz des aktualisierten visuellen Erscheinungsbilds das Erbe alter Technologien. Das Gewicht kann durch die neue visuelle Shell nicht verborgen werden.

Überprüfen der Codeabdeckung

Eine weitere nützliche Funktion von DevTools ist die Codeabdeckung. Es hilft zu verstehen, welche Teile des Codes nicht vom Browser ausgeführt wurden und möglicherweise bei Bedarf geladen werden können.

Etwa die Hälfte des Codes wurde nicht verwendet. Es kann legitime Elemente wie Ereignis-Listener und andere asynchrone Vorgänge geben. Aber es lohnt sich trotzdem, nicht verwendete Teile zu überprüfen. Wir können Code finden, der möglicherweise weggeworfen wird.

Zusätzlich zu den bereits erwähnten Hacks für ältere Versionen von Internet Explorer haben wir einige weitere interessante Teile gefunden:

Reste von Google Picasa

Der Dienst wurde heruntergefahren, der Speicher befindet sich jedoch noch im GMail-Code.

Bildschirmtastatur

Es gibt eine Reihe von Klassen, die für die Funktion verantwortlich sind und die Sie wahrscheinlich nicht täglich verwenden, die jedoch bei jedem Besuch einer Google Mail-Seite geladen werden.

Integration mit Google Kalender

Dasselbe wie oben: Sie verwenden möglicherweise nicht Google Kalender, aber die nette Besprechungsdarstellung wird geladen.

Fazit

In dieser Überprüfung werden möglicherweise einige Gründe für die Langsamkeit der Google Mail-Oberfläche erläutert. Leider können wir Google nicht dazu bringen, die Leistung ihrer Benutzeroberfläche zu verbessern. Wir können jedoch einige Lektionen für unsere eigenen Webanwendungen lernen:

  • Google Closure Compiler ist sehr leistungsfähig. Das war ein echtes Rätsel, um den Quellcode wiederherzustellen. Es bietet derzeit die beste Komprimierungsrate im Vergleich zu jedem anderen JS-Minifier.
  • Überprüfen Sie Ihr Projekt auf nicht verwendeten Code, z. B. Hacks für ältere Browser. Überprüfen Sie Ihren Code und entfernen Sie alle Dinge, die nicht mehr aktuell sind. Wenn Sie Babel verwenden, sollten Sie in Erwägung ziehen, browserlist config so bereitzustellen, dass nur Transformationen berücksichtigt werden, die für Ihre Zielgruppe sinnvoll sind.
  • Abstraktionen sind nicht frei. Wenn Sie eine Aufgabe mit einem eleganten Programmiermuster lösen möchten, müssen Sie zunächst über die Kosten nachdenken. Möglicherweise ist eine einfachere Lösung verfügbar.
  • Nehmen Sie keine sekundären Seitenelemente in die anfängliche Nutzlast auf, verwenden Sie die Codeteilung. Bei Google Mail wird das Hangouts-Widget sofort geladen, wodurch die Hauptressourcen verlangsamt werden. Möglicherweise wird es später nach der entscheidenden Funktionalität der Seite - der Liste der E-Mails - geladen.
  • Vernachlässigen Sie nicht die modernen Technologien. Sie können grundlegend unterschiedliche Lösungen für Ihre Probleme enthalten, die leistungsfähiger und praktischer sind.
  • Vergessen Sie nicht, auf die Leistung Ihrer App zu achten. Prüfen Sie es von Zeit zu Zeit oder richten Sie eine CI-Integration dafür ein.
Vielen Dank an Oli Steadman für das Korrekturlesen des Artikels