Găzduire WordPress: Pentru Ce Plătești De Fapt

Găzduirea WordPress se vinde într-un interval de preț care merge de la aproximativ £3 pe lună până la câteva sute, iar planurile de la ambele capete se descriu cu cuvinte aproape identice. Rapid. Sigur. Cu backup. Cu suport. Specificația care i-ar permite unui cumpărător să le deosebească, adică ce ramură de PHP rulează site-ul, ce motor de bază de date stă în spate, câte straturi de cache există și care dintre ele sunt de fapt pornite, lipsește de obicei din pagina de pe care vi se cere să cumpărați.

Absența aceea face parte din produs. “Administrat” este o categorie de marketing și nu una tehnică, iar niciun organism de standardizare nu o definește. Doi furnizori care folosesc același cuvânt pot să difere în privința unui object cache persistent activ, a dreptului de a păstra propriul plugin de cache, a posibilității ca un backup să iasă din infrastructura lor și a accesului la o consolă.

Ce urmează este specificația pe care paginile acelea o omit: ce cere WordPress, ce părți ale stivei mișcă viteza paginilor, ce adaugă și ce ia pe tăcute găzduirea administrată și intervale lunare realiste pentru fiecare nivel.

Pentru ce plătiți de fapt la găzduirea WordPress? Pentru patru lucruri. O versiune de PHP și un motor de bază de date care ating baza publicată de WordPress. Straturi de cache pe care altfel ar trebui să le instalați și să le reglați singuri. Muncă de operare, adică actualizări, staging, backupuri și un firewall. Și rezervă pentru cererile care nu pot fi puse în cache. Un site de prezentare nu are aproape deloc nevoie de al patrulea punct. Un magazin sau un site cu abonamente cheltuiește acolo cea mai mare parte din buget.

Găzduirea WordPress este un nume de categorie, nu o specificație

Diferența de preț din interiorul unei singure categorii este semnalul. Două planuri, ambele etichetate găzduire WordPress administrată, pot sta la £20 și la £250 pe lună, iar textul comercial nu va explica diferența, pentru că diferența e făcută din lucruri pe care textul nu le pomenește.

La capătul ieftin cumpărați o felie dintr-o mașină partajată cu un pool PHP-FPM, un cache de pagină și un panou de control. La capătul scump cumpărați calcul izolat, un object cache persistent, un mediu de staging, un firewall administrat, o echipă de suport care vă va citi jurnalul de erori și pe cineva răspunzător contractual atunci când o actualizare de nucleu strică un șablon.

Ambele sunt produse legitime. Problema este că un cumpărător nu poate vedea pe care dintre ele îl are în față, așa că decizia se ia pe preț și pe site-uri de recenzii ordonate după comisionul de afiliere. Rezultatul e previzibil în ambele direcții. Site-uri de prezentare ajung pe planuri de £150 pe care nu le vor epuiza niciodată, iar magazinele WooCommerce ajung pe planuri de £5 care cad la plată în prima sâmbătă aglomerată.

Ieșirea este să cumpărați după patru întrebări, nu după numele nivelului: ce ramură de PHP, ce straturi de cache, câte cereri care nu pot fi puse în cache absoarbe planul și ce se întâmplă cu datele voastre când plecați.

Ce cere de fapt WordPress de la un server

WordPress publică o pagină de cerințe, iar aceasta este scurtă, exact motivul pentru care este sărită. Citiți-o ca pe o specificație de achiziție, fiindcă un plan care nu o trece este descalificat înainte să se discute despre performanță.

Versiunea de PHP

Pagina de cerințe WordPress indică drept bază recomandată “PHP versiunea 8.3 sau mai nouă”. Poartă și un avertisment care contează mai mult decât recomandarea: WordPress “va rula în continuare pe PHP 7.4+ și MySQL 5.5.5+, dar acele versiuni au ajuns la sfârșitul oficial al vieții și pot expune site-ul vostru unor vulnerabilități de securitate”.

Toată capcana stă în această frază. WordPress nu va refuza să pornească pe o ramură veche de PHP. Rulează, arată normal și stă tăcut pe un interpretor care nu a mai primit o corecție de securitate de ani buni.

Baza de date

Aceeași pagină cere “MariaDB 10.11+ sau MySQL 8.0+”. Motoarele mai vechi funcționează în continuare, motiv pentru care atât de multe site-uri stau pe ele. Statisticile de utilizare publicate chiar de WordPress arată că aproximativ una din șase instalări raportează o versiune MySQL 5.x, mult sub pragul declarat, iar MySQL 5.7 singur reprezintă circa 12 la sută dintre site-urile care raportează.

Consecința nu este că site-ul se strică. Este că pierdeți îmbunătățiri ale motorului care contează exact pentru sarcinile greu de pus în cache și moșteniți o migrare pe care oricum va trebui să o faceți cândva.

HTTPS și extensiile PHP

HTTPS este listat drept “necesar pentru fiecare instalare”, nu recomandat. O gazdă care în 2026 tratează încă un certificat ca pe un supliment plătit vă spune ceva despre restul planului.

