Vreau ofertă
53 de termeni

Termeni de dezvoltare web și performanță

Cum e construit un site, pe ce rulează, ce îl face rapid sau lent și ce îl ține în siguranță. Fiecare termen are trei părți: ce este, de ce contează practic și greșeala frecventă sau metoda de verificare.

Partea pe care clientul o vede cel mai puțin și care decide cel mai mult. Pragurile de viteză din secțiunea de Core Web Vitals sunt cele oficiale, măsurate pe date reale de la vizitatori, nu în laborator.

Accesibilitate web WCAG

Proiectarea site-urilor astfel încât să poată fi folosite și de persoane cu deficiențe de vedere, auz sau motricitate, inclusiv cu cititoare de ecran sau doar de la tastatură. Reperul internațional este setul de recomandări WCAG. Practic înseamnă contrast suficient, texte alternative, structură corectă de titluri și formulare etichetate.

Publicul afectat este mai mare decât pare: nu doar persoane cu deficiențe permanente, ci și cineva care citește la soare, cu o mână ocupată, sau care navighează de la tastatură. Aceleași măsuri ajută și motoarele de căutare, pentru că structura corectă și textele alternative descriu explicit ce conține pagina.

Cum se verifică rapid: parcurge site-ul folosind doar tasta Tab și vezi dacă ajungi la toate elementele și dacă știi în orice moment unde te afli. Verifică apoi contrastul textului, textele alternative ale imaginilor și etichetele câmpurilor de formular. Sunt lucruri care se corectează la nivel de șablon, o singură dată.

API

Interfață prin care două aplicații schimbă date după reguli prestabilite, fără intervenție umană. Un magazin online poate trimite comenzile în programul de contabilitate sau poate prelua stocul de la furnizor prin API. Este fundamentul automatizărilor: elimină introducerea manuală a acelorași informații în mai multe sisteme.

Câștigul se măsoară în ore: comenzile intră singure în facturare, stocul se sincronizează cu depozitul, cursul valutar se actualizează fără intervenție. Se pierde, în schimb, exact în locurile unde datele se trec manual dintr-un sistem în altul, pentru că acolo apar întârzieri, greșeli de tastare și versiuni diferite ale aceleiași informații.

Cum se verifică înainte de a promite o integrare: cere documentația API a fiecărui sistem implicat și confirmă că există metode pentru operațiile de care ai nevoie, nu doar pentru citire. Verifică și limitele de apeluri. Ce se poate lega concret este descris la automatizări și integrări.

Backup

Copie de siguranță a fișierelor și a bazei de date ale unui site, păstrată separat de serverul de producție, care permite revenirea la o stare anterioară după o eroare, o actualizare eșuată sau o infectare. Este util doar dacă frecvența lui se potrivește ritmului de modificare a site-ului.

Un backup contează dacă este recent, dacă este păstrat în altă parte decât site-ul și dacă restaurarea a fost încercată măcar o dată. Copiile ținute pe același server dispar odată cu el, iar o copie de acum trei luni pentru un magazin înseamnă pierderea comenzilor din tot acest interval.

Cum se verifică: cere furnizorului o restaurare de test într-un mediu separat și cronometrează cât durează până când site-ul funcționează din nou. Întreabă câte versiuni se păstrează, cât de mult în urmă poți merge și unde anume sunt stocate. Ce include o schemă de copii care chiar funcționează — la mentenanță site web.

Bază de date

Sistem care stochează organizat informațiile unui site — produse, comenzi, utilizatori, articole — și le regăsește la cerere. Site-urile dinamice construiesc fiecare pagină interogând baza de date în momentul vizitei. Structura ei și indexarea corectă a câmpurilor influențează direct viteza site-ului la volume mari de date.

La volume mici nu observi nimic. Diferența apare la câteva zeci de mii de produse sau comenzi, când o pagină care se construia în milisecunde începe să dureze secunde, iar serverul cedează la trafic simultan. Cauza este aproape mereu aceeași: interogări care parcurg tot tabelul, pentru că lipsesc indecșii potriviți.

Cum se verifică: cere furnizorului de mentenanță raportul interogărilor lente de pe server, unde apar exact cererile care depășesc pragul configurat. Verifică separat și dimensiunea bazei. La WordPress crește necontrolat din revizii, date temporare și jurnale de pluginuri, iar o curățare periodică se simte în timpul de răspuns.

Cache

Păstrarea temporară a unui rezultat deja calculat, pentru a-l servi rapid la următoarea cerere în loc să fie regenerat. Există cache în browser, pe server și la nivel de CDN. Reduce mult timpul de încărcare, dar cere o strategie de invalidare, altfel vizitatorii pot vedea o versiune veche a conținutului.

Este optimizarea cu cel mai bun raport între efort și rezultat: o pagină generată o dată și servită de o mie de ori scade simultan timpul de răspuns și consumul serverului. Fără cache, fiecare vizitator plătește din nou același calcul, iar la trafic mare serverul cedează tocmai când ai mai multă nevoie de el.

Greșeala frecventă este cache-ul fără invalidare: modifici prețul unui produs și clientul vede ore întregi valoarea veche. Regula este simplă — orice publicare sau schimbare de preț golește automat cache-ul paginilor afectate. Verifică asta cerând o modificare de test și urmărind cât durează până se vede într-un browser fără istoric.

CDN

Rețea de servere distribuite geografic care păstrează copii ale fișierelor unui site — imagini, CSS, JavaScript — și le livrează de la locația cea mai apropiată de vizitator. Reduce timpul de încărcare pentru publicul aflat departe de serverul principal și absoarbe vârfurile de trafic. Multe servicii CDN filtrează și atacurile.

Câștigul este cu atât mai mare cu cât publicul este mai departe de server: un vizitator din altă țară primește imaginile de la un nod apropiat, nu de la o mie de kilometri distanță. În plus, la vârfuri de trafic sau la un atac, rețeaua preia cererile în locul serverului tău.

Greșeala frecventă este să tratezi CDN-ul ca pe o soluție universală de viteză. Dacă pagina este lentă pentru că serverul procesează greu, nu pentru că fișierele vin de departe, rețeaua de distribuție nu schimbă aproape nimic. Măsoară întâi timpul de răspuns al serverului, apoi decide dacă distanța chiar este problema.

CLS Cumulative Layout Shift

Indicator care măsoară deplasările neașteptate ale conținutului în timpul încărcării, atunci când textul sau butoanele sar din poziție pentru că o imagine, o reclamă sau un font se încarcă mai târziu. Valoarea considerată bună este sub 0,1. Se corectează rezervând din start spațiul elementelor care se încarcă ulterior.

