Optimizarea performanței site-ului și a căii critice de redare

Publicat: 2022-03-11

Performanța de redare a paginii dvs. web îndeplinește standardele actuale? Redarea este procesul de traducere a răspunsului unui server în imaginea pe care browser-ul „o pictează” atunci când un utilizator vizitează un site web. O performanță proastă de redare se poate traduce într-o rată de respingere relativ ridicată.

Există răspunsuri diferite de server care determină dacă o pagină este sau nu redată. În acest articol, ne vom concentra pe randarea inițială a paginii web, care începe cu analizarea HTML (cu condiția ca browserul să fi primit cu succes HTML ca răspuns al serverului). Vom explora lucrurile care pot duce la timpi mari de randare și cum să le remediam.

Calea critică de redare

Calea critică de redare (CRP) este procesul prin care trece browserul pentru a converti codul în pixeli afișabili pe ecran. Are mai multe etape, dintre care unele ar putea fi efectuate în paralel pentru a economisi timp, dar unele părți trebuie făcute în consecință. Aici este vizualizat:

Cale critică de redare

În primul rând, odată ce browserul primește răspunsul, începe să îl analizeze. Când întâlnește o dependență, încearcă să o descarce.

Dacă este un fișier de foaie de stil, browserul va trebui să îl analizeze complet înainte de a randa pagina și de aceea se spune că CSS blochează randarea .

Dacă este un script, browserul trebuie: să oprească analizarea, să descarce scriptul și să-l ruleze. Abia după aceea poate continua analiza, deoarece programele JavaScript pot modifica conținutul unei pagini web (HTML, în special). Și de aceea JS se numește blocare parser .

Odată ce toată analiza este finalizată, browserul are modelul de obiect document (DOM) și modelul de obiecte de foi de stil în cascadă (CSSOM). Combinarea lor împreună oferă Arborele de randare. Părțile neafișate ale paginii nu ajung în Arborele de randare, deoarece conține doar datele necesare pentru a desena pagina.

Penultimul pas este traducerea arborelui de randare în aspect. Această etapă se mai numește și Reflow. Acolo se calculează fiecare poziție a fiecărui nod al Arborelui de randare, precum și dimensiunea acestuia.

În cele din urmă, ultimul pas este Paint. Implică literalmente colorarea pixelilor în funcție de datele pe care browser-ul le-a calculat în etapele anterioare.

Concluzii legate de optimizare

După cum puteți ghici, procesul de optimizare a performanței site-ului web implică modificări ale site-ului web care reduc:

  • Cantitatea de date care trebuie transferată
  • Numărul de resurse pe care browserul trebuie să le descarce (în special cele de blocare)
  • Durata CRP

În continuare, ne vom scufunda în detalii despre cum se face, dar mai întâi trebuie respectată o regulă importantă.

Cum se măsoară performanța

O regulă importantă de optimizare este: Măsurați mai întâi, optimizați după cum este necesar . Majoritatea instrumentelor de dezvoltare ale browserelor au o filă numită Performanță și acolo au loc măsurătorile. Când optimizați pentru cea mai rapidă randare inițială (prima), cel mai important lucru de care trebuie să vă uitați este ora următoarelor evenimente:

  • Prima vopsea
  • Prima vopsea satisfăcătoare
  • Prima vopsea semnificativă

Aici, „Paint” înseamnă randarea cu succes a unei pagini, ultima etapă din calea critică de randare. Câteva randări se pot întâmpla una după alta, deoarece browserele încearcă să afișeze ceva cât mai curând posibil și să se actualizeze mai târziu.

Pe lângă timpul de randare, mai sunt și alte lucruri de luat în considerare - cel mai important, câte resurse de blocare sunt folosite și cât timp durează descărcarea acestora. Aceste informații se găsesc în fila Performanță după efectuarea măsurătorilor.

Strategii de optimizare a performanței

Având în vedere ceea ce am învățat mai sus, există trei strategii principale pentru optimizarea performanței site-ului web:

  1. Minimizarea cantității de date care trebuie transferate prin cablu,
  2. Reducerea numărului total de resurse care trebuie transferate prin fir și
  3. Scurtarea traseului critic de randare

1. Minimizați cantitatea de date de transferat

În primul rând, eliminați toate părțile neutilizate, cum ar fi funcțiile inaccesibile din JavaScript, stilurile cu selectoare care nu se potrivesc niciodată cu niciun element și etichetele HTML care sunt ascunse pentru totdeauna cu CSS. În al doilea rând, eliminați toate duplicatele.

Apoi, recomand să puneți un proces automat de minificare. De exemplu, ar trebui să elimine toate comentariile din ceea ce servește back-end-ul dvs. (dar nu și codul sursă) și fiecare caracter care nu conține informații suplimentare (cum ar fi caracterele cu spații albe în JS).

După ce se face acest lucru, ceea ce ne rămâne poate fi ca text. Înseamnă că putem aplica în siguranță un algoritm de comprimare, cum ar fi GZIP (pe care majoritatea browserelor îl înțeleg).

În cele din urmă, există stocarea în cache. Nu va ajuta prima dată când un browser redă pagina, dar va economisi mult la vizitele ulterioare. Este esențial să țineți cont de două lucruri:

  • Dacă utilizați un CDN, asigurați-vă că stocarea în cache este acceptată și setată corect acolo.
  • În loc să așteptați să vină data de expirare a resurselor, este posibil să doriți să aveți o modalitate de a o actualiza mai devreme din partea dvs. Încorporați „amprentele” fișierelor în adresele lor URL pentru a putea invalida memoria cache locală.