Dincolo de asta, manualul de găzduire WordPress numește json și mysqli drept necesare, iar curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml și zip drept puternic recomandate. Pe două merită să le pomeniți unui om de vânzări. Fără zip, pachetele de actualizare pentru pluginuri și nucleu nu pot fi dezarhivate. Fără imagick, încărcările media cad pe o bibliotecă de imagini mai slabă, iar imaginile voastre ies mai prost înainte ca cineva să atingă vreun plugin de optimizare.

Versiunea de PHP este linia cu cel mai mare efect de pe factură

Din tot ce controlează o gazdă, ramura de PHP are cel mai bun raport între efect și efort. În majoritatea panourilor este o listă derulantă. Nimic nu se reconstruiește, nimic nu se migrează, iar un site deja compatibil pur și simplu începe să ruleze pe un interpretor mai rapid și mai bine susținut.

Motivul pentru care rămâne neschimbată ani la rând este organizatoric, nu tehnic. Nimeni nu răspunde de ea. Agenția care a construit site-ul a plecat mai departe, gazda nu o schimbă unilateral fiindcă o eroare fatală într-un plugin abandonat ar deveni vina ei, iar firma nu are motiv să se gândească la un număr care nu i-a fost arătat niciodată.

Prima întrebare pusă unei gazde potențiale nu este deci despre viteză. Este ce ramură de PHP rulează planul implicit, ce ramuri oferă și dacă o puteți schimba singuri fără să deschideți un tichet. O gazdă care oferă doar o ramură pe care WordPress nu o mai recomandă a răspuns în același timp la toate celelalte întrebări.

Testați pe staging, nu comutați niciodată producția. Un site care trece de la PHP 7.4 la 8.3 scoate de obicei la iveală două sau trei avertismente de depreciere din pluginuri neîntreținute, iar acela este costul real. Bugetați între o jumătate de zi și o zi de dezvoltare, tratată pe larg în ghidul nostru despre tarifele dezvoltatorilor WordPress și ce să întrebați.

Jumătatea de securitate a argumentului PHP

Performanța este motivul invocat pentru actualizarea PHP. Securitatea este motivul care contează cu adevărat și care se măsoară în loc să se dezbată.

PHP publică propriul calendar al versiunilor susținute. Fiecare ramură primește doi ani de suport activ și încă doi ani doar de corecții de securitate. În septembrie 2026 asta pune PHP 8.2 în regim doar de securitate până la 31 decembrie 2026 și PHP 8.3 în același regim până la 31 decembrie 2027, după ce suportul activ s-a încheiat la 31 decembrie 2025. PHP 8.4 rămâne în suport activ până la 31 decembrie 2026, cu corecții de securitate până la 31 decembrie 2028, iar PHP 8.5 până la 31 decembrie 2027, cu corecții până la 31 decembrie 2029. Tot ce e mai vechi s-a terminat: PHP 8.1 s-a încheiat la 31 decembrie 2025, PHP 8.0 la 26 noiembrie 2023 și PHP 7.4 la 28 noiembrie 2022.

Puneți asta față în față cu ce rulează de fapt site-urile WordPress. Pagina de statistici WordPress raportează circa 38,8 la sută dintre instalări pe o ramură complet ieșită din suport, cu aproximativ 23,2 la sută încă pe PHP 7.4 sau mai vechi. Doar circa 36,4 la sută ating baza PHP 8.3 recomandată de WordPress, iar alte 24,8 la sută stau pe PHP 8.2, care pierde suportul de securitate la sfârșitul acestui an.

O majoritate a site-urilor WordPress rulează, prin urmare, pe un interpretor care fie nu mai primește corecții de securitate, fie este la câteva luni de acel moment, iar aproape întotdeauna este o setare de găzduire la care nu s-a uitat nimeni. Corectarea costă mai puțin decât o licență de plugin, motiv pentru care lista noastră de verificare pentru securizarea WordPress o tratează ca pe primul pas.

Straturile de cache, în ordinea în care le întâlnește o cerere

Aproape orice promisiune de performanță a unei gazde este o promisiune despre cache, iar aproape orice cumpărător o aude ca pe o singură promisiune nediferențiată. Există patru straturi distincte, stau într-o ordine fixă și fiecare economisește un alt fel de muncă. Ordinea de mai jos este cea prin care trece o singură cerere, iar o cerere servită de un strat anterior nu ajunge niciodată la cele următoare.

Cache-ul de edge sau CDN

Primul lucru pe care îl întâlnește o cerere este un cache complet în afara serverului vostru, într-o rețea de puncte de prezență aflate aproape de vizitator. Dacă răspunsul e deja stocat acolo, gazda voastră nu vede deloc cererea.

Acest strat economisește distanță de rețea, nu doar calcul. Un vizitator din Manchester care atinge un nod edge din London evită un drum transatlantic. Pentru resursele statice este aproape gratuit și merită întotdeauna. Pentru HTML este puternic, dar condiționat, fiindcă edge-ului trebuie să i se spună care răspunsuri sunt personale și nu au voie să fie împărțite.

