Știi când dai play la un video și parcă merge totul cu încetinitorul? Sau poate încerci să intri pe un site și rămâi blocat uitându-te cum se încarcă imaginile una câte una, de parcă ai fi iar în 2005 cu net pe cablu. Păi, tocmai te-ai lovit de resursele alea care blochează redarea. Tu probabil le zici doar “chestii enervante care fac să meargă greu totul”, și ai dreptate.

După ani întregi în care am blestemat calculatorul și am dat refresh ca disperatul, mi-am dat seama că problema nu-i aproape niciodată la dispozitivul nostru. De obicei, buba stă în felul cum își organizează paginile web sau aplicațiile toate fișierele lor. Și partea bună? Odată ce prinzi schema, chiar poți face ceva să rezolvi treaba.

Dar ce sunt mai exact resursele astea care blochează?

Ca să înțelegem despre ce vorbim, hai să ne gândim puțin cum funcționează un site sau o aplicație din ziua de azi. E un pic ca și cum ai construi o casă, știi? Nu pui acoperișul înainte să ridici pereții. La fel și browserul tău, are nevoie să încarce chestiile într-o anumită ordine ca să iasă totul cum trebuie.

Resursele care blochează redarea sunt fișierele alea pe care browserul simte că trebuie musai să le încarce complet înainte să-ți arate ceva pe ecran. De obicei vorbim despre JavaScript și CSS puse în capul paginii. Browserul se oprește, așteaptă să descarce fișierele astea, le procesează, și abia după aia merge mai departe cu restul.

Ce m-a uimit pe mine e că multe site-uri din ziua de azi încearcă să bage zeci de scripturi și foi de stil înainte să-ți arate măcar titlul. E ca și cum ai sta să se termine toate reclamele înainte de film, numai că aici reclamele sunt cod invizibil care pregătește terenul pentru ce vrei tu să vezi de fapt.

Când totul depinde de altceva

Treaba se complică rău când resursele astea au nevoie unele de altele ca să meargă. Un script are nevoie de altul, care și el depinde de un al treilea… se face un lanț întreg. Eu îi zic “cascada dependențelor”, unde fiecare așteaptă după cealaltă, iar tu stai cu ochii în ecranul alb și te întrebi dacă s-a stricat iar netul.

Săptămâna trecută am analizat un magazin online care, ține-te bine, încărca 47 de scripturi diferite înainte să-ți arate produsele. Patruzeci și șapte! Fiecare cu treaba lui, normal. Unul pentru statistici, altul pentru chat, altul pentru recomandări… știi cum e. Problema era că toate se încărcau la grămadă, blocând tot ce era important de văzut.

Cum găsești unde-i buba

Sculele din browser pe care nu le știe lumea

Prima unealtă pe care o ai la îndemână sunt instrumentele alea de dezvoltare din browser pe care majoritatea oamenilor nici nu știu că există. Chrome, Firefox, Edge, toate le au ascunse pe acolo. Apasă F12 sau dă click dreapta și “Inspect” pe orice pagină și o să descoperi o grămadă de chestii interesante.

Tab-ul ăla cu Network e mina de aur. Acolo vezi tot ce încarcă pagina, cât durează fiecare lucru și, mai ales, care dintre ele îi blochează pe ceilalți. Cauți barele alea roșii sau portocalii care se lungesc mult în grafic. Ăia sunt de obicei vinovații.

Am pățit cu un client care avea un font special care bloca toată pagina aproape două secunde. Două secunde! Poate nu pare mult, dar pe internet e o veșnicie. Am citit undeva că oamenii încep să plece de pe site după vreo trei secunde de așteptare, și cred că-i adevărat.

Citirea graficului waterfall

Graficul ăla waterfall din Network îți arată exact în ce ordine se încarcă lucrurile. E destul de mișto să vezi cum un singur fișier problematic poate să dea peste cap tot restul. Am văzut odată un script de tracking care venea de pe un server din cealaltă parte a lumii și bloca tot ce venea după el.