Desigur, politicile de stocare în cache ar trebui definite pe resursă. Unele s-ar putea schimba rar sau niciodată deloc. Alții se schimbă mai repede. Unele conțin informații sensibile, altele pot fi considerate publice. Utilizați directiva „privată” pentru a împiedica CDN-urile să păstreze în cache date private.

Se poate face și optimizarea imaginilor web, deși solicitările de imagini nu blochează nici analizarea, nici randarea.

2. Reduceți numărul total de resurse critice

„Critic” se referă numai la resursele necesare pentru ca pagina web să fie redată corect. Prin urmare, putem sări peste toate stilurile care nu sunt implicate direct în proces. Și toate scenariile de asemenea.

Foi de stil

Pentru a spune browserului că anumite fișiere CSS nu sunt necesare, ar trebui să setăm atribute media tuturor link-urilor care fac referire la foile de stil. Cu această abordare, browserul va trata doar resursele care se potrivesc cu media actual (tipul dispozitivului, dimensiunea ecranului) după cum este necesar, reducând în același timp prioritatea tuturor celorlalte foi de stil (vor fi procesate oricum, dar nu ca parte a redării critice). cale). De exemplu, dacă adăugați atributul media="print" la eticheta de style care face referire la stilurile de tipărire a paginii, aceste stiluri nu vor interfera cu calea critică de redare atunci când media nu este print (adică, când se afișează pagină într-un browser).

Pentru a îmbunătăți și mai mult procesul, puteți face, de asemenea, unele dintre stiluri aliniate. Acest lucru ne economisește cel puțin o călătorie dus-întors la server, care altfel ar fi fost necesară pentru a obține foaia de stil.

Scripturi

După cum am menționat mai sus, scripturile blochează analizatorul deoarece pot modifica DOM și CSSOM. Prin urmare, scripturile care nu le modifică nu ar trebui să fie blocate de analiză, economisindu-ne astfel timp.

Pentru a implementa acest lucru, toate etichetele de script trebuie să fie marcate cu atribute – fie async , fie defer .

Scripturile marcate cu async nu blochează construcția DOM sau CSSOM, deoarece pot fi executate înainte ca CSSOM să fie construit. Rețineți, totuși, că scripturile inline vor bloca oricum CSSOM, dacă nu le puneți deasupra CSS.

În schimb, scripturile marcate cu defer vor fi evaluate la sfârșitul încărcării paginii. Prin urmare, acestea nu ar trebui să afecteze documentul (în caz contrar, va declanșa o re-rendare).

Cu alte cuvinte, cu defer , scriptul nu este executat decât după ce evenimentul de încărcare a paginii este declanșat, în timp ce async permite scriptul să ruleze în fundal în timp ce documentul este analizat.

3. Scurtați lungimea căii critice de redare

În cele din urmă, lungimea CRP ar trebui scurtată la minimum posibil. În parte, abordările descrise mai sus vor face acest lucru.

Interogările media ca atribute pentru etichetele de stil vor reduce numărul total de resurse care trebuie descărcate. Atributele etichetei de script defer și async vor împiedica scripturile corespunzătoare să blocheze parsarea.

Reducerea, comprimarea și arhivarea resurselor cu GZIP vor reduce dimensiunea datelor transferate (reducend astfel și timpul de transfer al datelor).

Introducerea unor stiluri și scripturi poate reduce numărul de călătorii dus-întors între browser și server.

Ceea ce nu am discutat încă este opțiunea de a rearanja codul între fișiere. Conform celei mai recente idei despre cea mai bună performanță, primul lucru pe care un site ar trebui să-l facă cel mai repede este să afișeze conținut ATF. ATF înseamnă deasupra pliului. Aceasta este zona care este vizibilă imediat, fără defilare. Prin urmare, cel mai bine este să rearanjați tot ceea ce are legătură cu randarea acestuia, astfel încât stilurile și scripturile necesare să fie încărcate mai întâi, cu orice altceva oprindu-se - nici analizarea, nici randarea. Și nu uitați întotdeauna să măsurați înainte și după ce faceți schimbarea.

Concluzie: Optimizarea cuprinde întregul tău stack

Pe scurt, optimizarea performanței site-ului web încorporează toate aspectele răspunsului site-ului dvs., cum ar fi stocarea în cache, configurarea unui CDN, refactorizarea, optimizarea resurselor și altele, totuși toate acestea se pot face treptat. În calitate de dezvoltator web, ar trebui să utilizați acest articol ca referință și să vă amintiți întotdeauna să măsurați performanța înainte și după experimente.

Dezvoltatorii de browsere fac tot posibilul pentru a optimiza performanța site-ului web pentru fiecare pagină pe care o vizitați, motiv pentru care browserele implementează de obicei așa-numitul „pre-loader”. Această parte a programelor scanează înaintea unei resurse pe care ați solicitat-o ​​în HTML pentru a face mai multe solicitări simultan și a le face să ruleze în paralel. Acesta este motivul pentru care este mai bine să păstrați etichetele de stil aproape una de alta în HTML (în funcție de linie), precum și etichetele de script.

Mai mult, încercați să grupați actualizările în HTML pentru a evita mai multe evenimente de aspect, care sunt declanșate nu numai de o modificare a DOM sau CSSOM, ci și de o schimbare a orientării dispozitivului și o redimensionare a ferestrei.

Resurse utile și lecturi suplimentare:

  • PageSpeed ​​Insights
  • Lista de verificare a stocării în cache
  • O modalitate de a testa dacă GZIP este activat pentru site-ul dvs. web
  • Rețea de browser de înaltă performanță: o carte de Ilya Grigorik