Cache-ul de pagină întreagă

Al doilea strat stochează HTML-ul finit al unei pagini, ca PHP și baza de date să nu mai ruleze din nou. Manualul de găzduire WordPress recomandă un reverse proxy precum NGINX sau Varnish, care “stochează ieșirea direct în memoria serverului sau pe hard disk”, și adaugă regula care decide dacă stratul funcționează: “este o idee bună să excludeți din cache toți utilizatorii autentificați, fiindcă ei ar trebui să vadă conținut personalizat”.

Acesta este stratul care flatează găzduirea ieftină. Când funcționează, vizitatorului i se servește un fișier, iar versiunea de PHP, motorul de bază de date și numărul de pluginuri încetează să conteze pentru cererea aceea, fiindcă niciunul nu se execută.

Object cache-ul

Al treilea strat pune în cache rezultatele interogărilor individuale către bază și valorile calculate. WordPress îl livrează implicit, dar nu persistent. Documentația WP_Object_Cache este explicită: “În mod implicit, object cache-ul nu este persistent. Asta înseamnă că datele stocate în cache stau doar în memorie și doar pe durata cererii.”

A-l face persistent înseamnă a pune Redis sau Memcached în spatele lui printr-un drop-in, ceea ce transformă cache-ul din ceva reconstruit la fiecare încărcare de pagină în ceva împărțit între cereri și vizitatori. Este stratul care contează odată ce paginile nu mai pot fi puse integral în cache și cel care lipsește cel mai des din planurile ieftine.

Cache-ul de opcode

Al patrulea strat este OPcache, care ține în memoria partajată bytecode-ul compilat al fișierelor voastre PHP, ca interpretorul să nu le analizeze și să nu le recompileze la fiecare cerere. Manualul de găzduire spune că “pentru mediile WordPress de producție se recomandă ca OPcache să fie activat pentru cererile web și dimensionat pentru site sau pentru platforma de găzduire”.

Există o consecință la punerea în producție. Fiindcă OPcache ține cod compilat, o punere în producție trebuie să îl reseteze sau să invalideze fișierele schimbate, altfel serverul rulează în continuare versiunea anterioară. O gazdă care nu vă poate spune cum este invalidat OPcache este o gazdă unde o actualizare de plugin pare că nu face nimic timp de câteva minute.

De ce un site de prezentare este rapid pe aproape orice gazdă

Urmăriți cele patru straturi până la capăt și concluzia este incomodă pentru industria găzduirii. Dacă fiecare vizitator este anonim și fiecare pagină poate fi pusă în cache, cache-ul de pagină întreagă răspunde la aproape tot traficul, iar fișa tehnică a mașinii din spate aproape că nu contează.

De aceea un site de firmă cu cinci pagini pe un plan de £4 cu un cache de pagină decent poate arăta un timp de răspuns al serverului mai bun decât un site încărcat pe un plan de £200. Site-ul ieftin servește fișiere. Cel scump execută PHP.

Numărul de urmărit este timpul până la primul octet, care în sine nu este un Core Web Vital. Prezentarea Web Vitals a Google îl trece printre metricile de sprijin, utile pentru “diagnosticarea problemelor de LCP” cauzate de timpi lenți de răspuns ai serverului. Exact aceasta este felia din viteza paginii pe care o controlează o gazdă.

WordPress este de acord îndeajuns cât să o scrie în nucleu. Testul Starea site-ului pentru cache-ul de pagină întreagă, adăugat în WordPress 6.1, verifică “dacă site-ul folosește o soluție de cache de pagină întreagă și dacă timpul de răspuns este acceptabil”, cu un prag implicit de 600 de milisecunde. Dacă site-ul vostru stă peste acest prag cu un cache de pagină presupus activ, cache-ul nu funcționează, iar procesor în plus nu va ascunde asta.

Pentru un site de prezentare, o trecere la o găzduire superioară este deci de obicei achiziția greșită. Îl încetinesc mai des o imagine de antet supradimensionată, un constructor de pagini care livrează sute de kiloocteți de CSS sau șase grosimi de font, care este argumentul comparației noastre între Elementor și o temă la comandă.

Traficul autentificat și WooCommerce rup modelul

Tot ce s-a spus mai sus presupune că poate răspunde cache-ul de pagină. În clipa în care vizitatorii se autentifică, presupunerea se prăbușește, iar economia găzduirii se inversează.

WooCommerce documentează asta direct. Îndrumările sale despre cache cer excluderea paginilor Coș, Contul meu și Finalizare comandă din cache-ul de pagină, fiindcă acele pagini “trebuie să rămână dinamice, întrucât afișează informații specifice clientului curent și coșului său”. Sunt enumerate și cookie-urile care trebuie să ocolească cache-ul, între care woocommerce_cart_hash, woocommerce_items_in_cart și wp_woocommerce_session_, plus sfatul de a exclude _wc_session_ din cache-ul bazei de date.