Ce cauți tu sunt barele alea lungi care se întind mult pe orizontală înainte ca următorul lucru să înceapă să se încarce. Astea sunt gâtuirile site-ului. Și nu mereu e vorba de mărimea fișierului, câteodată problema e cât de repede răspunde serverul de unde vine resursa.

Lighthouse și alte unelte care fac treaba singure

Google Lighthouse a ajuns să fie cam standardul în domeniu pentru verificarea performanței. Îl pornești direct din Chrome DevTools și îți face un raport complet despre ce nu merge și cum să repari. Ce-mi place la el e că nu doar îți arată problemele, ci îți și explică de ce sunt probleme și cum îi afectează pe cei care intră pe site.

PageSpeed Insights e varianta mai serioasă, care rulează testele pe serverele Google și îți dă rezultate mai realiste. Am observat că scorurile pot fi destul de diferite între testul de pe calculatorul tău și cel de pe PageSpeed, mai ales dacă ai vizitatori din toată lumea.

Trucuri de optimizare care chiar merg

Încărcarea asincronă și trucul cu defer

Acum vine partea interesantă. După ce ai găsit scripturile problematice, poți să începi să le îmblânzești. Atributele alea async și defer pentru scripturi sunt geniale când știi să le folosești.

Async îi zice browserului ceva de genul “încarcă asta în paralel și rulează imediat ce e gata, nu mă aștepta”. Merge perfect pentru chestii independente care nu au nevoie de altele, gen analytics sau widgeturile de social media.

Defer e altă mâncare de pește. Îi spune browserului să descarce scriptul în paralel, dar să aștepte până se încarcă toată pagina înainte să-l pornească. E super pentru scripturi care modifică pagina dar nu sunt esențiale pentru prima vedere.

Un client și-a îmbunătățit timpul de încărcare cu vreo 40% doar punând defer la scripturile principale. Simplitatea soluției m-a dat pe spate, sincer.

CSS critic și stiluri inline

Una dintre cele mai tari șmecherii pe care le-am învățat e să scot CSS-ul critic și să-l pun direct în HTML. CSS-ul critic e porțiunea aia minimă de stil care face ca prima parte a paginii, aia pe care o vezi fără să dai scroll, să arate bine.

Restul stilurilor pot veni mai târziu, asincron, după ce utilizatorul vede deja conținutul principal. E ca și cum ai aranja vitrina magazinului prima, că aia văd clienții, și pe urmă te-ai ocupa de restul.

Sunt o grămadă de unelte care pot extrage automat CSS-ul critic. Critical, Penthouse, sau chiar Webpack cu pluginurile potrivite. Prima dată când am făcut asta, am scăzut timpul până la prima afișare cu aproape o secundă întreagă.

Lazy loading pentru imagini și iframe-uri

Lazy loading a devenit atât de popular că browserele noi îl au integrat. Pui loading=”lazy” la imagini și iframe-uri, și gata, browserul le încarcă doar când utilizatorul ajunge aproape de ele cu scroll-ul.

Mi-aduc aminte de site-uri de știri care încărcau deodată zeci de poze în rezoluție mare, deși poate nu ajungeai niciodată să le vezi pe toate. Cu lazy loading, prima încărcare devine mult mai rapidă și nu mai iroseși resurse aiurea.

Preloading și prefetching cu cap

Browserele moderne te lasă să le dai indicii despre ce o să ai nevoie în curând. Preload îi spune să încarce ceva cât mai repede, perfect pentru fonturi sau imaginea aia mare de la început.

Prefetch e mai subtil, sugerează browserului să încarce chestii pentru mai târziu, când are timp liber. DNS-prefetch și preconnect pot face conexiuni cu alte servere înainte să ai nevoie de ele, economisind timp mai încolo.

