Gluren onder de motorkap van opnieuw ontworpen Gmail

Een half jaar geleden kondigde Google een bijgewerkte versie van de Gmail-interface aan. Ondanks meerdere klachten van mensen, is dit nu de standaardinterface.

Naast andere problemen constateerden mensen prestatieproblemen met de nieuwe interface, vooral op low-end machines. Laten we eens kijken hoe dit kan gebeuren en wat zo zwaar kan zijn in de webinterface van de e-mailclient. We zullen de DevTools van Google Chrome gebruiken, dus dit artikel zal ook een goede herinnering zijn over de functies die ze hebben.

Initiële setup

Laten we eerst eens kijken naar de prestaties van Gmail. Chrome Devtools hebben een ingebouwde tool, Lighthouse, die een mooi en duidelijk rapport toont over verschillende aspecten van uw website, inclusief prestaties. Gmail-prestatiescore is 2 van de 100:

Om eerlijk te zijn, is dit niet het resultaat dat u van een Google-product mag verwachten. Laten we desalniettemin eens dieper ingaan op deze situatie. Na het uitschakelen van de cache en het opnieuw laden van de pagina, worden op het tabblad Netwerk van dev-tools alle verzoeken weergegeven om deze pagina te laden. Voor mij was het in totaal 6,9 Mb. Dit is veel, vooral gezien het feit dat Webpack u bijvoorbeeld standaard waarschuwt wanneer uw activagrootte meer dan 244 Kb is. Hier hebben we 27 keer meer.

Het is vermeldenswaard dat moderne webservices (inclusief Gmail) Service Workers gebruiken voor geavanceerde caching van middelen. Dus om voldoende cijfers voor de koude start-payload te krijgen, moet u niet alleen de cache uitschakelen, maar ook Service Workers resetten, die ook enkele bronnen in de cache bevat. Daarna geven uw nummers de volledige grootte van de activa weer.

Laten we nu eens kijken naar het laden van de pagina in slow motion. Er is een uitleg in de documentatie voor Google Chrome over hoe dat te doen. We zullen een aantal screenshots krijgen die de pagina in verschillende laadfasen tonen:

Het laat zien dat de pagina min of meer bruikbaar wordt na 9 seconden.

Als de pagina opnieuw wordt geladen met de cache en Servicewerkers ingeschakeld, krijgt u een beter beeld. Er zijn slechts 250 Kb aan aanvragen, maar het maakt de pagina niet echt sneller, we moeten nog steeds een laadscherm gedurende 9 seconden zien. Er is iets anders waardoor de pagina langzamer laadt, niet de wisselwerking tussen het netwerk.

Sommige bronnen blokkeren

Als we de lijst met bronnen bekijken, zijn er veel:

Misschien zijn sommigen van hen niet echt nodig voor het paginawerk? Laten we proberen bronnen te blokkeren en kijken hoe dit de pagina beïnvloedt. Het is gemakkelijk om te doen met de ingebouwde dev-functie.