Citit ca specificație de găzduire, spune ceva fără menajamente. Într-un magazin, paginile care produc încasări sunt exact paginile pe care cache-ul de pagină nu le poate atinge. Catalogul și fișele de produs pot fi puse în cache pentru vizitatorii anonimi. Coșul și finalizarea comenzii, niciodată, pentru nimeni.

La fel stau lucrurile la site-urile cu abonamente, platformele de învățare, forumuri și orice site cu portal de client. Odată setat un cookie de sesiune, majoritatea pluginurilor de cache încetează complet să servească HTML din cache acelui vizitator, așa că fiecare clic execută PHP și lovește baza de date. Aici object cache-ul încetează să fie o optimizare și devine portant, iar aici un plan ieftin doare într-un fel pe care niciun test sintetic pe prima pagină nu îl arată, așa cum explicăm în de ce magazinul vostru WooCommerce este lent.

Ce include de fapt găzduirea WordPress administrată

Dacă scoateți adjectivele, găzduirea administrată se reduce la un pachet destul de constant de muncă de operare. Merită să dați un preț cinstit acelei munci, pentru că unei firme fără personal tehnic îi iese adesea mai ieftin cumpărată decât făcută.

Actualizările

Planurile administrate aplică de regulă automat actualizările de nucleu, uneori și pe cele de pluginuri, ocazional cu o verificare vizuală de regresie înainte și după. Lucrul util de știut este cât face deja WordPress gratuit.

WordPress actualizează automat, de ani buni, versiunile minore de nucleu și fișierele de traducere, iar de la 5.6 instalările noi au actualizările automate active atât pentru versiunile minore, cât și pentru cele majore ale nucleului, cu excepția cazului în care este detectat un checkout de control al versiunilor, în timp ce instalările existente păstrează comportamentul mai vechi. Partea plătită nu sunt deci actualizările minore de nucleu. Sunt actualizările de pluginuri, revenirea atunci când unul se strică și cineva care observă că s-a stricat.

Staging și backupuri

Un mediu de staging la un clic are valoare reală și e chiar enervant de construit singur. Judecați-l după două detalii, nu după simpla lui existență: dacă trimiterea stagingului înapoi în producție suprascrie baza de date live, ceea ce ar arunca comenzile și comentariile primite după copie, și dacă site-ul de staging este blocat pentru motoarele de căutare și pentru trimiterea de e-mailuri.

Firewall și scanare antimalware

Cele mai multe planuri administrate includ un firewall de aplicație la edge și o formă de scanare antimalware. Firewallul este valoare reală, fiindcă peticirea virtuală la nivel de rețea cumpără timp între dezvăluirea unei vulnerabilități de plugin și actualizarea voastră.

Scanarea este mai slabă decât sună. De obicei detectează semnături cunoscute de fișiere rău intenționate, deci prinde infecțiile de masă și le ratează pe cele țintite. Tratați-o ca pe un detector de fum, nu ca pe o încuietoare, și păstrați munca de securizare de partea voastră a liniei.

Ce ia găzduirea administrată

Restricțiile sunt jumătatea pe care nu o citește nimeni și cântăresc de obicei mai mult decât funcțiile. Există din motive care se pot apăra, dar motivele sunt ale furnizorului, nu ale voastre.

Cel mai clar exemplu publicat este lista de pluginuri interzise a WP Engine, care interzice categorii întregi în loc de vinovați individuali. Pluginurile de cache sunt interzise fiindcă “pot intra în conflict cu structura de cache integrată a platformei noastre”. Pluginurile de backup sunt interzise pe motiv că “vă îngreunează inutil site-ul”. Pluginurile de articole similare sunt interzise ca fiind “extrem de intensive pentru baza de date”. Pluginurile cu vulnerabilități documentate sunt interzise de-a dreptul, la fel ca cele care dublează funcții ale platformei.

Fiecare dintre acestea este o decizie tehnică rezonabilă. Împreună înseamnă că site-ul vostru nu este portabil în felul în care presupuneați. Dacă instalarea voastră depinde de configurația unui anumit plugin de cache, configurația aceea nu se mută împreună cu voi.

Accesul la consolă este cealaltă omisiune obișnuită. Multe planuri administrate nu oferă deloc SSH, sau oferă o consolă restrânsă fără WP-CLI, ceea ce transformă o muncă de rutină, precum o căutare și înlocuire în masă după o schimbare de domeniu, într-un tichet de suport. Alte două lucruri iau lumea prin surprindere: procesele de lungă durată sunt frecvent plafonate, așa că un import de 50.000 de produse trebuie tăiat în bucăți, iar poșta de ieșire este adesea blocată sau limitată, pornind de la ideea că un site compromis va fi folosit pentru spam.

Promisiunile de performanță care nu supraviețuiesc unui test

Marketingul din găzduire trăiește dintr-un set mic de afirmații care se destramă în clipa în care întrebați ce anume s-a măsurat.

“De douăzeci de ori mai rapid” aproape niciodată nu numește un termen de comparație. Mai rapid decât ce, pe ce pagină, cu ce pluginuri, la ce concurență? Fără aceste patru elemente, cifra este un raport între două mărimi fără nume.