Costul este direct: butonul pe care voiai să apeși se mută cu un rând și apeși altceva. Într-un magazin, asta înseamnă produse adăugate greșit și coșuri abandonate. Vinovații obișnuiți sunt imaginile fără dimensiuni declarate, bannerele inserate deasupra conținutului și fonturile care se schimbă la încărcare.

Cum se verifică: încarcă pagina pe o conexiune lentă simulată și urmărește ce sare din poziție. Reparația este aproape mereu aceeași — declari lățimea și înălțimea imaginilor și rezervi spațiul elementelor care vin mai târziu. Detaliile, cu exemple concrete, în ghidul despre Core Web Vitals.

CMS sistem de administrare a conținutului

Aplicație care permite adăugarea și modificarea conținutului unui site dintr-o interfață de administrare, fără a scrie cod. Separă textele și imaginile de structura tehnică, astfel încât o echipă de marketing poate publica singură. Exemple răspândite sunt WordPress, PrestaShop sau Shopify, fiecare potrivit unui alt tip de proiect.

Pentru o firmă, alegerea nu este între bine și rău, ci între cine actualizează conținutul și cât costă întreținerea. Un CMS îți dă autonomie asupra textelor, dar aduce actualizări obligatorii, pluginuri și o suprafață de atac mai mare. Un site fără CMS este mai rapid și mai sigur, însă orice modificare trece prin dezvoltator.

Greșeala frecventă este să alegi platforma înainte de a ști cine publică și cât de des. Dacă adaugi conținut o dată pe an, plătești administrare pentru o unealtă pe care nu o folosești. Am comparat cele două abordări, cu costuri și situații concrete, în site static sau WordPress.

Conținut mixt mixed content

Situația în care o pagină livrată prin https încarcă resurse — imagini, scripturi, stiluri — prin http, deci necriptat. Browserele blochează sau avertizează pentru aceste resurse, pentru că anulează garanția conexiunii securizate. Apare tipic după trecerea la https, dacă adresele vechi au rămas în conținut.

Efectul vizibil este că lacătul dispare sau apare cu avertisment, iar unele elemente nu se mai încarcă deloc. Un script blocat poate opri sliderul, validarea formularului sau urmărirea conversiilor, fără niciun mesaj de eroare. Vizitatorul vede un site care pare stricat și nesigur, exact după ce ai plătit pentru certificat.

Cum se verifică: deschide consola browserului pe câteva pagini importante și caută avertismentele de conținut mixt, care numesc exact fișierul vinovat. Sursele obișnuite sunt adresele http scrise direct în articole vechi, în descrierile de produs și în opțiunile temei, rămase de dinaintea trecerii la https. Vezi și securitate site web.

Core Web Vitals

Setul de indicatori prin care Google măsoară experiența reală de utilizare a unei pagini: LCP pentru viteza de afișare, INP pentru reacția la interacțiune și CLS pentru stabilitatea vizuală. Evaluarea se face pe date de teren, colectate de la utilizatori reali prin raportul CrUX, nu doar pe teste de laborator.

Pentru o firmă contează în două feluri: ca semnal folosit de Google și, mai important, ca măsură a comportamentului real al vizitatorilor. O pagină care se afișează greu sau care sare sub deget pierde oameni înainte de a apuca să le spună ceva, indiferent de poziția obținută în rezultate.

Pragurile considerate bune sunt LCP sub 2,5 secunde, INP sub 200 de milisecunde și CLS sub 0,1, evaluate pe datele de teren din CrUX, nu pe scorul de laborator. Cum se citesc corect, ce le strică cel mai des și ce se repară întâi — în ghidul despre Core Web Vitals.

CSP Content Security Policy

Antet prin care site-ul declară browserului din ce surse are voie să încarce scripturi, stiluri, imagini sau fonturi. Tot ce nu se află pe listă este blocat, chiar dacă a fost strecurat în pagină. Este principala apărare împotriva execuției de cod străin într-o pagină compromisă.

Diferența se vede la un atac de tip cross-site scripting: fără o astfel de politică, un script introdus printr-un comentariu sau printr-un plugin vulnerabil rulează cu toate drepturile paginii și poate citi ce completează utilizatorul în formular. Cu o politică strictă, browserul refuză să îl execute, chiar dacă a ajuns în cod.

Greșeala frecventă este o politică scrisă atât de permisiv încât nu mai blochează nimic, doar ca să nu strice widgeturile existente. Pornește în modul de raportare, adună câteva zile ce ar fi fost blocat, apoi restrânge lista. Sursele externe pe care le tot adaugi sunt, de fapt, lista dependențelor tale reale. Vezi securitate site web.

CSS

Limbajul care descrie cum arată elementele unei pagini web: culori, spațiere, tipografie, poziționare și comportamentul la dimensiuni diferite de ecran. Separă aspectul de conținut, astfel încât un singur fișier poate schimba înfățișarea întregului site. Tot prin CSS se construiește design-ul responsiv, fără a modifica structura HTML.

Pentru o firmă, avantajul este costul modificărilor: o schimbare de culoare, de font sau de spațiere se face într-un singur loc și se propagă peste tot. Dezavantajul apare când foaia de stil crește necontrolat, cu reguli adăugate de la un plugin la altul. Browserul trebuie să descarce și să proceseze tot, înainte de a afișa ceva.

Greșeala frecventă este să rezolvi fiecare problemă vizuală adăugând o regulă nouă peste cele existente, adesea marcată ca prioritară. După un an, fișierul are zeci de kilobiți de reguli care se anulează reciproc și nimeni nu mai îndrăznește să șteargă ceva. Curățarea periodică a stilurilor nefolosite scade greutatea paginii și scurtează timpul până la prima afișare.

CSS critic

Porțiunea minimă de stiluri necesară pentru afișarea corectă a părții de sus a paginii, livrată direct în HTML, astfel încât browserul să poată desena ceva fără să aștepte descărcarea foii de stil complete. Restul stilurilor se încarcă apoi, fără să blocheze afișarea.

Foaia de stil este o resursă care blochează randarea: până nu este descărcată și procesată, browserul nu afișează nimic, chiar dacă HTML-ul a ajuns deja. Cu stilurile critice puse direct în pagină, primul conținut apare cu una-două cereri de rețea mai devreme, iar LCP se îmbunătățește fără nicio schimbare de design.

Site-ul acesta este construit static, cu CSS critic livrat direct în pagină, tocmai din acest motiv. Greșeala frecventă este să incluzi tot fișierul de stil în HTML, crezând că este același lucru: atunci fiecare pagină cară zeci de kilobiți repetați, care nu se mai pot păstra în cache. Vezi optimizare viteză site.

