Viteza nu este un scor. Este un lanț de evenimente, fiecare cu durata lui, fiecare cu o cauză. Descompunem lanțul întreg, găsim unde se pierde timpul și îl recuperăm acolo unde chiar contează.
Un test de laborator rulează o pagină într-un mediu controlat: un dispozitiv simulat, o rețea simulată, o singură încărcare. Este reproductibil, deci este util ca să compari înainte și după o modificare. Nu îți spune însă ce trăiesc oamenii tăi.
Datele de teren vin din browserele vizitatorilor reali, pe telefoanele lor, pe conexiunile lor, cu extensiile lor instalate. Acestea sunt datele pe care Google le folosește la clasare. Un site poate arăta impecabil în laborator și prost în teren, de obicei din trei motive: majoritatea traficului vine de pe mobil, o parte semnificativă din vizitatori sunt la prima vizită și nu au nimic în cache, iar un script terț se comportă diferit sub sarcină reală.
Lucrăm cu ambele. Terenul stabilește prioritatea, pentru că spune ce doare cu adevărat. Laboratorul stabilește cauza, pentru că se poate reproduce și izola.
Fiecare etapă dintre apăsarea unui link și pagina utilizabilă are un cost. Le măsurăm separat, pentru că optimizarea etapei greșite nu produce nimic.
| Etapă | Ce măsurăm | Ce corectăm |
|---|---|---|
| Rezolvare DNS | Timpul până la primul răspuns, numărul de furnizori DNS interogați | Furnizor DNS rapid, reducerea domeniilor distincte, preconectare acolo unde este justificat |
| Conexiune și TLS | Durata negocierii, versiunea de protocol, reutilizarea sesiunii | HTTP/2 sau HTTP/3, reluarea sesiunii TLS, eliminarea redirectărilor care forțează reconectare |
| Timp până la primul octet | Separat pentru pagină cache-uită și necache-uită | Cache de pagină, cache de obiecte, interogări lente, versiune de PHP, distanța până la utilizator |
| Blocarea randării | Ce fișiere CSS și JS opresc afișarea și pentru cât timp | CSS critic livrat inline, restul amânat, scripturi neesențiale scoase din calea critică |
| Cea mai mare afișare de conținut | Care element este, în cât timp apare, ce anume îl întârzie | Preîncărcarea resursei corecte, dimensionarea imaginii, eliminarea lanțurilor de cereri înlănțuite |
| Întârzierea la interacțiune | Cât durează până pagina răspunde la prima atingere sau apăsare | Reducerea muncii pe firul principal, spargerea sarcinilor lungi, întârzierea scripturilor terțe până la interacțiune |
| Stabilitatea layoutului | Cât sare conținutul în timpul încărcării și din cauza cui | Dimensiuni explicite pe imagini și iframe-uri, spațiu rezervat pentru reclame și bannere, fonturi încărcate fără salt |
| Fonturi | Număr de familii, greutăți, formate, comportamentul la afișare | Doar greutățile chiar folosite, format modern, subset de caractere, afișare fără text invizibil |
| Imagini | Mărime transferată față de mărime afișată, format, moment de încărcare | Format modern, dimensiuni multiple pentru fiecare ecran, încărcare amânată sub linia de plutire, dar niciodată pentru imaginea principală |
| Scripturi terțe | Fiecare domeniu extern, ce aduce, cât cântărește, cât ocupă firul principal | Eliminarea celor nefolosite, întârzierea celor neesențiale, mutarea urmăririi acolo unde nu blochează |
| Baza de date | Interogări lente, tabele umflate, autoload excesiv, sarcini programate | Indexare, curățare, mutarea sarcinilor grele în afara cererii vizitatorului |
Când cineva spune „am pus cache”, de obicei se referă la unul singur din straturile de mai jos. Ele nu se substituie unul altuia.
Salvează HTML-ul deja generat, deci PHP nu mai rulează la fiecare vizită. Cel mai mare câștig unic pentru un site cu conținut preponderent static. Partea delicată este invalidarea: ce se golește când publici, când se schimbă un preț, când un utilizator este autentificat.
Ține în memorie rezultatele interogărilor de bază de date. Contează enorm pentru zonele pe care cache-ul de pagină nu le poate acoperi: coșuri, conturi, filtre, tot ce este personalizat pe utilizator. Redis, configurat corect și monitorizat, nu doar activat.
La nivel de PHP, evită recompilarea acelorași fișiere la fiecare cerere. Adesea lăsat pe valorile implicite, care sunt prea mici pentru un WordPress cu multe plugin-uri. Îl dimensionăm după ce măsurăm câtă memorie chiar se cere.
Copii ale conținutului în centre de date apropiate de vizitator. Cu Cloudflare inclus în abonament, configurăm ce se cache-uiește la margine, cât timp, ce se ocolește și cum se golește la publicare. Diferența pentru un vizitator aflat departe de serverul tău este de sute de milisecunde.
Fișierele deja descărcate nu se mai cer la a doua vizită. Depinde în întregime de anteturi corecte și de nume de fișiere versionate. Făcut prost, ori nu se folosește deloc, ori servește vizitatorilor o versiune veche zile întregi după ce ai publicat o modificare.
Rezultate scumpe salvate temporar de WordPress și de plugin-uri: cursuri valutare, feeduri, răspunsuri de la API-uri externe. Când expiră prost, un vizitator nefericit plătește așteptarea unui apel extern. Le identificăm și le mutăm în fundal.
Nu activăm toate opțiunile dintr-un plugin de cache ca să iasă un scor mai mare. Combinarea agresivă a fișierelor, eliminarea automată a stilurilor nefolosite și amânarea totală a JavaScript pot arăta excelent într-un test și pot strica formularul de comandă pe un anumit browser. Fiecare opțiune se activează separat, se testează pe fluxurile reale ale site-ului, apoi rămâne.
Fiecare pagină din administrare, pe mobil și pe desktop, în laborator și în teren. Rezultatele se salvează, deci există un punct de referință real, nu o amintire.
O modificare care taie 40 de milisecunde nu merită riscul dacă alta taie 900. Ordinea se stabilește după cifre, nu după cât de ușor este de bifat.
O modificare pe rând, ca efectul să fie atribuibil. Fluxurile critice se verifică manual: formulare, coș, autentificare, căutare.
Aceleași pagini, aceleași condiții. Dacă diferența nu se confirmă în producție, modificarea se retrage.
Performanța se degradează singură: o imagine urcată nedimensionată, un plugin nou, un script de urmărire adăugat de cineva din marketing. Măsurarea continuă prinde asta în zile, nu în luni.
Ce s-a schimbat, cât a câștigat, ce rămâne de făcut și de ce. Fără capturi de ecran cu cadrane verzi și fără concluzii pe care nu le poți verifica singur.
Nu neapărat. Scorul acela vine dintr-un test de laborator, pe un singur dispozitiv simulat, pe o singură pagină, la un singur moment. Google folosește pentru clasare datele de teren, adică ce experimentează utilizatorii tăi reali, pe telefoanele lor, pe conexiunile lor. Am văzut site-uri cu 100 în laborator și date de teren proaste, și invers.
Rezolvă un strat, cel al generării paginii, și îl configurăm cu atenție. Nu atinge însă mărimea imaginilor, blocarea la randare, comportamentul fonturilor, scripturile terțe, stabilitatea layoutului sau întârzierea la interacțiune. Cache-ul face pagina să ajungă repede. Nu o face rapidă după ce ajunge.
Modificările tehnice se văd imediat în laborator. Datele de teren pe care le folosește Google se calculează pe o fereastră glisantă de 28 de zile, deci raportarea oficială se stabilizează după aproximativ o lună. Vizitatorii tăi simt diferența din prima zi.
Fiecare modificare se face întâi pe mediul de test, cu o măsurătoare înainte și una după. Dacă un rezultat nu justifică riscul, nu îl păstrăm. Toate modificările sunt versionate, deci revenirea este imediată.
Până la un punct. Dacă serverul răspunde în 1,2 secunde la o pagină deja cache-uită, niciun front-end nu poate compensa. Măsurăm și îți spunem cu cifre exact cât din problemă este găzduirea și cât se poate câștiga fără să o schimbi.
Trimite-ne adresa site-ului. Îl măsurăm și îți arătăm concret ce îl încetinește, cu cifre pe care le poți verifica singur.