Cum folosești waterfall-ul din WebPageTest pentru a descoperi blocajele de redare?

Dacă te-ai uitat vreodată la un grafic waterfall din WebPageTest și ți s-a părut că te uiți la Matrix, nu ești singur.

Prima dată când am deschis eu unul dintre aceste diagrame, am stat vreo zece minute să înțeleg ce înseamnă toate barele colorate acelea. Dar odată ce prinzi logica din spatele lor, devine un instrument fantastic pentru a vedea exact unde se împotmolește site-ul tău.

Ce e de fapt waterfall-ul acesta

Waterfall-ul e practic o reprezentare vizuală a modului în care browserul încarcă fiecare resursă de pe site-ul tău, în ordine cronologică. Imaginează-ți că fiecare fișier pe care browserul trebuie să-l descarce (HTML, CSS, JavaScript, imagini, fonturi) e o bară orizontală.

Cu cât bara e mai lungă, cu atât mai mult timp a durat descărcarea acelui fișier. Și mai important, poți vedea când începe și când se termină încărcarea fiecăruia.

Ce face special waterfall-ul e că îți arată și dependențele dintre resurse. Adică, dacă un fișier JavaScript trebuie să se încarce înainte ca browserul să poată procesa restul paginii, o să vezi asta foarte clar. E ca și cum ai privi o cascadă (de-aia și numele) în care fiecare nivel depinde de cel de dinainte.

De ce sunt atât de importante aceste blocaje

Poate te întrebi de ce ar trebui să-ți pese de câteva fișiere care se încarcă mai încet. Păi, problema e că nu toate fișierele sunt create egale. Unele blochează literal procesul de redare a paginii.

Browserul stă cuminte și așteaptă până se încarcă ele, iar utilizatorul tău vede o pagină albă sau parțial încărcată. Ceea ce nu e deloc plăcut.

Am avut un proiect acum vreo lună unde site-ul avea un timp de încărcare decent pe hârtie, dar utilizatorii se plângeau că „pare lent”. Când m-am uitat în waterfall, am văzut că un script de analytics bloca redarea primelor secunde. Tehnică vorbind, site-ul se încărca repede, dar nimeni nu vedea nimic util pe ecran. Frustrant rău pentru toată lumea.

Cum citești barele colorate

Fiecare bară din waterfall are segmente colorate care îți spun ce se întâmplă în fiecare moment. Partea verde închis de obicei reprezintă timpul de așteptare inițial, cât durează până serverul răspunde, iar verdele deschis e timpul efectiv de download.

Dacă vezi mult verde închis, problema e la server sau la latență. Dacă vezi mult verde deschis, probabil fișierul e prea mare sau conexiunea e lentă.

Dar ce mă interesează pe mine cel mai mult sunt barele care apar în partea de sus a waterfall-ului și au o linie roșie sau portocalie în dreptul lor. Astea sunt resursele care blochează redarea. Browserul nu poate continua să afișeze pagina până nu se termină cu ele. E ca și cum ai pune Stop pe tot procesul.

Cascada primelor secunde

Primele 1-2 secunde din waterfall sunt cele mai critice. Aici vezi HTML-ul principal, apoi CSS-ul și JavaScript-ul din head-ul paginii. De multe ori, aici se ascund și problemele. Am văzut site-uri care aveau 5-6 fișiere CSS separate, fiecare așteptând să se încarce înainte ca browserul să poată face ceva. Horror.

Un truc pe care l-am învățat e să mă uit la Start Render în WebPageTest. Ăsta e momentul când utilizatorul vede ceva pe ecran pentru prima dată. Dacă linia asta e departe de început, înseamnă că ai resurse care blochează redarea inițială.

Speed Index e altă metrică interesantă, un pic mai complicată, dar îți spune cât de repede se populează vizual pagina. Un Speed Index mare înseamnă că, deși browserul a început să redeze ceva, conținutul util apare târziu. Și utilizatorul tău stă și se uită la ecran ca la televizor stricat.

JavaScript-ul, acel necunoscut

JavaScript-ul e probabil cel mai mare vinovat când vine vorba de blocaje. Browserul tradițional oprește tot când întâlnește un tag de script în HTML și așteaptă să se descarce și să se execute scriptul. Asta se vede foarte clar în waterfall ca o pauză în cascada de resurse.

De exemplu, dacă ai jQuery încărcat în head fără atributul async sau defer, o să vezi că toate resursele următoare așteaptă cuminte. E ca și cum ai avea o mașină oprită la semafor, iar toate celelalte mașini din spate stau și ele. Nimeni nu merge nicăieri.

CSS-ul și fonturile

CSS-ul blochează și el redarea, dar într-un mod puțin diferit. Browserul nu vrea să afișeze pagina până nu știe cum ar trebui să arate. Are sens, nu vrei să vezi pagina săltând din toate părțile pe măsură ce se aplică stilurile. Ar fi haotic.

Fonturile personalizate sunt și ele interesante. Multe site-uri folosesc Google Fonts sau fonturi proprii, și browserul trebuie să le descarce înainte să le poată folosi. În waterfall, o să vezi cererile către fonturile externe, și dacă astea durează mult, textul fie nu apare deloc (în lumea web se numește FOIT, Flash of Invisible Text), fie apare mai întâi cu un font de rezervă (FOUT, Flash of Unstyled Text). Ambele variante pot arăta ciudat pentru utilizator.

Cum descoperi exact ce blochează

Când deschizi rezultatele din WebPageTest, mergi la secțiunea Waterfall View. Acolo caută prima bară care are o notă sau un indicator special lângă ea. De obicei, WebPageTest marchează automat resursele care blochează redarea, ceea ce îți simplifică munca considerabil.