Design responsiv

Metodă de construcție prin care aceeași pagină își reorganizează automat structura în funcție de lățimea ecranului, de la telefon la monitor mare. Se realizează prin grile flexibile, imagini scalabile și reguli CSS aplicate la praguri de dimensiune. Este necesar pentru că majoritatea traficului vine de pe dispozitive mobile.

Google evaluează versiunea mobilă a paginii, iar de acolo vin și cei mai mulți vizitatori. Un site care pe telefon cere mărire ca să fie citit, are butoane prea apropiate sau tabele care ies din ecran pierde oameni înainte de a fi citit. Nu este o chestiune de estetică, ci de contacte care nu se mai întâmplă.

Cum se verifică: deschide site-ul pe telefon și parcurge traseul complet până la formularul de contact sau la finalizarea comenzii, cu o singură mână. Urmărește dacă textul se citește fără mărire, dacă butoanele sunt suficient de mari și dacă nimic nu depășește lățimea ecranului. Vezi realizare site web.

Disponibilitate uptime

Proporția din timp în care un site este accesibil și răspunde corect vizitatorilor. Se măsoară din exterior, prin verificări automate la interval regulat, și se exprimă de obicei ca procent dintr-o lună. Contează la fel de mult ce anume se verifică: o pagină care se încarcă nu înseamnă că formularul funcționează.

O pană nedetectată costă în două feluri: comenzile din acel interval, care nu se recuperează, și accesările pierdute ale motoarelor de căutare, dacă indisponibilitatea se repetă. Diferența dintre a afla de la un client supărat și a afla de la un sistem de monitorizare este, de obicei, de câteva ore bune.

Cum se verifică: pune monitorizare care testează nu doar pagina principală, ci și o pagină generată dinamic și, la magazin, pasul de finalizare a comenzii, cu alertă pe telefon. Cere apoi raportul lunar de la furnizor și compară-l cu propriile măsurători, făcute din altă rețea decât a lui.

DNS

Sistemul care traduce numele de domeniu în adresa IP a serverului pe care se află site-ul. Tot prin înregistrările sale se dirijează e-mailul și se validează servicii externe. Modificările nu se propagă instantaneu: în funcție de valoarea TTL configurată, pot trece de la câteva minute la câteva ore până sunt vizibile peste tot.

Consecința practică apare la fiecare mutare. Dacă schimbi găzduirea fără să pregătești înregistrările, site-ul și e-mailul pot fi indisponibile ore bune, iar în tot acest timp o parte dintre vizitatori ajung pe serverul vechi și alta pe cel nou. Este o pană complet evitabilă, dar foarte des întâlnită.

Cum se verifică: cu o zi înainte de mutare scazi TTL-ul la câteva minute, ca schimbarea să se propage repede. După modificare, interoghează serverele DNS din mai multe rețele și compară răspunsurile. Ce înregistrări există și cum se leagă de găzduire este explicat în ghidul despre domeniu și găzduire.

Domeniu

Adresa în cuvinte prin care un site este accesat, de exemplu dianys.ro, tradusă în adresa numerică a serverului prin DNS. Se închiriază anual de la un registrar și rămâne al titularului atâta timp cât este reînnoit. Domeniul aparține proprietarului afacerii, nu furnizorului de găzduire sau agenției.

Este singurul element al prezenței online pe care nu îl poți reface: dacă expiră și este înregistrat de altcineva, pierzi și adresa, și pozițiile construite pe ea ani întregi. Domeniul stă pe numele cuiva, iar acel cineva trebuie să fie firma ta, nu persoana care ți-a făcut cândva site-ul.

Cum se verifică: caută domeniul într-un serviciu WHOIS și confirmă datele titularului și data expirării. Asigură-te că ai acces la contul de la registrar, nu doar la panoul de găzduire. Criteriile de alegere și greșelile care se plătesc mult mai târziu sunt în ghidul despre domeniu și găzduire.

Firewall aplicativ WAF

Filtru care analizează traficul către un site și blochează cererile cu tipar de atac, precum injecțiile SQL sau încercările repetate de autentificare, înainte ca acestea să ajungă la aplicație. Nu înlocuiește actualizările, dar reduce fereastra de risc pentru vulnerabilitățile încă nereparate.

Practic, îți cumpără timp: între momentul în care o vulnerabilitate devine publică și cel în care aplici corecția trec de obicei zile, iar scanările automate încep în câteva ore. În plus, oprește o parte din traficul automat abuziv, care consumă resursele serverului fără să aducă niciun vizitator real.

Greșeala frecventă este să îl consideri suficient și să amâni actualizările. Filtrele lucrează pe tipare cunoscute, deci un atac țintit sau o vulnerabilitate în propriul cod trec de ele. Ce protejează fiecare strat și în ce ordine merită implementate — în articolul despre riscurile reale de securitate.

Font self-hosted

Font livrat de pe propriul server, în loc să fie încărcat de la un serviciu extern precum Google Fonts. Fișierele stau alături de restul site-ului, sunt servite pe aceeași conexiune și nu depind de disponibilitatea unui terț sau de o conexiune suplimentară către alt domeniu.

Câștigul este dublu. Tehnic, elimini o conexiune către alt domeniu, deci fontul ajunge mai repede și textul se afișează fără pauză, ceea ce se vede în LCP și în stabilitatea vizuală. Juridic, nu mai transmiți adresa IP a vizitatorului unui furnizor extern la fiecare încărcare, ceea ce simplifică discuția despre consimțământ.

Site-ul acesta folosește fonturi găzduite local, exact din aceste motive. Greșeala frecventă este să descarci familia întreagă, cu toate grosimile și seturile de caractere, și să o urci pe server: ajungi să livrezi mai mult decât livra serviciul extern. Păstrează două grosimi, formatul woff2 și setul latin cu diacritice românești.

Framework

Set de biblioteci și convenții care oferă o structură gata făcută pentru dezvoltarea unei aplicații: rutare, tratarea formularelor, securitate de bază, organizarea codului. Scurtează timpul de dezvoltare și impune practici comune într-o echipă, în schimbul acceptării regulilor sale. Exemple din zona web sunt Laravel, Symfony, React sau Next.js.

Pentru o firmă care comandă o aplicație, alegerea framework-ului decide cât de ușor se găsește altcineva care să continue lucrarea. Un framework răspândit înseamnă documentație, oameni disponibili și componente deja scrise. Un cod construit pe unelte exotice sau pe o bibliotecă proprie a furnizorului te leagă practic de acel furnizor.

