Aruncând o privire sub capota reproiectatului Gmail

În urmă cu jumătate de an, Google a anunțat o versiune actualizată a interfeței Gmail. În ciuda mai multor reclamații din partea oamenilor, aceasta este interfața implicită acum.

Printre celelalte probleme, oamenii au remarcat probleme de performanță cu noua interfață, în special pe mașinile de ultimă generație. Să vedem cum s-ar putea întâmpla acest lucru și ce poate fi atât de greu în interfața web a clientului de e-mail. Vom folosi DevTool-urile Google Chrome, astfel că acest articol va fi, de asemenea, un memento bun despre funcțiile pe care le au.

Configurare inițială

În primul rând, să ne uităm la performanțele Gmail. Chrome Devtools au un instrument încorporat, Farul, care arată un raport frumos și clar despre diferite aspecte ale site-ului dvs. web, inclusiv performanța. Scorul de performanță Gmail este 2 din 100:

Pentru a fi sincer, acesta nu este rezultatul pe care îl puteți aștepta de la un produs Google. Cu toate acestea, să privim mai profund la această situație. După dezactivarea cache-ului și reîncărcarea paginii, pe fila Rețea a instrumentelor dev vor fi afișate toate solicitările pentru a încărca această pagină. Pentru mine a fost 6,9 Mb în total. Acest lucru este mult, mai ales având în vedere că Webpack, de exemplu, în mod implicit vă avertizează atunci când mărimea activelor dvs. este mai mare de 244 Kb. Aici avem de 27 de ori mai mult.

Este de menționat aici faptul că serviciile web moderne (inclusiv Gmail) utilizează Work Workers pentru caching-ul avansat al activelor. Așadar, pentru a obține un număr adecvat pentru încărcarea de pornire la rece, nu numai că trebuie să dezactivați memoria cache, ci și să resetați Work Workers, care deține și unele resurse în cache. După aceea, numerele dvs. vor arăta dimensiunea completă a activelor.

Să ne uităm la încărcarea paginii în mișcare lent. Există o explicație în documentația pentru Google Chrome cum să faceți acest lucru. Vom primi o serie de capturi de ecran, care arată pagina în diferite etape de încărcare:

Arată că pagina devine mai mult sau mai puțin utilizabilă după 9 secunde.

Încărcarea din nou a paginii cu cache și Service Workers activat arată o imagine mai bună. Există doar 250 de Kb de solicitări, dar de fapt nu face pagina mai rapidă, trebuie să vedem un ecran de încărcare timp de 9 secunde. Altceva face ca încărcarea paginii să fie mai lentă, nu compromisurile rețelei.

Blocarea unor resurse

Dacă vom analiza lista resurselor, vor fi multe dintre ele:

Poate că unele dintre ele nu sunt cu adevărat necesare pentru lucrările pe pagină? Să încercăm să blocăm resursele și să vedem cum va afecta această pagină. Este ușor de făcut cu funcția de instrumente dev încorporate.