Un alt lucru pe care îl fac e să mă uit la coloana Request Number. Primele 10-15 cereri sunt cele mai importante pentru experiența inițială. Dacă printre ele vezi scripturi grele de la terțe părți, analytics, ads, widgets și alte chestii care nu sunt esențiale pentru redarea inițială, ai găsit un blocaj potențial.

Mai există și o vizualizare în WebPageTest numită Connection View care îți arată cum sunt folosite conexiunile TCP. Browserele moderne pot deschide multiple conexiuni simultan, dar dacă vezi că toate conexiunile sunt ocupate cu resurse blocante, restul rămâne în așteptare. E ca și cum ai avea doar două mâini și ai vrea să cari zece pungi deodată.

Ce faci cu informația asta

Odată ce ai identificat blocajele, vine partea interesantă. Pentru JavaScript-ul care blochează, poți fie să-l muți la finalul paginii, fie să folosești atributele async sau defer. Async încarcă scriptul în paralel și îl execută când e gata. Defer îl încarcă în paralel dar îl execută după ce s-a terminat de procesat HTML-ul. E diferența dintre a aștepta să termine cineva de vorbit sau a-l întrerupe.

Pentru CSS, poți încerca să extragi doar stilurile critice, cele necesare pentru conținutul vizibil imediat, și să le pui inline în HTML. Restul CSS-ului îl încarci asincron. E un proces mai complicat, recunosc, dar face minuni pentru timpii de redare.

Fonturile le poți preîncărca cu tag-ul link rel=”preload”. Asta îi spune browserului să înceapă descărcarea fontului mai devreme, fără să blocheze restul paginii. Există și strategia de a folosi font-display: swap în CSS, care îi spune browserului să afișeze textul cu un font de rezervă până se încarcă fontul personalizat. Textul apare instant, fontul se schimbă după.

Dacă vrei să înveți mai multe despre cum sa optimizesti resursele care blocheaza incarcarea site-ului, există ghiduri detaliate care intră în profunzime în fiecare tehnică și îți arată exact pașii.

Testarea înainte și după

Ce îmi place la WebPageTest e că poți salva rezultatele și le poți compara. După ce faci optimizări, rulezi din nou testul și compari waterfall-urile. O să vezi cum barele se scurtează, cum linia de Start Render se mută mai aproape de început, cum apar mai multe cereri în paralel. E satisfăcător să vezi îmbunătățirile.

Am avut cazuri în care doar mutând două scripturi de analytics din head în footer am câștigat 1,5 secunde la Start Render. Poate nu pare mult când citești așa, dar pentru utilizator e diferența dintre o pagină care pare rapidă și una care pare lentă. E diferența dintre a rămâne pe site sau a apăsa back.

Limitările și contextul

Trebuie să menționez că waterfall-ul îți arată o singură încărcare, într-un singur moment.

Condițiile de rețea se schimbă, serverele au performanțe variabile. De asta, eu rulez întotdeauna cel puțin 3-5 teste și mă uit la mediane, nu la un singur rezultat care ar putea fi o anomalie.

Mai e important și locația testului. WebPageTest îți permite să alegi de unde rulezi testul, Virginia, Frankfurt, Tokyo și așa mai departe. Un site poate avea performanțe excelente pentru utilizatorii din SUA dar să fie lent pentru cei din Asia dacă serverul e în America și nu folosești un CDN. Geografia contează enorm.

Aspecte mai avansate

Dacă te simți confortabil cu baza, există și setări mai avansate în WebPageTest. Poți simula diferite viteze de conexiune precum 3G, 4G sau cablu, diferite browsere, chiar și diferite dispozitive mobile. Waterfall-ul se schimbă dramatic pe o conexiune 3G simulată și îți arată exact cât de vulnerabil e site-ul tău la condiții mai puțin ideale. Realitatea e că mulți utilizatori nu au conexiuni perfecte.

Există și opțiunea de a bloca anumite domenii în timpul testului. E util când vrei să vezi cât de mult impactează o resursă externă (să zicem un widget de Facebook sau un script de advertising) performanța generală. Simplu blochezi acel domeniu și compari waterfall-urile. Surprizele sunt uneori neplăcute când vezi că un widget încetinește totul cu 2-3 secunde.

Sincer, waterfall-ul din WebPageTest a devenit pentru mine ca un reflex. Ori de câte ori lucrez la un site nou sau investighez probleme de performanță, prima dată mă uit acolo.

E ca și cum ai avea o radiografie a site-ului tău, care îți arată exact unde sunt problemele, fără să trebuiască să ghicești sau să bagi degetul în ochi. Vezi datele, înțelegi ce se întâmplă, iei decizii informate. Și asta face toată diferența.

Parteneri

Articole recomandate din rețeaua noastră

Dolce SportLisandro Martinez reproșează șefilor lui Manchester United transferurile după 0-2 cu Atlético MadridGetPonyIntimidarea prin apropiere sau frânare bruscă aduce până la 1.081,25 lei amendă și 30 de zile fără permisBravonetProcurorii au dispus control judiciar pentru Toma Cuzin după accidentul produs cu permisul suspendatLylaVaccinul anti-HPV protejează împotriva unor cancere. Când sunt necesare 2 sau 3 dozeRevista IoanaCum calculezi banii pentru zugrăvit acasă. Un buget orientativ de 370 de lei acoperă numai perețiiNews24Alerta aeriană din Tulcea s-a încheiat la 19.03 după intrarea unei ținte în spațiul României