Cum se verifică: cere în contract numele exact al tehnologiilor folosite și versiunile lor, plus accesul la depozitul de cod. Dacă răspunsul rămâne vag sau codul stă doar la furnizor, riști să nu poți muta proiectul. Întreabă și cât timp mai primește versiunea folosită actualizări de securitate.

Găzduire web

Serviciul prin care fișierele și baza de date ale unui site sunt stocate pe un server conectat permanent la internet. Variază de la găzduire partajată, unde resursele sunt împărțite cu alte site-uri, până la servere dedicate. Alegerea influențează viteza, disponibilitatea și capacitatea de a susține creșterea traficului.

Pe găzduire partajată împarți procesorul și memoria cu alte site-uri, deci un vecin cu trafic mare îți încetinește paginile. Diferența de câțiva euro pe lună între planuri se traduce des în secunde de încărcare și în minute de indisponibilitate. Contează mai mult decât prețul viteza discului, versiunea de PHP și calitatea suportului.

Verifică oricum două lucruri înainte de plată: ce copii de siguranță include planul și dacă poți muta site-ul altundeva fără să depinzi de bunăvoința furnizorului actual. Cum alegi concret, ce întrebi înainte de a semna și cum recunoști o ofertă care pare ieftină doar în primul an — în ghidul despre domeniu și găzduire.

Headless CMS

Sistem de administrare a conținutului care stochează și livrează doar datele, prin API, fără să impună felul în care sunt afișate. Același conținut poate alimenta un site, o aplicație mobilă și un ecran din magazin. Oferă libertate tehnică, dar cere dezvoltare separată pentru partea vizibilă utilizatorului.

Are sens când același conținut trebuie afișat în mai multe locuri sau când vrei ca partea vizibilă să fie complet independentă de platformă, deci ușor de reconstruit fără a muta datele. Pentru un site de prezentare obișnuit, adaugă în general complexitate și cost, fără un câștig proporțional pentru firmă.

Greșeala frecventă este alegerea lui pentru că sună modern, urmată de descoperirea că nimic din ce venea gratuit într-un CMS clasic nu mai vine din cutie: formularele, previzualizarea, meniurile, redirectările. Întreabă înainte cine construiește și cine întreține partea vizibilă și ce se întâmplă cu proiectul dacă acea echipă pleacă.

HSTS

Antet trimis de server prin care site-ul îi comunică browserului să folosească de acum înainte exclusiv conexiune securizată, pentru o perioadă declarată. După prima vizită, browserul nu mai încearcă varianta http nici dacă utilizatorul o tastează, ci trece direct la https.

Închide fereastra dintre momentul în care cineva scrie adresa fără https și redirectarea către varianta securizată, adică intervalul în care o cerere poate fi interceptată într-o rețea publică. Elimină și o cerere inutilă la fiecare vizită, deci are un efect mic, dar real, asupra timpului de încărcare.

Greșeala frecventă este activarea cu o durată lungă înainte ca totul să funcționeze pe https, inclusiv subdomeniile. Dacă apoi ceva rămâne fără certificat valid, vizitatorii nu mai pot ajunge acolo până expiră perioada declarată, iar tu nu poți anula rapid. Pornește cu o valoare mică și crește-o după ce ai verificat tot.

HTML

Limbajul de marcare în care este scrisă structura oricărei pagini web: titluri, paragrafe, liste, imagini, linkuri și formulare. Nu se ocupă de aspect, ci de sensul fiecărui element. Marcajele potrivite pentru rolul lor ajută atât cititoarele de ecran, cât și motoarele de căutare să înțeleagă ce conține pagina.

Consecința practică se vede în două locuri. Un site construit din blocuri generice, fără marcaje cu sens, pierde tocmai structura pe care Google o folosește ca să înțeleagă ierarhia informației. Iar utilizatorii care navighează de la tastatură sau cu cititor de ecran rămân blocați. Un titlu marcat corect și o listă marcată ca listă nu costă nimic în plus la implementare.

Cum se verifică: deschide pagina și afișează sursa sau inspectează elementele. Uită-te dacă există un singur H1, dacă subtitlurile coboară în ordine, dacă imaginile au atribut alt și dacă butoanele sunt butoane reale, nu imagini pe care s-a legat un eveniment. Sunt verificări de câteva minute, făcute o dată pe fiecare tip de șablon.

HTTP/2 și HTTP/3

Versiunile moderne ale protocolului prin care browserul cere fișierele unui site. HTTP/2 permite transferul mai multor fișiere în paralel, pe o singură conexiune. HTTP/3 schimbă și modul de transport, ceea ce reduce timpul pierdut la reconectare, mai ales pe rețele mobile instabile.

Pentru tine este o setare a găzduirii, nu o modificare de cod: dacă serverul le suportă, câștigul apare imediat pe paginile cu multe fișiere. În schimb, unele optimizări vechi, gândite pentru HTTP/1.1 — combinarea tuturor stilurilor într-un singur fișier uriaș, imaginile lipite într-o planșă comună — devin inutile sau chiar dăunătoare.

Cum se verifică: deschide panoul de rețea din instrumentele de dezvoltare ale browserului și afișează coloana de protocol, unde vezi h2 sau h3 pentru fiecare cerere. Dacă apare http/1.1, întreabă furnizorul de găzduire dacă se poate activa. De obicei se poate, fără cost suplimentar și fără intervenție în site.

INP Interaction to Next Paint

Indicator care măsoară cât durează până pagina răspunde vizibil la o interacțiune a utilizatorului — un clic, o atingere sau o tastă — luând în calcul toate interacțiunile din vizită. Valoarea considerată bună este sub 200 de milisecunde. A înlocuit indicatorul FID în martie 2024.

Măsoară senzația de site care nu răspunde: apeși și nu se întâmplă nimic. Cauza obișnuită este JavaScript-ul care ține browserul ocupat — scripturi de urmărire, ferestre de chat, bannere de cookies, carusele. Se simte mai ales pe telefoanele de gamă medie, adică exact pe dispozitivele majorității vizitatorilor.

Fiind mai sever decât indicatorul pe care l-a înlocuit, pentru că ia în calcul toate interacțiunile dintr-o vizită, nu doar prima, trebuie urmărit pe datele de teren, nu în laborator, unde interacțiunea nici nu are loc. Ce scripturi merită amânate, încărcate mai târziu sau eliminate — în ghidul despre Core Web Vitals.

JavaScript

Limbajul de programare care rulează în browser și face paginile interactive: meniuri care se deschid, formulare validate în timp real, conținut încărcat fără reîncărcarea paginii. Se poate executa și pe server. Folosit în exces, întârzie afișarea și reacția paginii, ceea ce se vede direct în indicatorii de performanță.