Het bleek dat verzoeken om `https: //mail.google.com / _ / scs / *` cruciaal zijn voor de Gmail-interface, maar sommige andere kunnen worden geblokkeerd:

  • www.gstatic.com/og/* - Google API Сlient Library, voor het aanvragen van API's van verschillende Google-services
  • ssl.gstatic.com/inputtools/* - Google Input Tools - schermtoetsenbordwidget
  • hangouts.google.com - ingesloten Hangouts-widget

Na het blokkeren van deze scripts wordt de pagina in 4 seconden geladen, maar de essentiële functies zoals het lezen en schrijven van e-mails werken nog steeds. Als u ook prestatieproblemen ondervindt in de Gmail-interface, kan het blokkeren van deze URL's een oplossing voor u zijn.

Profiling

Op dit moment hebben we enkele bronnen afgesneden, maar de pagina wordt nog steeds langzaam geladen. We moeten kijken wat er tijdens deze 4 seconden gebeurt. Chrome heeft een ingebouwde Javascript-profiler, die ons de volgende afbeelding laat zien:

Blijkbaar was de browser gedurende deze tijd bezig met het uitvoeren van Javascript. Het is interessant om te zien wat voor soort code dit is. Javascript wordt meestal verzonden naar klanten in een verkleinde vorm zonder opmaak en met verminkte functie en variabelenamen.

Minimaliseren van de broncode

Laten we proberen de verkleinde code te begrijpen. We zullen bronnen downloaden en doorgeven aan Prettier, een tool voor het formatteren van codes. U kunt ook een ingebouwde functie van Chrome DevTools gebruiken.

Code wordt beter leesbaar, maar het is nog steeds heel moeilijk om zonder originele namen te begrijpen wat deze functies doen. Gelukkig blijven tekenreeksen behouden en kunnen we deze aanwijzingen gebruiken om de broncode te herstellen. Er zijn enkele strings zoals closing_uid_ of type_error: TrustedResourceUrl. We kunnen ze op internet zoeken in de hoop een open-source framework te vinden waar ze vandaan komen.

De zoekopdracht zou ons naar Google Closure Library leiden. Het lijkt erop dat we enkele verkleinde stukken van dit raamwerk hebben gezien. Verder vergelijken onthult enkele overeenkomsten tussen geminimaliseerde code en bronnen van Closure Library:

Twee if-instructies, een korte en een lange, vervolgens toewijzing en ten slotte een functieaanroep. Dit moet dezelfde code zijn.

Verder gaan we ook strings zoals GwtExecutor, ListenableFuture, DaggerComponentFactory tegen die eruit zien als delen van Java-stack, mogelijk gecompileerd naar Javascript. Een gerelateerd Google Inbox-project is te vinden op de pagina "projecten met GWT" en het is mogelijk dat het code heeft gedeeld met de hoofdinterface van Gmail.

Deze technologiestapel is zeer onverwacht. Gezien het feit dat Google actief webcomponenten en hun framework daarbovenop promoot (Polymer), is het zeer verrassend om in 2018 een herontwerp van een Google-project te zien dat ze niet gebruikt.

In plaats daarvan hebben we een heel oude technologiestapel met veel artefacten van afgelopen dagen waarbij niet alle browsers de normen volgden en je voor elke browser een speciale behandeling moest schrijven. De overblijfselen ervan zijn er nog, in 2018 editie van Gmail-code:

  • AJAX via ActiveXObject, een hack voor IE6, omdat het geen XMLHttpRequest-ondersteuning had
  • Event-luisteraars via attachEvent waren nodig voor IE8 en lager, ze hadden geen standaard `addEventListener`-methode.

Deze code is zonder praktische reden in de bundel opgenomen, omdat Gmail officieel alleen IE10 + ondersteunt, er zijn geen consumenten voor deze hacks.

Naast legacy overhead heeft deze stapel een verouderd componentenparadigma. Het is gebaseerd op klassehiërarchie - een aanpak met een groot aantal zware abstracties, die worden gemaakt voor elke component die de weergave aanzienlijk vertraagt ​​wanneer je honderden componenten op een pagina hebt. Moderne UI-frameworks doen geen lange overervingsketens, hun klassen zijn licht en het renderingwerk wordt uitgevoerd door de framework-kern. Dit vermindert de overhead van componenten, zodat u meer componenten kunt hebben zonder prestatieverlies.

Het draagt ​​zeker bij aan een trage pagina-initialisatie: er worden duizenden klassen geïnstantieerd tijdens het laden van de pagina die het renderen van pagina's vertraagt.

Dus, ondanks de bijgewerkte visuele look, draagt ​​de code van Gmail de erfenis van oude technologieën, het gewicht kan niet worden verborgen door de nieuwe visuele shell.

Controle van codedekking

Een andere handige functie van DevTools is codedekking. Het helpt te begrijpen welke delen van de code niet door de browser zijn uitgevoerd en mogelijk op aanvraag kunnen worden geladen.

Ongeveer de helft van de code is niet gebruikt. Er kunnen legitieme stukken zijn, zoals gebeurtenisluisteraars en andere asynchrone bewerkingen. Maar het is de moeite waard om toch ongebruikte onderdelen te controleren, we kunnen een code vinden die misschien wordt weggegooid.

Naast de al genoemde hacks voor oudere versies van Internet Explorer hebben we nog een aantal interessante stukken gevonden:

Restjes van Google Picasa

De service is afgesloten, maar het geheugen leeft nog steeds in GMail-code.

Schermtoetsenbord

Er zijn een aantal klassen die verantwoordelijk zijn voor de functie, die je waarschijnlijk niet elke dag gebruikt, maar ze zitten vol met elk bezoek aan een Gmail-pagina.

Integratie met Google Agenda

Hetzelfde als hierboven: u gebruikt mogelijk Google Agenda niet, maar de mooie vergaderrepresentatie wordt geladen.

Gevolgtrekking

Deze beoordeling kan enkele redenen verduidelijken waarom de Gmail-interface traag is. Helaas hebben we het niet in onze handen om Google de prestaties van hun interface te verbeteren. Maar we kunnen enkele lessen leren voor onze eigen webapplicaties:

  • Google Closure Compiler is zeer krachtig. Dat was een echte puzzel om de broncode te herstellen, het geeft momenteel de beste compressieverhouding in vergelijking met elke andere JS-minifier.
  • Controleer uw project op ongebruikte code, bijvoorbeeld hacks voor oudere browsers. Controleer uw code en verwijder dingen die niet meer actueel zijn. Als u Babel gebruikt, overweeg dan om browserlist-configuratie aan te bieden met alleen transformaties die logisch zijn voor uw doelgroep.
  • Abstracties zijn niet gratis. Als u een taak wilt oplossen met behulp van een elegant programmeerpatroon, moet u eerst nadenken over de kosten ervan. Er is mogelijk een eenvoudigere oplossing beschikbaar.
  • Neem geen secundaire pagina-elementen op in de initiële lading, gebruik codesplitsing. In het geval van Gmail wordt de Hangouts-widget onmiddellijk geladen, waardoor de belangrijkste bronnen worden vertraagd. Het kan later worden geladen, na de cruciale functionaliteit van de pagina - de lijst met e-mails.
  • Verwaarloos moderne technologieën niet. Ze kunnen fundamenteel verschillende oplossingen voor uw problemen bevatten, performanter en handiger.
  • Vergeet ten slotte niet om aandacht te besteden aan de prestaties van uw app. Audit het van tijd tot tijd of zet er een CI-integratie voor op.
Met dank aan Oli Steadman voor het proeflezen van het artikel