Săptămâna trecută m-am trezit în fața unei probleme care m-a ținut treaz mai multe nopți.
Un site care teoretic ar fi trebuit să zboare se târa de parcă eram în 2003 și aveam internet pe cartelă. După vreo șapte cești de cafea și ore bune petrecute săpând prin cod, am dat peste vinovatul cel mai neașteptat: niște fișiere JavaScript aparent banale care blocau absolut totul.
Știi senzația aia când dai click pe un link și stai ca prostul uitându-te la o pagină albă? Păi, de cele mai multe ori problema vine tocmai de la codul ăla care teoretic ar trebui să facă site-ul mai șmecher. Ironic, nu? Resursele astea care blochează redarea sunt fix ca dopul de la cadă… până nu îl scoți, apa stă pe loc, indiferent cât de tare dai drumul la robinet.
Ce sunt resursele care blochează redarea și de ce ar trebui să ne pese
Browser-ul tău citește o pagină web cam cum citești tu o carte, de sus în jos, rând cu rând. Numai că uneori dă peste chestii care îl obligă să se oprească din citit și să facă altceva întâi. E ca și cum ai citi un roman și la fiecare două pagini cineva ți-ar băga o enciclopedie în față zicând „citește și asta întâi, că altfel nu înțelegi ce urmează”.
În general, vinovații sunt fișierele CSS și JavaScript pe care le bagi în head-ul paginii. Browser-ul le vede, se panichează că sunt super importante și refuză să arate ceva pe ecran până nu termină cu ele. Rezultatul? Vizitatorii tăi se holbează la un ecran alb în timp ce se descarcă tone de cod care probabil nici măcar nu e necesar imediat.
Zilele trecute am dat peste un site care încărca vreo 15 fișiere JavaScript diferite chiar în head. Fiecare cerea timp să fie descărcat, procesat, executat. Și na, oamenii nu au răbdare. După vreo 3 secunde, jumătate din vizitatori pleacă. Trei secunde! Atât îți ia să citești fraza asta de două ori.
Lighthouse, salvatorul tău din Chrome
Google Lighthouse e genul ăla de tool pe care îl descoperi și te întrebi cum naiba ai trăit fără el. E chiar acolo, în Chrome, în DevTools, și odată ce îl înveți nu mai scapi de el.
Ca să ajungi la el, deschizi Chrome-ul, dai click dreapta oriunde pe pagină, alegi Inspect și cauți tab-ul cu Lighthouse. Sau dacă ești mai techie, bagi direct Ctrl+Shift+I pe Windows sau Command+Option+I dacă ești pe Mac. Prima dată pare complicat, recunosc, dar după ce îl folosești de câteva ori devine reflexul ăla pe care îl ai când deschizi frigiderul să vezi dacă a apărut ceva nou între timp.
Partea mișto la Lighthouse e că nu doar îți zice „ai o problemă”, ci îți și explică ce să faci ca să o rezolvi. Rulezi un audit și primești un raport întreg cu toate mizeriile găsite, cât timp pierde fiecare și cum să le repari. Practic ai un consultant care lucrează moca și nu te judecă când vezi rezultatele.
Cum rulezi primul audit și la ce să te uiți
După ce deschizi Lighthouse, trebuie să alegi ce vrei să testezi. Pentru problemele cu resursele care blochează, vrei să te uiți la Performance. Apeși pe Generate report și aștepți. Durează cam 10-30 de secunde, depinde cât de încărcat e site-ul tău.
Când apare raportul, o să vezi un scor mare și colorat sus. Dar ăla e pentru impresionat șefii. Ce te interesează pe tine sunt detaliile de mai jos. Dai scroll până găsești secțiunile Opportunities și Diagnostics. Acolo găsești exact cum detectezi resursele care blocheaza redarea site-ului. Le vezi pe toate frumos listate, cu nume, cu timp pierdut, cu tot ce trebuie.
Luna trecută am reparat un magazin online care avea scorul 23 din 100. După ce am scos tot ce bloca aiurea, am ajuns la 78. Nu e perfect, dar măcar nu mai plecau clienții înainte să vadă produsele.
Metricile alea ciudate și ce înseamnă de fapt
Lighthouse îți aruncă o grămadă de termeni pompoși în față. First Contentful Paint, Largest Contentful Paint, Time to Interactive… Sună ca niște nume de cocktail-uri pretențioase, dar fiecare măsoară ceva simplu.
First Contentful Paint e momentul când apare prima chestie vizibilă pe ecran. Dacă durează mai mult de 2 secunde, începi să ai probleme. Largest Contentful Paint e când se încarcă bucata aia mare de conținut pentru care a venit omul pe site. Time to Interactive e când în sfârșit poți da click pe chestii și chiar se întâmplă ceva.
Toate metricile astea sunt direct influențate de resursele care blochează. Un singur fișier CSS mai mare poate întârzia totul cu secunde bune. Am văzut odată cum scoțând un script vechi și uitat, timpul de încărcare a scăzut cu 40%. Așa, dintr-odată.
Fascinant e cum probleme care par minore pot avea efecte uriașe. Un font care se încarcă prost poate bloca tot textul de pe pagină. Un script de analytics pus unde nu trebuie poate întârzia tot site-ul. În optimizare chiar contează fiecare detaliu mic.
Ce tipuri de resurse fac probleme și cum le prinzi
CSS-ul din head e problema clasică. Browser-ul crede că nu poate arăta nimic frumos fără stiluri, așa că așteaptă cuminte să le descarce pe toate. Numai că majoritatea site-urilor încarcă tot CSS-ul pentru toate paginile, chiar dacă pe pagina curentă folosești poate 10% din el.
JavaScript-ul e și mai rău. Nu doar că blochează afișarea când e pus în head, dar poate opri și citirea HTML-ului. Am văzut site-uri care băgau jQuery, Bootstrap, trei librării de animații și o grămadă de plugin-uri înainte să arate măcar titlul. De parcă era concurs de cine încarcă mai multe.
Fonturile web sunt o categorie aparte de bătăi de cap. Browser-ele moderne au un comportament dubios unde nu arată deloc textul până nu vine fontul. Îți imaginezi? Vizitatorul așteaptă 3 secunde să vadă textul doar pentru că tu ai vrut neapărat Helvetica Neue Ultra Light.
Și mai sunt și imaginile. Deși tehnic vorbind nu blochează redarea inițială, pot încetini rău încărcarea finală. Lighthouse te atenționează și despre astea, mai ales când sunt mari și sunt primele pe care le vede vizitatorul.
Ce faci concret ca să repari treburile astea
După ce știi care-s problemele, vine partea care chiar e fun… rezolvarea. Și zic fun pentru că vezi rezultatele imediat și te simți ca un magician.
Pentru CSS, trucul e să scoți doar stilurile absolut necesare pentru ce se vede inițial pe ecran. Restul poate veni mai târziu, când browser-ul are timp. Sunt tool-uri care fac asta automat, dar poți și tu manual să te uiți ce e chiar necesar pentru prima impresie.
La JavaScript, secretul stă în două cuvinte magice: async și defer. Async îi zice browser-ului să descarce scriptul în timp ce citește și restul paginii. Defer e și mai tare, execută scriptul doar după ce a terminat cu toată pagina. Pentru chestii care nu sunt vitale imediat, bagă defer și gata.
Eu de obicei mut aproape tot JavaScript-ul la sfârșitul body-ului. Simplu, eficient și nu ai nevoie de doctorate în webpack. Browser-ul arată conținutul întâi și pe urmă se ocupă de funcționalități.
Pentru fonturi, trucul meu preferat e să adaug font-display: swap în CSS. Basically îi zici browser-ului să arate textul cu ce font are el și apoi să schimbe când e gata fontul tău. Omul vede conținutul instant, chiar dacă nu arată perfect din prima.
Cum să prioritizezi ce se încarcă și când
Nu toate resursele sunt la fel de importante. Scriptul de chat sau cel de analytics nu ar trebui să se bată pe bandwidth cu CSS-ul principal sau cu imaginea aia mare de la început.
Resource hints sunt arma secretă pe care puțini o știu. Preconnect face conexiuni din timp către alte domenii. Prefetch descarcă chestii pentru mai târziu. Preload forțează descărcarea rapidă a lucrurilor importante.
Am lucrat recent la un site de știri care avea 8 scripturi diferite de reclame. După ce am băgat preconnect pentru domeniile de ads și defer pentru scripturi, am câștigat 2 secunde. Poate nu pare mult, dar pentru un site cu milioane de vizitatori, vorbim de bani serioși.
Pentru imagini, lazy loading e acum standard în browsere. Doar adaugi loading=”lazy” la imagini și browser-ul se descurcă. Pentru browsere vechi, există soluții simple de backup.
Cum ții performanța sub control pe termen lung
Optimizarea nu e ceva ce faci o dată și gata. Site-urile cresc, se adaugă feature-uri, librării noi și încet, încet performanța se duce iar pe apa sâmbetei.
Eu rulez Lighthouse măcar o dată pe lună. Sau după fiecare schimbare majoră. Salvez rapoartele să văd cum evoluează treaba în timp. Am clienți care urmăresc scorurile Lighthouse ca pe cifra de afaceri.
Automatizarea te salvează pe termen lung. Poți băga Lighthouse direct în procesul de deployment. Sunt tool-uri care verifică automat și îți trimit mail când performanța scade sub un anumit nivel.
Un pont pe care l-am învățat pe pielea mea… pune-ți limite clare. Nicio pagină să nu aibă mai mult de 200KB de JavaScript. First Contentful Paint sub 1.5 secunde. Și apoi folosește tool-uri care verifică automat limitele astea.
Situații speciale care necesită atenție extra
Nu toate site-urile sunt la fel, evident. Un blog simplu nu are aceleași nevoi ca o aplicație web complexă. Single Page Applications au cu totul alte probleme când vine vorba de blocarea redării.
Pentru SPA-uri, durerea mare e bundle-ul JavaScript inițial. O aplicație React sau Angular ajunge lejer la sute de kilobytes care trebuie descărcate și executate înainte să apară ceva pe ecran. Code splitting e salvarea aici, împarți aplicația în bucăți mai mici care vin când e nevoie de ele.
Site-urile de e-commerce au provocarea să balanseze între funcționalități complexe și viteză. Filtre, galerii, review-uri, chat, toate vor o bucată din timpul tău. Trebuie să alegi ce e mai important… să arate produsul rapid sau să aibă toate zorzoanele de la început?
Am reparat odată un magazin cu 23 de scripturi third-party. După analiză, jumătate nici nu se foloseau pe majoritatea paginilor. Le-am făcut să se încarce doar unde trebuiau și brusc site-ul zbura.
Impactul real asupra afacerii tale
Performanța nu e doar despre scoruri și millisecunde. E despre bani, conversii, clienți mulțumiți. Fiecare secundă în plus de așteptare înseamnă vânzări pierdute.
Amazon a calculat că pierde 1% din vânzări pentru fiecare 100ms de întârziere. Pentru un site mai mic, procentul poate fi și mai dureros. Am văzut magazine care și-au dublat conversiile doar reparând problemele astea de blocare.
Și mai e ceva… Google folosește viteza ca factor de ranking. Un site rapid nu doar că face vizitatorii fericiți, dar și urcă în căutări. Win-win, cum s-ar zice.
După ce optimizezi, urmărește nu doar metricile tehnice. Uită-te la bounce rate, timp pe site, pagini per vizită. Toate ar trebui să se îmbunătățească odată cu performanța.
Partea aia de final care nu vrea să fie concluzie
Treaba cu optimizarea performanței e că nu se termină niciodată. Lighthouse îți arată drumul, resursele care blochează sunt gropile din asfalt, iar rezultatul e un site care chiar funcționează cum trebuie.
Fiecare milisecundă chiar contează. Fiecare optimizare mică se adună. Începe cu ce e evident problematic și apoi rafinezi continuu. Nu te opri după prima rundă.
Și uite un sfat din ăla de final… testează pe telefoane reale, nu pe laptop-ul tău de gaming cu fibră optică. Oamenii reali folosesc telefoane de acum 3 ani pe 4G aglomerat. Pentru ei optimizezi, nu pentru tine. Așa că ia un telefon mai vechi, du-te într-o cafenea cu wifi dubios și vezi cum se comportă site-ul tău acolo. O să ai surprize, garantez.
