Construirea fikl.com: un site bilingv Astro v5 pentru pictorul contemporan Gheorghe Fikl

Brief-ul: un site la nivel de galerie pentru o audienta internationala

Audienta lui Fikl nu este una casuala. Colectionari, curatori, gallerists si pasionati seriosi de arta ajung pe site pentru a-i evalua opera in vederea achizitiei, expozitiei sau studiului critic. Sunt internationali si vorbitori de romana in proportii aproximativ egale. Site-ul trebuie sa se comporte cum se comporta receptia unei galerii majore: nepripit, calm autoritar, deferent fata de opera de pe pereti.

Inainte sa desenam un singur ecran, am stabilit trei cuvinte pentru brand: elegant, misterios, atemporal. Site-ul trebuia sa vorbeasca cu increderea linistita a unei galerii majore. Niciodata strident. Niciodata decorativ in sine. Fiecare element trebuia sa cedeze in fata operei. Am numit obiectivele emotionale explicit. Uimire si contemplatie, ca atunci cand stai in fata unei picturi intr-o camera intunecata. Curiozitate si descoperire, fiecare serie atragand vizitatorii mai adanc. Incredere si certitudine, astfel incat un vizitator la prima venire sa simta in cateva secunde ca acesta este un artist consacrat care merita colectionat. Acele trei obiective au devenit brief-ul editorial pentru fiecare pagina.

Mandatul estetic a urmat de aici. Am luat reperele de la Gagosian, David Zwirner si Pace Gallery: imaginea pe primul plan, spatiu alb generos, tipografie restransa, neutre calde in loc de alburi reci. Am stabilit o lista de anti-pattern-uri inca de la inceput si ne-am tinut de ea. Niciun cue de marketplace. Niciun efect la moda. Nicio micro-interactiune supra-animata. Nicio compozitie aglomerata. Fiecare element trebuia sa isi merite locul.

Constrangerile din spatele suprafetei au fost mai putin evidente, dar mai pretentioase. Site-ul trebuia sa fie bilingv fara sa-si paralizeze performanta de cautare. Trebuia sa fie rapid pe Wi-Fi-ul lent de hotel si pe conexiuni provinciale din Romania. Trebuia sa onoreze accesibilitatea (prefers-reduced-motion respectat, ARIA pe loc, navigare cu tastatura functionala) fara sa renunte la miscarea deliberata, de inhalare si exhalare, care face un site de galerie sa para o galerie, nu o brosura. Fiecare decizie tehnica de mai jos este un raspuns la una dintre acele constrangeri, iar fiecare decizie de design de mai jos este disciplina care a facut raspunsul coerent.

Mandatul estetic: cinci principii care au transat fiecare decizie

Un site de galerie este un lucru ciudat de proiectat. Cele mai multe site-uri concureaza pentru atentie. Acesta a trebuit sa o cedeze. Cele mai multe site-uri adauga elemente. Acesta si-a castigat forta prin scoaterea lor. Inainte sa scriem o linie de cod am asezat cinci principii: suficient de scurte cat sa le tinem minte, suficient de specifice cat sa transeze argumente. Fiecare decizie vizuala si de miscare de pe site poate fi urmarita pana la unul dintre ele.

1. Opera este suverana

Picturile sunt eroul fiecarei pagini. Chrome-ul UI se retrage. Navigarea este o linie subtire in partea de sus a ecranului. Captionurile stau la marginile cadrului, niciodata in fata lucrarii. Starile de hover regleaza opacitate, nu culoare, pentru ca schimbarile de culoare fura focusul. Cand am avut indoieli, am intrebat pe ce element ar trebui sa cada primul ochiul vizitatorului. Daca raspunsul nu era pictura, am schimbat ceva.

2. Incredere linistita

O galerie majora nu striga. Nu trebuie. Am scos fiecare element care nu servea fie opera, fie sarcina vizitatorului. Homepage-ul nu se deschide cu un slogan sau o propunere de valoare. Se deschide cu o pictura si un rand de declaratie a artistului. Mai mult de atat ar fi parut nervozitate.

3. Miscare deliberata

