Concepte avansate pentru măsurarea vitezei paginii în 2020
Publicat: 2020-04-09Pentru a înțelege ce afectează viteza paginii în 2020, mai întâi trebuie să înțelegem cum redă un browser o pagină web. Dacă nu sunteți familiarizat cu conceptele privind viteza paginii și tehnologia web, cum ar fi DOM, CSSOM, arborele de randare, costul de reflux și tipurile DOM, probabil că doriți să începeți prin a citi articolul de mai sus.
Pe măsură ce site-urile web și browserele web devin mai complexe, viteza paginii devine mai mult decât cât de mare este o pagină sau cât de repede poate răspunde un server. În acest articol, vom analiza unele dintre valorile noi și emergente pentru viteza paginii în 2020 și ulterior: numărul și dimensiunea solicitărilor de resurse, calea critică de redare, LCP, CLS și timpul total de blocare.
Acest articol este al doilea dintr-o serie de patru articole despre viteza paginii. Primul articol îl găsiți aici: Cum creează un browser o pagină web?
Gestionarea comenzii, mărimii și numărului de solicitări de resurse
Fiecare pas al procesului de randare necesită timp. Modul de a găsi unde site-ul dvs. este lent și cum să-l accelerați, implică analizarea modului în care browserul gestionează resursele în timpul procesului de redare a paginii.
Aceasta înseamnă că ordinea, numărul și dimensiunea solicitărilor joacă un rol important în măsurarea vitezei paginii astăzi.
Cea mai importantă contribuție a ordinii resurselor și a optimizării indicațiilor de încărcare a resurselor este reducerea TTI (Time to Interactive) prin cea mai mare vopsea de conținut. Cu optimizarea comenzii resurselor, puteți încărca fișiere de același număr și aceeași dimensiune în mai puțin timp și le puteți livra utilizatorilor și motoarelor de căutare.
Ce este calea critică de redare?
Calea critică de randare include toate resursele care vor crea partea paginii web deasupra pliului.
Pagina dvs. web poate fi mai lentă decât pagina web a concurenților din cauza dimensiunii totale de încărcare a paginii dvs. Dar iată trucul: chiar dacă alte departamente de afaceri nu vă vor lăsa să remediați dimensiunea de încărcare a paginii, puteți în continuare să vă difuzați conținutul mai rapid decât concurenții, prin optimizarea căii critice de randare.
Cum să optimizați calea critică de randare
Acesta este un simulator de corelare a vitezei paginii și a ratei de conversie, creat de Sergey Chernyshev. Este posibil să găsiți răspunsul la întrebarea ce s-ar întâmpla dacă pagina mea web s-ar încărca cu 0,5 secunde mai rapid pentru utilizatori și s-ar arăta echipei de dezvoltatori pentru a specifica că fiecare milisecundă poate îmbunătăți conversia.
Pentru a optimiza calea critică de randare, trebuie să determinați ce resurse aveți nevoie pentru a crea partea de deasupra pliului. După aceea, trebuie puse câteva întrebări minore:
- Ce resurse împiedică descărcarea surselor critice de către browser?
- Dimensiunea și numărul surselor critice pot fi reduse?
- Pot fi incluse sursele critice?
- Pot fi unificate sursele critice ale căilor de redare pentru a limita procesul de căutare DNS?
Ne vom uita la un exemplu. De asemenea, vom oferi câteva recomandări pentru accelerarea CSS, JS și HTML.
Iată un exemplu de parte critică dintr-o pagină web Amazon. Cu DevTools, puteți vedea cel mai important element <div> în partea critică a paginii împreună cu codurile CSS necesare. În acest fel, puteți crea un bloc de cod CSS inline înainte de a reda resursele de blocare a perturba browserul. Este posibil să vedeți și stivele de coduri neutilizate în partea de jos. Amazon folosește întotdeauna aceleași modele de resurse CSS/JS pentru diferite categorii, chiar dacă acestea nu sunt optimizate.
Pe lângă viteză, există și o altă problemă aici. Cu diferite dimensiuni ale ecranelor telefonului mobil, partea critică a paginii web variază de la model la model. Unele ecrane nu afișează prețul, unele dintre ele nu afișează informațiile despre stoc. Aceasta este o eroare importantă de proiectare, dar îngreunează și optimizarea căii critice de redare. De asemenea, împarte valoarea PageRank dacă există o legătură în această zonă și scade probabilitatea de conversie.
Puteți utiliza Puppeteer (Googlebot's Crawl Engine) pentru a examina acest tip de problemă și pentru a face capturi de ecran automate pentru fiecare model de smartphone/tabletă și pentru a verifica designul părții critice a paginii web. Jean-Francois Lagarde are o bibliotecă drăguță de păpuși pentru această sarcină, pe care poate doriți să o verificați.
Iată o captură de ecran rapidă pentru configurarea dispozitivului în captură de ecran automată Puppeteer pentru fiecare instrument de vizualizare a dispozitivului.
Care este cea mai mare vopsea plină de conținut?
Largest Contentful Paint (LCP) este cea mai mare zonă dintr-o pagină web în ceea ce privește octeții și dimensiunea. În fiecare pagină web, există o mulțime de elemente „div” și toate conțin diferite componente ale paginii. Și aceste componente au valori diferite de încărcare a paginii.
Potrivit Google, Largest Contentful Paint este afectat în mare parte de cel mai important element al paginii. Pentru a vă face o idee despre importanța LCP, Google a decis să adauge această nouă măsurătoare la rapoartele Lighthouse în viitor.
Acest lucru înseamnă, de asemenea, că vom auzi din ce în ce mai multe despre LCP, deoarece va fi folosit împreună cu Real User Metrics (RUM) și va fi o măsură cheie, în special în ceea ce privește calea critică de redare.
Iată un exemplu de cea mai mare vopsea satisfăcătoare de la Lendio. După cum puteți vedea, DevTools arată LCP-ul pe o pagină împreună cu date despre tipul, dimensiunea și timpul de încărcare. Conținutul celui mai mare conținut de vopsea dvs. ar trebui să includă întotdeauna scopul și valoarea paginii, împreună cu cea mai importantă funcționalitate sau CTA și, cel mai important, ar trebui să fie încărcată mai întâi!
În acest exemplu, este doar text. Combinarea acestuia cu un instrument funcțional ar fi mai bine decât un simplu LCP text/imagine.
LCP ia în considerare doar anumite tipuri de resurse. Motivul principal pentru aceasta este acela de a menține măsurarea LCP simplă la început. Mai jos este o „Instanță de script” care este ștampilată pentru a crea lista de intrări LCP. Studierea acestor bucăți de cod vă va învăța la ce și cum sunt atenți dezvoltatorii Google atunci când încarcă o pagină.
[Exposed=Fereastră]
interfață LargestContentfulPaint : PerformanceEntry {
atributul readonly DOMHighResTimeStamp renderTime;
atributul readonly DOMHighResTimeStamp loadTime;
readonly atribut unsigned long size;
atributul numai citire DOMString id;
readonly atribut DOMString url;
element de atribut numai în citire? element;
[Implicit] obiect toJSON();
};
Ceea ce vedeți în această listă sunt scalele necesare pentru compararea articolelor candidate care intră în lista de înscrieri LCP. Mai jos, vă voi arăta o metodologie pentru alegerea candidaților LCP („large body text” și „large image”).
Înțelegerea principiilor și a procesului de definire a LCP
Principiile pentru determinarea LCP sunt extrem de importante:
- În timp ce o pagină se încarcă, LCP se poate schimba în câteva secunde. Uneori, chiar dacă o componentă de pagină rămâne suficient de lungă ca LCP pe ecran, chiar și un element de pagină mai mare încărcat în urmă nu schimbă starea anterioară.
- Uneori, un element de deasupra plierii (în partea critică a paginii web) este selectat ca LCP în loc de un element mai mare sub pliază (partea necritică a paginii web).
- Un element<div> mai mare nu poate fi selectat ca LCP dacă componentele sale sunt împărțite pe ecran. În schimb, un element bloc <div> va fi selectat ca LCP. Mai jos veți vedea un exemplu care ilustrează acest lucru.
În acest exemplu, vedem că cea mai mare componentă este <div> care include patru imagini diferite. Dar, niciuna dintre aceste imagini individuale nu este mai mare decât Oncrawl Logo și textul care este inclus cu acesta în același element <div>. Deoarece ambele se află în partea critică a paginii web, al doilea element va fi LCP.
În timp ce calculați sincronizarea LCP și determinați punctul de vedere al dezvoltatorilor Google, ar trebui să vă concentrați și pe designul „compounding”. Dacă un element <div> nu are un aspect/vizualizare de design combinat și unificat, probabil că nu va fi ales ca LCP.
Chiar dacă este selectat, Google Chrome poate crede că acesta nu este un LCP sănătos cu coduri noi pe care le va adăuga la API-ul LCP în viitor. Din motive legate de UX și pentru o mai bună înțelegere a vitezei paginii, Google va continua să-și îmbunătățească propria percepție folosind aceste metode.
Ce sunt schimbarea aspectului și schimbarea cumulată a aspectului?
Schimbarea aspectului este ideea că, în timp ce o pagină este descărcată de browser, elementele paginii își schimbă pozițiile într-un mod care poate fi deranjant pentru utilizator.
În timp ce o pagină este descărcată, fiecare parte a paginii va fi vizibilă una câte una, într-o anumită ordine. Asta este normal. Dar dacă aceste părți își schimbă poziția de pornire din cauza părților ulterioare, aceasta este schimbarea aspectului.
Cumulative Layout Shifting (CLS) este suma tuturor evenimentelor de schimbare a aspectului.
Chrome User Experience are și o secțiune despre scorul CLS. Dar nu este vorba doar despre UX. Schimbarea aspectului poate fi dăunătoare pentru pacienții cu epilepsie fotosensibilă. Ca „companie de sănătate”, Google trebuie să dea valoare și sănătății utilizatorilor; ei încearcă să scadă „stresul web” oriunde pot.
„Cred că Google este deja o companie de sănătate. A fost în ADN-ul companiei de la început”
David Feinberg – Șeful Google Health
Iată un exemplu simplu și decisiv de schimbare a aspectului de pe unul dintre aceleași site-uri pe care le-am văzut mai devreme în această serie. Este un site principal de știri din Turcia și aceasta este pagina lor principală...
Puteți citi mai multe despre Schimbarea aspectului, pâlpâirile, blițurile și variațiile de culoare care sunt periculoase pentru sănătate de la dezvoltatorii Moz.
Cum să găsiți schimbarea cumulată a aspectului pe site-ul dvs
Pentru a vedea modificările părților de aspect ale paginilor dvs. web, puteți utiliza Google Chrome DevTools sau puteți utiliza API-ul Layout Instability pentru a scala procesul pentru toate paginile dvs. web.
Schimbarea cumulată a aspectului, sau suma tuturor evenimentelor de schimbare a aspectului, este un criteriu important atât pentru viteza paginii, cât și pentru UX în 2020 și ulterior. Dacă partea de deasupra paginii web se schimbă în timpul încărcării, trebuie să o optimizați și atunci când optimizați viteza.
Mai jos, veți găsi Formula de schimbare a aspectului, de asemenea, un exemplu de cod API de instabilitate a aspectului, pentru a vă oferi o perspectivă asupra contribuției CLS și o metodă de calculare a scorului de schimbare a aspectului.
Formula de schimbare a aspectului este mai jos:
scor shift layout = fracțiune de impact * fracțiune de distanță
Scorul de schimbare a aspectului este calculat cu doi termeni noi folositori, Fracția de impact și Fracția de distanță:
- Fracția de impact este procentul de ecran afectat de schimbare. Știți că CLS-ul dvs. va fi ridicat dacă elementul de pagină, care acoperă 50% din fereastra de vizualizare pe dispozitivele mobile, creează o schimbare de aspect, deoarece mutarea acestuia va afecta cel puțin mai mult de 50% din ecran.
- Fracția de distanță este măsurată prin cât de departe se îndepărtează elementul de deplasare de punctul său inițial în direcția în care se deplasează în timpul deplasării. Dacă distanța dintre prima și ultima poziție este excesivă, fracțiunea Distanță va fi, de asemenea, excesivă.
Acest lucru vă va face mai ușor să estimați scorul CLS și să vă consiliați echipele IT și UX.
Mai sus, puteți vedea un fragment de cod API CLS și mai jos, un GIF care arată cum se calculează deplasarea cumulativă a aspectului.
Pe același site de știri turc la care ne-am uitat, CLS-ul nostru este 0,47. Având în vedere că este calculat între 0 și 1, acesta este un scor destul de prost.
Vă puteți calcula CLS cu ajutorul Sistemului de metrice personalizate avansat de la Webpagetest.org. Ar trebui să utilizați codurile CLS API până când „Trimite partea de informații”. După aceea, trebuie să vă schimbați adresa URL de la root/results/ la root/custom_metrics.php?test={Același număr de rezultat}.
Ce este timpul total de blocare?
Puteți descărca partea de mai sus a paginii dvs. web rapid, fără nicio schimbare a aspectului, dar dacă nu răspunde la intrarea utilizatorului, algoritmii Google susțin că aveți o altă problemă UX și viteza paginii. Timpul total de blocare este timpul pierdut în această etapă.
La fel ca schimbarea cumulativă a aspectului și cea mai mare vopsea cu conținut maxim, timpul total de blocare este o nouă valoare a vitezei paginii și a UX pentru 2020 și ulterior.
Ceea ce contează pentru timpul total de blocare (TBT) este orice eveniment de încărcare dintre First Paint (FP) și Time to Interactive (TTI) care blochează firul principal al browserului (sau dispozitivului) pentru mai mult de 50 de milisecunde și împiedică utilizatorii să efectuarea oricărui proces.
Cum se calculează și se optimizează TBT
Puteți calcula timpul total de blocare (TBT) cu Long Tasks API.
Pentru a vă optimiza scorul TBT, ar trebui să vă concentrați și pe ordinea și preferințele de încărcare a resurselor, împreună cu numărul și dimensiunea solicitărilor.
Acesta este de pe același site de înainte. După cum puteți observa, firul principal este complet ocupat timp de mai mult de 5 secunde fără oprire. LCP-ul lor este încă încărcat după aproape 2,5 secunde... Lucrul important de remarcat aici este că cea mai lungă cerere de sarcină este mai mare de 350 MS. Aceasta înseamnă că se consideră că blochează firul principal pentru mai mult de 300 MS.
De asemenea, toate timpii blocați sunt socotiți ca parte a Timpului total de blocare. Acest lucru nu include numai elemente din partea de mai sus, ci se aplică tuturor componentelor paginii web. Acesta creează un istoric de browser dăunător pentru site-ul dvs. web.
Dacă TBT-ul dvs. este mai mare de 300 de milisecunde, probabil că acest lucru va afecta considerabil reținerea utilizatorilor și rata de conversie.
Este posibil să vedeți un exemplu de calcul pentru TBT pentru firul principal de mai sus. În acest exemplu, există patru cereri. Google Chrome poate crea 6 solicitări de pe același server simultan. Doar primele 50 MS dintre ele vor merge fără probleme; după aceea va începe să facă mai multe sarcini în același timp, atât cât o permite CPU/rețea. Amintiți-vă, o ființă umană poate vedea un cadru la fiecare 16 MS. Google îi pasă de fiecare milisecundă pentru utilizatori.
În acest exemplu, timpul total de blocare este de 1 secundă și 100 MS.
Următorii pași în optimizarea vitezei paginii
Până acum, în această serie, am examinat acum modul în care browserele creează pagini web, ceea ce ne-a permis să vedem în acest articol modul în care noile valori legate de modul în care se încarcă paginile în browser pot afecta viteza paginii. Am analizat câteva dintre principalele valori noi și cum să le măsurăm și să le optimizăm.
În următorul articol din această serie despre viteza paginilor de pe site-urile web de astăzi, vom acoperi un subiect care a devenit un subiect major în SEO și dezvoltarea web: optimizarea activelor JavaScript pentru a îmbunătăți viteza și redarea paginii.