Infrastructura web profesională: dincolo de un simplu domeniu

01Un domeniu este o adresă, nu o casă

Când o afacere decide să «intre online», primul lucru cumpărat este aproape mereu un domeniu: numefirma.ro, câțiva euro pe an, și senzația că pasul a fost făcut. E un pas adevărat, dar e cel mai mic. Un domeniu este o adresă: îți spune unde să mergi, nu ce găsești când ajungi.

În spatele acelei adrese trebuie să existe un server, adică un calculator pornit zi și noapte într-un centru de date, care primește cererile vizitatorilor și răspunde cu paginile. El este casa. Și, ca la o casă adevărată, întrebările care contează sunt altele: cât de mare este, cine mai locuiește în ea cu tine, cât rezistă când sosesc o sută de musafiri în același timp, cine are cheile.

Între adresă și casă există o a treia piesă, DNS-ul: harta străzilor din Internet, care traduce numele scris de oameni în numărul (adresa IP) pe care îl înțeleg calculatoarele. Cum funcționează în detaliu domeniul, DNS-ul și certificatul HTTPS povestesc în capitolul despre ce se întâmplă când cineva îți scrie adresa. Aici ne interesează punctul de sosire: serverul.

Pentru o carte de vizită online, câteva pagini care se schimbă o dată pe an, casa poate fi mică. Pentru un portal de firmă, cu clienți care intră cu propriul cont, rezervări, plăți, un program de gestiune în spate și date personale de protejat, casa este piesa care ține totul. Și tocmai aici oferta «domeniu + hosting la câțiva euro» începe să nu mai ajungă.

02Hostingul partajat: un bloc cu pereți subțiri

Hostingul partajat este formula cea mai răspândită și cea mai ieftină: un singur server fizic găzduiește sute, uneori mii, de site-uri ale unor clienți diferiți. Fiecare are dosarul și spațiul lui, dar procesorul, memoria, discul și conexiunea sunt comune. Furnizorul se ocupă de tot: actualizări, securitatea serverului, e-mail, panou de control. Tu încarci fișierele și gata.

E ca un bloc de apartamente: costă puțin pentru că cheltuielile se împart, iar cineva are grijă de părțile comune. Dar pereții sunt subțiri. Dacă vecinul dă o petrecere, adică dacă alt site primește un vârf de vizite sau are un program scris prost care consumă tot procesorul, încetinești și tu, fără să fi făcut nimic. În jargon se numește efectul «vecinului zgomotos».

Când hostingul partajat e foarte bun

Nu e un produs de disprețuit: e un produs de folosit pentru ce a fost făcut. E foarte bun pentru:

• un site de prezentare cu câteva pagini, mai ales dacă e făcut din fișiere statice și nu interoghează o bază de date la fiecare vizită;
• un blog personal sau al unei afaceri mici, cu trafic constant și fără vârfuri;
• o pagină de destinație pentru o campanie sau un site de probă.

Limitele pe care le descoperi prea târziu

Problemele apar când îi ceri site-ului să devină o aplicație. Pe un hosting partajat, de obicei:

• nu instalezi programe după bunul plac: folosești versiunea de PHP și de MySQL oferită de furnizor, atunci când o oferă;
• există plafoane ascunse la procese simultane, memorie pe cerere, durata maximă a unui script, numărul de conexiuni la baza de date;
• lucrările programate (trimiterea e-mailurilor din timpul nopții, backupul, sincronizarea cu programul de gestiune) au limite de frecvență sau lipsesc cu totul;
• nu poți rula un serviciu pornit permanent, de exemplu un API în .NET sau în Node.js, ori un sistem de notificări în timp real;
• reputația adresei IP este comună: dacă un vecin trimite spam, e-mailurile domeniului tău pot ajunge în dosarul de spam. Vorbesc despre asta în capitolul despre e-mailul profesional de firmă.

03VPS-ul: un server al tău, fără să cumperi unul

Un VPS (Virtual Private Server, server privat virtual) este o felie dintr-un server fizic puternic, separată de celelalte de un program numit hypervisor. Hypervisorul face un singur lucru, și îl face riguros: dă fiecărei felii cota ei de procesor, de memorie și de disc și împiedică o felie să atingă resursele alteia. Pentru sistemul de operare care rulează înăuntru, felia aceea este un calculator întreg.

În practică, un VPS se descrie prin trei numere: vCPU (procesoarele virtuale), RAM și spațiul pe disc, aproape mereu pe discuri rapide SSD. O configurație ca 2 vCPU, 4 GB de memorie și 40 GB de disc susține liniștit un portal de firmă cu baza lui de date, un API și lucrările programate, cât timp traficul rămâne cel al unei afaceri locale sau regionale.

Cele patru avantaje care contează

Reversul medaliei: cheile le ai tu