“Lățime de bandă nelimitată” stă lângă un plafon lunar de vizite în același tabel. Lățimea de bandă rareori este oricum constrângerea pe un site WordPress. Constrângerea este execuția simultană a PHP, pe care planul de obicei nu o pomenește deloc.

“99,9 la sută disponibilitate” sună absolut și nu este. Pe o lună de treizeci de zile permite cam 43 de minute de indisponibilitate. Trei de nouă este o valoare normală pentru găzduirea partajată, patru de nouă permit circa patru minute pe lună, iar diferența este cea dintre un neajuns și o cădere pe care nu o observă nimeni. Citiți ce plătește de fapt despăgubirea când ținta este ratată, subiect tratat separat în SLA-uri de disponibilitate care înseamnă ceva.

Ultima afirmație este cea mai frecventă și cea mai înșelătoare: o captură cu un test de viteză pe o primă pagină din cache. Aceea măsoară cache-ul de pagină, nu gazda, iar cache-ul de pagină este singura componentă aproximativ echivalentă peste tot.

Cum se testează corect o gazdă

Testarea găzduirii nu este grea, dar trebuie făcută pe traseul care solicită cu adevărat serverul. Cinci pași, în ordine.

Întâi, testați un traseu care nu este în cache. Adăugați un șir de interogare unic pentru a păcăli cache-ul de pagină sau cereți o pagină care nu este niciodată pusă în cache, precum un coș sau o pagină de cont. Dacă nu puteți face o cerere care execută PHP, testați un server de fișiere.

Apoi, repetați. O singură cerere nu vă spune nimic despre variație, iar în variație se vede găzduirea ieftină. Luați cel puțin douăzeci de măsurători și citiți percentila 75, statistica pe care Google o folosește pentru datele din teren.

În al treilea rând, testați de acolo de unde sunt vizitatorii voștri. Un răspuns măsurat dintr-un centru de date de alături de server nu este răspunsul pe care îl primesc clienții voștri din Leeds.

În al patrulea rând, testați sub concurență. Lansați zece sau douăzeci de cereri simultane care nu pot fi puse în cache. Este singurul test care arată epuizarea worker-elor PHP, iar epuizarea worker-elor este cea care doboară un magazin în timpul unei promoții.

În al cincilea rând, comparați lucruri egale: aceeași ramură de PHP, același set de pluginuri, aceeași temă, același volum de conținut. O migrare care schimbă stiva de pluginuri odată cu gazda nu a dovedit nimic nici despre una, nici despre cealaltă. Dacă vreți asta rulat pe un site real în loc de pe o gazdă candidată, exact asta face un audit de performanță WordPress.

Ce Core Web Vitals mișcă de fapt găzduirea

Core Web Vitals este locul unde promisiunile de găzduire și clasarea în căutare se amestecă, așa că merită să fim preciși în privința metricii pe care un server o poate influența.

Sunt trei, evaluate la percentila 75 a încărcărilor și separate pe mobil și desktop. Largest Contentful Paint măsoară încărcarea și este bun la 2,5 secunde sau mai puțin, are nevoie de îmbunătățiri între 2,5 și 4,0 secunde și este slab peste 4,0. Interaction to Next Paint măsoară reactivitatea și este bun la 200 de milisecunde sau mai puțin, are nevoie de îmbunătățiri până la 500 de milisecunde și este slab peste. Cumulative Layout Shift măsoară stabilitatea vizuală și este bun la 0,1 sau mai puțin, are nevoie de îmbunătățiri până la 0,25 și este slab peste. First Input Delay a fost retras și înlocuit cu INP, devenit Core Web Vital stabil în 2024.

Găzduirea mișcă direct exact una dintre ele. Timpul de răspuns al serverului face parte din LCP, așa că o gazdă care taie din el 400 de milisecunde ia 400 de milisecunde din LCP pentru fiecare vizitator. Pe o gazdă lentă asta poate fi diferența dintre trecere și picare.

Nu face aproape nimic pentru CLS, care vine din imagini fără dimensiuni și din fonturi încărcate târziu, și foarte puțin pentru INP, dominat de JavaScript pe firul principal. Regula este că, dacă LCP este slab și răspunsul vostru de server necache stă peste pragul de 600 de milisecunde semnalat de WordPress, găzduirea face parte din problemă. Dacă răspunsul este comod și LCP rămâne slab, vina este în pagină, iar ghidul nostru pentru trecerea Core Web Vitals în 2026 este locul mai bun pentru buget.

Backupurile și partea pe care nu o verifică nimeni

Orice plan de deasupra celui mai ieftin face reclamă backupurilor. Aproape nimeni dintre cei care cumpără unul nu pune întrebările care decid dacă backupul valorează ceva.

Dacă l-a restaurat cineva vreodată

NCSC o spune limpede în ghidul său pentru organizațiile mici: odată ce ați făcut un backup, “este important să știți cum să îl restaurați și să verificați că el conține toate datele voastre importante”. Un backup netestat este o convingere, nu un control.

