Vedeți-vă încărcarea site-ului prin ochii vizitatorului
Faceți-vă o idee bună despre ceea ce se confruntă de fapt vizitatorii dvs. atunci când vă vizitează site-ul web.
Observați ceva care se încarcă lent sau deplasat? Acest lucru vă poate ajuta să identificați întârzierile importante și problemele de conversie pe care le întâmpină vizitatorii dvs.
Captură de ecran care arată rezultatul unui test de performanță web DebugBear, octombrie 2022 Filmarea cronologică arată progresul redării site-ului de-a lungul timpului.
De exemplu, această pagină începe să fie randată după 0,7 secunde, iar imaginea principală este redată după 1,3 secunde.
Site-ul web este redat complet, cunoscut și sub numele de Vizual Complete, când widgetul de chat este afișat după 3,7 secunde.
Captură de ecran cu DebugBear care arată progresul redării unui site web de-a lungul timpului, octombrie 2022 În cadrul instrumentului, puteți viziona și o înregistrare video a procesului de randare.
Aceasta este o modalitate excelentă de a demonstra impactul problemelor de performanță clienților sau altor membri ai echipei dvs.
Captură de ecran care arată o înregistrare video a unui site web parțial redat în DebugBear, octombrie 2022 Testați modificările vitezei site-ului, văzând statisticile dvs. adevărate de încărcare
Să presupunem că v-ați optimizat site-ul web și doriți să înțelegeți dacă aceste modificări vor avea un impact.
Acest instrument rulează un „test de laborator” într-un mediu optim pentru a descoperi dacă vă optimizați corect site-ul.
Când vă testați site-ul, veți obține un „Scor de laborator” oficial, care este un rezumat al șase valori de performanță care provin din Scorul de performanță din instrumentul Lighthouse de la Google:
- First Contentful Paint (10% din scorul total).
- Indicele de viteză (10%).
- Cea mai mare vopsea plină de conținut (25%).
- Timp pentru interactiv (10%).
- Timp total de blocare (30%).
- Schimbare cumulativă a aspectului (15%).
Folosind aceste date, veți descoperi cât de utilă a fost ultima rundă de optimizări și ce ar putea fi necesar să schimbați.
Până acum, probabil vă întrebați ce trebuie să schimbați. Să învățăm cum să vă optimizați site-ul utilizând fiecare măsură cheie din Prezentarea generală a valorilor.
Cum să optimizați viteza site-ului
Executarea unui test de viteză este prima parte a călătoriei dvs. de optimizare a site-ului.
După ce aveți valorile dvs., va trebui să știți cum să le interpretați și ce să faceți pentru a le remedia.
În zona Prezentare generală a valorilor din raportul privind viteza site-ului dvs., veți vedea valorile cheie pe care ne vom concentra pentru a vă ajuta să vă accelerați site-ul:
- First Contentful Paint : Acest lucru poate fi accelerat prin repararea vitezei de comunicare a serverului.
- Cea mai mare vopsea plină de conținut : aceasta poate fi accelerată prin optimizarea media și a resurselor.
În plus, puteți utiliza cascada solicitărilor pentru a vedea cât timp durează solicitările și cum afectează aceste valori.
Cum să accelerezi First Contentful Paint (FCP)
Să începem prin a face site-ul dvs. să apară mai devreme pentru vizitatorii dvs.; ne vom ocupa mai întâi de First Contentful Paint.
Ce este First Contentful Paint?
First Contentful Paint măsoară cât de repede începe să apară conținutul unei pagini după ce vizitatorul dvs. navighează la pagina respectivă.
Este important ca conținutul dvs. cheie să apară rapid pentru a împiedica vizitatorul să părăsească site-ul. Cu cât un utilizator părăsește mai repede site-ul dvs., cu atât Google învață mai repede că experiența paginii poate fi proastă.
Dar de unde știi exact ce anume face ca site-ul tău să se încarce încet?
Cum descoperi ce probleme de server îți încetinesc site-ul? Să aflăm.
De ce durează atât de mult prima mea vopsea satisfăcătoare?
FCP-ul dvs. poate fi afectat de viteza conexiunii la server, solicitările serverului, resursele de blocare a redării și multe altele.
Sună mult, dar există o modalitate ușoară de a vedea exact ce vă încetinește FCP - cascada cererii.
Acest instrument util arată ce solicitări sunt făcute de site-ul dvs. și când începe și se termină fiecare solicitare.
De exemplu, în această captură de ecran, vedem mai întâi o solicitare pentru documentul HTML și apoi două solicitări de încărcare a foilor de stil la care se face referire în document.
Captură de ecran care arată datele de depanare pentru valoarea First Contentful Paint din DebugBear, octombrie 2022 De ce apare prima vopsea satisfăcătoare după 0,6 secunde? Putem detalia ceea ce se întâmplă pe pagină pentru a înțelege acest lucru.
Înțelegerea a ceea ce se întâmplă înainte de o primă vopsea plină de conținut
Înainte ca primele bucăți de conținut să se poată încărca pe pagina dvs. web, browserul utilizatorului trebuie mai întâi să se conecteze la serverul dvs. și să preia conținutul.
Dacă acest proces durează mult timp, atunci este nevoie de mult timp pentru ca utilizatorul dvs. să vă vadă site-ul.
Scopul dvs. este să aflați ce se întâmplă înainte ca site-ul dvs. să înceapă să se încarce, astfel încât să puteți identifica problemele și să accelerați experiența.
Încărcarea paginii Partea 1: Browserul creează o conexiune la server
Înainte de a solicita prima dată un site web de la un server, browserul vizitatorului dvs. trebuie să stabilească o conexiune de rețea la acel server.
Acest lucru necesită de obicei trei pași:
- Verificarea înregistrărilor DNS pentru a căuta adresa IP a serverului pe baza numelui de domeniu.
- Stabilirea unei conexiuni de server de încredere (cunoscută sub numele de conexiune TCP).
- Stabilirea unei conexiuni securizate la server (cunoscută sub numele de conexiune SSL).
Acești trei pași sunt efectuati de browser, unul după altul. Fiecare pas necesită o călătorie dus-întors de la browserul vizitatorului dvs. la serverul site-ului dvs. web.
În acest caz, este nevoie de aproximativ 251 de milisecunde pentru a stabili conexiunea la server.
Captură de ecran DebugBear care arată călătoriile dus-întors în rețea utilizate pentru a stabili o conexiune la server, octombrie 2022 Încărcarea paginii Partea 2: Browserul solicită documentul HTML (Timpul până la primul octet are loc aici)
Odată ce conexiunea la server este stabilită, browserul vizitatorului dumneavoastră poate solicita codul HTML care conține conținutul site-ului dumneavoastră. Aceasta se numește cerere HTTP.
În acest caz, solicitarea HTTP durează 102 milisecunde. Această durată include atât timpul petrecut în rețea dus-întors, cât și timpul petrecut în așteptarea ca serverul să genereze un răspuns.
După 251 de milisecunde pentru a crea conexiunea și 102 de milisecunde pentru a face cererea HTTP, browserul vizitatorului poate începe în sfârșit să descarce răspunsul HTML.
Această etapă se numește Time to First Byte (TTFB). În acest caz, asta se întâmplă după un total de 353 de milisecunde.
După ce răspunsul serverului este gata, browserul vizitatorului dvs. petrece ceva timp suplimentar pentru a descărca codul HTML. În acest caz, răspunsul este destul de mic și descărcarea durează doar 10 milisecunde suplimentare.
Captură de ecran DebugBear care arată diferitele componente ale unei solicitări HTTP, octombrie 2022 Încărcarea paginii Partea 3: Site-ul dvs. încarcă resurse suplimentare de blocare a randării
Browserele nu redă și nu afișează pagini imediat după încărcarea documentului. În schimb, există de obicei resurse suplimentare de blocare a redării.
Majoritatea paginilor ar arăta prost fără stil vizual, așa că foile de stil CSS sunt încărcate înainte ca o pagină să înceapă redarea.
Încărcarea celor 2 foi de stil suplimentare în acest exemplu de testare a vitezei site-ului durează 137 de milisecunde.
Rețineți că aceste solicitări nu necesită o nouă conexiune la server. Fișierele CSS sunt încărcate de pe același domeniu ca înainte și pot reutiliza conexiunea existentă.
Captură de ecran DebugBear care arată resurse suplimentare de blocare a randării care sunt încărcate după documentul HTML, octombrie 2022 Încărcarea paginii Partea 4: Browserul redă pagina
În cele din urmă, odată ce toate resursele necesare au fost încărcate, browserul vizitatorului dvs. poate începe redarea paginii. Cu toate acestea, realizarea acestei lucrări necesită și o anumită cantitate de timp de procesare - în acest caz, 66 de milisecunde. Acest lucru este indicat de marcatorul de sarcini portocaliu al procesorului din vizualizarea cascadă.
Captură de ecran DebugBear care arată pașii care duc de la încărcarea documentului HTML până la redarea paginii web, octombrie 2022 Înțelegem acum de ce FCP are loc după 632 de milisecunde:
- 364 de milisecunde pentru cererea de document HTML.
- 137 de milisecunde pentru a încărca foile de stil.
- 66 de milisecunde pentru a reda pagina.
- 65 de milisecunde pentru alte lucrări de procesare.
Cealaltă activitate de procesare include lucrări mici, cum ar fi rularea de scripturi inline sau analizarea codului HTML și CSS odată ce este descărcat. Puteți vedea această activitate ca mici linii gri chiar sub banda de filmare de randare.
Cum să optimizați First Contentful Paint (FCP)
Acum că înțelegeți ce duce la redarea site-ului dvs., vă puteți gândi la cum să-l optimizați.
- Poate serverul să răspundă la cererea HTML mai rapid?
- Pot fi încărcate resursele prin aceeași conexiune în loc să se creeze una nouă?
- Există solicitări care pot fi eliminate sau modificate pentru a nu mai bloca redarea?
Acum că piesele de început ale site-ului dvs. se încarcă mai devreme, este timpul să vă concentrați pe ca întregul site să se încarce mai rapid.
Cum accelerați cea mai mare vopsea de conținut (LCP) cu recomandările lui DebugBear
Există o mulțime de moduri de a vă accelera LCP.
Pentru a fi ușor, DebugBear ne oferă următorii pași grozavi în secțiunea Recomandări.
Să aruncăm o privire la câteva exemple de recomandări și să aflăm cum să accelerăm LCP-ul acestui site web.
Recomandarea 1: Inițiați solicitări de imagine LCP din documentul HTML
Dacă cel mai mare element de conținut de pe pagina dvs. este o imagine, cea mai bună practică este să vă asigurați că adresa URL este conținută direct în documentul HTML inițial. Acest lucru îl va ajuta să înceapă să se încarce cât mai curând posibil.
Cu toate acestea, această bună practică nu este întotdeauna utilizată și, uneori, durează mult timp până când browserul descoperă că trebuie să descarce imaginea principală.
În exemplul de mai jos, cel mai mare conținut, care este o imagine, este adăugat la pagină folosind JavaScript. Ca urmare, browserul trebuie să descarce și să ruleze un script de 200 de kilobyți înainte de a descoperi imaginea și de a începe descărcarea acesteia.
Captură de ecran DebugBear care arată un lanț de cereri secvenţiale care duce la o solicitare de imagine, octombrie 2022 Cum se remediază: În funcție de site, există două soluții posibile.
Soluția 1: dacă utilizați JavaScript pentru a încărca leneș o imagine mare, atunci optimizați dimensiunea imaginii și a eliminat scriptul de încărcare leneșă sau înlocuiți-l cu atributul modern loading="lazy", care nu necesită JavaScript.
Soluția 2: În alte cazuri, redarea pe server ar preveni nevoia de a descărca aplicația JavaScript înainte ca pagina să poată fi redată. Cu toate acestea, acest lucru poate fi uneori complicat de implementat.
Recomandarea 2: Asigurați-vă că imaginile LCP sunt încărcate cu prioritate ridicată
După încărcarea codului HTML al unei pagini, browserele vizitatorilor dvs. pot descoperi că, pe lângă imaginea dvs. principală, poate fi necesar să fie încărcate un număr mare de resurse suplimentare, cum ar fi foile de stil.
Scopul aici este să vă asigurați că imaginea dvs. principală mai mare se încarcă pentru a îndeplini cerința Google pentru cea mai mare vopsea cu conținut maxim.
Alte resurse, cum ar fi scripturile de analiză terță parte, nu sunt la fel de importante ca imaginea dvs. principală.
În plus, majoritatea imaginilor la care se face referire în codul HTML al site-ului dvs. vor fi sub fold odată ce pagina a fost redată. Unele pot fi ascunse complet într-o navigare din antet imbricată.
Din acest motiv, browserele setează inițial prioritatea tuturor solicitărilor de imagini la Scăzut. Odată ce pagina a fost redată, browserul află ce imagini sunt importante și schimbă prioritatea. Puteți vedea un exemplu în captura de ecran de mai jos, așa cum este indicat de asterisc în coloana cu prioritate.
Captură de ecran DebugBear care arată o imagine LCP încărcată cu prioritate inițială scăzută, octombrie 2022 Cascada arată că, deși browserul a știut despre imagine devreme, nu a început să o descarce, așa cum indică bara gri.
Cum să remediați: Pentru a rezolva acest lucru, puteți utiliza o nouă funcție de browser numită indicii de prioritate. Dacă adăugați atributul fetchpriority="high" la un element img, browserul va începe să încarce imaginea chiar de la început.
Recomandarea 3: Nu ascundeți conținutul paginii folosind CSS
Uneori s-ar putea să vă uitați la o cascadă de solicitare și s-au încărcat toate resursele de blocare a redării, dar totuși, nu apare niciun conținut al paginii. Ce se întâmplă?
Instrumentele de testare A/B ascund adesea conținutul paginii până când variațiile de testare au fost aplicate elementelor de conținut de pe pagină. În aceste cazuri, browserul a redat pagina, dar tot conținutul este transparent.
Ce poți face dacă nu poți elimina instrumentul de testare A/B?
Cum se remediază: verificați dacă puteți configura instrumentul pentru a ascunde numai conținutul care este afectat de testele A/B. Alternativ, puteți verifica dacă există o modalitate de a face instrumentul de testare A/B să se încarce mai rapid.
Captură de ecran DebugBear care arată o bandă de redare în care conținutul este ascuns de un instrument de testare A/B, octombrie 2022 Monitorizați viteza site-ului dvs. cu DebugBear
Doriți să vă testați continuu site-ul? Încercați instrumentul nostru de monitorizare plătită cu o perioadă de încercare gratuită de 14 zile.
În acest fel, puteți verifica dacă optimizările dvs. de performanță funcționează și puteți fi alertat cu privire la orice regresii de performanță pe site-ul dvs.
Captură de ecran care arată tendințele vitezei site-ului pentru un site web în DebugBear, octombrie 2022 
Captură de ecran care arată datele Core Web Vitals în DebugBear, octombrie 2022