Cum crești viteza site-ului (PageSpeed, cache, hosting)

Un raport PageSpeed cu multe avertismente nu este încă un plan. Nici un scor de 100 nu dovedește că un vizitator vede repede oferta, poate folosi meniul și trimite formularul. Ca să crești viteza site-ului, trebuie să identifici mai întâi experiența lentă, apoi bucata de infrastructură sau cod care o produce și abia după aceea să alegi remedierea.

Ordinea contează. Dacă instalezi un plugin de cache înainte să măsori, poți ascunde temporar un server lent și poți introduce pagini vechi pentru utilizatorii autentificați. Dacă transformi toate imaginile în WebP, dar imaginea principală este descoperită numai după ce rulează JavaScript, Largest Contentful Paint rămâne lent. Dacă amâni toate scripturile, formularul ori consimțământul pot înceta să funcționeze.

Ghidul acesta este despre implementare verificabilă. Separă datele reale de testul de laborator, urmărește LCP, INP și CLS până la cauză și oferă un checklist cu zece verificări pass/fail. Pentru definiția aprofundată și rolul SEO al metricilor, citește ghidul despre viteza site-ului și Core Web Vitals. Aici mergem de la simptom la schimbare și de la schimbare la dovadă.

Viteza bună înseamnă că traseul critic funcționează, nu că raportul este verde

Începe cu ceea ce încearcă omul să facă. Pe o pagină de serviciu, traseul poate fi: vede promisiunea, înțelege diferențiatorul, deschide meniul, completează formularul și primește confirmarea. Pe un magazin: vede produsul, schimbă varianta, adaugă în coș și plătește. O optimizare este utilă dacă reduce întârzierea pe acest traseu fără să strice funcția, accesibilitatea, măsurarea sau calitatea vizuală de care depinde decizia.

PageSpeed Insights este un punct de pornire, nu verdictul final. Documentația Chrome despre scorul Lighthouse arată că scorul de performanță este calculat din metrici de laborator cu ponderi și curbe de scor. O modificare mică într-o metrică poate mișca scorul mai mult decât alta, iar o rulare sintetică nu reproduce fiecare telefon, rețea, stare de cache și interacțiune reală.

Definește înainte de lucru trei rezultate:

• pagina și cohorta pentru care viteza contează: homepage, categorie, produs, landing page ori formular;
• comportamentul pe care îl protejezi: conținut vizibil, meniu utilizabil, căutare, checkout sau lead trimis;
• condiția de acceptare: metrică de teren, test de laborator și test funcțional, toate trecute după schimbare.

Nu transforma „site lent” într-un proiect care atinge simultan tema, baza de date, hostingul, tagurile și imaginile. Dacă toate se schimbă deodată, nu mai știi ce a ajutat și nu poți reveni în siguranță. Un diagnostic de marketing bun fixează întâi pagina și rezultatul comercial; diagnosticul tehnic fixează apoi resursa, taskul ori răspunsul lent.

Măsoară aceeași pagină în teren și în laborator

Datele de teren răspund la întrebarea „ce au trăit utilizatorii eligibili?”. Datele de laborator răspund la „ce pot reproduce acum într-un mediu controlat?”. Ai nevoie de ambele. Fluxul recomandat de web.dev începe cu datele de teren, continuă cu diagnostic și optimizare și se închide prin monitorizarea regresiilor.

În PageSpeed Insights citește separat:

• URL-ul introdus versus întreaga origine;
• mobil versus desktop;
• experiența reală agregată versus diagnosticul Lighthouse;
• perioada datelor de teren versus momentul rulării de laborator;
• metricile Core Web Vitals versus oportunitățile tehnice.

CrUX folosește experiențe eligibile din Chrome și raportează distribuții agregate. Dacă un URL nu are suficientă acoperire, poți vedea numai date pentru origine sau deloc. Absența nu înseamnă performanță bună; înseamnă că acel set public nu poate răspunde la întrebare. Pentru un site cu trafic suficient, Real User Monitoring poate adăuga template, țară, tip de conexiune, versiune și elementul concret care a produs valoarea, cu condiția să fie implementat și interpretat corect.

În laborator, păstrează condițiile comparabile. Notează URL-ul, commitul, dispozitivul simulat, limitarea CPU și rețea, starea cache-ului, locația testului și numărul de rulări. Testează cold cache și repeat view dacă ambele există în traseu. Rulează pagina anonimă și, separat, stările autentificate ori personalizate care nu apar într-un test public.

