WordPress nu s-a stricat între timp. Site-urile construite pe el sunt des lente, dar cauza nu e platforma — e felul în care s-a construit pe ea: un teanc de pluginuri instalate ca să nu fie nevoie să scrie nimeni cod, plus un page builder care produce de trei ori mai mult HTML decât ar avea nevoie pagina.

Iar motivul pentru care s-a construit așa era, până de curând, perfect rațional. Un bloc custom sau un plugin propriu de o sută cincizeci de linii însemna zile de muncă tehnică. Un plugin de-a gata, cu configurare din admin, însemna un sfert de oră. La diferența asta de cost, alegerea se făcea singură — chiar și când toată lumea știa că plătește performanță și mentenanță pentru ea.

Partea care s-a schimbat e exact raportul ăsta. Textul de mai jos e despre ce decizii fac un site WordPress rapid din construcție, nu prin cache adăugat la final, și de ce platforma rămâne o alegere rezonabilă pentru cine are nevoie de ea. Dacă ai deja un site lent și vrei ordinea reparațiilor, aia e altă discuție, scrisă separat.

Ce s-a schimbat: codul custom a devenit ieftin

Un agent AI care lucrează în interiorul proiectului — citește tema, caută prin ea, rulează comenzi, scrie modificări — schimbă economia unei funcționalități mici. Un bloc de conținut cu trei câmpuri, un shortcode care afișează o listă filtrată, un endpoint care primește un formular și trimite un email: fiecare dintre ele e acum câteva ore de muncă, din care majoritatea se duc în revizie, nu în scris.

Consecința nu e că „AI-ul construiește site-ul“. E mai puțin spectaculoasă și mai utilă: pragul de la care merită cod propriu a coborât mult. Funcțiile pentru care, acum trei ani, instalai un plugin pentru că era evident mai ieftin, azi se scriu în bugetul proiectului.

Iar asta atacă exact defectul istoric al WordPress-ului. Platforma nu e grea în sine. Un WordPress cu o temă subțire și cinci pluginuri alese cu cap servește HTML rapid. Ce o îngreunează e acumularea: douăzeci și cinci de pluginuri, fiecare cu CSS-ul și JavaScript-ul lui încărcat pe toate paginile, instalate pe rând, de-a lungul anilor, fiecare pentru un motiv rezonabil la momentul lui.

Fiecare plugin e o dependență pe termen lung

Criteriul de decizie nu e „plugin sau cod“, ci ce anume delegi.

Merită plugin ce e greu, reglementat sau bine rezolvat de altcineva: magazinul și plățile, backup-ul și restaurarea, partea tehnică de SEO, securitatea, cache-ul. Sunt domenii în care un proiect matur, folosit de sute de mii de site-uri, a trecut prin cazuri particulare pe care tu nu le vei întâlni decât o dată — și atunci în cel mai prost moment.

Merită cod propriu ce e specific site-ului tău: felul în care arată lista de produse, un calculator de ofertă, un tip de conținut cu câmpurile lui, o integrare cu ERP-ul din firmă. Aici un plugin generic te obligă oricum la compromisuri de afișare și îți încarcă, în plus, funcții pe care nu le folosești.

Ce plătești pentru fiecare plugin instalat, dincolo de licență: actualizări care apar săptămânal și trebuie verificate, resurse încărcate pe pagini unde funcția lui nici nu apare, un autor care poate abandona proiectul, și o suprafață de atac în plus. Inventarul complet al costului ăstuia recurent e în articolul despre cât costă mentenanța — merită citit înainte de a decide că un plugin e „gratis“.

Regula practică pe care o folosim: dacă funcția se scrie în sub două sute de linii și e specifică site-ului, se scrie. Dacă e o categorie întreagă de probleme, se instalează.

Tema: acolo se decide performanța

Nicio optimizare de după nu repară o temă care livrează, pe fiecare pagină, un CSS global cu regulile tuturor componentelor bibliotecii și straturi de div-uri cu stiluri inline generate pentru fiecare element.

Un page builder vizual e un compromis conștient: câștigi control fără cod, plătești în greutatea paginii. Compromisul a avut sens exact atâta timp cât alternativa — markup scris de un om — era scumpă. Cu cod custom ieftin, argumentul principal pentru builder slăbește vizibil, iar o temă bloc sau o temă proprie subțire devine opțiunea implicită pentru un site de firmă.

Diferența nu e ideologică. O temă în care tu controlezi markup-ul poate fi optimizată; una în care markup-ul e generat de o bibliotecă, doar parțial. Am detaliat ce se vede în măsurători în articolul despre site-uri lente — aici e destul să spun că e decizia cu cel mai lung efect din tot proiectul, fiindcă e singura care nu se poate schimba mai târziu fără să refaci site-ul.

Bugetul de performanță se stabilește înainte, nu se măsoară la final

Un site rapid nu e un site optimizat la sfârșit. E un site căruia i s-au pus praguri de la început, tratate ca cerințe, nu ca verificare finală:

