Găzduire WooCommerce România: ce se strică la o găzduire ieftină și cum verifici înainte să semnezi

La pachetele de găzduire foarte ieftine, resursele ajung, în practică, doar pentru site-uri mici, servite mai ales din cache: câteva pagini care se schimbă rar, aproape nimic de calculat la fiecare vizită. Un magazin WooCommerce cere altceva: are panou de administrare care muncește serverul și clienți care își fac coșuri și conturi. La firmele care ajung la noi cu un astfel de hosting, cumpărat la lansare pentru că era cel mai ieftin din listă, concluzia e de regulă aceeași: nu ai ce repara acolo. Ori treci pe un pachet mai serios la același furnizor, ori te muți.

Articolul ăsta nu e un clasament de furnizori de găzduire WooCommerce. Cam tot ce găsești în română pe subiect e scris fie de un furnizor care se recomandă pe sine, fie de un afiliat plătit din recomandările pe care le face. Nici noi nu suntem parte neutră: ținem site-uri de client pe un pachet de reseller luat de la un furnizor român, ales pentru ce ne trebuia nouă, fără să îl propunem altcuiva. Așa că mai jos nu apar nume și clasamente. Apare întrebarea care ne interesează: ce se strică de fapt la o găzduire proastă și cum îți dai seama înainte să semnezi.

De ce un magazin nu se găzduiește ca un site de prezentare

Diferența stă scrisă în documentațiile oficiale. Pagina de cerințe a WordPress recomandă PHP 8.3 sau mai nou și nu spune nimic despre memorie. Documentația WooCommerce e mai pretențioasă: tot PHP 8.3 sau mai nou, dar și o limită de memorie WordPress de cel puțin 256 MB. Puse una lângă alta, cele două pagini spun ceva ce rar se spune direct: un magazin cere de la server, oficial, mai mult decât un site obișnuit.

A doua diferență e mai puțin cunoscută și mai importantă. Tot WooCommerce cere ca paginile de coș, de checkout și de cont să rămână dinamice, adică excluse din cache. Are logică: fiecare client are alt coș și altă sesiune, nu poți servi tuturor aceeași pagină salvată. Consecința practică: din secunda în care un vizitator pune ceva în coș, cache-ul de pagini iese din joc, iar în configurările obișnuite fiecare cerere lovește direct PHP-ul și baza de date.

Pe un site de prezentare, ecuația e inversă. Acolo aproape totul poate fi servit din cache, așa că un pachet modest cu un cache bine configurat te poate ține pe linia de plutire ani întregi. Pe un magazin, scurtătura asta nu există: fix paginile care fac banii rulează pe resursele reale ale serverului. De aici și capcana lui „e rapid”. Viteza promisă în ofertă sau măsurată pe prima pagină e, de obicei, viteza paginilor din cache; despre checkout nu spune nimic.

Uită-te apoi ce listează ofertele de găzduire: spațiu pe disc și număr de domenii. Memoria disponibilă pentru PHP sau numărul de procese simultane apar rar. Pentru un site de prezentare, lipsa asta se iartă. Pentru un magazin, ele sunt cifrele de care depinde cât de repede răspunde checkout-ul, așa că întreabă de ele înainte de orice discuție despre preț.

Cum îți dai seama, pe un site deja live, că găzduirea e vinovatul? Am scris separat lista de verificări pe care le poți face singur, cu tot cu reperul nostru de memorie pentru un WordPress care merge cum trebuie. Aici rămânem la pasul de dinainte de semnătură.

Ce nu poți porni singur

Cea mai bună investiție de un sfert de oră pe un magazin care merge greu e, din experiența noastră, object cache-ul persistent, cel mai des pe Redis. Activarea pe server plus o configurare scurtă în plugin înseamnă cam 15 minute de lucru cu totul, iar interogările repetate spre baza de date încep să fie servite din memorie. Se simte imediat, mai ales în admin și pe paginile care oricum nu stau în cache: coș, checkout, cont.