Costul lui nu stă în kilobiți, ci în timp de procesare: browserul trebuie să descarce, să interpreteze și să execute codul, iar pe telefoanele mai vechi asta durează. Un site încărcat cu scripturi de urmărire, widgeturi de chat și carusele răspunde cu întârziere la atingere, ceea ce se măsoară direct în INP.

Cum se verifică: deschide site-ul pe un telefon obișnuit, nu pe cel mai bun din birou, și încearcă să apeși un buton imediat ce apare pagina. Dacă nu se întâmplă nimic o secundă, ai prea mult JavaScript la încărcare. În PageSpeed Insights, diagnosticul arată ce fișiere consumă acel timp de execuție.

Lazy loading

Tehnică prin care imaginile și alte elemente grele se încarcă abia când vizitatorul ajunge aproape de ele prin derulare, nu la deschiderea paginii. Reduce volumul descărcat inițial și grăbește afișarea. Nu trebuie aplicată imaginii principale din partea de sus a paginii, pentru că ar întârzia tocmai elementul măsurat de LCP.

Efectul cel mai mare apare pe pagini lungi, cu multe imagini: liste de produse, galerii, articole ilustrate. Un vizitator care nu derulează până jos nu descarcă niciodată jumătate din imagini, deci pagina se afișează mai repede, iar consumul de date scade — ceea ce contează pe conexiuni mobile slabe.

Greșeala frecventă este aplicarea ei la toate imaginile, inclusiv la cea din partea de sus. Atunci amâni exact elementul pe care îl măsoară LCP și înrăutățești indicatorul pe care voiai să îl repari. Regula practică: imaginile vizibile fără derulare se încarcă normal, restul se amână.

LCP Largest Contentful Paint

Indicator care măsoară cât durează până se afișează cel mai mare element vizibil din partea de sus a paginii, de obicei o imagine sau un bloc mare de text. Este pragul la care vizitatorul simte că pagina s-a încărcat. Valoarea considerată bună este sub 2,5 secunde.

Fiind momentul în care vizitatorul simte că pagina s-a încărcat, pragul de 2,5 secunde nu este o formalitate tehnică. Cauzele obișnuite sunt puține și repetitive: un server care răspunde lent, o imagine mare neoptimizată în partea de sus a paginii, fonturi sau foi de stil care blochează afișarea.

Cum se verifică: în PageSpeed Insights, secțiunea de date de teren arată valoarea reală, iar diagnosticul îți spune care element a fost măsurat efectiv ca LCP. De cele mai multe ori este imaginea principală. Ce faci concret cu ea și în ce ordine — în ghidul despre Core Web Vitals.

Machetă mockup

Reprezentarea vizuală finală a unei pagini, cu design, culori, tipografie și conținut real, așa cum va arăta după implementare. Vine după wireframe și înainte de scrierea codului, servind ca reper agreat între client și echipa de dezvoltare. Este statică: nu include funcționalitate, ci doar aspectul.

Este documentul pe baza căruia se aprobă aspectul, deci trebuie să conțină conținut real, nu text de umplutură. Un titlu inventat, de trei cuvinte, arată perfect în machetă și se rupe la titlul real, de douăsprezece cuvinte. La fel se întâmplă cu fotografiile alese frumos, dar diferite de cele pe care le ai efectiv.

Cum se verifică înainte de aprobare: cere să vezi macheta cu cel mai lung titlu real, cu cea mai lungă descriere de produs și în varianta pentru telefon. Cere și starea de eroare a formularului, și pagina fără rezultate. Acolo apar problemele, nu în ecranul frumos de prezentare.

Malware

Cod rău intenționat introdus într-un site pentru a fura date, a insera linkuri și redirectări ascunse sau a trimite spam. Ajunge de obicei prin pluginuri neactualizate, parole slabe sau conturi compromise. Consecința vizibilă este pierderea traficului: browserele și Google marchează site-ul ca periculos.

Efectul nu este doar tehnic. Odată marcat, traficul se prăbușește în câteva zile, iar ieșirea din listele de avertizare durează și după curățare. Dacă infecția a fost folosită pentru redirectări sau pentru pagini de spam, pot suferi și pozițiile construite ani întregi, nu doar disponibilitatea site-ului.

Cum se verifică: în Google Search Console există un raport de probleme de securitate; deschide-l periodic, nu doar când se întâmplă ceva. Semnele obișnuite sunt fișiere modificate recent fără motiv și conturi de administrator pe care nu le recunoști. Cum ajunge codul acolo — în articolul despre riscurile reale de securitate.

Mediu de test staging

Copie separată a site-ului, cu aceleași fișiere și date, pe care se fac modificările și actualizările înainte de a ajunge la vizitatori. Nu este accesibilă publicului și nu trebuie indexată de motoarele de căutare. Se folosește pentru a vedea ce se strică, fără ca cineva din afară să observe.

Fără ea, orice actualizare de plugin sau modificare de șablon este un experiment făcut direct pe clienți. Un magazin care își pierde butonul de finalizare a comenzii pentru două ore într-un weekend pierde exact comenzile din acel interval, iar revenirea la copia de siguranță aduce înapoi și problema pe care voiai să o rezolvi.

Greșeala frecventă este mediul de test lăsat public și indexabil: ajunge în Google, concurează cu site-ul real ca și conținut duplicat, iar formularele lui trimit e-mailuri adevărate. Protejează-l cu parolă la nivel de server și verifică, la fiecare lansare, că directiva noindex a rămas acolo și nu a migrat pe site-ul live.

Mentenanță

Activitatea periodică prin care un site rămâne funcțional și sigur: actualizarea platformei și a extensiilor, verificarea copiilor de siguranță, monitorizarea disponibilității, corectarea linkurilor rupte și a erorilor. Este necesară pentru că vulnerabilitățile apar continuu în componentele folosite, iar un site nesupravegheat devine în timp o țintă ușoară.

Costul absenței ei este asimetric: nu se întâmplă nimic luni de zile, apoi se întâmplă tot deodată — site infectat, actualizare care rupe o funcție, certificat expirat, formulare care nu mai trimit. Refacerea după un incident costă de regulă mai mult decât ar fi costat supravegherea în tot acel interval.

Cum se verifică ce primești: cere un raport lunar cu ce s-a actualizat, când s-au făcut copiile de siguranță, ce erori au apărut și cât a fost disponibil site-ul. Dacă nu există raport, nu există nici dovada că s-a lucrat. Ce intră concret — la mentenanță site web.

Migrare site

Mutarea unui site pe altă platformă, alt domeniu, altă structură de adrese sau alt server. Riscul principal este pierderea pozițiilor din căutare, dacă adresele vechi rămân fără corespondent. Se gestionează cu o hartă completă a redirectărilor 301, făcută înainte de lansare, nu după.

