Site-ul tău WordPress se încarcă în 4 secunde. De ce și ce poți face

Patru secunde până la afișarea conținutului principal e un interval pe care îl întâlnim des pe site-uri de firmă construite pe WordPress. Nu e o catastrofă și nu e nici acceptabil: pragul recomandat pentru Largest Contentful Paint, în documentația Google despre Core Web Vitals, e 2,5 secunde pe mobil. Peste el, o parte din vizitatori pleacă înainte să vadă ceva.

Vestea bună e că, în majoritatea cazurilor, cauza nu e o singură problemă gravă, ci cinci–șase lucruri mici care se adună. Vestea proastă e că se repară în ordinea corectă, nu în ordinea în care sunt cel mai ușor de reparat.

Măsoară înainte să repari

Primul lucru care trebuie spus: „site-ul merge greu“ nu e o măsurătoare. Înainte de orice intervenție, ai nevoie de trei date.

O măsurătoare de laborator, cu PageSpeed Insights sau Lighthouse, pe profil mobil, cu throttling activ. Îți dă o listă de probleme reproductibile.

Date de teren, dacă site-ul are trafic suficient — raportul Chrome UX din PageSpeed Insights arată ce experimentează utilizatorii reali, pe conexiunile și dispozitivele lor, nu pe ale tale.

Timpul până la primul byte (TTFB), măsurat separat. E singura cifră care îți spune dacă problema e în server sau în browser. Dacă TTFB e mare, optimizarea imaginilor nu te ajută cu nimic.

Fără cele trei, orice intervenție e ghicit. Cu ele, ordinea de atac devine evidentă.

Cauza 1: serverul răspunde greu

Dacă primul byte vine după mai mult de o secundă, restul discuției e secundar. WordPress construiește fiecare pagină la fiecare vizită: pornește PHP, interoghează baza de date, execută tema și toate pluginurile active, apoi trimite HTML-ul. Pe găzduire partajată ieftină, pasul ăsta poate dura singur cât ar trebui să dureze toată încărcarea.

Ce contează aici, în ordinea impactului: existența unui cache de pagină (astfel încât HTML-ul să nu fie regenerat pentru fiecare vizitator), versiunea de PHP (versiunile vechi sunt sensibil mai lente și, mai important, nu mai primesc patch-uri de securitate), și numărul de interogări pe care le face pagina. Un plugin prost scris poate genera sute de interogări pe o singură pagină; se vede imediat cu Query Monitor.

Cache-ul de pagină e, aproape întotdeauna, intervenția cu cel mai bun raport efort/rezultat pe un site care nu are unul. Nu rezolvă cauza — codul rămâne la fel de lent — dar îl execută mult mai rar.

Cauza 2: prea multe pluginuri, sau cele greșite

Numărul de pluginuri nu e în sine problema. Un plugin care adaugă un câmp în admin nu costă nimic la afișare. Problema e categoria de pluginuri care încarcă CSS și JavaScript pe fiecare pagină, indiferent dacă sunt folosite acolo.

Cazul clasic: un plugin de slider-e care își încarcă biblioteca pe toate paginile, inclusiv pe cele care nu au niciun slider. Sau un plugin de formulare care încarcă tot stack-ul lui pe homepage, deși formularul e doar pe pagina de contact. Fiecare adaugă cereri de rețea și kilobytes de JavaScript pe care browserul trebuie să-i descarce, parseze și execute înainte să afișeze ceva.

Verificarea e simplă: deschide panoul Network din DevTools, sortează după dimensiune și uită-te ce se încarcă pe homepage. Dacă nu poți explica ce face un fișier acolo, probabil nu are ce căuta.

Cauza 3: page builder-ul

Un site construit cu un page builder vizual produce, de regulă, mult mai mult HTML decât ar avea nevoie: straturi de div-uri imbricate, stiluri inline generate pentru fiecare element, un fișier CSS global care conține reguli pentru toate componentele bibliotecii, nu doar pentru cele folosite.

E un compromis conștient: câștigi control fără cod, plătești în greutatea paginii. Pe un site mic compromisul e acceptabil. Pe un site cu pagini complexe, page builder-ul devine componenta dominantă din bugetul de performanță și nu ai cum să-l optimizezi decât parțial, fiindcă nu tu scrii markup-ul.

Dacă măsurătorile arată că majoritatea CSS-ului și JavaScript-ului nefolosit vine din builder, ai ajuns la limita a ce se poate regla fără o schimbare structurală.

Cauza 4: imaginile