O singură rulare nu este baseline. Păstrează mai multe observații și urmărește mediana sau distribuția, fără să selectezi rezultatul cel mai frumos. Variabilitatea poate veni din server, rețea, extensii, încărcarea mașinii și conținut dinamic. Abia după ce poți reproduce simptomul ai o bază pentru o intervenție.

Folosește LCP, INP și CLS ca piste diferite de investigație

Cele trei metrici nu sunt trei note pentru aceeași problemă. Fiecare deschide altă investigație.

LCP bun este definit la cel mult 2,5 secunde pentru percentila 75, separat pe mobil și desktop. El măsoară momentul în care cel mai mare element eligibil din viewport este randat. Dacă este lent, află întâi ce element a fost LCP în acea vizită. Poate fi o imagine hero, un bloc de text sau posterul unui video. Apoi descompune timpul în răspunsul documentului, întârzierea până la descoperirea resursei, durata downloadului și întârzierea de randare.

INP bun este definit la cel mult 200 milisecunde la percentila 75. El urmărește răspunsul vizual la interacțiuni eligibile de-a lungul vizitei. Un meniu care răspunde repede la încărcare nu compensează un filtru care blochează după zece secunde. Pentru un INP slab, separă input delay, timpul event handlerului și presentation delay. Cauza poate fi un task existent, codul interacțiunii, recalcularea layoutului ori pictarea unui efect costisitor.

CLS bun este cel mult 0,1 pentru cel puțin 75% dintre vizite. El nu măsoară bytes și nici timpul complet de încărcare, ci instabilitatea vizuală neașteptată. Imaginile fără dimensiuni, bannerele injectate, fonturile și embedurile fără spațiu rezervat sunt cauze comune. Un site poate avea LCP rapid și totuși să mute butonul exact când utilizatorul îl apasă.

Nu optimiza media totală fără segmentare. Un template de produs poate avea LCP lent din imagine; căutarea poate avea INP slab din JavaScript; o pagină editorială poate avea CLS din banner. Grupează paginile după mecanism și repară cauza comună, nu fiecare URL ca incident separat.

Urmărește resursa LCP din HTML până la primul pixel util

Pentru LCP, deschide Performance panel și Network waterfall. Identifică elementul, URL-ul resursei și momentul în care browserul îl descoperă. Ghidul web.dev pentru optimizarea LCP reduce investigația la patru obiective: resursa începe devreme, elementul poate fi randat imediat ce resursa ajunge, transferul este scurt, iar documentul inițial vine repede.

Dacă imaginea hero este în HTML ca <img src> ori srcset, browserul o poate descoperi la parsarea documentului. Dacă URL-ul apare numai după execuția unui bundle ori într-un background CSS descoperit târziu, downloadul pornește mai târziu. Un preload poate ajuta o resursă critică greu de descoperit, dar nu pune preload pe orice. Când toate sunt prioritare, resursele concurează pentru aceeași conexiune și scopul se pierde.

Verifică lanțul:

1. requestul documentului și eventualele redirecturi;
2. Time to First Byte și timpul de generare server-side;
3. momentul în care parserul descoperă resursa LCP;
4. prioritatea ei față de CSS, fonturi și alte imagini;
5. mărimea transferată și dimensiunea decodată;
6. timpul dintre finalul downloadului și randare.

Dacă TTFB consumă mare parte din buget, comprimarea imaginii nu rezolvă începutul târziu. Dacă documentul vine repede, dar imaginea este ascunsă în JavaScript, un hosting mai scump nu schimbă ordinea. Dacă downloadul este lung, verifică dimensiunea și varianta livrată. Dacă resursa ajunge și elementul tot nu apare, caută CSS blocant, font, hidratare sau condiții de vizibilitate.

Livrează imaginea potrivită și nu amâna elementul principal

O imagine de 2.000 de pixeli servită într-un card de 400 nu devine eficientă pentru că are extensia WebP. Construiește variante responsive și lasă browserul să aleagă din srcset și sizes. Controlează calitatea vizuală pe ecranele reale ale site-ului; comprimarea agresivă care deteriorează produsul sau portofoliul nu este succes.

Pentru imaginea din primul viewport, evită loading="lazy". Documentația despre lazy loading în browser recomandă încărcarea normală pentru imaginile vizibile inițial, mai ales candidatul LCP, și loading="lazy" pentru imaginile offscreen. Dacă imaginea principală are nevoie de prioritate, fetchpriority="high" poate exprima acest lucru; nu îl copia pe fiecare imagine.