Când adresele vechi rămân fără corespondent, dispar din index atât paginile, cât și valoarea linkurilor primite din exterior de-a lungul anilor. Scăderea nu este imediat vizibilă: se observă des abia după câteva săptămâni, când numărul de cereri sau de comenzi scade fără o explicație aparentă.

Verificarea nu se încheie în ziua lansării: urmărește indexarea și erorile 404 în Google Search Console în primele săptămâni și compară, adresă cu adresă, lista celor vechi cu destinațiile noi. Pașii, în ordine, și ce se verifică înainte de a comuta efectiv — la migrare site web.

Minificare

Eliminarea din fișierele CSS, JavaScript și HTML a tot ce nu este necesar execuției: spații, indentare, comentarii, nume lungi de variabile. Codul devine ilizibil pentru om, dar identic ca efect pentru browser, iar fișierul scade de obicei cu o parte însemnată din greutatea inițială.

Este o optimizare ieftină, automată și fără risc pentru design: se face la publicare, dintr-o unealtă de build sau dintr-un plugin, și nu cere nicio decizie. Câștigul se simte mai ales pe conexiuni mobile lente, unde fiecare kilooctet economisit contează, și se adună cu compresia făcută de server la transfer.

Greșeala frecventă este să te oprești aici și să consideri viteza rezolvată. Minificarea taie spații, nu funcționalitate: un fișier de trei sute de kilobiți de JavaScript nefolosit rămâne, și minificat, un fișier pe care browserul trebuie să îl descarce și să îl execute. Elimină întâi ce nu folosești, apoi minifică restul.

Mobile first

Abordare de proiectare în care interfața se gândește întâi pentru ecranul mic și abia apoi se extinde pentru ecrane mari. Obligă la prioritizarea conținutului esențial și la performanță, pentru că spațiul și resursele sunt limitate. Se aliniază și cu indexarea Google, care evaluează versiunea mobilă a paginii.

Ordinea în care lucrezi schimbă rezultatul final. Dacă pornești de la desktop și comprimi apoi, ajungi cu un telefon plin de elemente ascunse care se descarcă totuși. Dacă pornești de la ecranul mic, ești obligat să decizi ce este esențial, iar pagina rămâne ușoară și pe restul dispozitivelor.

Greșeala frecventă este să ascunzi din CSS blocuri întregi pe mobil, crezând că le-ai eliminat. Ele se descarcă în continuare și consumă același timp. Verifică ce se încarcă efectiv pe telefon, nu ce se vede: dacă un carusel de zece imagini este doar ascuns, imaginile lui tot ajung la vizitator.

PageSpeed Insights

Instrument gratuit de la Google care analizează o pagină și raportează atât datele de teren din CrUX, adică măsurători de la utilizatori reali, cât și un test de laborator cu recomandări concrete de optimizare. Scorul de laborator este orientativ; evaluarea Core Web Vitals se face pe datele de teren.

Diferența dintre cele două seturi de date este sursa celor mai multe confuzii. Scorul colorat din partea de sus vine dintr-un test de laborator, pe un dispozitiv simulat, la un moment dat. Datele de teren vin din CrUX, adică din vizitele reale ale utilizatorilor, adunate pe o perioadă mai lungă.

Greșeala frecventă este vânătoarea scorului de 100. Un site poate trece pragurile pe datele de teren cu un scor de laborator mediocru și invers. Urmărește secțiunea de date reale și rezolvă problemele în ordinea impactului. Cum se citește raportul — în ghidul despre Core Web Vitals.

Preload

Indicație dată browserului să descarce din timp o resursă de care va avea nevoie sigur, dar pe care altfel ar descoperi-o târziu: fontul principal, imaginea din partea de sus a paginii sau un fișier de stil referit din alt fișier. Se declară în HTML, printr-un element link.

Browserul descoperă resursele pe măsură ce citește pagina, deci un font referit dintr-un fișier CSS ajunge la rând abia după ce acel CSS a fost descărcat și procesat. Declarat din timp, poate scurta lanțul cu câteva sute de milisecunde din LCP, fără nicio modificare vizibilă în design sau în conținut.

Greșeala frecventă este să declari zece resurse ca prioritare. Dacă totul este prioritar, nimic nu mai este: cererile se luptă pentru aceeași lățime de bandă, iar elementul care conta întârzie. Două-trei resurse, alese pe baza a ce raportează PageSpeed Insights ca element LCP, sunt de obicei suficiente.

PWA Progressive Web App

Site care folosește tehnologii de browser pentru a se comporta ca o aplicație: poate fi instalat pe ecranul telefonului, pornește dintr-o iconiță, funcționează parțial fără conexiune și poate trimite notificări. Rămâne totuși un site, accesibil de la o adresă web, fără trecere prin magazinele de aplicații.

Avantajul practic este că eviți costul unei aplicații native duble, pentru iOS și Android, și procesul de aprobare din magazine. Actualizarea se face publicând pe site, deci toți utilizatorii au imediat ultima versiune. Are sens acolo unde oamenii revin des: comenzi repetate, urmărirea unui cont, conținut consultat zilnic.

Greșeala frecventă este să presupui că oamenii o vor instala. Rata de instalare rămâne mică dacă nu există un motiv clar de revenire, iar suportul pentru notificări diferă între sisteme de operare. Înainte de investiție, uită-te în statistici câți vizitatori revin lunar; dacă aproape nimeni nu revine, o aplicație nu schimbă asta.

REST

Stil de proiectare a interfețelor API în care fiecare resursă are propria adresă, iar operațiile se exprimă prin metodele HTTP: GET pentru citire, POST pentru creare, PUT pentru modificare, DELETE pentru ștergere. Datele circulă de obicei în format JSON. Simplitatea și larga lui răspândire îl fac ușor de integrat cu aproape orice platformă.

Fiind un stil larg răspândit, aproape orice platformă serioasă expune o interfață REST, deci integrările nu mai cer dezvoltare de la zero de fiecare parte. Pentru tine înseamnă că un magazin, un program de contabilitate și o firmă de curierat pot fi legate între ele, fără ca vreunul să fi fost gândit special pentru celelalte.

Greșeala frecventă este să presupui că „are API REST” înseamnă că integrarea va fi simplă. Contează ce operații sunt expuse, cum se face autentificarea, ce limite de apeluri există și dacă furnizorul anunță din timp schimbările de versiune. Cere un cont de test și încearcă un apel real înainte de a semna.

Server

