Acasă/Blog/Optimizare viteză site WordPress: ghid practic, în ordinea impactului

Optimizare viteză site WordPress: ghid practic, în ordinea impactului

Ghid practic pentru viteza unui site WordPress: ce măsori, ce repari întâi (hosting, cache, imagini, pluginuri, scripturi) și ce nu merită să faci.

Etapele optimizării vitezei unui site WordPress: măsurare, hosting, cache, imagini și pluginuri, ilustrate în ordinea priorității.

„Site-ul meu WordPress e lent” este una dintre cele mai frecvente probleme, și cea mai frecventă greșeală este să începi cu un plugin de optimizare „tot-în-unul”, fără să știi ce încărează pagina. Viteza unui site WordPress vine din câteva decizii, iar impactul lor nu e egal: hostingul și cache-ul contează mult mai mult decât minificarea unui fișier CSS.

Ghidul de mai jos te duce prin optimizare în ordinea impactului: ce măsori, ce repari întâi și ce nu merită să faci. Dacă ai un magazin WooCommerce, citește și ghidul despre INP și Core Web Vitals în WooCommerce, care tratează coșul și checkout-ul. Pentru un audit făcut de o echipă, vezi serviciul nostru de optimizare a vitezei.

Pe scurt, în ordinea impactului: (1) măsoară pe date reale; (2) alege un hosting și o versiune de PHP potrivite; (3) activează cache de pagină și de browser; (4) optimizează imaginile, în special imaginea principală; (5) curăță pluginurile și tema; (6) amână CSS, JavaScript și fonturile care blochează afișarea; (7) controlează scripturile terților; (8) ocupă-te de baza de date la final. Schimbă un singur lucru o dată și măsoară după fiecare pas.

1. Măsoară înainte să schimbi ceva

Folosește două tipuri de date. Datele reale, de la utilizatori, le găsești în raportul Core Web Vitals din Search Console și în secțiunea de date reale din PageSpeed Insights: ele spun cum simt site-ul vizitatorii tăi, inclusiv cei de pe telefoane lente. Testele de laborator (Lighthouse, WebPageTest) sunt utile pentru a găsi cauze, dar nu înlocuiesc datele reale.

Pentru fiecare pagină importantă notează trei lucruri: timpul până la primul octet de la server (TTFB), timpul până apare elementul principal (LCP) și greutatea totală a paginii. Dacă TTFB e mare, problema e în server și în cache, nu în imagini. Pentru a vedea ce încetinește codul propriu-zis, un plugin precum Query Monitor arată interogările lente la baza de date și pluginurile responsabile. Nu urmări un scor de 100 la un test: urmărește timpii și datele reale.

2. Hosting și versiunea de PHP

Hostingul stabilește limita de jos a vitezei tale. Pe un server supraaglomerat sau cu resurse prea mici, nicio optimizare de front-end nu te salvează. Întreabă ce procesor și câtă memorie primește contul tău, dacă există limite de procese PHP simultane și dacă ai un mediu separat de alte site-uri. Un site WordPress cu trafic constant sau un magazin merită resurse dedicate sau un hosting optimizat pentru WordPress, nu cel mai ieftin plan partajat.

Verifică și versiunea de PHP. Versiunile noi sunt, de obicei, mai rapide și mai sigure, iar cele învechite nu mai primesc nici actualizări de securitate. Folosește o versiune încă suportată oficial (verifică lista pe php.net), după ce ai testat pluginurile pe staging. Dacă îți trebuie un mediu configurat pentru WordPress și WooCommerce, vezi cum arată un hosting optimizat pentru WordPress și WooCommerce. Un CDN, precum Cloudflare, aduce fișierele statice mai aproape de vizitator și reduce încărcarea serverului.

3. Cache: de pagină, de browser și de obiect

Fiecare vizită pe o pagină WordPress fără cache înseamnă executări PHP și interogări la baza de date. Cache-ul de pagină salvează rezultatul gata făcut și îl servește direct, ceea ce poate scădea mult timpul de răspuns. Alege un singur mecanism de cache de pagină (un plugin dedicat sau cache-ul serverului), nu două care se suprapun, și exclude din cache coșul, checkout-ul și contul clientului, pentru că acolo conținutul e personalizat.

Cache-ul de browser ține fișierele statice pe dispozitivul vizitatorului. Se configurează prin antete de expirare: pe propriul nostru site, fișierele CSS, JavaScript, imaginile și fonturile au un antet de expirare de 30 de zile, ca vizitatorul care revine să nu le mai descarce. Cache-ul de obiect (de exemplu Redis) salvează rezultatele interogărilor repetate, iar efectul se simte mai ales pe site-uri cu mult conținut dinamic, ca un magazin.

4. Imaginile, cel mai des vinovate pentru LCP

De cele mai multe ori, elementul principal al paginii este o imagine, așa că aceasta dă LCP-ul. Patru reguli aduc cele mai multe câștiguri:

  • Format modern. WebP sau AVIF sunt mult mai mici decât JPEG sau PNG la aceeași calitate vizuală.
  • Dimensiunea potrivită. Nu încărca o imagine de 4000 de pixeli unde se afișează una de 800. Folosește imagini responsive, ca browserul să aleagă dimensiunea potrivită.
  • Încărcare leneșă (lazy-load) pentru ce e sub pliu, dar nu pentru imaginea principală: pe aceasta o încarci cu prioritate.
  • Lățime și înălțime setate, ca pagina să nu sară în timpul încărcării.