Întrebați furnizorul cum se pornește o restaurare, cât durează pentru un site de mărimea vostră și dacă restaurarea bazei de date restaurează și directorul de încărcări. Apoi faceți-o o dată pe staging, înainte să aveți nevoie. Modul de eșec de urmărit este o restaurare care aduce înapoi fișierele, dar nu și baza de date, sau una care reușește și pierde pe tăcute tot ce a apărut după copie.

Păstrare și frecvență

Backupuri zilnice cu păstrare de șapte zile sună generos până când vă gândiți cum cade de fapt un site WordPress. Un site desfigurat se observă în câteva ore. O compromitere care injectează pe tăcute linkuri de spam în articole vechi se observă în câteva săptămâni, iar până atunci fiecare copie păstrată conține injecția.

Treizeci de zile sunt un prag mai util pentru orice este comercial, iar o copie lunară separată este o asigurare ieftină. Un magazin are nevoie și de un interval de backup al bazei măsurat după volumul de comenzi, fiindcă a pierde patru ore de comenzi nu este aceeași categorie de problemă cu a pierde patru ore de modificări pe blog.

Unde stă copia și în ce format

Celălalt punct al NCSC este că un backup care rămâne atașat de sistemul viu nu este separat: un dispozitiv care ține backupuri “nu ar trebui să rămână conectat la dispozitivul vostru când nu este folosit”, fiindcă orice compromite sursa îl poate atinge. Aplicat la găzduire, un backup păstrat în același cont și restaurabil doar din același panou împarte soarta lucrului pe care îl protejează.

Formatul este varianta mai subtilă a aceleiași probleme. Dacă singura cale de a citi un backup este butonul de restaurare al furnizorului, aveți o comoditate, nu o copie portabilă. Testul este dacă puteți descărca astăzi un dump SQL simplu și o arhivă de fișiere pe care un dezvoltator competent le-ar putea ridica în altă parte. Dacă nu, migrarea încetează să fie o decizie tehnică și devine o negociere.

Unde stau datele și de ce contează pentru cumpărătorii britanici

Deciziile de găzduire sunt decizii de protecție a datelor, iar pentru o firmă britanică întrebarea nu este unde este înregistrată societatea, ci unde stau datele personale și cine poate ajunge la ele.

Ghidul ICO despre transferurile internaționale fixează un test în trei pași. Dacă GDPR-ul britanic se aplică prelucrării voastre, dacă voi sunteți cei care inițiați transferul și dacă organizația care primește este o entitate juridică distinctă, faceți un transfer restricționat. ICO spune explicit că regulile “se aplică tuturor transferurilor restricționate, chiar și celor mici și rare” și acoperă orice organizație care prelucrează date personale, “inclusiv întreprinzătorii individuali și persoanele care lucrează pe cont propriu”.

Observați ce se pune la socoteală drept transfer. ICO include atât trimiterea de date personale, cât și “punerea lor la dispoziție” unei organizații din afara Regatului Unit. O echipă de suport din străinătate cu acces la administrarea voastră sau un backup extern replicat în altă regiune pot îndeplini fiecare acea definiție.

Orice transfer restricționat trebuie acoperit de unul din trei lucruri: reglementări britanice de adecvare pentru destinație, garanții potrivite precum International Data Transfer Agreement, Addendumul sau regulile corporatiste obligatorii, ori o excepție. Când vă bazați pe garanții, ICO așteaptă și o evaluare a riscului transferului care să arate că protecția nu este semnificativ mai scăzută după aceea. Nimic din toate acestea nu face inutilizabilă o gazdă din străinătate. Face din ea o decizie care trebuie documentată, iar documentarea costă mult mai puțin înainte de migrare decât în timpul unei cereri de acces la date.

Ce ar trebui să spună un contract cu împuternicitul

Gazda voastră este împuternicit, iar voi sunteți operator, așa că un contract scris nu este opțional. ICO enumeră ce trebuie să conțină acel contract, iar patru dintre clauzele sale se citesc direct ca întrebări despre găzduire.

Subîmputerniciții vin primii. Conform articolului 28(3)(d), împuternicitul nu are voie să angajeze un alt împuternicit fără autorizarea voastră, trebuie să vă anunțe despre schimbările intenționate ca să vă puteți opune și trebuie să impună obligații echivalente pe lanț. În termeni de găzduire, aceștia sunt CDN-ul, destinația backupurilor, releul de e-mail și furnizorul de cloud din spate. Cereți lista.

Securitatea vine a doua. Articolul 28(3)(c) cere măsuri care să respecte articolul 32, iar ICO detaliază ce cuprind acestea: criptare și pseudonimizare, reziliența sistemelor de prelucrare, “capacitatea de a restabili accesul la datele personale în cazul unui incident” și “procese de testare și evaluare periodică a eficacității măsurilor”. Acesta este testul de restaurare scris în lege, nu într-un articol de bune practici.

