Ce îi face serverul tău scorului PageSpeed.

Cele mai multe sfaturi despre performanță se opresc la browser: comprimă imaginile, amână JavaScriptul, taie CSS-ul nefolosit. Sfaturile sunt corecte și au un plafon, pentru că fiecare dintre aceste optimizări începe să lucreze abia după ce serverul a răspuns. Dacă primul octet ajunge târziu, ajunge prost comprimat sau vine dintr-un proces care dormea, nicio optimizare de front-end nu recuperează timpul pierdut. Asta am descoperit când am încetat să mai reglăm paginile și am început să măsurăm mașina de sub ele — pe propriile noastre trei domenii de producție, nu pe un mediu de test.

Checklist de server: ce verifici și cum arată un rezultat bun

Parcurge-le în această ordine. Primele patru decid dacă se poate măsura serios orice optimizare de pagină; restul decid dacă rezultatul ajunge la vizitatori reali și la roboți.

Aceiași octeți, în trei feluri

Conținut identic la nivel de octet, verificat cu SHA-256, același server, aceeași cerere. Măsurat pe propriul nostru hosting, în august 2026.

Serverul nu are un audit al lui

PageSpeed Insights nu are un scor „hostingul tău este lent”. Nu există o categorie pentru el și niciun număr care să îl izoleze. Serverul apare indirect, în metrici care par probleme de front-end: timpul până la primul octet hrănește First Contentful Paint, care la rândul lui condiționează Largest Contentful Paint, iar Lighthouse îl numește — ca Reduce initial server response time — abia când este deja suficient de rău încât să sară în ochi.

Google consideră bun un TTFB de 0,8 secunde sau mai puțin și slab orice trece de 1,8 secunde, măsurat din momentul în care începe navigarea până când sosește primul octet. Fereastra aceea include redirecturile, DNS-ul, stabilirea conexiunii și negocierea TLS, nu doar timpul în care gândește aplicația ta — așa că un lanț de redirecturi și un handshake lent ți se pun în cârcă exact ca un cod lent.

De asta se sare peste stratul de server. Nu depune niciodată o plângere în nume propriu. Doar plafonează discret ce poate obține orice altă optimizare.

Compresia: am măsurat „brotli”-ul platformei noastre și a pierdut în fața propriului gzip

Compresia este setarea de server cu cel mai mare efect și, în același timp, cea despre care se presupune cel mai des că este deja rezolvată. La noi era activată. Antetul răspunsului o confirma. Totul părea corect.

Apoi am comparat numărul de octeți pe conținut identic, iar brotli-ul platformei producea fișiere mai mari decât propriul ei gzip — 75.377 de octeți față de 54.284 pentru același HTML al paginii principale, așa cum arată tabelul de compresie de mai sus. Cauza era o implementare în flux, cu o fereastră de compresie foarte mică, care nu vedea niciodată destul din document ca să găsească repetițiile pentru care merită folosit brotli. Față de un brotli configurat corect, trimitea de 2,7 ori mai mulți octeți.

Un antet care spune că ceva este pornit nu este o dovadă că acel ceva funcționează. Testul este să ceri același URL de trei ori — o dată acceptând brotli, o dată gzip, o dată nimic — și să compari singur numărul de octeți. Dacă „brotli” nu este clar cel mai mic dintre cele trei, nu își face treaba, indiferent ce scrie în antet.

Repararea acelei singure setări este ce a dus toate cele trei domenii ale noastre la un scor mobil de 99 spre 100 și nu a cerut nicio modificare într-o pagină.

Încetineala care nu apare deloc într-un scor

Iată defectul care ne-a convins că stratul acesta merită un articol al lui. Același URL, la aceeași dimensiune în octeți, era servit în 20-60 de milisecunde aproape întotdeauna — și, ocazional, în 700-2000 de milisecunde. Rulezi PageSpeed Insights și, de regulă, îl prinzi pe cel rapid. Îl rulezi din nou și s-ar putea să îl prinzi pe cel lent, iar diferența să o pui pe seama instrumentului.

Nu era variație. Procesul aplicației era omorât și repornit la fiecare zece minute de un script de întreținere, iar primul vizitator de după fiecare repornire plătea o pornire completă la rece. În cel mai rău moment, 11,7% dintre cereri nimereau într-o pornire la rece de 1,1-2,0 secunde; după reparație au scăzut la 1,6%, iar durata de viață a unui proces a urcat de la zece minute la peste trei ore și jumătate.

Nicio modificare de front-end nu rezolvă asta și nicio rulare singulară de PageSpeed nu o scoate la iveală. Este o problemă de distribuție, iar un scor este o singură probă. Singurul mod de a o vedea este să ceri același URL de câteva sute de ori, să înregistrezi fiecare timp de răspuns și să te uiți la cele mai lente câteva procente, nu la medie. Dacă p95 este de zece ori mediana pe o pagină servită identic de fiecare dată, problema este sub aplicație, nu în ea.

Pe hosting partajat, împarți mai mult decât spațiul pe disc

Planurile partajate și cele administrate de intrare limitează numărul de procese pe care le poate rula un cont, iar limita este de obicei pe cont, nu pe site. Am atins-o: fiecare deploy lăsa în urmă un proces vechi al aplicației, fiecare ținea memorie și un loc de proces la nesfârșit, iar acestea se adunau până când contul ajungea aproape de plafon. Site-uri pe care nu le atinsese nimeni de săptămâni deveneau mai lente din cauza unor deployuri pe alt domeniu.