Adaugă width și height cu raportul corect. Browserul poate rezerva spațiul înainte să sosească fișierul, reducând deplasarea de layout. Pentru <picture>, verifică dacă sursele păstrează raportul așteptat. Pentru imagini încărcate de CMS, controlează markupul final, nu doar setarea din biblioteca media.

MDN descrie lazy loading ca încărcare amânată a resurselor necritice. Aplică principiul și iframeurilor/video de sub fold, dar păstrează poster, dimensiuni și fallback. După schimbare, verifică vizual pagina, navigarea cu tastatura, zoomul și conexiunile lente. O economie de bytes nu justifică o zonă goală sau un control inutilizabil.

Redu JavaScriptul care blochează răspunsul, nu doar fișierul comprimat

Minificarea micșorează transferul, dar nu elimină neapărat parsarea, compilarea și execuția. Pentru INP contează ce ocupă main thread înainte ca browserul să picteze răspunsul. Înregistrează interacțiunea lentă în DevTools și urmărește exact event handlerul, taskurile anterioare, stilul, layoutul și paintul.

Un task lung este o pistă, nu diagnosticul complet. Specificația Long Tasks API descrie raportarea taskurilor care blochează main thread suficient de mult pentru a afecta răspunsul. Într-o implementare reală, întreabă despre fiecare bucată de lucru:

• este necesară pentru următorul cadru vizual?
• poate fi eliminată fiindcă funcția nu mai este folosită?
• poate fi încărcată doar pe paginile care au nevoie de ea?
• poate fi împărțită, întreruptă ori mutată după paint?
• poate rula într-un worker fără acces direct la DOM?
• citește și scrie layoutul repetat într-o buclă?

Debounce poate reduce frecvența unei căutări, dar munca tot va rula. defer poate scoate un script din calea parserului, dar scriptul poate bloca ulterior o interacțiune. Code splitting poate micșora pornirea, dar un chunk descărcat exact la click poate întârzia răspunsul. Măsoară efectul asupra funcției reale și folosește cea mai simplă schimbare care eliberează main thread.

Tag managerul merită propriul inventar. Un tag care ascultă fiecare apăsare, rulează personalizare sau injectează mai multe biblioteci poate concura cu interacțiunea. Nu îl elimina fără proprietar și impact măsurat; stabilește ce date sunt necesare, când pot fi trimise și ce se întâmplă când consimțământul diferă.

CSS-ul, fonturile și componentele dinamice trebuie să poată ocupa loc fără surprize

CSS critic nu înseamnă „pune tot stylesheetul în <head>”. Înseamnă livrează stilurile necesare primului viewport fără să trimiți inutil întreaga aplicație ca blocaj. Identifică stilurile care întârzie randarea, elimină regulile nefolosite cu grijă și testează toate stările componentei. Un instrument de coverage poate rata clase adăugate după interacțiune, eroare, autentificare ori breakpoint.

Fonturile pot întârzia textul LCP sau pot schimba geometria când se aplică. Alege familiile și greutățile folosite, servește formate potrivite și stabilește o strategie font-display care păstrează lizibilitatea. Preload numai pentru fontul necesar imediat și verifică crossorigin; un preload configurat greșit poate produce al doilea request. Compară fallbackul cu fontul final pentru a limita schimbarea liniilor și butoanelor.

Pentru bannere, cookie UI, reclame, review widgets, chat și embeduri, rezervă dimensiunea realistă înainte să vină conținutul. Nu injecta un promo deasupra titlului după ce omul a început să citească. Dacă dimensiunea diferă pe breakpointuri, măsoară fiecare stare. Dacă un banner poate lipsi, containerul nu trebuie să lase permanent un gol nejustificat; proiectează starea absentă explicit.

Testează și după încărcare. Lighthouse poate surprinde deplasările din fereastra lui, dar un popup întârziat, o recomandare personalizată sau un carusel pot produce CLS mai târziu. Datele de teren și o sesiune reală lungă completează testul inițial.

Cache-ul este o politică de prospețime, nu o bifă într-un plugin

Cache-ul bun evită să transfere sau să genereze din nou același răspuns când reutilizarea este sigură. Ghidul MDN despre HTTP caching separă prospețimea, validarea și caracterul public ori privat al răspunsului. De aceea „activează cache” este incomplet: trebuie să spui ce resursă, pentru cine, cât timp și cum se invalidează.

