Lashstudio.ro — site beauty construit ca produs.

În București și Ilfov sunt câteva mii de saloane beauty. Toate oferă cam aceleași lucruri: extensii gene, micropigmentare, laminare, faciale. Diferențierea offline ține până la un punct. Pentru un client nou, primul contact e o căutare pe Google sau scroll pe Instagram.

Și aici e problema. Majoritatea saloanelor au site-uri lente, fără SEO, fără date structurate. WordPress cu teme generice și 20+ pluginuri care încarcă a doua imagine după 5 secunde. Bara competitivă tehnic e jos. Oricine vine cu un site curat și rapid intră peste ele.

Am exclus WordPress din start. Nu pentru că WordPress e prost — e o platformă matură. Dar pluginurile multiple, baza de date suprasolicitată și overhead-ul temelor beauty din România fac performanța aproape imposibilă fără efort de tuning continuu. Pentru un site de prezentare cu booking, există variante mai curate.

Stack-ul ales:

• Next.js 16 cu App Router: componente server-side, image optimization integrată, ISR pentru pagini frecvent actualizate
• Tailwind CSS 4: fără fișier de config, paleta direct în globals.css, zero overhead de runtime
• Neon Postgres: baza de date a programărilor și clientelor
• Vercel: hosting și CDN global
• NameHero: email pe domeniu propriu ([email protected])
• NextAuth: autentificare admin

Cu stack-ul ăsta, Best Practices și SEO erau 100 din primul deploy. Performance și Accessibility au cerut muncă suplimentară.

Datele structurate

Schema.org JSON-LD e cum Google și motoarele AI (ChatGPT Search, Perplexity, AI Overviews) înțeleg ce face site-ul tău. Fără ele, ești tăcut pentru sistemele astea — apari poate, dar nu te citează nimeni în răspunsuri AI.

Lashstudio are mai multe straturi de schema:

• BeautySalon schema globală în root layout: adresă completă, telefon, email, ore, social media, coordonate geo
• Service schema pe fiecare pagină de serviciu: preț, durată, descriere, offers
• FAQPage schema: 9–10 întrebări per serviciu cu răspunsuri formatate corect
• BreadcrumbList pentru navigația ierarhică

Keywords pe coadă lungă

Pe „micropigmentare" simplu nu poți câștiga. Acolo concurezi cu toate clinicile mari și cu portalurile Treatwell, Booksy. Am mers pe queries cu intent specific:

• „cum se îngrijesc extensiile de gene"
• „contraindicații micropigmentare buze"
• „cât durează vindecarea după carbon peel"
• „pot face stilizare sprâncene după botox"