Calculator care rulează permanent și livrează fișierele și paginile unui site către browserele vizitatorilor. Resursele lui — procesor, memorie, tip de stocare — și distanța geografică față de utilizatori determină timpul de răspuns. Un server subdimensionat se vede mai ales la trafic simultan mare, când paginile încep să se încarce lent.

Un server subdimensionat costă vizibil: timp mare până la primul octet, pagini lente la ore de vârf, uneori erori afișate unor vizitatori care ar fi cumpărat. Un server supradimensionat, în schimb, nu grăbește un site prost construit. Dacă pagina cere trei secunde de procesare, hardware-ul mai bun scurtează doar o parte din ele.

Cum se verifică: urmărește timpul de răspuns al serverului în raportul de statistici de accesare din Google Search Console și în diagnosticul din PageSpeed Insights. Dacă răspunsul este lent constant, nu doar la vârfuri de trafic, problema ține de configurare sau de resurse, nu de numărul de vizitatori.

Site static

Site ale cărui pagini sunt generate în prealabil ca fișiere HTML și servite ca atare, fără interogări la baza de date la fiecare vizită. Rezultă timpi de încărcare foarte mici și o suprafață de atac redusă. Potrivit pentru site-uri de prezentare și blog; conținutul se actualizează prin regenerare, nu în timp real.

Pentru un site de prezentare, diferența practică se vede la viteză, la costul găzduirii și la timpul de mentenanță: nu ai bază de date de protejat și nu ai pluginuri de actualizat lunar. În schimb, funcțiile care cer prelucrare pe server, precum coșul, contul de client sau căutarea complexă, se rezolvă prin servicii externe.

Greșeala frecventă este să presupui că static înseamnă că nu mai poți modifica textele singur. Conținutul se poate edita tot dintr-o interfață; diferența este că paginile se regenerează după salvare, în loc să fie construite la fiecare vizită. Comparația completă, cu costuri reale, este în site static sau WordPress.

SLA acord de nivel al serviciului

Document contractual care stabilește nivelul de serviciu garantat: în cât timp se răspunde la o sesizare, în cât timp se intervine, în ce interval orar, ce disponibilitate se asigură și ce se întâmplă dacă valorile nu sunt respectate. Fără el, cuvântul „suport” din ofertă nu obligă la nimic.

Diferența practică apare într-o zi proastă, nu în ziua semnării. Când magazinul nu mai funcționează sâmbătă seara, contează dacă în contract sunt scrise un interval de intervenție și un canal prin care anunți, sau dacă rămâi cu un e-mail la care se răspunde luni dimineața, după ce ai pierdut weekendul.

Cum se verifică înainte de semnare: cere să fie scrise separat timpul de răspuns și timpul de rezolvare, programul acoperit, canalul oficial de sesizare și ce excepții există. Întreabă și cum se dovedește o pană — cine măsoară disponibilitatea și pe ce date se întocmește raportul lunar.

SSL certificat de securitate

Certificatul care permite conexiunea criptată între browser și server, afișată ca adresă https. Împiedică interceptarea datelor transmise prin formulare sau la plată și este așteptat implicit de browsere, care marchează site-urile fără el ca nesigure. Se instalează pe server și trebuie reînnoit periodic, adesea automat.

Fără el, browserul afișează un avertisment de site nesigur, iar o parte dintre vizitatori pleacă înainte să citească ceva. Datele completate în formulare circulă necriptate și pot fi citite pe traseu. Certificatul se obține gratuit la majoritatea găzduirilor, deci nu costul este motivul pentru care lipsește, ci neatenția la reînnoire.

Cum se verifică: deschide site-ul și dă clic pe lacătul din bara de adresă, unde vezi emitentul și data expirării. Verifică și că varianta fără https redirecționează către cea securizată. Ce protejează efectiv certificatul și ce nu protejează — în articolul despre riscurile reale de securitate.

TTFB Time To First Byte

Timpul scurs de la cererea browserului până la primul octet de răspuns primit de la server. Măsoară partea din încărcare care se petrece înainte ca browserul să aibă ce afișa: rezolvarea DNS, stabilirea conexiunii, procesarea pe server. Nu este un Core Web Vital, dar intră în fiecare dintre ei.

Este prima piesă din lanțul care duce la LCP: dacă serverul răspunde în două secunde, nicio optimizare de imagini nu mai poate aduce afișarea sub pragul de 2,5 secunde. Cauzele obișnuite sunt găzduirea slabă, lipsa cache-ului pe server, interogări grele la baza de date și distanța geografică față de vizitatori.

Cum se verifică: PageSpeed Insights îl raportează ca timp de răspuns al serverului, iar Google Search Console arată media în statisticile de accesare. Compară valoarea pe o pagină cu cache și pe una care nu poate fi pusă în cache, precum coșul; diferența îți spune dacă problema este serverul sau aplicația.

TTL Time To Live

Durata pentru care o informație este păstrată în memorie temporară înainte de a fi cerută din nou de la sursă. Se folosește mai ales la DNS, unde spune serverelor cât timp să rețină o înregistrare, dar și la cache-ul de browser sau de CDN.

La o mutare de găzduire, valoarea lui decide cât durează tranziția. Cu un TTL de 24 de ore, o parte dintre vizitatori ajung încă o zi întreagă pe serverul vechi, unde comenzile intră într-o bază de date pe care urmează să o abandonezi. Cu unul de câteva minute, schimbarea se propagă aproape imediat.

Cum se procedează corect: cu una-două zile înainte de mutare scazi TTL-ul înregistrărilor la câteva minute, faci schimbarea, verifici din mai multe rețele, apoi îl ridici la loc, ca să nu încarci inutil serverele DNS. Valoarea curentă se vede în panoul de administrare a domeniului sau printr-o interogare DNS.

UI interfața cu utilizatorul

Stratul vizibil prin care utilizatorul interacționează cu un site: butoane, meniuri, câmpuri de formular, tipografie, culori, spațiere. Ține de aspect și de comportamentul elementelor, în timp ce UX ține de rezultatul întregului parcurs. O interfață bună este consecventă și face evident ce se poate face pe fiecare ecran.

Consecvența este criteriul practic: aceleași butoane arată la fel peste tot, aceleași acțiuni stau în același loc, starea unui element se vede fără dubiu. Când fiecare pagină are altă convenție, utilizatorul reînvață interfața la fiecare pas și obosește, chiar dacă nu ar putea explica de ce a renunțat.

Greșeala frecventă este contrastul sacrificat pentru estetică: text gri deschis pe fundal alb, butoane care nu se disting de restul, câmpuri de formular fără chenar vizibil. Arată bine pe monitorul designerului și devine ilizibil pe un telefon, în lumina zilei. Verifică pe un ecran obișnuit, afară, înainte de a aproba.