A treia este ieșirea. Conform articolului 28(3)(g), împuternicitul trebuie, la alegerea voastră, să șteargă sau să returneze toate datele personale la finalul contractului și să șteargă copiile existente. Un furnizor ale cărui backupuri nu pot părăsi platforma are o problemă contractuală, nu doar una practică. A patra este auditul, care conform articolului 28(3)(h) vă dă dreptul la informațiile necesare pentru a demonstra conformitatea și la certificările și rapoartele sale.

Nivelurile și cât costă în Regatul Unit

Patru niveluri acoperă aproape orice site WordPress, iar granițele dintre ele sunt fixate de încărcarea care nu poate fi pusă în cache, nu de trafic. Intervalele de mai jos sunt ce plătesc de obicei cumpărătorii britanici pe lună. Sunt intervale de categorie, nu lista de prețuri a vreunui furnizor anume, așa că tratați-le ca pe o verificare de bun-simț a unei oferte, nu ca pe o ofertă.

Găzduire partajată, £3 la £15 pe lună

Perfect potrivită pentru un site de prezentare care poate fi pus în cache și un raport chiar prost dacă se autentifică cineva. Împărțiți capacitatea PHP cu vecini pe care nu îi vedeți, așa că sub încărcare mușcă variația, nu media. Verificați întâi ramura de PHP, fiindcă la acest nivel se adună interpretoarele ieșite din suport.

WordPress administrat, £20 la £400 pe lună

Alegerea implicită potrivită pentru site-uri de conținut și magazine mici. Cumpărați actualizări, staging, un firewall, un object cache persistent și o echipă de suport și plătiți pentru ele cu restricțiile de mai sus. Intervalul de la £20 la £100 acoperă un singur site cu trafic moderat. Peste asta plătiți de obicei pentru mai multe site-uri, mai multe vizite sau mai multe worker-e PHP.

VPS sau cloud cu stiva voastră, £15 la £120 plus administrare

O instanță cloud modestă costă £15 la £120 pe lună, dar mașina este partea ieftină. Cineva trebuie să peticească sistemul de operare, să regleze reverse proxy-ul, să țină object cache-ul și să se ocupe de backupuri, iar cumpărarea acestei munci costă încă £150 la £600 pe lună. Merită când încărcarea necache este reală sau când stiva voastră are cerințe pe care o platformă administrată le interzice.

Infrastructură la comandă, de la £400 pe lună în sus

Instalări pe mai multe regiuni, evenimente cu concurență mare, rezidență strictă a datelor sau o arhitectură în care WordPress este o componentă între altele. Găzduirea încetează să fie o decizie de produs și devine parte din construcție, exact felul în care o abordăm într-un proiect de dezvoltare web.

Dimensionare după cereri necache, nu după afișări de pagină

Planurile de găzduire se vând în vizite lunare fiindcă acesta e un număr pe care cumpărătorii îl recunosc. Este aproape inutil pentru planificarea capacității, fiindcă 100.000 de afișări anonime din cache nu costă mai nimic, în timp ce 10.000 de afișări autentificate pot satura un server mic.

Numărul care contează este cel al cererilor necache simultane, iar aritmetica e simplă. Un worker PHP tratează o cerere necache pe rând. Numărul de worker-e necesare este aproximativ vârful de cereri necache pe secundă înmulțit cu timpul mediu de răspuns al PHP în secunde. Douăzeci de cereri necache pe secundă, cu câte 400 de milisecunde fiecare, cer cam opt worker-e ca să țină pasul, iar vreți cel puțin încă jumătate din ele ca rezervă.

Puneți deci două întrebări la care nu răspunde nicio pagină de plan: câte worker-e PHP rulează acest plan și care este limita de memorie pentru fiecare proces? Ambele numere există și niciunul nu este publicat de obicei. Suportul vi le va spune în mod normal dacă întrebați direct, iar răspunsul spune mai mult despre plan decât orice test de pe pagină.

Apoi estimați cinstit partea voastră. Numărați proporția sesiunilor autentificate, traficul de finalizare a comenzii și de cont din ora voastră cea mai aglomerată în loc de cea medie și tot traficul admin-ajax sau REST pe care pluginurile voastre îl produc în fundal, invizibil în statistici și foarte vizibil într-un jurnal de server.

Numărul de pluginuri și volumul editorial sunt decizii de găzduire

Două lucruri din interiorul site-ului determină de câtă găzduire are nevoie, iar amândouă sunt tratate de obicei ca decizii de conținut luate de oameni care nu văd niciodată factura.

Primul este stiva de pluginuri. Fiecare plugin activ adaugă opțiuni încărcate automat la fiecare cerere, evenimente programate care pornesc la cererile vizitatorilor fiindcă cronul WordPress nu este un cron adevărat și interogări la fiecare construcție de pagină. Treizeci de pluginuri pe un site de prezentare din cache se suportă. Treizeci de pluginuri pe un magazin unde nu se pune nimic în cache înseamnă treizeci de pluginuri executate la fiecare pas al comenzii. Nucleul WordPress are o idee aproximativă despre momentul în care asta începe să doară: verificarea Starea site-ului pentru object cache-ul persistent sugerează object caching odată ce un site trece de praguri precum 2.000 de articole, 2.000 de utilizatori sau 600 de opțiuni încărcate automat.