Pentru fiecare serviciu am identificat 10–15 astfel de întrebări — parte din People Also Ask, parte din ce o întreabă Andreea cliente la fiecare programare. Răspunsurile apar în două locuri. Pe pagină, ca chenare informative („Reguli de îngrijire", „Contraindicații", „Pregătirea înainte de procedură"). Și în FAQ schema, ca să poată fi citate în featured snippets sau în răspunsurile AI.

NAP consistency

Numele, adresa și telefonul trebuie identice peste tot. Pe site, în schema JSON-LD, pe Google Business Profile, în directoriile locale. Google folosește asta ca semnal de încredere. O virgulă în plus, o cifră inversată sau o adresă scurtată într-un singur loc slăbește ranking-ul local. Am centralizat datele într-un singur loc în cod și verific manual oriunde apar.

Sitemap dinamic

app/sitemap.ts generează automat sitemap.xml cu toate URL-urile, priority și changeFrequency per tip de pagină. Adăugarea unei pagini noi intră în sitemap fără cod suplimentar.

Câteva detalii practice:

• Meniul mobil închis primește atributul inert prin useEffect. Linkurile dispar din tab order, iar utilizatorii cu tastatură nu mai nimeresc invizibili.
• Skip link „Sari la conținut" — focusabil, ascuns vizual, apare doar la tabulare.
• Toate textele cu contrast minim 4.5:1. Opacitățile /60 sau /50 pe text le-am înlocuit cu culori solide din paletă.
• Focus visible explicit pe toate butoanele și linkurile, cu ring colorat.
• ARIA labels pe iconițe, aria-hidden pe decorative.

Scorul final: 96. Pentru 100, ar trebui revizuite câteva texte mici care folosesc accent color. Mai jos explic de ce am ales să rămân la 96.

După prima săptămână live, am revenit pentru o rundă de optimizări țintite. PageSpeed Insights ne-a marcat câteva probleme: render blocking 900ms, forced reflow 348ms, unused JS 29 KiB.

Am încercat 6 lucruri. Trei au mers, trei nu. Le povestesc pe toate, pentru că „ce nu funcționează" e la fel de util ca „ce funcționează".

Ce a mers

1. Resize logo de la 5000×2092 la 600×251 — logo-ul livrat era 5000px lățime, 306 KB. Pe site se afișa la maxim 80 CSS pixels. Adică livram o imagine de 13× mai mare decât era nevoie. Resize cu sharp la 600×251, quality 90, output WebP: rezultatul a ajuns la 26 KB. Câștig direct: −280 KB la fiecare prim load, fără absolut nicio diferență vizuală.

2. Scroll listener cu requestAnimationFrame — navul scurta înălțimea când utilizatorul scrolla mai jos de 40px. Handler-ul citea window.scrollY și seta state-ul direct. PSI marca „forced reflow 348ms". Soluția: throttle cu requestAnimationFrame și setState doar când valoarea chiar se schimbă. Plus am scurtat tranziția CSS de la 500ms la 300ms. Forced reflow a trecut la verde.

3. Hero image cu placeholder blur — <Image> din Next.js suportă placeholder="blur" cu blurDataURL. Am generat un base64 minuscul (10×10px blurat) pentru hero. Utilizatorul vede ceva pictat pe ecran instant, înainte ca imaginea reală să se descarce. Perceived performance ↑ chiar și fără îmbunătățire reală de LCP.

Ce nu a mers

4. experimental.optimizeCss: true — pe hârtie sună perfect: extrage critical CSS, inline-uiește, defer restul. Rezultat real: Performance a scăzut de la 91 la 89. Forced reflow a reapărut. Flag-ul experimental chiar e experimental. Rollback în 2 secunde. Lecție: testează flag-uri experimentale separat, nu în producție pe trafic real.

5. Dynamic import pentru CookieConsent și GoogleAnalytics — am vrut să scot cele două componente client-side din bundle-ul inițial via next/dynamic. Logic — sunt non-critice. Rezultat: Performance a scăzut de la 91 la 87. Pentru componente atât de mici (sub 3 KB fiecare), overhead-ul unei runtime fetch separate e mai mare decât câștigul din bundle splitting. Lecție: code splitting are sens pentru componente mari sau rar folosite, nu pentru cele care apar pe primul paint.

6. Schimbare accent color pentru Accessibility 100 — cea mai dureroasă decizie. PSI marca contrast fail pe #e8967e (pink-coral) folosit ca text pe fundal cream. Pentru 100 perfect ar trebui schimbat la o variantă mai închisă (#a4502f, rust). 115 înlocuiri în 19 fișiere. Am făcut schimbarea, apoi am revenit. Accentul a devenit ruginiu, paleta și-a pierdut feel-ul „warm coral" care era parte din identitatea vizuală. Câștigul de 4 puncte la Accessibility nu compensa schimbarea de paletă. Salonul a ales să rămână la 96 cu paleta originală. 96 e tot scor industry-leading.

Ce am învățat din runda asta

Două lucruri practice care-mi rămân:

Primul: nu fiecare „best practice" recomandată de PSI se aplică universal. Flag-uri experimentale și dynamic imports pentru chunk-uri mici pot avea efect invers. Măsoară după fiecare modificare. Nu presupune că direcția e bună doar pentru că documentația o spune.

Al doilea: există un punct dincolo de care optimizările tehnice nu mai aduc câștig real pentru utilizator. Diferența între 91 și 95 la PSI nu se vede în comportamentul real. Câștigul vine după aceea din content nou, backlink-uri, conversie — nu dintr-un kilobyte tăiat dintr-un chunk shared.

1. WordPress nu e cea mai bună alegere pentru saloane mici dacă vrei performance real. Cost-benefit slab vs alternative moderne.
2. Schema JSON-LD e cea mai subestimată optimizare SEO. Două ore de muncă, beneficii măsurabile pe luni întregi.
3. FAQ extins pe pagina serviciului funcționează mai bine decât blog separat pentru long-tail searches. Plus, Google îl citează mai des în featured snippets.
4. JPEG → WebP salvează 50–80% din mărimea imaginilor fără pierdere vizibilă. Pentru un site beauty cu zeci de poze, înseamnă megabytes economisiți la fiecare load.
5. Nu adăuga librării pentru lucruri simple. Un lightbox funcțional în React e 50 linii cu Context. O librărie de 30KB pentru același rezultat e overkill.