Kigger under hætten på redesignet Gmail

For et halvt år siden annoncerede Google en opdateret version af Gmail-grænsefladen. På trods af flere klager fra folk er dette standardgrænsefladen nu.

Blandt de andre spørgsmål bemærkede folk ydelsesproblemer med den nye grænseflade, især på low-end maskiner. Lad os se, hvordan dette kunne ske, og hvad der kan være så tungt i e-mail-klientens webgrænseflade. Vi bruger Google Chrome's DevTools, så denne artikel vil også være en god påmindelse om funktioner, de har.

Første opsætning

Lad os først se på Gmail's ydelse. Chrome Devtools har et indbygget værktøj, Lighthouse, der viser en pæn og klar rapport om forskellige aspekter af dit websted, herunder ydeevne. Gmail-resultatresultatet er 2 ud af 100:

For at være ærlig er dette ikke det resultat, du måske forventer af et Google-produkt. Lad os alligevel se dybere på denne situation. Efter deaktivering af cache og genindlæsning af siden vises på fanen Netværk af dev-værktøjer, alle anmodninger er blevet udført for at indlæse denne side. For mig var det i alt 6,9 Mb. Dette er meget, især i betragtning af at Webpack for eksempel som standard advarer dig, når din aktivstørrelse er mere end 244 Kb. Her har vi 27 gange mere.

Det er værd at nævne her, at moderne webservices (inklusive Gmail) bruger Service Workers til avanceret cache-formue. Så for at få tilstrækkelige antal til koldstart-nyttelasten, skal du ikke kun deaktivere cachen, men også nulstille servicemedarbejdere, som også indeholder nogle ressourcer cache. Derefter viser dine numre aktivets fulde størrelse.

Lad os nu se på sideindlæsningen i langsom bevægelse. Der er en forklaring i dokumentationen til Google Chrome om, hvordan man gør det. Vi får et antal skærmbilleder, der viser side i forskellige indlæsningstrin:

Det viser, at siden bliver mere eller mindre anvendelig efter 9 sekunder.

Indlæsning af side igen med cachen og servicearbejdere aktiveret viser et bedre billede. Der er kun 250 Kb anmodninger, men det gør ikke siden hurtigere, vi er stadig nødt til at se en indlæsningsskærm i 9 sekunder. Der er noget andet, der gør siden indlæst langsommere, ikke netværksudvekslingen.

Blokering af nogle ressourcer

Hvis vi ser på listen over ressourcer, vil der være mange af dem:

Måske er nogle af dem ikke rigtig nødvendige til sidearbejdet? Lad os prøve at blokere ressourcer og se, hvordan dette vil påvirke siden. Det er let at gøre med den indbyggede dev-værktøjsfunktion.