Pentru active cu nume versionat — de exemplu app.abc123.js — poți folosi o durată lungă și schimba URL-ul când conținutul se schimbă. Pentru HTML, preț, stoc, coș, cont sau conținut personalizat, politica trebuie să respecte prospețimea și identitatea. no-cache nu înseamnă neapărat „nu stoca”; poate cere revalidare. no-store are altă intenție. Verifică headerul efectiv în response, nu doar interfața pluginului.

Cache-ul de pagină poate reduce generarea pe origin. NGINX documentează mecanica proxy_cache, dar regula concretă trebuie să excludă stările care nu pot fi partajate. Testează utilizator anonim, autentificat, monedă, limbă, query-uri și cookie-uri. O pagină rapidă care arată coșul altui utilizator este un incident, nu o optimizare.

Un CDN aduce răspunsul mai aproape și poate proteja originul, dar nu cache-uiește automat orice. Documentația Cloudflare despre comportamentul implicit arată că extensia, metoda, statusul și header-ele influențează eligibilitatea. Citește Age, Cache-Control, Vary și headerul furnizorului; compară HIT, MISS și BYPASS. Nu declara CDN-ul rezolvat doar fiindcă DNS-ul trece prin el.

Hostingul ajută când întârzierea este pe server; nu repară main threadul

Într-un waterfall lent, separă timpul până la primul byte de download și de randare. Dacă documentul HTML pornește târziu, investighează aplicația, baza de date, cache miss, API-uri, CPU, memorie, procese concurente și distanța față de utilizator. Cere loguri și percentila răspunsurilor, nu numai o captură dintr-un test bun.

Schimbarea hostingului este justificată când poți arăta o limită: CPU throttling, I/O, procese epuizate, baze de date lente, latență geografică, lipsă de cache ori instabilitate. Este insuficientă când problema este o imagine prea mare, un bundle care rulează în browser sau un widget terț. Acestea ajung la utilizator și pe un server mai puternic.

Compară înainte și după pe aceeași aplicație, aceeași stare de cache și locație. Fă load test numai cu autorizare și cu praguri care nu afectează producția. Monitorizează erori și latență în timpul schimbării. Un mediu nou poate răspunde repede în gol și se poate degrada la trafic, cron jobs, importuri sau cache invalidation.

Documentația PageSpeed Insights explică faptul că raportul combină date de laborator Lighthouse cu date reale din Chrome UX Report, atunci când acestea sunt disponibile. Instrumentul identifică diagnostice și oportunități tehnice; nu estimează singur orele, bugetul sau pachetul comercial necesar site-ului tău.

Scripturile terțe trebuie bugetate după funcție și cost

Chat, analytics, advertising, heatmaps, A/B testing, recenzii, video și antifraudă pot fi necesare. Problema apare când nimeni nu deține inventarul și fiecare furnizor mai injectează alte requesturi. Pentru fiecare terț notează proprietarul, scopul, paginile, momentul încărcării, datele trimise și comportamentul când este blocat.

Testează pagina cu și fără terț într-un mediu controlat. Urmărește bytes, conexiuni, taskuri, layout și interacțiunea afectată. Dacă scriptul nu este necesar înainte de consimțământ sau înainte de primul paint, încarcă-l la momentul justificat. Dacă este necesar pentru măsurarea conversiei, verifică faptul că amânarea nu pierde evenimentul și că implementarea respectă politica de consimțământ.

Nu muta automat orice într-un worker. Unele biblioteci se bazează pe DOM, ordine de evenimente și API-uri care nu sunt disponibile acolo. Nu bloca un tag esențial numai pentru a îmbunătăți o rulare Lighthouse. Soluția este un buget decis de business și o integrare testată: ce păstrăm, ce eliminăm, ce încărcăm condiționat și ce măsurăm după schimbare.

Leagă această muncă de optimizarea traseului spre conversie. Dacă scoți un widget care nu aduce leaduri și eliberezi interacțiunea, ai un câștig coerent. Dacă scoți dovada socială folosită în decizie fără să măsori, ai schimbat oferta, nu doar performanța.

Checklist tehnic: zece verificări pass/fail

Checklistul de mai jos se completează pe o cohortă de pagini, nu pe „site” ca total abstract. La fiecare rând atașează captura, trace-ul, response headers ori logul care permit altcuiva să repete controlul.