Animatiile pe site se simt ca o inhalare lenta: cu sens, fluide, nepripite. Am standardizat pe curbele de easing GSAP power2.out si power3.out, durate intre 350 si 1500 milisecunde. Fara bouncing. Fara snap. Fara wiggle-uri jucause. Tranzitiile intre pagini folosesc o cortina alba moale care se estompeaza in sase zecimi de secunda. Cursor-ul urmareste cu inertie, nu cu snap. Fiecare animatie trebuia sa treaca un singur test: ar parea potrivita intr-o galerie la miezul noptii, cu un singur vizitator in camera?

4. Minimalism cald

Cea mai consecventa decizie de culoare a proiectului a fost alegerea unei scari de gri cu tenta galbuie in loc de una rece, inclinata spre albastru. Diferenta este invizibila pentru majoritatea clientilor intr-un brief si evidenta in camera. Grurile reci se citesc ca clinice, corporative, tehnologice. Grurile calde se citesc ca hartie, ipsos, perete de galerie. Cea mai deschisa nuanta de pe site (#FAFAF8) este abia off-white. Cea mai inchisa (#0D0C0B) este abia neagra. Fiecare nuanta dintre ele poarta aceeasi caldura. Singurul accent (un coral-rust #dd4b39) apare doar pe elemente interactive, niciodata decorativ. Cele mai multe pagini de pe site nu contin niciun accent de culoare.

5. Tipografia ca arhitectura

Am folosit un singur typeface (Roboto) in trei greutati si am construit ierarhia din spatiere si greutate, nu numai din marime. Titlurile coboara in greutate inainte sa coboare in marime. Captionurile stau in majuscule cu letter-spacing generos, suficient de larg cat sa se citeasca ca semne arhitecturale, nu ca cuvinte. Body-ul ruleaza la greutate light 300 ca sa pastreze paginile de proza nepripite. Diacriticele romanesti (ă, î, ș, ț) primesc aceeasi grija ca setul Latin de baza, servite dintr-un subset Unicode-range separat astfel incat un curator care navigheaza in romana sa nu plateasca pentru glife pe care nu le va vedea, iar diacriticele sa nu se randeze in greutatea gresita pe o conexiune lenta.

Cursor-ul personalizat merita propria nota. Am inlocuit sageata default cu un mic punct si un cerc care foloseste mix-blend-mode: difference, ceea ce inseamna ca cursorul se adapteaza la orice se afla in spate fara sa fie nevoie sa fie tematizat explicit. Pe o pagina alba de galerie apare ca un semn intunecat. Peste o pictura intunecata apare ca unul palid. Cursorul devine el insusi o piesa de tipografie care respecta opera, nu un element de chrome care lupta cu ea.

Arhitectura: Astro v5, Cloudflare, static-first

Am ales Astro v5 cu output complet static. Portofoliul lui Fikl se actualizeaza sezonier, nu orar, asa ca nu exista nimic de castigat din randarea pe server si foarte mult de castigat din livrarea de HTML pur printr-un CDN. Build-ul produce ~60 de pagini prerenderate pe care Cloudflare le cacheaza la edge.

Tabloul de ansamblu:

• Astro v5 cu content collections. Fiecare serie, expozitie si imagine este descrisa in MDX cu o schema stricta si validata la build.
• GSAP + ScrollTrigger pentru reveals scroll-driven, plus Lenis pentru scroll fluid cu inertie.
• Astro View Transitions pentru fade-uri moi intre pagini in loc de reload-uri complete.
• Sharp pentru optimizarea imaginilor la build. Fiecare pictura servita ca WebP in patru latimi responsive.
• Apache + Cloudflare pentru hosting si cache, cu un .htaccess reglat manual pentru redirect-uri, compresie si cache headers.
• TypeScript peste tot, cu path aliases care pastreaza importurile lizibile (@components, @i18n, @scripts).

Nu exista baza de date, API sau runtime pe server. Site-ul care se incarca in browser este acelasi set de fisiere generate la build, servite de pe disc si cacheate agresiv. Acea decizie a eliminat din proiect intreaga categorie de probleme "baza de date e lenta azi" inca din prima zi si a transformat restul muncii in mestesug, nu infrastructura.

URL-uri bilingve fara durere de duplicare

Prima problema grea a fost limba. Audientele engleze asteapta URL-uri ca /works/ si /about/. Audientele romanesti asteapta /lucrări/ (transliterat in /lucrari/ pentru URL-uri ASCII) si /despre/. Slug-urile generice traduse automat se citesc ca un gand secundar. Strica vraja unui site facut cu grija.

Constrangerea a fost dubla. Engleza trebuia sa pastreze URL-urile fara prefix pentru ca ani de link-uri externe (recenzii de expozitii, articole de presa, site-uri de galerii) trimit la /works/, nu la /en/works/. Nu aveam de gand sa renuntam la acel link equity. Romana avea nevoie de slug-uri in limba naturala pentru ca orice altceva s-ar fi citit ca o traducere, nu ca un site romanesc. Iar Google trebuia sa inteleaga ca cele doua versiuni apartin impreuna, dar servesc audiente diferite.

Solutia este o mica structura de date care ridica cea mai mare parte a greutatii. Numele interne ale paginilor sunt mapate la segmente URL specifice fiecarei limbi intr-un singur routeMap:

export const routeMap = {
  en: { works: 'works',   about: 'about',  exhibitions: 'news',     contact: 'contact' },
  ro: { works: 'lucrari', about: 'despre', exhibitions: 'articole', contact: 'contact' },
};

Acel mic obiect este coloana vertebrala a fiecarui link, fiecarei intrari de sitemap si fiecarui tag hreflang de pe site. Un resolver getAlternateUrl calculeaza URL-ul corespunzator in cealalta limba pentru orice pagina, iar un singur component SEOHead emite cele trei tag-uri link de limba alternativa de care are nevoie fiecare pagina: cate unul pentru fiecare limba plus un fallback x-default catre engleza. Am construit fiecare limba ca propriul fisier de pagina in loc sa ne bazam pe trucuri de routing dinamic. Este putin mai verbos de scris, dar lasa generatorul static al lui Astro fara ambiguitate si lasa editorilor viitori o structura evidenta la prima privire.

Rezultatul este genul de detaliu pe care vizitatorii nu il observa si pe care motoarele de cautare il rasplatesc. Un colectionar roman care da click dintr-o revista de arta din Bucuresti ajunge pe fikl.com/ro/lucrari/baroque/: un URL scris in limba lui. Un curator international care da click dintr-o recenzie din Londra ajunge pe fikl.com/works/baroque/. Ambele pagini stiu una de cealalta. Google le indexeaza ca un set, fara penalitati de continut duplicat si fara hack-uri inteligente cu query-string-uri. Hreflang (semnalul care ii spune Google care versiune a paginii apartine carei audiente) valideaza curat pe fiecare pagina.

Boot lazy pentru GSAP si Lenis: pastrarea cinstita a first paint

A doua problema grea a fost miscarea. Miscarea cu ritm de galerie este o constrangere de design inainte sa fie una de inginerie. Fiecare curba de easing, fiecare durata, fiecare tranzitie a trebuit sa treaca testul galeriei la miezul noptii. Dar bibliotecile care fac acea miscare posibila sunt grele. Incarcarea GSAP, ScrollTrigger si Lenis devreme pe un site de galerie impinge afara momentul in care vizitatorul vede opera. Pe un site de galerie, acel moment este intregul produs.

Nu eram dispusi sa renuntam la miscare. Reveals scroll-driven, hover magnetic-cursor, inertia de smooth-scroll si cortinele de view-transition fac parte din modul in care site-ul comunica increderea sa linistita. Nu eram dispusi nici sa penalizam first paint.

Solutia este un boot in doua etaje. Scriptul de intrare critical-path este mic (cateva zeci de linii) si gestioneaza doar ce este necesar inainte ca prima animatie sa porneasca. Restul este amanat. Importam dinamic motorul greu de animatie inauntrul requestIdleCallback, API-ul "spune-mi cand esti liber" al browser-ului, cu un fallback de 1.5 secunde pentru browser-ele care nu il suporta. ScrollTrigger se inregistreaza doar cand browser-ul este idle. Lenis porneste doar cand pagina s-a asezat. Comentariul care deschide fisierul de intrare o spune simplu:

// Critical-path entry: only what's needed before/at first paint.
// Heavy init (ScrollTrigger, Lenis, scroll-driven animations) is moved to
// boot.ts and dynamic-imported from inside `requestIdleCallback` so it
// doesn't push out LCP or inflate Total Blocking Time on first load.

Problema corolara este curatenia. View Transitions pastreaza acelasi tab de browser si context JavaScript intre navigari, asa ca animatiile care nu sunt curatate clean se acumuleaza. Fiecare pagina devine putin mai lenta decat cea anterioara. Inregistram fiecare animatie cu o functie de cleanup, iar la fiecare navigare le apelam pe toate, omoram orice timeline GSAP ramas si scoatem fiecare ScrollTrigger inainte ca pagina noua sa lege propriile sale. Memoria ramane plata. A cincizecea navigare se simte exact ca prima.

Rezultatul vizibil este raspunsul la cea mai linistita constrangere a brief-ului. Lucrarea apare aproape instant. Sistemul de animatie porneste in fundal, fara sa se ia la cursa cu pipeline-ul de paint. Pagina se simte si rapida si vie, si ramane asa indiferent cat sta vizitatorul.

Un pipeline de imagini LCP-first pentru un site greu de picturi

A treia problema grea a fost imaginile. Fiecare pagina de pe site are o pictura in partea de sus. Largest Contentful Paint (momentul in care imaginea hero apare efectiv pe ecran) este, in consecinta, cel mai important indicator de performanta de pe un site de galerie. Daca LCP este lent, nimic altceva nu conteaza. Principiul opera-este-suverana devine o problema de pipeline de retea.

Constrangerile au fost familiare, dar neinduratoare. Nu puteam servi cea mai mare varianta desktop catre vizitatorii mobili pentru ca asta risipeste cam un megabyte per pagina, iar datele mobile nu sunt gratis. Nu puteam folosi JavaScript pentru a schimba imagini in functie de marimea ecranului pentru ca asta strica SEO si accesibilitatea, si nu poate rula inainte ca browser-ul sa fi parsat si executat scriptul (cel mai prost moment posibil pentru a descoperi ce imagine sa cere). Imaginea hero trebuia sa inceapa sa se descarce in momentul in care HTML-ul ajunge in browser, si trebuia sa fie imaginea hero corecta pentru dispozitiv.

Pregenerar la build patru variante WebP din fiecare pictura folosind Sharp, backend-ul nativ de optimizare a imaginilor al lui Astro. Layout-ul de baza expune un mic prop lcpImage care emite tag-uri <link rel="preload" as="image"> cu atribute imagesrcset comutate prin media query. Browser-ul citeste acele tag-uri preload inainte sa parseze body-ul, alege varianta corecta pentru viewport-ul curent si incepe sa o descarce imediat, batand parser-ul de body la tag-ul <img> cu cateva sute de milisecunde pe o conexiune tipica. Aceleasi variante Sharp alimenteaza apoi elementul <picture> randat, asa ca transformarea nu ruleaza niciodata de doua ori si cheile de cache se aliniaza perfect.

Orice alta imagine de pe pagina (thumbnail-uri, lucrari secundare, copertele de expozitie) foloseste lazy loading cu o mica tranzitie de fade-in care mascheaza reteaua. Doar pictura LCP primeste tratamentul prioritar, pentru ca doar pictura LCP are nevoie de el.

Rezultatul calitativ este ca site-ul se simte corect imediat. Vizitatorul aterizeaza pe homepage si pictura hero este acolo inainte ca ei sa fi terminat de scrollat. Dau click intr-o serie si prima lucrare este deja pictata pe ecran. Vizitatorii mobili nu platesc costul de banda al desktop-ului. Scorurile Lighthouse Performance raman mari fara ca echipa sa trebuiasca sa se gandeasca la performanta pe fiecare pagina noua. Arhitectura este optimizarea.

Animatie care cedeaza in fata operei

Dincolo de munca grea, trei sisteme mai mici de animatie dau site-ului textura. Fiecare este disciplinat de principiul miscarii deliberate.

View Transitions cu rezilienta la click rapid

View Transitions transforma navigarile in fade-uri moi in loc de reload-uri complete. O cortina alba pozitie-fixa face fade-in pentru 0.4 secunde in timp ce pagina urmatoare se incarca, apoi face fade-out pentru 0.6 secunde dupa ce continutul nou este la locul lui: aceeasi senzatie de cortina de galerie pe care un vizitator ar avea-o trecand dintr-o sala in alta. Exista un detaliu subtil de inginerie dedesubt. Click-urile rapide (un curator care decide la mijlocul fade-ului sa mearga in alta parte) lasau site-ul blocat pe un overlay pe jumatate estompat pentru ca promisiunea animatiei originale nu se rezolva niciodata. Am separat layer-ul vizual (controlat de GSAP, care se suprascrie elegant cand este intrerupt) de layer-ul de timing (un setTimeout simplu, care se rezolva intotdeauna), si jank-ul de click rapid a disparut.

Trigger-e de animatie declarative

Trigger-urile de animatie declarative permit echipei de design sa lucreze fara sa atinga JavaScript. Fiecare element animabil de pe site este adnotat cu un atribut data-animate: fade-in, text-reveal, image-reveal, clip-reveal, parallax, stagger-children. Motorul de animatie citeste acele atribute pe fiecare pagina si leaga comportamentul potrivit. Adaugarea unui fade-in nou la un bloc de marketing este o schimbare de un atribut, nu una de cod. Designerii raman in instrumentele de design. Inginerii le ies din drum.

ArtworkViewer: pinch, swipe, tastatura, scroll-aware

ArtworkViewer este componenta cea mai complexa a site-ului: un viewer multi-imagine personalizat care gestioneaza pinch-zoom pe tableta, navigarea cu sageti pe desktop, gesturile de swipe pe telefoane si o banda de thumbnail-uri care face auto-scroll ca sa pastreze imaginea curenta vizibila. Detaliul de care suntem cei mai mandri este mic. Cat timp un vizitator face pinch sau drag pe o lucrare, scroll-ul fluid se opreste asa ca pagina nu se lupta cu gesturile lui. Este genul de detaliu pe care nimeni nu il observa cand functioneaza si pe care toata lumea il observa cand nu functioneaza.

Content collections si un graf de entitati JSON-LD conectat

In spatele scenei, site-ul este tinut impreuna de doua sisteme linistite si puternice.

Primul este Astro v5 content collections. Fiecare serie, fiecare expozitie, fiecare pictura individuala este descrisa in MDX cu o schema stricta. Referintele la imagini sunt validate la build. O greseala de scriere intr-un nume de fisier face build-ul sa cada in loc sa expedieze un 404. Adaugarea unei picturi noi la o serie este o chestiune de editare a unui fisier si adaugare a unei imagini. Poster-ul de pe homepage, grila de lucrari, thumbnail-ul prev/next de navigare a seriei si artwork viewer-ul citesc toate din aceeasi lista canonica. Exista exact o sursa de adevar pentru continutul fiecarei serii, si sta langa proza care o descrie.

Acest sistem incrustreaza si o lectie de proces pe care proiectul ne-a invatat-o devreme. Fisierele de continut englezesti si romanesti au derivat usor. Cateva picturi au cazut dintr-o limba, cateva nu s-au propagat niciodata in cealalta. Am rezolvat-o nu prin adaugare de tooling, ci prin adaugare de conventie: engleza este canonica, romana mirroreaza exact lista de imagini din engleza si doar proza (mediu, descriere, tag-uri, body) este localizata. Problema de drift nu era o problema de cod si nu ar fi fost rezolvata de cod.

Al doilea sistem este JSON-LD structured data. Homepage-ul emite un @graph conectat: o Person tipata ca VisualArtist (cu profilurile sociale verificate legate prin sameAs), un WebSite care declara ambele limbi suportate si un WebPage care descrie homepage-ul insusi. Paginile de detaliu de serie emit un CreativeWorkSeries cu un array hasPart de obiecte VisualArtwork: fiecare pictura de pe pagina descrisa individual cu mediu, dimensiuni, an si URL de imagine. Breadcrumb-urile sunt explicite. Pagina /despre/ foloseste AboutPage legata inapoi la entitatea artistului. Pagina /lucrari/ foloseste CollectionPage.

Scopul acestei structuri nu este sa pacaleasca motoarele de cautare. Scopul este ca Google sa inteleaga acum ca Fikl este o entitate de artist, nu doar un site. Apare in feature-urile Knowledge Graph. Picturile lui sunt eligibile sa apara in Google Images cu metadatele bogate care genereaza click-uri de la colectionari: titlu, an, dimensiuni, mediu, toate in slot-ul pe care algoritmul il vrea. Datele structurate fac munca de a face site-ul lizibil pentru sistemele care il pun in fata. Pentru rationamentul mai profund despre SEO de graf de entitati, vezi studiul nostru de caz despre vizibilitatea in cautarea AI prin llms.txt.

Deployment, caching si migrarea URL-urilor mostenite

Site-ul este gazduit pe cPanel cu un .htaccess reglat manual si fronted de CDN-ul Cloudflare. Nu exista runtime Node in productie, niciun Lambda, nicio edge function. Doar HTML, CSS, JavaScript si fisiere de imagini statice servite de pe disc si cacheate la edge.

Cateva detalii isi merita locul. Facem 301-redirect pentru fiecare URL legacy /en/ catre echivalentul englez fara prefix, conservand link equity-ul de intrare din anii de acoperire de presa si recenzii de expozitii care trimit la structura veche. HTTPS este aplicat. Varianta www face redirect catre apex. URL-ul canonic este lipsit de ambiguitate. Asset-urile cu hash sunt cacheate un an cu headere imutabile. HTML-ul este cacheat o ora, suficient de scurt cat actualizarile de continut sa apara repede fara sa forteze o purjare globala de cache. Compresia este pornita pentru text, JSON si JSON-LD. Headerele standard de securitate sunt la locul lor: X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Nimic din asta nu este nou. Tot este corect.

Rezultate in productie

Rezultate reale, acolo unde avem masuratori:

• First paint rapid pe ambele limbi. Pictura hero apare in pragul "good" LCP al Google pe conexiuni reprezentative, atat pe homepage-ul englez cat si pe cel roman. Cifre de audit Lighthouse live disponibile la cerere.
• Validare hreflang curata. Fiecare pagina isi declara corect contraparte in cealalta limba. Search Console nu raporteaza nicio eroare de hreflang.
• Eligibilitate pentru rich results. Schemele Person, CreativeWorkSeries, VisualArtwork, BreadcrumbList si WebSite valideaza toate fara avertismente in Google Rich Results Test.
• Performanta stabila intre navigari. Pentru ca animatiile si ScrollTrigger-urile sunt curatate la fiecare tranzitie, site-ul se simte exact la fel la al cincizecilea click ca la primul.
• Pinch-zoom care functioneaza la vernisaje. Curatorii care rasfoiesc artwork viewer-ul pe iPad-uri la deschideri de expozitii pot face pinch intr-o pictura la 4x ca sa inspecteze un detaliu fara ca pagina sa le fure gestul.

Rezultatul calitativ este cel care conteaza cel mai mult. Site-ul dispare in fata operei. Vizitatorii nu se mai gandesc la site si incep sa se gandeasca la picturi, ceea ce este, in cele din urma, exact ce a cerut brief-ul.

Lectii pe care le ducem mai departe

Patru concluzii merita duse la fiecare proiect care urmeaza acestuia.

1. Principiile de design sunt economisitoare de decizii, nu decoratiuni. Cele cinci principii pe care le-am stabilit la inceputul proiectului (opera este suverana, incredere linistita, miscare deliberata, minimalism cald, tipografia ca arhitectura) au transat cel putin un argument pe saptamana de build. Scrierea lor in limbaj clar, inainte de orice pixel, a fost ora cu cea mai mare parghie din proiect.
2. Drift-ul de continut bilingv este o problema de proces, nu de cod. Cand listele de imagini engleze si romanesti au divergat scurt, solutia nu a fost tooling. A fost o conventie explicita: o limba este canonica pentru structura, cealalta o mirroreaza si doar proza este localizata. Procesul bate automatizarea cand oamenii fac localizarea.
3. Amana tot ce poti. Cea mai mare parghie de performanta perceputa pe acest proiect a fost mutarea GSAP si Lenis in spatele requestIdleCallback si dynamic-importul lor dupa first paint. Pattern-ul este general. Fiecare site care expediaza miscare grea beneficiaza de aceeasi disciplina. Daca un script nu trebuie sa ruleze inainte de first paint, nu ar trebui sa o faca.
4. Schemele se platesc singure. Tipul de continut image() al lui Astro a prins referinte rupte de imagini la build si a salvat proiectul de cel putin un 404 expediat in productie. Fiecare minut petrecut definind schema s-a returnat de multe ori in probleme care nu au ajuns niciodata la vizitator.

Stack-ul complet

• Astro v5 (output static, content collections, MDX, View Transitions)
• GSAP + ScrollTrigger (reveals scroll-driven, tranzitii intre pagini)
• Lenis (scroll fluid cu inertie, integrat cu ticker-ul GSAP)
• Sharp (optimizare WebP la build)
• TypeScript (mod strict, path aliases)
• Apache + Cloudflare (hosting, CDN, caching, redirect-uri 301)

Intrebari frecvente

De ce Astro v5 in loc de WordPress pentru un site de artist?

Portofoliul unui pictor contemporan se actualizeaza sezonier, nu orar. Nu exista nimic de castigat din randarea pe server, ci foarte mult de castigat din livrarea de HTML pur printr-un CDN. Astro v5 cu output static complet produce ~60 de pagini prerenderate pe care Cloudflare le cacheaza la edge. Nu exista baza de date, nu exista API, nu exista runtime pe server. Acea decizie a eliminat din proiect intreaga categorie de probleme "baza de date e lenta azi" inca din prima zi.

Cum functioneaza strategia URL bilingva fara sa strice SEO?

Engleza pastreaza URL-uri fara prefix (fikl.com/works/) astfel incat ani de link-uri din presa, recenzii de expozitie si site-uri de galerii continua sa rezolve. Romana primeste slug-uri in limba naturala (fikl.com/ro/lucrari/) astfel incat sa citeasca natural ca un site romanesc, nu ca o traducere. Un mic routeMap mapeaza numele interne ale paginilor la segmente URL specifice fiecarei limbi. Un singur component SEOHead emite tag-urile hreflang pentru fiecare limba plus un fallback x-default catre engleza. Search Console nu raporteaza nicio eroare hreflang.

Ce este strategia de imagine LCP-first si de ce conteaza?

Largest Contentful Paint este momentul in care imaginea hero apare efectiv pe ecran. Pe un site de galerie, acel moment este intregul produs. Pregenerar la build patru variante WebP din fiecare pictura folosind Sharp. Layout-ul de baza emite tag-uri <link rel="preload" as="image"> cu atribute imagesrcset comutate prin media query. Browser-ul citeste acele tag-uri preload inainte sa parseze body-ul, alege varianta corecta pentru viewport-ul curent si incepe sa o descarce imediat. Vizitatorii mobili nu platesc costul de banda al desktop-ului.

Cum pastrati polish-ul de animatie fara sa afectati first paint?

Boot in doua etaje. Scriptul de intrare critical-path este mic si gestioneaza doar ce este necesar inainte ca prima animatie sa porneasca. Restul este amanat. Importam dinamic motorul greu de animatie (GSAP, ScrollTrigger, Lenis) inauntrul requestIdleCallback cu fallback la 1.5 secunde. Lucrarea apare aproape instant. Sistemul de animatie porneste in fundal, fara sa se ia la cursa cu pipeline-ul de paint.

Pot alte galerii sau artisti sa foloseasca aceeasi abordare?

Da. Pattern-ul se generalizeaza la orice site de portofoliu cu imagini ca prim subiect: galerii, fundatii, ateliere, fotografi, sculptori, designeri. Deciziile centrale (hosting static-first, content collections cu scheme stricte, boot lazy pentru animatie, pipeline LCP-first pentru imagini, graf de entitati JSON-LD conectat) se transfera toate. Principiile estetice sunt la fel de portabile. Singurul lucru care trebuie construit de la zero este brand-ul: paleta de culori, stack-ul tipografic, vocabularul de miscare si copy-ul. Daca esti o galerie, fundatie, atelier sau artist care cauta un site care respecta opera, serviciul nostru de dezvoltare website corporate incepe aici.