Det viste sig, at anmodninger om `https: //mail.google.com / _ / scs / *` er afgørende for Gmail-grænsefladen, men nogle andre kan blokeres:

  • www.gstatic.com/og/* - Google API Сlient Library, for at anmode om API til forskellige Google-tjenester
  • ssl.gstatic.com/inputtools/* - Google Inputværktøjer - skærmtastaturwidget
  • hangouts.google.com - integreret Hangouts-widget

Efter blokering af disse scripts indlæses siden på 4 sekunder, men de vigtige funktioner såsom læsning og skrivning af e-mails fungerer stadig. Hvis du også oplever ydelsesproblemer i Gmail-grænsefladen, kan blokering af disse webadresser muligvis være en løsning for dig.

profilering

På dette tidspunkt har vi afskåret nogle ressourcer, men siden belastes stadig langsomt. Vi skal se, hvad der sker i løbet af disse 4 sekunder. Chrome har en indbygget Javascript-profil, der viser os følgende billede:

Tilsyneladende var browseren travlt med at udføre Javascript i hele denne tid. Det er interessant at se, hvilken slags kode dette er. Javascript sendes normalt til klienter i en minificeret form uden formatering og med manglet funktion og variabelnavne.

Afminificering af kildekoden

Lad os prøve at forstå den minificerede kode. Vi vil downloade ressourcer og sende dem gennem Prettier, et værktøj til kodeformatering. Alternativt kan du bruge en indbygget funktion i Chrome DevTools.

Kode bliver mere læselig, men det er stadig meget svært at forstå uden originale navne, hvad disse funktioner gør. Heldigvis bevares strenge, og vi kan bruge disse spor til at gendanne kildekoden. Der er nogle strenge som closure_uid_ eller type_error: TrustedResourceUrl. Vi kan søge efter dem på internettet i håb om at finde nogle open source-rammer, de kommer fra.

Søgningen ville føre os til Google Closure Library. Det ser ud til, at vi har set nogle forkortede stykker af denne ramme. Yderligere sammenligning afslører nogle matchninger mellem minificeret kode og kilder til Closure Library:

To hvis udsagn, en kort og en lang, derefter tildeling og til sidst et funktionsopkald. Dette skal være den samme kode.

For at komme videre møder vi også strenge som GwtExecutor, ListenableFuture, DaggerComponentFactory, der ligner dele af Java-stack, muligvis kompileret til Javascript. Et relateret Google Inbox-projekt er vist på “projekter, der bruger GWT” -siden, og det er muligt, at det delte en eller anden kode med den vigtigste Gmail-grænseflade.

Denne teknologistapel er meget uventet. I lyset af det faktum, at Google aktivt promoverer webkomponenter og deres rammer oven på det (Polymer), er det meget overraskende at se i 2018 en redesign af et Google-projekt, der ikke bruger dem.

I stedet har vi en meget gammel teknologistak med en masse artefakter fra tidligere dage, hvor alle browsere ikke fulgte standarder, og du var nødt til at skrive en særlig behandling for hver browser. Resterne af det er der stadig, i 2018-udgaven af ​​Gmail-kode:

  • AJAX via ActiveXObject, et hack til IE6, fordi det ikke havde XMLHttpRequest support
  • Begivenhedslyttere via attachEvent, var nødvendige for IE8 og nedenfor, de havde ikke standard `addEventListener` metode.

Denne kode er inkluderet i bundtet uden praktisk grund, da Gmail officielt kun understøtter IE10 +, der ikke er nogen forbrugere til disse hacks.

Ud over arven overhead har denne stak forældede komponentparadigme. Det er baseret på klassehierarki - en tilgang med et stort antal tunge abstraktioner, som skabes for hver komponent, der markant bremser gengivelsen, når du har hundreder af komponenter på en side. Moderne UI-rammer opretter ikke lange arvekæder, deres klasser er lette, og gengivelsesarbejdet udføres af rammekernen. Dette reducerer en overhead af komponenter, så du kan have flere komponenter uden ydelsesstraf.

Det bidrager bestemt til langsom sideinitialisering: der er tusinder af klasser, der bliver instantieret under sideindlæsning, der bremser sidegengivelsen.

På trods af det opdaterede visuelle udseende, koden til Gmail bærer arven fra gamle teknologier, kan vægten ikke skjules af den nye visuelle skal.

Kontrol af kodedækning

En anden nyttig funktion ved DevTools er kodedækning. Det hjælper med at forstå, hvilke dele af koden, der ikke blev udført af browseren, og muligvis kan indlæses efter behov.

Cirka halvdelen af ​​koden blev ikke brugt. Der er kan være legitime stykker, som begivenhedslyttere og andre async-operationer. Men det er værd at kontrollere ubrugte dele alligevel. Vi kan finde en kode, der muligvis kan smides.

Ud over allerede nævnte hacks til ældre versioner af Internet Explorer har vi fundet et par mere interessante stykker:

Rester af Google Picasa

Tjenesten er lukket ned, men hukommelsen lever stadig i GMail-kode.

Skærmtastatur

Der er en masse klasser, der er ansvarlige for funktionen, som du sandsynligvis ikke bruger hver dag, men de er indlæst med hvert besøg på Gmail-siden.

Integration med Google Kalender

Samme som ovenfor: du bruger muligvis ikke Google Kalender, men den pæne møderepræsentation bliver indlæst.

Konklusion

Denne gennemgang kan muligvis tydeliggøre nogle af grundene til, at Gmail-grænsefladen er langsom. Desværre er det ud af vores hænder at få Google til at forbedre ydelsen på deres interface. Men vi kan lære nogle lektioner til vores egne webapplikationer:

  • Google Closure Compiler er meget kraftfuld. Det var et rigtigt puslespil for at gendanne kildekoden, det giver i øjeblikket den bedste komprimeringsgrad sammenlignet med enhver anden JS-minifier.
  • Kontroller dit projekt for ubrugt kode, for eksempel hacks til ældre browsere. Gennemgå din kode og slippe af med ting, som ikke er reelle mere. Hvis du bruger Babel, kan du overveje at levere browserlist-konfiguration til kun at omfatte transformationer, der giver mening for din målgruppe.
  • Abstraktioner er ikke gratis. Hvis du gerne vil løse en opgave ved hjælp af et elegant programmeringsmønster, skal du først tænke på omkostningerne ved den. Der kan være en enklere løsning tilgængelig.
  • Medtag ikke sekundære sideelementer i den indledende nyttelast, brug kodespaltning. For Gmail indlæses Hangouts-widget øjeblikkeligt, hvilket bremser de vigtigste ressourcer. Det kan muligvis indlæses senere, efter den vigtige funktionalitet på siden - listen over e-mails.
  • Forsøm ikke moderne teknologier. De kan muligvis indeholde grundlæggende forskellige løsninger til dine problemer, mere udførlige og praktiske.
  • Til sidst, glem ikke at være opmærksom på ydeevnen på din app. Kontroller det fra tid til anden, eller indstil en CI-integration til den.
Tak til Oli Steadman for korrekturlæsning af artiklen