„PASS” nu înseamnă aceeași valoare pe orice site. Numai LCP, INP și CLS au aici pragurile oficiale citate. Pentru server, bytes, număr de requesturi și JavaScript, stabilești bugetul din baseline, public, funcție și risc. Un catalog cu imagini are alt profil decât o pagină de contact; o aplicație are alte interacțiuni decât un articol.

Repară în ordinea blocajului și păstrează controlul regresiilor

Prioritizează după impact, încredere și efort, dar păstrează dependențele tehnice. O ordine practică este:

1. repară erorile funcționale, 5xx și resursele lipsă;
2. identifică template-ul și elementul/interacțiunea dominantă;
3. elimină requesturile și codul care nu au scop;
4. rezolvă descoperirea și prioritatea resursei critice;
5. optimizează transferul și cache-ul;
6. reduce munca main thread și instabilitatea;
7. investighează backendul și hostingul dacă TTFB rămâne problema;
8. publică gradual și urmărește datele reale.

După fiecare schimbare, rulează testul funcțional înainte de a compara performanța. Verifică formulare, checkout, autentificare, căutare, navigare, consimțământ, analytics și CRM. Folosește un rollout limitat când riscul o cere. Notează versiunea și momentul, altfel nu poți lega schimbarea de datele ulterioare.

Adaugă bugete de performanță în procesul de livrare: mărimea resursei LCP, JavaScript pe template, taskuri observate, layout shifts și teste Lighthouse consistente. CI-ul poate opri regresii evidente, dar nu înlocuiește RUM. Datele reale pot arăta dispozitive, interacțiuni sau stări pe care laboratorul nu le-a reprodus.

Nu aștepta 28 de zile ca să observi un formular rupt. După deploy verifici imediat funcția, erorile și laboratorul; apoi RUM-ul pe măsură ce sosesc vizite; apoi distribuția CrUX când fereastra se actualizează. Fiecare strat răspunde la altă întrebare.

Întrebări frecvente despre viteza site-ului

Cum cresc viteza site-ului?

Măsoară întâi o pagină și un traseu real, separă datele de teren de laborator și identifică elementul LCP, interacțiunea lentă sau layout shiftul. Repară cauza observată — resursă descoperită târziu, imagine nepotrivită, JavaScript blocant, cache, server sau terț — apoi retestează performanța și funcția.

Cum verific implementarea înainte să folosesc datele sau rezultatele?

Păstrează un baseline reproductibil, testează schimbarea într-un mediu comparabil, verifică header-ele și trace-urile și execută traseele funcționale. După deploy confirmă analytics, formularul sau checkoutul și monitorizează metricile pe aceeași cohortă și versiune.

Ce scor PageSpeed trebuie să am?

Nu există un scor universal care garantează leaduri, vânzări ori poziții. Folosește scorul Lighthouse pentru diagnostic de laborator și urmărește separat LCP, INP și CLS în datele de teren. Obiectivul este ca experiența critică să fie rapidă și stabilă pentru utilizatorii reali.

Un plugin de cache rezolvă un site lent?

Poate reduce generarea și transferul pentru răspunsurile eligibile, dar nu repară automat imagini supradimensionate, JavaScript care blochează main threadul, layout shifts sau un API lent. Verifică ce răspunsuri sunt cache-uite, pentru cine, cât timp și cum sunt invalidate.

Trebuie să schimb hostingul?

Numai dacă măsurarea arată că întârzierea ori instabilitatea vine din server și resursele planului actual. Dacă problema este în browser, schimbarea hostului nu elimină bundleul, widgetul sau imaginea grea. Compară aceeași aplicație în condiții controlate înainte să muți infrastructura.

În cât timp se vede rezultatul?

În laborator și în testele funcționale vezi efectul imediat după deploy. În RUM ai nevoie de suficiente vizite pe noua versiune, iar datele CrUX folosesc o fereastră agregată și se schimbă mai lent. Notează data lansării și nu amesteca observațiile dinainte și după schimbare.

Viteza sustenabilă nu vine dintr-o curățenie făcută o dată. Vine dintr-un proces: măsori experiența reală, reproduci cauza, schimbi o piesă, verifici funcția și previi regresia. Dacă nu știi dacă blocajul este trafic, site sau măsurare, pornește din diagnostic; dacă traseul este corect dar oamenii tot nu finalizează, extinde analiza în CRO. Un scor este o observație. O pagină rapidă și funcțională este un rezultat construit.