LCP sub 2,5 secunde pe mobil, pragul recomandat în documentația Google despre Core Web Vitals.
O limită de JavaScript livrat, stabilită la început și verificată la fiecare funcție adăugată.
Un număr maxim de cereri către domenii externe, cu justificare pentru fiecare.

Cu pragurile scrise, deciziile de construcție se iau altfel. Fonturile se găzduiesc local și se preîncarcă, nu se aduc de pe un domeniu extern. Imaginile intră în format modern, dimensionate pentru spațiul în care se afișează, cu width și height puse și cu încărcare leneșă peste tot, mai puțin pe imaginea principală. CSS-ul și JavaScript-ul unei componente se încarcă doar pe paginile care o conțin. Cache-ul de pagină și object cache-ul sunt configurate din prima zi, nu adăugate în panică după prima măsurătoare.

Niciuna dintre astea nu e o tehnică nouă sau exotică. Sunt lucruri pe care le știe toată lumea și care se aplică rar, fiindcă nu are cine să le ceară. Un prag scris în caietul de sarcini rezolvă problema mai bine decât orice unealtă.

Unde ajută agenții AI pe un proiect WordPress — și unde nu

Ajută, concret și repetat:

Blocuri și tipuri de conținut custom — partea de cod repetitiv care leagă un câmp de un formular, de un template și de un export.
Migrări de conținut și scripturi WP-CLI — mutat câmpuri dintr-un plugin abandonat în structura proprie, curățat revizii și opțiuni tranzitorii, redenumit taxonomii în masă.
Înțelegerea unei teme moștenite. Când preiei un site construit de altcineva acum șase ani, întrebarea „unde se generează bucata asta de HTML?“ primește răspuns în minute, nu într-o după-amiază.
Prima versiune a verificărilor — teste pentru cazurile evidente, peste care omul adaugă ce contează cu adevărat.

Nu ajută, și e important să fie spus la fel de apăsat:

Deciziile de arhitectură. Ce se face cu cod propriu, ce se deleagă unui plugin, ce structură de conținut rezistă peste doi ani — alegeri care depind de echipa care întreține site-ul și de bugetul tău, adică de lucruri care nu sunt în cod.
Securitatea delegată orbește. Cod care atinge autentificare, plăți sau încărcări de fișiere se citește de un om, linie cu linie, indiferent cine l-a scris.
Datoria tehnică, care doar își schimbă forma. Un plugin generat rapid e tot cod pe care cineva îl întreține. Dacă nimeni nu l-a citit, ai schimbat dependența de un autor extern pe o dependență de cod propriu pe care nu-l înțelege nimeni din firmă. E, adesea, un schimb prost.

Formularea pe care o folosim intern e simplă: agentul nu decide, agentul execută. Am scris pe larg despre cum arată fluxul ăsta și ce nu trimitem niciodată unei unelte externe.

Când WordPress rămâne alegerea corectă — și când nu

Onest, fiindcă altfel textul ăsta e reclamă.

Rămâne alegerea corectă dacă ai magazin online cu inventar, comenzi și plăți; dacă publici des, cu mai mulți autori care nu sunt tehnici și au nevoie de ciorne, revizii și programare; dacă ai nevoie de conturi de utilizator și zone protejate; sau dacă depinzi deja de integrări construite în jurul lui. În toate situațiile astea, ecosistemul rezolvă probleme reale pe care nu vrei să le rezolvi de la zero, iar mentenanța face parte din costul de funcționare, exact ca la orice aplicație care rulează în producție.

Nu mai e alegerea corectă pentru un site de prezentare de zece pagini, modificat de trei ori pe an, în care nimeni din firmă nu intră vreodată în admin. Acolo plătești lunar întreținerea unei platforme executabile pentru conținut care putea fi generat o singură dată și servit din CDN. Criteriile de decizie, în detaliu, sunt în Astro vs WordPress, inclusiv situațiile în care trecerea nu are niciun sens.

Codul custom ieftin nu schimbă granița asta. Un site care nu execută cod în producție rămâne mai simplu decât unul care execută, oricât de bine ar fi construit al doilea.

Ce facem noi

Partea de WordPress — construcție, optimizare, mentenanță — o tratăm prin WPFitness, serviciul nostru dedicat, cu proceduri și ritm propriu. Pentru site-urile de prezentare unde arhitectura statică e răspunsul corect, construim site-uri cu Astro. Nu sunt poziții contradictorii — sunt două răspunsuri la două întrebări diferite, iar prima întrebare pe care ți-o punem e care dintre ele e a ta.

Dacă ai un site WordPress și nu ești sigur dacă merită optimizat, reconstruit sau înlocuit, trimite-ne adresa lui și o propoziție despre cât de des îl modifici. Îți spunem ce vedem, inclusiv când răspunsul e că nu ai nevoie de noi.

Scrie-ne — răspundem în maxim 8 ore lucrătoare.

WordPress în 2026: de ce e încă o alegere bună și cum îl faci rapid