De aici decurg două lucruri. Citește limitele de procese și de memorie ale unui plan înainte să îi citești prețul, pentru că ele decid dacă site-ul se degradează din propria lui întreținere. Și tratează o încetinire apărută „din senin” ca pe o întrebare despre ce altceva mai locuiește pe cont, nu doar despre ce s-a schimbat în cod.

Stratul din fața serverului poate bloca Google de tot

Un CDN sau un firewall de aplicație stă în fața aplicației și răspunde unor cereri fără să o consulte vreodată. Exact ăsta este rostul lui și, tot acolo, o singură listă derulantă face pagube reale.

Pe una dintre proprietățile noastre, un nivel de securitate CDN setat pe „mediu” a început să răspundă la sitemap cu 403 și cu o pagină de verificare a browserului. Un browser trecea verificarea fără ca vizitatorul să observe ceva. Googlebot nu rulează o provocare JavaScript ca să ia un sitemap, așa că Search Console a raportat pur și simplu că nu poate prelua fișierul, cu zero pagini descoperite — și nimic din codul site-ului nu era greșit.

Nimic din toate astea nu apare în PageSpeed Insights, pentru că PageSpeed cere o pagină și primește o pagină. Apare în Search Console, după săptămâni, ca problemă de indexare. Verificarea care merită făcută este să ceri robots.txt și sitemap.xml cu un user agent de crawler și să confirmi că amândouă răspund cu 200 și cu tipul de conținut corect.

Anteturile de cache sunt o decizie de server, nu de framework

Frameworkul tău poate propune un comportament de cache; serverul web, CDN-ul și panoul de hosting îl pot suprascrie fiecare. Am văzut o politică de la nivelul aplicației înlocuită în întregime de o regulă de mai sus din stivă, fără ca aplicația să afle. RFC 9111 definește ce înseamnă directivele, dar nu și cine are ultimul cuvânt în stiva ta — asta ține de configurația ta, iar singurul mod de a o ști este să citești anteturile răspunsului la margine, nu codul care a intenționat să le pună.

Regula pe care o folosim este simplă: pentru orice pretinde că este pus în cache, cere-l de două ori și compară. Dacă al doilea răspuns nu arată un cache hit și o vechime, nu este în cache, oricât ar scrie în fișierul de configurare.

Și nu doar PageSpeed

Tratarea scorului ca scop este exact ce face munca de server să pară opțională, pentru că o pagină bine construită poate avea un scor mare pe un server prost configurat, de cele mai multe ori. Costurile aterizează în altă parte.

Roboții absorb o parte disproporționată din răspunsurile lente, pentru că cer continuu, nu în rafalele scurte pe care le generează un om — așa că un defect care lovește o cerere din nouă este unul pe care Google îl întâlnește constant, pe mii de URL-uri. Economia din compresie se încasează la fiecare cerere, de la fiecare vizitator și fiecare robot, nu o singură dată la build. Iar pagina care apare ocazional în două secunde este cea care decide dacă cineva mai așteaptă, lucru pe care nicio mediană dintr-un raport nu ți-l va arăta vreodată.

Scorul este un indicator util și o țintă proastă. Ce cumperi de fapt cu o configurare bună de server este cea mai rea experiență de pe site-ul tău, nu cea obișnuită.

Cum abordăm asta în practică

Când preluăm lucrări de hosting și deployment, trecerea prin server vine înaintea oricărei munci la pagini, pentru că munca la pagini se măsoară față de ce face serverul, iar măsurătoarea nu valorează nimic cât timp serverul se mișcă sub ea. Checklistul din capul articolului este chiar ordinea pe care o urmăm și este ordonat intenționat: primele patru puncte decid dacă se poate avea încredere în ce măsori după, iar restul decid dacă rezultatul ajunge efectiv la vizitatori și la roboți.

Nimic din toate astea nu cere acces la aplicație. Fiecare punct se poate verifica din exterior, cu câteva cereri, ceea ce îl face și cel mai rapid mod de a afla dacă un site lent este o problemă de hosting sau una de cod, înainte să se angajeze cineva la o rescriere.

Dacă vrei asta ca lucrare de sine stătătoare, nu ca un angajament pe termen lung, este prima jumătate din Auditul tehnic. Iar dacă stratul de pagină este cel care te ține pe loc, Cum obții un scor PageSpeed de 100 acoperă cealaltă parte a liniei.

Surse

Pragurile și definițiile de mai jos sunt ale Google și ale IETF. Măsurătorile din acest articol sunt ale noastre, făcute pe cele trei domenii de producție în august și septembrie 2026.

• web.dev — Time to First Byte (TTFB) ↗

  Definește metrica și pragurile ei — 0,8 s sau mai puțin este bun, peste 1,8 s este slab — și enumeră ce cuprinde fereastra: redirecturi, pornirea service workerului, DNS, conexiune și negociere TLS, plus cererea propriu-zisă.

• Chrome for Developers — Reduce initial server response time ↗

  Auditul Lighthouse care scoate la suprafață latența serverului și pragul de la care începe să o raporteze.

• Chrome for Developers — Lighthouse performance scoring ↗

  Ponderile metricilor din spatele numărului unic, adică exact ce face ca momentul afișării să conteze mai mult decât lista lungă de audituri pe care PageSpeed o tipărește dedesubt.

• RFC 9111 — HTTP Caching ↗

  Ce înseamnă directivele de cache. Definește semantica, nu și care strat din stiva ta le setează ultimul.

• RFC 7932 — Brotli Compressed Data Format ↗

  Specificația formatului, inclusiv fereastra glisantă a cărei dimensiune decide câtă repetiție poate găsi compresorul — parametrul aflat la rădăcina măsurătorilor din tabelul de mai sus.