UX experiența utilizatorului

Experiența pe care o are un utilizator parcurgând un site: cât de ușor găsește ce caută, cât de clar înțelege pașii și cât de puține obstacole întâlnește. Se construiește prin structură, formulare simple și viteză, nu prin decor. Un site frumos cu navigație confuză are UX slab și pierde conversii.

Se măsoară în comportament, nu în păreri și nu în gusturi: câți vizitatori ajung la formular, câți îl completează efectiv, unde se opresc și la ce pas renunță. O navigație neclară sau un formular cu paisprezece câmpuri costă contacte în fiecare zi, indiferent cât de bine arată site-ul și cât s-a plătit pentru design.

Cum se verifică ieftin: roagă trei persoane care nu cunosc site-ul să facă o sarcină concretă — găsește prețul serviciului și trimite o cerere — și privește fără să intervii sau să explici. Fiecare ezitare este o problemă reală. Trei oameni scot de obicei la iveală majoritatea obstacolelor importante.

Versionare Git

Sistem care păstrează istoricul complet al modificărilor aduse codului unui proiect: cine a schimbat, ce, când și de ce, cu posibilitatea de a reveni la orice stare anterioară. Standardul practic este Git, iar codul se păstrează într-un depozit, de obicei găzduit separat de serverul site-ului.

Pentru firma care comandă lucrarea, este garanția că proiectul nu depinde de un singur om și de fișierele de pe laptopul lui. Un depozit la care ai acces înseamnă că poți schimba furnizorul fără să reconstruiești de la zero și că o modificare care a stricat ceva poate fi anulată în minute, nu în zile.

Cum se verifică: cere acces de citire la depozitul proiectului tău încă din prima lună de colaborare, nu la final. Uită-te dacă istoricul este real — modificări dese, cu descrieri lizibile — sau dacă există o singură înregistrare cu tot site-ul, semn că versionarea a fost adăugată de formă, la cerere.

Webhook

Mecanism prin care o aplicație anunță automat alta că s-a întâmplat ceva, trimițând un mesaj către o adresă configurată în prealabil. Spre deosebire de un API interogat periodic, informația vine în momentul evenimentului. Se folosește pentru notificări de plată confirmată, comandă nouă sau formular trimis.

Diferența practică stă în întârziere și în consum: fără webhook, sistemul tău trebuie să întrebe periodic dacă s-a schimbat ceva, deci ori afli târziu, ori faci mii de cereri inutile. Cu webhook, confirmarea plății ajunge în câteva secunde, iar comanda pleacă mai repede către pregătire și livrare.

Greșeala frecventă este să tratezi adresa care primește mesajele ca pe ceva ce funcționează întotdeauna. Dacă serverul tău este indisponibil în acel moment, notificarea se pierde. O implementare serioasă verifică semnătura mesajului, răspunde rapid, ignoră duplicatele și este dublată de o verificare periodică pentru evenimentele care nu au ajuns.

WebP

Format de imagine dezvoltat de Google, care obține fișiere semnificativ mai mici decât JPEG sau PNG la calitate vizuală comparabilă și acceptă transparență. Este suportat de toate browserele moderne. Convertirea imaginilor grele în WebP este una dintre cele mai simple intervenții pentru îmbunătățirea timpului de încărcare.

Imaginile sunt de obicei cea mai grea parte a unei pagini, deci conversia lor are cel mai bun raport între efort și rezultat. Aceeași fotografie poate ajunge la o fracțiune din dimensiune, fără diferență vizibilă pe ecran, ceea ce scurtează direct timpul până la afișarea elementului principal.

Greșeala frecventă este să încarci fotografia direct de la telefon sau de la aparat, la câțiva megaocteți și câteva mii de pixeli lățime, și să o micșorezi din CSS. Vizitatorul descarcă tot fișierul, oricât de mic apare pe ecran. Redimensionează la dimensiunea la care se afișează efectiv, apoi convertește.

Wireframe

Schiță simplificată a unei pagini, în care se stabilesc doar structura, ierarhia informației și poziția elementelor, fără culori, fotografii sau text final. Se lucrează la începutul proiectului, pentru că modificările sunt rapide și ieftine în această fază. Permite validarea logicii paginii înainte de a investi în design.

Valoarea lui este economică: o modificare de structură costă minute acum și zile după implementare. Discuțiile despre ce intră în pagină și în ce ordine se poartă pe o schiță alb-negru, unde nimeni nu se ceartă pe nuanța butonului, ci pe ce trebuie să afle vizitatorul primul.

Greșeala frecventă este să sari peste el ca să câștigi timp. Rezultatul este că observațiile de structură apar abia la prezentarea machetei finale sau, mai rău, după implementare, când refacerea costă. O oră de schițe la început scurtează de obicei mai mult de o săptămână la final.

WordPress

Sistem de administrare a conținutului cu sursă deschisă, cel mai folosit din lume pentru site-uri de prezentare, bloguri și magazine online prin extensia WooCommerce. Are un ecosistem foarte mare de teme și pluginuri, ceea ce îl face flexibil și ieftin de pornit, dar cere actualizări periodice ca să rămână sigur și rapid.

Avantajul real este că găsești ușor oameni care lucrează cu el și extensii pentru aproape orice cerință. Costul este întreținerea: fiecare plugin instalat este cod scris de altcineva, care trebuie actualizat. Site-urile compromise pe care le refacem au aproape întotdeauna aceeași cauză, pluginuri sau teme lăsate neactualizate luni întregi.

Greșeala frecventă este acumularea: douăzeci de pluginuri instalate în timp, dintre care jumătate nefolosite, dar toate încărcate la fiecare vizită. Fiecare adaugă cod, cereri la baza de date și un risc în plus. Comparația cu alternativa statică, pe viteză, cost și mentenanță, este în site static sau WordPress.

Scris și verificat de Ciobanu Dan-Ionuț

Fondator și CEO — Dianys Holding & Zarina CRM

Fondator și CEO al Dianys Holding și al platformei Zarina CRM. Are 22 de ani de experiență în web development, programare, web marketing și optimizare SEO. A coordonat peste 2.500 de proiecte web pentru clienți din România, Spania, Franța și Emiratele Arabe Unite.

22 de ani de experiență · Web development · Programare · Web marketing · Optimizare SEO · E-commerce · Platforme CRM și ERP

Ultima actualizare a conținutului: . Prețurile afișate sunt orientative, fără TVA, și se confirmă prin ofertă scrisă.

Ai o întrebare care nu e aici

Îți răspundem fără jargon

Vezi și cele 100 de întrebări frecvente sau scrie-ne direct.

Scrie-ne pe WhatsApp