WordPress însuși împinge în direcția asta: de la versiunea 6.1, verificarea de sănătate a site-ului recomandă un object cache persistent, iar pentru activare te trimite la furnizorul de găzduire. Aici e nodul. Redis rulează ca serviciu pe server și are nevoie de o extensie PHP pe care doar administratorul serverului o poate instala; pluginul din WordPress doar folosește ce e deja pus acolo. Pe un pachet partajat sau pe un reseller nu ți-l pornești singur, oricât de priceput ai fi: ori ți-l dă furnizorul, ori nu există. Sunt și furnizori care îl oferă pe pachete partajate; la cele ieftine, de regulă, nu e nicăieri în meniu.

Asta schimbă întrebarea cu care compari ofertele. Nu „cât de rapid e serverul vostru”, ci „ce am voie să activez pe el și cine decide”. Pe pachetul nepotrivit, cele mai bune 15 minute de optimizare din WordPress rămân un articol de documentație pe care îl citești cu invidie.

Ce versiune de PHP ai voie să rulezi și cine decide

Un caz de la un client căruia îi administrăm găzduirea: patru site-uri pe același cont, dintre care unul e un WordPress mai vechi care nu merge peste PHP 8.0. Celelalte au nevoie de versiuni mai noi. Am testat actualizarea și site-ul vechi a picat cu eroare fatală, adică ecran alb, site jos de tot. Am revenit la versiunea pe care mergea tot, pentru că nu dărâmi un site live ca să actualizezi restul. Cauza exactă nu am investigat-o; site-ul vechi nu era în grija noastră.

Costul se vede în timp: PHP 8.0 nu mai primește corecții de securitate din 26 noiembrie 2023. În cazul de mai sus, un singur site care nu poate trece de PHP 8.0 le ține pe celelalte trei legate de o versiune care nu se mai repară.

Partea care se putea ști dinainte: în unele configurații de găzduire partajată, versiunea de PHP se setează o singură dată, pentru tot contul; în altele, separat, pentru fiecare domeniu. În lista de prețuri nu scrie asta nicăieri, iar consecința apare abia când un site rămâne în urmă. Noi mergem invers și publicăm tot: vezi cât costă un magazin online. Deci pe lângă ce găzduire iei, contează și cum îți sunt așezate site-urile pe ea: mai multe site-uri pe un singur cont pot însemna o singură versiune de PHP pentru toate, iar ritmul îl dă cel mai vechi dintre ele. Dacă ții mai multe site-uri la un loc, întreabă explicit dacă pot rula versiuni diferite.

Când găzduirea decide dacă lansezi sau nu

Cel mai ciudat cost al unei găzduiri nepotrivite l-am văzut la un client internațional. I-am construit varianta site-ului pentru piața americană. E terminată, dar când scriu asta încă nu e live. Găzduirea existentă de acolo e lentă, iar o lansare pe ea ar fi însemnat un start cu handicap pentru un site nou, așa că varianta așteaptă o infrastructură pe care să aibă sens să pornească.

De pe margine sună absurd: totul e gata și totuși site-ul stă. Dar exact așa arată, dusă până la capăt, o găzduire aleasă greșit: te lasă să faci orice, doar că fiecare opțiune are un cost. Lansezi pe ea și pornești cu prima impresie stricată, fără istoricul care să te ierte: un site nou are doar vizitatori care îl văd pentru prima oară, iar clienții fideli, care revin indiferent de viteză, se câștigă în timp. Sau nu lansezi și aștepți.

E un singur caz, nu o regulă. Dar tot ce ține site-ul ăla pe loc se putea afla dinainte de contract, cu câteva întrebări puse la rece: ce resurse are pachetul dincolo de spațiul pe disc, ce se poate activa pe el și cine decide, cum se comportă la trafic real.

Cele șase întrebări pe care le pui înainte să semnezi