Un VPS «negestionat» este o casă predată goală, cu cheile în mână. Furnizorul garantează că mașina e pornită și conectată; tot restul este responsabilitatea celui care o administrează:

• actualizările de securitate ale sistemului de operare și ale programelor;
• firewallul, adică ce porturi sunt deschise spre Internet și care nu;
• certificatele HTTPS și reînnoirea lor automată;
• backupurile, care trebuie să iasă din mașină: un backup care stă pe același server dispare odată cu el. Explic asta în capitolul despre backupul de firmă și regula 3-2-1;
• monitorizarea: să știi că site-ul s-a oprit înainte să ți-o spună un client, plus un serviciu care îl repornește singur.

De aceea adevărata întrebare nu este «hosting sau VPS», ci «VPS administrat de cine?». Un VPS lăsat de capul lui e mai puțin sigur decât un hosting partajat bun. Un VPS administrat cu metodă este cea mai solidă bază pe care o poate avea o firmă mică sau mijlocie, la o fracțiune din costul unui server dedicat.

04Linux sau Windows Server: cum alegi sistemul de operare

Pe VPS trebuie instalat un sistem de operare, iar alegerea se face o dată pentru ani de zile. Cele două familii sunt Linux (în distribuțiile pentru servere: Ubuntu Server, Debian, AlmaLinux, Rocky Linux) și Windows Server de la Microsoft. Nu e o chestiune de gust: depinde de ce trebuie să ruleze serverul.

Linux: alegerea firească pentru web

Marea majoritate a serverelor web din lume rulează pe Linux, din motive foarte concrete:

• stabilitate: un server Linux bine configurat rămâne pornit luni întregi; actualizările de securitate se instalează aproape mereu fără repornire;
• ușurință: fără interfață grafică, sistemul ocupă puțină memorie și lasă resursele aplicațiilor;
• ecosistemul web: PHP, MySQL și MariaDB, PostgreSQL, Python, Node.js, serverele web Nginx și Apache se nasc și se testează în primul rând pe Linux;
• nicio licență: sistemul e open source, nu plătești per procesor sau per utilizator;
• administrare de la distanță sigură cu SSH și chei criptografice, fără desktop la distanță expus pe Internet;
• securitate în straturi: permisiuni stricte pe fișiere și procese, firewall integrat, actualizări rapide de la comunități foarte mari.

Mitul de demontat: «.NET înseamnă Windows»

Până acum câțiva ani era adevărat. Astăzi nu mai e. Din 2016 Microsoft și-a rescris platforma ca .NET (numită înainte .NET Core), care rulează nativ pe Linux și este versiunea pe care se dezvoltă tot software-ul nou. Din 2017 există și SQL Server pentru Linux. O aplicație modernă în C# poate deci să stea pe un VPS Linux, cu aceleași avantaje de ușurință și cost ca un site în PHP.

Când Windows Server e cu adevărat indispensabil

• când există software scris pentru vechiul .NET Framework 4.x (WebForms, servicii WCF pe server), care există doar pentru Windows și nu se mută pe .NET fără să-l rescrii parțial;
• când firma folosește Active Directory ca să gestioneze utilizatorii, calculatoarele și permisiunile rețelei interne: controlerul de domeniu este un rol al Windows Server;
• când trebuie să rulezi programe de gestiune care există doar pentru Windows sau să faci mai multe persoane să lucreze pe un desktop la distanță comun;
• când îți trebuie o funcție din SQL Server care lipsește din versiunea pentru Linux (unele servicii auxiliare, cum sunt cele de rapoarte): se verifică de la caz la caz în documentația Microsoft.

În toate celelalte cazuri, Windows Server adaugă costul licențelor, mai multă memorie ocupată de sistem și o suprafață de atac mai mare, fără să dea nimic în schimb unui portal web.

05TTFB: cât așteaptă cine bate la ușă

TTFB (Time to First Byte, timpul până la primul byte) măsoară cât trece de când browserul cere o pagină până când sosește prima bucățică a răspunsului. Nu e timpul de încărcare completă: e timpul în care vizitatorul privește un ecran alb, așteptând ca serverul să înceapă să vorbească.

Google, în ghidul său pentru dezvoltatori, consideră bun un TTFB de 0,8 secunde sau mai puțin și slab unul peste 1,8 secunde. Fiecare milisecundă pierdută aici se adună la tot ce urmează: un server lent face lent chiar și cel mai ușor site.

Cum îl măsori, fără programe speciale

• În browser: deschide Instrumentele pentru dezvoltatori (tasta F12), fila Rețea, reîncarcă pagina și apasă pe primul rând. În secțiunea timpilor, intrarea «Se așteaptă răspunsul serverului» este partea din TTFB care depinde de server.
• Din linia de comandă: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://site-ul-tau.ro/ afișează secundele până la primul byte.
• Cu instrumente publice ca PageSpeed Insights, care arată și datele culese de la vizitatorii reali cu Chrome.