Cea mai frecventă cauză și cea mai ușor de reparat. Trei probleme distincte, care apar de obicei împreună:

• Dimensiuni greșite. O imagine de 3000 de pixeli lățime afișată într-un spațiu de 600 de pixeli. Browserul descarcă tot, apoi micșorează.
• Format vechi. JPEG și PNG în loc de WebP sau AVIF. Diferența de greutate la calitate vizuală comparabilă e substanțială, iar suportul în browsere e general de ani buni.
• Fără width și height. Lipsa lor produce salturi de layout în timpul încărcării — exact ce măsoară Cumulative Layout Shift. Nu încetinește pagina, dar o face să pară stricată.

Adaugă la asta încărcarea leneșă (loading="lazy") pentru tot ce e sub prima vizualizare și, la fel de important, absența ei pentru imaginea principală din hero. O imagine LCP marcată lazy e un autogol clasic.

Cauza 5: fonturi și scripturi externe

Fiecare font încărcat de pe un domeniu extern înseamnă o conexiune nouă: DNS, TLS, cerere. Fonturile găzduite local, preîncărcate și cu font-display: swap elimină o parte din costul ăsta și, în plus, scot o dependență externă din calea critică.

Scripturile de la terți — analytics, chat, hărți, pixeli de publicitate — sunt de multe ori contribuția cea mai mare la timpul până când pagina devine utilizabilă. Nu poți optimiza cod care nu-ți aparține, dar poți controla dacă și când se încarcă: după consimțământ, amânat, sau deloc. Un widget de chat pe care îl folosesc trei vizitatori pe lună nu justifică sute de kilobytes pe fiecare pagină.

Cauza 6: baza de date umflată

E cauza pe care nu o vezi în Lighthouse, fiindcă se manifestă doar ca TTFB mare. Un site vechi de câțiva ani acumulează revizii ale fiecărei pagini, opțiuni tranzitorii expirate care nu au fost niciodată curățate, tabele rămase de la pluginuri dezinstalate și, pe site-urile cu formulare, tot istoricul de trimiteri stocat local.

Nimic din toate astea nu e periculos în sine, dar tabelul de opțiuni e citit la fiecare cerere. Când crește de la câteva sute de rânduri la câteva zeci de mii, se simte. Curățarea e o operațiune de rutină — cu backup înainte, obligatoriu — și în unele cazuri e singura schimbare care mută TTFB-ul vizibil, fără să atingi nimic din front-end.

Merită verificat și dacă tabelele au indecșii pe care îi presupun interogările pluginurilor. Un plugin care filtrează după un câmp meta pe un site cu multe intrări poate fi singurul motiv pentru care o pagină de listare durează secunde întregi.

Ordinea în care merită să lucrezi

1. Măsoară și separă TTFB de restul.
2. Dacă TTFB e mare: cache de pagină, versiune de PHP actuală, apoi găzduire.
3. Curăță imaginile — dimensiuni, format, atribute, lazy loading.
4. Elimină scripturile externe care nu-și merită costul.
5. Dezactivează pluginurile nefolosite și verifică ce încarcă cele rămase.
6. Măsoară din nou, cu aceeași metodă. Fără pasul ăsta nu știi ce a ajutat.

Primele cinci puncte pot aduce o îmbunătățire semnificativă pe un site care nu a fost niciodată optimizat. Cât de mare, depinde de la ce pornești — de aceea pasul 1 și pasul 6 folosesc aceeași unealtă și același profil.

Când optimizarea nu mai are ce să dea

Există un plafon. Dacă ai făcut tot ce e mai sus și ești în continuare peste 2,5 secunde pe mobil, cauza e arhitecturală: o platformă care generează fiecare pagină la cerere are un cost de bază pe care nu-l poți elimina, doar ascunde sub cache.

Pentru un site de prezentare — pagini care se schimbă de câteva ori pe an — alternativa e să generezi HTML-ul o singură dată, la publicare, și să-l servești din CDN. Asta facem cu site-urile construite pe Astro, și am detaliat criteriile de decizie în Astro vs WordPress.

Dacă însă WordPress e alegerea corectă pentru tine — magazin, blog cu redactori, integrări specifice — atunci optimizarea și mentenanța fac parte din costul de funcționare. Partea asta o tratăm prin WPFitness. Iar dacă urmează să construiești un site nou pe WordPress, deciziile care îl fac rapid din start, înainte să ai ce repara, sunt aici.

Vrei o evaluare pe site-ul tău, cu măsurători și cu lista problemelor în ordinea impactului? Scrie-ne — îți răspundem în maxim 8 ore lucrătoare.