Am aplicat aceste reguli și pe propriul sistem de articole: imaginile de hero sunt convertite automat în WebP, la maximum 1.600 de pixeli lățime, cu dimensiunile salvate și cu prioritate de încărcare.

5. Pluginuri și temă: curățenia care contează

Nu numărul de pluginuri e problema, ci ce face fiecare. Un plugin bine scris poate fi ușor, iar unul prost scris poate încetini toată pagina. Fă un inventar: pentru fiecare plugin întreabă-te la ce folosește, dacă mai e necesar și dacă încărcă CSS sau JavaScript pe pagini unde nu ai nevoie de el. Dezactivează ce nu folosești, înlocuiește mai multe pluginuri mici care fac același lucru cu unul singur și verifică cu Query Monitor care sunt cele mai lente.

Tema contează la fel de mult. Constructorii de pagini vizuali adaugă mult cod și un DOM mare, ceea ce încetinește randarea, iar o temă „multifuncțională” încărcă adesea funcții pe care nu le folosești. Pentru un site de care depinde afacerea ta, o temă sau un plugin făcute la comandă pot costa mai puțin în timp decât o temă grea care trebuie ocolită constant; pentru asta vezi serviciul de dezvoltare WordPress custom.

6. CSS, JavaScript și fonturi

Fișierele CSS și JavaScript care blochează randarea întârzie apariția paginii. Amână JavaScript-ul necritic (defer), încarcă stilurile critice în linie și restul într-un fișier separat și elimină codul nefolosit. Fonturile Google încetinesc adesea prima afișare: preîncărcă fonturile critice și încarcă restul fără să blochezi randarea, așa cum am făcut pe propriul site, unde încărcarea neblocantă a fonturilor a rezolvat o avertizare din PageSpeed. Minificarea și combinarea fișierelor ajută mai puțin decât se crede, iar o minificare agresivă poate strica funcționalitatea, deci testează după fiecare schimbare.

7. Scripturile terților

Pixelii de marketing, chatul, widget-urile de recenzii, harta și video-urile înglobate adaugă cerere după cerere. Elimină ce nu folosești, încarcă restul doar când e nevoie (de exemplu harta, după un clic) și leagă pixelii de consimțământ, ca să nu se încarce înainte de acordul vizitatorului. Cum se face corect această legătură e descris în ghidul despre Consent Mode v2.

8. Baza de date, WP-Cron și detaliile finale

La final, ocupă-te de baza de date: reviziuni de articole acumulate, date tranzitorii expirate și opțiuni încărcate automat (autoload) în cantitate mare, care se citesc la fiecare cerere. WP-Cron, mecanismul care rulează sarcinile programate, se declanșează implicit la vizite; pe un site cu trafic, e mai stabil să îl muti pe un cron real al serverului. Reduce și frecvența cererilor Heartbeat din admin dacă încarcă serverul. Sunt optimizări mici față de cele de mai sus, dar contează la site-uri mari.

Ce nu ajută

  • Un scor de 100 la un test sintetic. Utilizatorii nu cumpără scorul, ci pagina.
  • Un plugin „tot-în-unul” instalat fără măsurare. Poate rezolva două lucruri și poate strica alte cinci.
  • Minificare agresivă fără teste. Strică formulare, glisoare și meniuri.
  • Optimizarea imaginilor pe un server lent. Dacă TTFB e de câteva secunde, imaginile nu sunt prima problemă.

Un plan pe 30 de zile

SăptămânaCe faciCe măsoari
1Măsori pe date reale, verifici hostingul și versiunea de PHPTTFB, LCP, raportul din Search Console
2Activezi cache-ul de pagină și de browserTTFB, timpul de încărcare
3Optimizezi imaginile și curăți pluginurileLCP, greutatea paginii
4Amâni scripturile, tratezi fonturile, curăți baza de dateINP, CLS, raportul din Search Console

După fiecare pas așteaptă să se acumuleze date noi: datele reale se actualizează cu întârziere, pentru că se calculează pe o fereastră de câteva săptămâni.

Întrebări frecvente

De ce e lent site-ul meu WordPress?

De obicei din una sau mai multe cauze: hosting slab sau supraaglomerat, lipsa cache-ului de pagină, imagini mari, prea multe pluginuri sau o temă grea. Măsoară întâi, ca să afli care dintre ele este.

Care este cel mai bun plugin de cache pentru WordPress?

Nu există unul universal. Alege un singur mecanism de cache de pagină, potrivit hostingului tău, și testează-l pe staging. Nu folosi două pluginuri de cache în același timp.

Câte pluginuri sunt prea multe?

Nu contează numărul, ci ce încărcă fiecare. Folosește Query Monitor ca să vezi care sunt cele mai lente și dezactivează ce nu folosești.

Trebuie să am scor 100 în PageSpeed?

Nu. Scorul e un indicator de laborator. Contează mai mult datele reale de la utilizatori și timpii efectivi de încărcare.

Cât durează să se vadă îmbunătățirile în Google?

Datele reale din Search Console se actualizează cu întârziere, pe o fereastră de câteva săptămâni. Efectul asupra utilizatorilor se vede imediat, în măsurătorile tale.

Dacă vrei un audit al vitezei site-ului tău, cu priorități și estimări, sau un abonament de mentenanță WordPress care îți ține site-ul rapid și actualizat, scrie-ne.

Vrei să discutăm despre proiectul tău?

Spune-ne ce ai de rezolvat. Revenim cu idei concrete și o propunere tehnică, nu cu o ofertă șablon.

sau pe email: contact@maxdev.ro