Al doilea este volumul editorial. Reviziile se adună implicit fără limită, bibliotecile media ajung la zeci de mii de fișiere, cu mai multe dimensiuni generate fiecare, iar amândouă umflă baza de date și fereastra de backup. Un site care publică zilnic de cinci ani este o problemă de găzduire semnificativ diferită de același proiect care publică lunar, iar nimic din pagina planului nu reflectă asta. Auditarea construcției, nu a planului, este ce ar trebui să facă un dezvoltator WordPress înainte să ofere un preț pentru o migrare.

Alegerea, în ordine

Parcurgeți secvența aceasta și decizia se ia de obicei singură. Stabiliți ce proporție din traficul vostru nu poate fi pusă în cache, fiindcă acel singur număr vă alege nivelul. Confirmați că ramura de PHP și versiunea bazei de date ating baza publicată, fiindcă un plan care pică acolo este descalificat indiferent de preț. Stabiliți ce straturi de cache sunt incluse și pe care trebuie să le aduceți voi. Întrebați unde stau backupurile, în ce format și dacă puteți descărca unul astăzi. Apoi citiți clauzele despre împuternicit pentru subîmputerniciți, locul datelor și ștergerea la finalul contractului. Abia după toate acestea prețul înseamnă ceva, fiindcă până atunci comparați produse care nu sunt același produs.

Mecanik face asta ca lucrare cu preț fix înaintea oricărei migrări, de obicei alături de un proiect de dezvoltare web, și o preia ca suport continuu prin serviciul nostru de dezvoltator WordPress de închiriat. Dacă vă întrebați încotro se îndreaptă platforma însăși, articolul nostru despre WordPress 7.0 și clientul AI din nucleu merge bine alături de acesta.

Întrebări frecvente

Cât ar trebui să coste găzduirea WordPress în Regatul Unit? Depinde aproape în întregime de cât din traficul vostru poate fi pus în cache. Un site de prezentare cu vizitatori anonimi este bine servit la £3 la £15 pe lună pe găzduire partajată. Un site de conținut sau un magazin mic aparține de obicei găzduirii WordPress administrate, la £20 la £100 pe lună, urcând la £100 la £400 pentru planuri aglomerate sau multisite. Un magazin sau un site cu abonamente și trafic autentificat mare are nevoie de regulă de un VPS sau de o stivă cloud la £15 la £120 pentru mașină, plus £150 la £600 pe lună dacă o administrează altcineva.

Merită găzduirea WordPress administrată banii în plus? Merită dacă nu aveți un om de operare, fiindcă alegeți actualizări, staging, backupuri, un firewall și un object cache persistent pe care altfel le-ați configura singuri. Schimbul se face cu restricții reale. Furnizorii interzic în mod obișnuit pluginurile de cache, de backup și pe cele intensive pentru baza de date, rețin adesea accesul la consolă, plafonează procesele lungi și blochează poșta de ieșire. Verificați aceste limite față de instalarea voastră înainte să vă angajați, nu după.

De ce versiune de PHP are nevoie WordPress în 2026? WordPress recomandă PHP 8.3 sau mai nou. Rulează încă pe PHP 7.4 și peste, dar acele ramuri au ieșit din suport și nu primesc corecții de securitate. PHP 8.1 s-a încheiat la 31 decembrie 2025, PHP 8.0 la 26 noiembrie 2023 și PHP 7.4 la 28 noiembrie 2022, în timp ce PHP 8.2 este în regim doar de securitate până la 31 decembrie 2026. Circa 38,8 la sută dintre instalările WordPress raportează încă o ramură complet ieșită din suport.

O găzduire mai bună îmbunătățește Core Web Vitals? Doar una dintre cele trei și doar indirect. Timpul de răspuns al serverului face parte din Largest Contentful Paint, așa că o gazdă mai rapidă scade LCP pentru fiecare vizitator. Nu face aproape nimic pentru Cumulative Layout Shift, care vine din imagini fără dimensiuni și fonturi încărcate târziu, și foarte puțin pentru Interaction to Next Paint, dominat de JavaScript pe firul principal. Dacă răspunsul vostru de server este deja comod, problema rămasă este în pagină.

De ce este magazinul meu WooCommerce lent pe un plan care se declară rapid? Fiindcă paginile care contează nu pot fi puse în cache. WooCommerce cere ca paginile Coș, Contul meu și Finalizare comandă să rămână dinamice și setează cookie-uri de sesiune care ocolesc cache-ul de pagină pentru cumpărătorii autentificați. Testul de viteză pe prima voastră pagină măsoară un fișier din cache, în timp ce finalizarea comenzii execută PHP și lovește baza de date la fiecare cerere. Capacitatea pentru cererile necache, nu cifra primei pagini din cache, este ceea ce cumpără de fapt un magazin.