Ce scade TTFB, în ordinea eficienței

1. O bază de date proiectată bine: indexuri corecte și interogări care cer doar ce trebuie (vedem imediat).
2. Cache-ul: o pagină care e la fel pentru toți se calculează o dată și se livrează gata de o mie de ori.
3. Codul: mai puțină muncă inutilă la fiecare cerere, mai puține biblioteci încărcate degeaba.
4. Resursele rezervate: pe un VPS procesorul nu e disputat cu vecinii.
5. Apropierea: un server în Italia sau în Europa răspunde mai repede clienților din Italia sau din România decât unul de peste ocean.
6. Protocoalele moderne: HTTP/2 sau HTTP/3 și criptarea TLS 1.3 elimină pași din conexiune.

TTFB este doar prima dintre măsurile cu care Google evaluează experiența vizitatorului. Celelalte trei, cele care se văd în browser, le explic în capitolul despre Core Web Vitals.

06Baza de date: depozitul care decide viteza

De fiecare dată când un client intră în profilul lui, caută o disponibilitate sau se uită la o comandă, serverul pune întrebări bazei de date, adică depozitului ordonat în care stau toate datele. Cât îi ia să răspundă depinde mai puțin de puterea serverului și mult mai mult de felul în care e organizat depozitul.

Indexurile: diferența dintre a căuta și a găsi

Imaginează-ți că trebuie să găsești cuvântul «factură» într-o carte de o mie de pagini fără index alfabetic: trebuie să o răsfoiești toată. Cu indexul, mergi la litera F și găsești numărul paginii. Un index de bază de date face exact asta: în loc să citească toate rândurile unui tabel ca să găsească clienții dintr-un oraș, merge direct la cele potrivite.

Indexurile însă nu sunt gratuite: ocupă spațiu și încetinesc puțin scrierile, pentru că la fiecare dată nouă trebuie actualizate. Se pun pe coloanele folosite cu adevărat pentru a căuta, a filtra și a lega, nu pe toate, din prudență. A decide care este muncă de proiectare și se face privind întrebările reale pe care le va pune portalul.

Interogările: cere doar ce îți trebuie

O interogare (query) este întrebarea pe care programul o pune bazei de date. Același rezultat se poate cere în moduri foarte diferite, iar diferența de viteză poate fi de o sută de ori. Greșelile cele mai frecvente, pe care le găsești în multe site-uri lente:

• a cere toate coloanele (SELECT *) când ai nevoie de trei, transferând date inutile la fiecare cerere;
• problema numită «N+1»: ca să arate cincizeci de comenzi, codul pune o întrebare pentru listă și apoi cincizeci de întrebări separate, câte una pentru fiecare client, în loc de o singură întrebare care leagă cele două tabele;
• a filtra în program în loc de baza de date: descarci zece mii de rânduri ca să arăți zece;
• a nu te uita niciodată la jurnalul interogărilor lente, nici la planul de execuție (EXPLAIN), care îți spun exact unde se chinuie baza de date.

Sunt greșeli care nu se văd cât timp datele sunt puține și care explodează când afacerea crește: portalul care în ianuarie răspundea într-o zecime de secundă, în decembrie are nevoie de trei. De aceea calitatea codului sursă cântărește în performanța serverului cât puterea mașinii, și adesea mai mult: vorbesc despre asta în capitolul următor, dedicat valorii unui profesionist al codului și limitelor inteligenței artificiale și ale page builderelor.

07Cum alegi, de la caz la caz

Punând laolaltă tot ce am văzut, alegerea infrastructurii se reduce la câteva întrebări sincere despre ce va face portalul azi și peste doi ani.

Infrastructura este coloana vertebrală a tot ce vine după: portalul cu rezervări și PWA-ul, e-mailul de firmă, site-ul care trebuie să fie găsit. Un server ales bine nu se observă niciodată. Unul ales prost se observă mereu, de obicei în ziua cu cel mai mult de lucru.

Întrebări frecvente

Surse

1. web.dev (Google), «Time to First Byte (TTFB)»: definiția, fazele și pragurile de 0,8 și 1,8 secunde.
2. Microsoft Learn, «Instalarea .NET pe Linux» (în italiană): distribuțiile Linux suportate de .NET-ul modern.
3. Microsoft Learn, «Prezentare generală SQL Server pe Linux» (în italiană): SQL Server pentru Linux și funcțiile disponibile.
4. Manualul MySQL, «How MySQL Uses Indexes»: cum evită indexurile citirea completă a tabelelor.
5. Wikipedia, «Virtual private server» (în italiană): virtualizarea și hypervisorul.

Capitol actualizat în octombrie 2026. Pragurile și compatibilitățile citate provin din documentația oficială a producătorilor; timpii din planșe sunt exemple care arată proporțiile, nu măsurători ale unui anumit site.