S-a dovedit că cererile către `https: //mail.google.com / _ / scs / * 'sunt cruciale pentru interfața Gmail, dar unele altele pot fi blocate:

  • www.gstatic.com/og/* - Biblioteca Google API Сlient, pentru a face solicitări către API de diferite servicii Google
  • ssl.gstatic.com/inputtools/* - Instrumente Google Input - widget tastatură ecran
  • hangouts.google.com - widget Hangouts încorporat

După blocarea acestor scripturi, pagina se încarcă în 4 secunde, dar funcțiile esențiale, cum ar fi citirea și scrierea e-mailurilor, încă funcționează. Dacă aveți și probleme de performanță în interfața Gmail, blocarea acestor adrese URL poate fi o soluție pentru dvs.

profilare

În acest moment, am întrerupt anumite resurse, dar pagina se încarcă încet. Ar trebui să ne uităm, ce se întâmplă în aceste 4 secunde. Chrome are un profil de Javascript încorporat, care ne va arăta următoarea imagine:

Aparent, browserul a fost ocupat executând Javascript în tot acest timp. Este interesant să observăm ce fel de cod este acesta. Javascript este, de obicei, expediat către clienți într-o formă simplificată, fără formatare și cu funcție mangled și nume variabile.

Reducerea codului sursă

Să încercăm să înțelegem codul redus. Vom descărca resurse și le vom trece prin Prettier, un instrument de formatare a codurilor. În mod alternativ, puteți utiliza o caracteristică încorporată a Chrome DevTools.

Codul devine mai lizibil, dar este încă foarte greu de înțeles fără nume originale, ce fac aceste funcții. Din fericire, șirurile sunt păstrate și putem folosi aceste indicii pentru a restabili codul sursă. Există unele șiruri cum ar fi închidere_uid_ sau tip_error: TrustedResourceUrl. Le putem căuta pe internet în speranța de a găsi un cadru open-source din care provin.

Căutarea ne-ar duce la Google Closure Library. Se pare că am văzut câteva piese minunate din acest cadru. O comparație suplimentară dezvăluie câteva potriviri între codul minificat și sursele Bibliotecii de închidere:

Două instrucțiuni if, una scurtă și una lungă, apoi alocarea și în final un apel funcțional. Acesta trebuie să fie același cod.

Mergând mai departe, întâlnim și șiruri precum GwtExecutor, ListenableFuture, DaggerComponentFactory, care arată ca părți ale stivei Java, eventual compilate la Javascript. Un proiect conex Inbox Google este prezentat pe pagina „proiecte care folosesc GWT” și este posibil ca acesta să partajeze ceva cod cu interfața principală Gmail.

Această stivă tehnologică este foarte neașteptată. Având în vedere faptul că Google promovează activ componentele web și cadrul lor pe deasupra (Polimer) este foarte surprinzător să vedem în 2018 o reproiectare a unui proiect Google care nu le folosește.

În schimb, avem o stivă tehnologică foarte veche, cu o mulțime de artefacte din zilele trecute, în care toate browserele nu respectau standardele și trebuia să scrieți un tratament special pentru fiecare browser. Resturile acesteia sunt încă acolo, în ediția 2018 a codului Gmail:

  • AJAX prin ActiveXObject, un hack pentru IE6, deoarece nu a avut suport XMLHttpRequest
  • Ascultătorii de evenimente prin attachEvent, erau necesari pentru IE8 și mai jos, nu aveau metoda standard „addEventListener”.

Acest cod este inclus în pachet, fără niciun motiv practic, deoarece Gmail acceptă oficial doar IE10 +, nu există consumatori pentru aceste hack-uri.

În plus față de moștenirea generala, această stivă are paradigma componentelor depășite. Se bazează pe ierarhia de clase - o abordare cu un număr mare de abstractizări grele, care se creează pentru fiecare componentă care încetinește semnificativ redarea când aveți sute de componente pe o pagină. Cadrele moderne de interfață de utilizator nu realizează lanțuri lungi de moștenire, clasele lor sunt ușoare, iar munca de redare este realizată de nucleul cadru. Aceasta reduce o supraîncărcare a componentelor, astfel încât să puteți avea mai multe componente fără penalități de performanță.

Contribuie cu siguranță la inițializarea lentă a paginii: există mii de clase care sunt instantanee în timpul încărcării paginii care încetinește redarea paginii.

Astfel, în ciuda aspectului vizual actualizat, codul Gmail poartă moștenirea vechilor tehnologii, greutatea nu poate fi ascunsă de noua coajă vizuală.

Verificarea acoperirii codului

O altă caracteristică utilă a DevTools este acoperirea Codului. Vă ajută să înțelegeți ce părți ale codului nu au fost executate de browser și, eventual, pot fi încărcate la cerere.

Aproximativ jumătate din cod nu a fost utilizat. Există piese legitime, cum ar fi ascultătorii de evenimente și alte operațiuni async. Dar merită să verificați piesele neutilizate oricum, putem găsi unele coduri care ar putea fi aruncate.

Pe lângă versiunile deja menționate pentru versiunile mai vechi de Internet Explorer, am găsit câteva piese mai interesante:

Resturi de Google Picasa

Serviciul a fost oprit, dar memoria rămâne în continuare în cod GMail.

Tastatura ecranului

Există o mulțime de clase responsabile de funcție, pe care probabil nu le folosiți în fiecare zi, dar sunt încărcate cu fiecare vizită a paginii Gmail.

Integrare cu Google Calendar

La fel ca mai sus: este posibil să nu utilizați Google Calendar, dar reprezentarea frumoasă a ședinței va fi încărcată.

Concluzie

Această recenzie poate clarifica unele motive pentru care interfața Gmail este lentă. Din păcate, este din mâinile noastre, pentru a face Google îmbunătăți performanțele interfeței lor. Dar putem învăța câteva lecții pentru propriile noastre aplicații web:

  • Google Closure Compiler este foarte puternic. Acesta a fost un adevărat puzzle pentru a restabili codul sursă, în prezent oferă cea mai bună rată de compresie în comparație cu orice alte minificatoare JS.
  • Verificați proiectul dvs. pentru codul neutilizat, de exemplu, hacks pentru browserele mai vechi. Examinați-vă codul și scăpați de lucruri care nu mai sunt reale. Dacă utilizați Babel, luați în considerare furnizarea configurației listei de browser pentru a include doar transformări care au sens pentru publicul țintă.
  • Rezumările nu sunt gratuite. Dacă doriți să rezolvați o sarcină folosind un model elegant de programare, gândiți-vă mai întâi la costul acesteia. Este posibil să existe o soluție mai simplă.
  • Nu includeți elemente de pagină secundară în sarcina utilă inițială, folosiți divizarea codurilor. În cazul Gmail, widgetul Hangouts este încărcat imediat, încetinind resursele principale. Poate fi încărcat mai târziu, după funcționalitatea crucială a paginii - lista de e-mailuri.
  • Nu neglijați tehnologiile moderne. Acestea pot conține soluții fundamental diferite pentru problemele dvs., mai performante și mai convenabile.
  • În cele din urmă, nu uitați să acordați atenție performanței aplicației dvs. Verificați din când în când sau configurați o integrare CI pentru aceasta.
Mulțumesc Oli Steadman pentru citirea corectă a articolului