Orice ofertă de găzduire WooCommerce ar trebui trecută prin ele înainte de semnătură, cu răspunsurile cerute pe e-mail, ca să rămână undeva la care te poți întoarce. Contează ce ți se răspunde, dar și felul în care vine răspunsul: concret și cu detalii tehnice, sau ca o trimitere înapoi la pagina de vânzare.

  1. Am object cache persistent, Redis sau Memcached, pe pachetul ăsta? Cine îl activează? Dacă răspunsul e nu, știi din prima că cea mai eficientă optimizare pe care am văzut-o pe un magazin lent îți rămâne închisă, oricâte pluginuri de viteză ai instala peste.
  2. Pot alege versiunea de PHP? Per site sau pe tot contul? Un magazin trăiește ani, iar versiunile de PHP ies din suport la termene pe care nu le controlezi. Întreabă și când retrage furnizorul versiunile vechi, ca să nu afli odată cu eroarea.
  3. Ce se întâmplă concret când depășesc resursele? Mă încetiniți sau mă suspendați? Cine mă anunță și cât de repede? Vârfurile de trafic vin din campanii și din sezon, adică din perioadele în care magazinul vinde cel mai mult, și tot atunci se ating și limitele pachetului.
  4. Cum verific că backupul chiar se restaurează? „Backup zilnic” promite oricine. Întrebarea reală e cine face restaurarea când magazinul e jos și cât durează. Dacă se poate, cere o probă pe un site de test, înainte de contract. Și, tot aici: în cât timp ajungi la un om, cu magazinul jos.
  5. Cât costă de la al doilea an încolo și ce nu e inclus? Nu dau cifre aici, se schimbă des; principiul rămâne. Prețul din reclamă și prețul de la reînnoire pot fi departe unul de altul, iar momentul în care afli vine de obicei după ce magazinul e deja instalat și mutarea a devenit incomodă.
  6. Cum plec de la voi? Mai toți furnizorii promit migrare gratuită spre ei; ce se întâmplă când vrei să pleci nu prea scrie nicăieri. Cere în scris două lucruri: export complet al datelor și acces la backupuri și după încheierea contractului.

Ce faci dacă ești deja pe o găzduire proastă

Întâi diagnosticul. Nu orice magazin lent e vina găzduirii: am avut un site care se târa din cauza pluginurilor, câte unul pentru fiecare funcție măruntă, și care după o reconstrucție curată a rămas pe aceeași găzduire, fără nicio schimbare de hosting. Dacă însă problema e pachetul în sine, cel foarte ieftin, dimensionat pentru site-uri mici servite din cache, de reparat nu prea ai ce. De regulă alegerea e între un pachet mai potrivit la același furnizor și o mutare.

Mutarea unui magazin e o lucrare separată, cu pașii ei. Riscul specific vine din propagarea DNS: intervalul, de la câteva ore până la o zi sau două, în care o parte din internet încă știe vechea adresă a serverului. La un blog e un detaliu. La un magazin înseamnă comenzi care pot ateriza pe serverul vechi după ce tu te uiți deja la cel nou, așa că serverul vechi se închide controlat, iar comenzile din interval se verifică bucată cu bucată.

După mutare rămâne partea care nu se termină: update-uri care vin peste un site viu și un backup care trebuie verificat periodic, cu câte o restaurare de probă. Cineva trebuie să aibă magazinul în grijă lună de lună, iar în multe firme mici omul ăsta nu există. Pentru situația asta există mentenanța lunară de WordPress: partea tehnică rămâne în grija cuiva, iar la noi, cât timp mentenanța e activă, domeniul și găzduirea sunt incluse.

Iar dacă ești în punctul bun al poveștii, cu oferta încă nesemnată pe masă, pune cele șase întrebări de mai sus și cere răspunsurile în scris. Cel mai scump lucru la un pachet ieftin nu e prețul lui, e ce nu te lasă să faci.