Dar nu exagera cu ele. Am văzut programatori care puneau preload pe tot ce mișcă, transformând optimizarea într-o problemă și mai mare. E ca și cum ai cumpăra toate ingredientele din magazin doar că poate gătești ceva cândva.

Optimizarea de la sursă

Minificare și compresie

Minificarea scoate toate spațiile și comentariile inutile din cod, micșorând fișierele. La JavaScript și CSS poți reduce dimensiunea cu vreo 30-40% așa. Compresia gzip sau Brotli duce treaba mai departe, comprimând fișierele pentru transfer.

Îmi place să mă gândesc la asta ca la împachetat pentru mutat. Minificarea e când aranjezi eficient lucrurile în cutii, compresia e când folosești sacii ăia cu vid pentru haine. Amândouă economisesc spațiu, dar în moduri diferite.

Bundling și împărțirea codului

Bundling-ul combină mai multe fișiere mici într-unul mare, reducând numărul de cereri către server. Dar ai grijă, un bundle prea mare devine problemă în sine. De-aia există code splitting.

Code splitting împarte aplicația în bucăți care se încarcă doar când ai nevoie de ele. Webpack, Rollup, Parcel, toate uneltele moderne fac asta aproape singure acum. Parcă ieri concatenam manual fișierele JavaScript…

CDN și strategie de cache

Un CDN bun face minuni pentru timpul de încărcare, mai ales dacă ai vizitatori din toată lumea. Fișierele vin de la serverul cel mai apropiat, reducând întârzierea considerabil.

Strategia de cache e la fel de importantă. Dacă setezi bine headerele de cache, browserul păstrează fișierele local și nu le mai descarcă la fiecare vizită. Dar bagă de seamă la versionare, că altfel lumea rămâne cu versiuni vechi.

Monitorizare constantă

Monitorizarea utilizatorilor reali

Testele în laborator sunt ok, dar nimic nu bate datele de la utilizatori adevărați. Real User Monitoring îți arată cum merge site-ul în realitate, pe telefoane și calculatoare reale, cu conexiuni reale la internet.

Am găsit probleme cu RUM pe care nu le-aș fi prins niciodată altfel. Spre exemplu, un script de chat care mergea perfect în teste dar bloca tot pe anumite versiuni de Safari mobil. Fără date reale, problema asta ar fi rămas ascunsă cine știe cât timp.

Bugete de performanță

A-ți stabili un buget de performanță e ca și cum ți-ai pune singur limite. Decizi că nicio pagină nu depășește 3MB sau că site-ul trebuie să fie interactiv în maxim 5 secunde. Apoi verifici mereu și iei măsuri când depășești.

E foarte ușor să adaugi “doar încă un script micuț” sau “doar încă o poză”. Dar se adună repede toate astea. Un buget te obligă să alegi cu grijă ce pui pe site și ce nu.

Ce ne aduce viitorul

Tehnologia merge înainte mereu. HTTP/3 promite conexiuni mai rapide, WebAssembly permite cod mai rapid pentru aplicații complexe, Edge computing aduce procesarea mai aproape de oameni.

Dar la bază, principiile rămân aceleași. Găsești ce blochează, optimizezi calea critică, încarci mai târziu ce poți, și stai cu ochii pe metrici. Se schimbă uneltele, dar nevoia de experiențe rapide pentru utilizatori rămâne.

Optimizarea asta cu resursele care blochează nu-i ceva ce faci o dată și gata. E un proces continuu. Fiecare update, fiecare funcție nouă, fiecare librărie pe care o adaugi poate introduce probleme noi. Secretul e să fii atent mereu, să testezi des și să pui experiența utilizatorului pe primul loc.

Până la urmă, totul se reduce la respectul pentru timpul oamenilor care intră pe site-ul tău. Fiecare secundă pe care o salvezi e o secundă pe care ei o pot folosi să citească, să cumpere, să se uite la ce ai de oferit, nu să aștepte. Și într-o lume în care atenția e din ce în ce mai greu de captat, chiar contează fiecare secundă.