Lucrez cu site-uri web de ceva vreme și pot să spun că una dintre cele mai des întâlnite probleme e asta cu scripturile sincrone care blochează totul.
Nu e doar o chestiune tehnică pe care o discuți între programatori la cafea, ci ceva ce simte direct utilizatorul când intră pe site. Mai exact, tu ca și proprietar de site poate nici nu-ți dai seama, dar vizitatorii tăi stau și se uită la un ecran alb ca prostul câteva secunde bune. Și ghici ce? Pleacă.
M-am lovit de situația asta de atâtea ori încât am ajuns să recunosc semnele aproape instinctiv. Te-ai uitat vreodată la o pagină care se încarcă ciudat, cu sughițuri? Apare textul, dispare, apoi iarăși apare, totul se rearanjează… e haos. Acolo probabil că se joacă exact drama asta.
Dar hai să lămurim ce înseamnă de fapt un script sincron, că altfel vorbim degeaba. Când browserul citește HTML-ul tău, merge frumos de sus în jos, linie cu linie. Parcă citește o carte. Și brusc dă peste un tag de script fără nimic special la el. Ce face? Se oprește din tot. Descarcă fișierul ăla JavaScript, îl execută complet, și abia după aia continuă să citească restul paginii. E ca și cum ai citi un roman și autorul îți spune „stai, oprește-te aici și du-te citește întâi cartea asta de 300 de pagini, după aia continuăm”. Absurd, nu?
Ce observi cu ochiul liber
Prima metodă prin care poți să prinzi problema e pur și simplu să te uiți cu atenție cum se încarcă pagina. Serios acum, deschide site-ul în modul incognito, eventual șterge și cache-ul ca să fii sigur, și stai cu ochii pe ecran. Dacă vezi că pagina rămâne albă, complet goală, câteva secunde, și după aia bam, apare tot conținutul dintr-odată, ai prins-o. Ăsta e un semn clasic.
Am un prieten care și-a făcut singur un blog acum vreo doi ani. Mă tot întreba de ce îi e site-ul atât de lent, că nu pricepea. M-am uitat eu la el și ghici ce găsesc? Avea un script imens de analytics băgat în header care bloca absolut tot. Pagina aștepta să se descarce și să execute tot codul ăla înainte să afișeze orice. Pentru vizitatori părea că site-ul e mort, pur și simplu nu se întâmpla nimic.
Un alt lucru pe care îl observi e când anumite părți ale paginii apar mai târziu decât altele, dar nu într-un mod logic. Dacă headerul apare instantaneu dar conținutul principal întârzie suspect, probabil că ai undeva la mijlocul paginii un script care oprește totul.
DevTools, salvarea ta
Dacă vrei să fii sigur, nu să ghicești, atunci DevTools din browser e prietenul tău. Apeși F12 în Chrome sau Firefox, mergi la tab-ul Network și reîncarci pagina. Simplu.
Uită-te la coloana aia cu Waterfall, reprezentarea vizuală cu bare colorate. Dacă vezi o bară lungă, masivă, și nimic altceva nu se întâmplă în paralel, ai găsit problema. E exact ca atunci când stai în trafic și vezi că toată șoseaua e blocată de un singur camion care merge încet.
Mai poți folosi și tab-ul Performance. Pornești o înregistrare, reîncarci pagina, oprești înregistrarea și analizezi ce iese. Aici vezi foarte clar când browserul a stat pe loc, procesând JavaScript în loc să deseneze pagina. Dacă vezi zone galbene sau roșii lungi înainte ca procesul de paint să înceapă, bingo, acolo e blocajul.
Lighthouse face treaba grea pentru tine
Google Lighthouse, pe ăsta îl folosesc constant. Poți să-l rulezi direct din DevTools sau online prin PageSpeed Insights. Ce-mi place la el e că îți spune direct, fără ocolișuri, ce resurse îți blochează redarea site-ului și îți dă și soluții.
Rulezi un audit, te duci la secțiunea cu oportunități sau diagnostice și acolo găsești de obicei un warning legat de resurse care blochează render-ul. Lighthouse îți listează exact fișierele JavaScript care se încarcă sincron și care amână primul paint. Practic ai un asistent care îți analizează tot codul.
Un lucru pe care mulți îl ignoră e metrica First Contentful Paint. Dacă valoarea asta e mare, să zicem peste 3-4 secunde, și ai scripturi în head fără async sau defer, cam acolo e problema. Am văzut cazuri în care doar mutând un script sau adăugând un defer s-a îmbunătățit tot cu vreo 2 secunde. Diferență uriașă.
Uită-te în codul sursă
Uneori cea mai simplă metodă e să te uiți direct în HTML. Click dreapta pe pagină, View Page Source și cauți tag-urile de script. Un script sincron arată banal de simplu, fără nimic special, gen <script src="fisier.js"></script>. Dacă vezi multe din astea în head sau la începutul body-ului, ai găsit sursa problemelor.
Compară cu variantele care nu blochează. Un script cu async arată așa: <script async src="fisier.js"></script>, iar unul cu defer așa: <script defer src="fisier.js"></script>. Diferența în comportament e uriașă. Async descarcă scriptul în paralel dar îl execută imediat ce e gata, întrerupând parsarea. Defer descarcă în paralel dar execută doar după ce HTML-ul e complet parsat. Subtil dar crucial.
Testează pe conexiuni mai slabe
Un truc pe care l-am învățat de la un coleg mai vechi, simulează o conexiune proastă. În DevTools, la Network, setezi throttling la Fast 3G sau chiar Slow 3G. Când reîncarci pagina așa, problemele devin evidente. Un script care durează 200ms pe fibră optică poate dura 3 secunde pe 3G, și atunci vezi adevărata dimensiune a problemei.
Am lucrat la un magazin online unde tipul era convins că totul merge perfect. L-am pus să testeze site-ul pe telefon cu 3G și brusc a înțeles. Pagina stătea goală 5 secunde bune pentru că încărca sincron jQuery, apoi alte două librării de plugins, toate una după alta. Horror.
Ce arată consola
Consola din DevTools îți poate da indicii în plus. Dacă vezi multe erori sau warning-uri legate de scripturi, sau dacă vezi că funcții JavaScript încearcă să manipuleze elemente care nu există încă, ai probleme cu ordinea de încărcare. Scripturile sincrone se execută imediat, iar dacă încearcă să acceseze DOM-ul înainte să fie gata, primești erori.
Poți folosi și console.time cu console.timeEnd ca să măsori exact cât durează execuția anumitor părți din cod. Dacă o funcție durează 500ms și rulează sincron la începutul paginii, ai identificat un blocaj serios.
Impactul real asupra utilizatorilor
Când un script blochează redarea, asta se vede direct în metrici. Time to First Byte poate fi OK, dar First Contentful Paint și Largest Contentful Paint sunt dezastruoase. Am văzut site-uri cu TTFB de 200ms dar FCP de 3000ms, numai din cauza scripturilor blocante.
Ce e mai grav e că utilizatorii nu stau să analizeze. Ei văd ecran alb, presupun că site-ul e spart și pleacă. Și Google ia în calcul metricile astea pentru ranking, deci nu e doar despre experiența utilizatorului, ci și despre vizibilitate în search.
Ce faci după ce ai prins problema
Odată ce știi exact care scripturi blochează, ai opțiuni. Poți adăuga defer pentru majoritatea scripturilor care nu trebuie executate instant. Poți muta scripturile neesențiale în josul paginii, chiar înainte de tag-ul de închidere body. Sau poți încărca unele scripturi dinamic, prin JavaScript, doar când sunt necesare.
Important e să testezi după fiecare modificare, că altfel riști să spargi ceva. Uneori un script are dependințe care se bazează pe ordinea de execuție, și dacă schimbi asta fără verificare, poți strica funcționalități. De aia prefer să lucrez incremental, schimb câte un script, testez tot site-ul, apoi merg mai departe.
Problema cu scripturile sincrone e dintre cele mai frecvente în optimizarea web, dar și dintre cele mai ușor de rezolvat. Cu puțină răbdare și instrumentele potrivite, poți identifica rapid unde e blocajul și poți face îmbunătățiri majore pentru viteza site-ului.
