sendreagabriel.ro — Arhitectură & Sarcini

Google acceptă ambele blocuri ca valide dar e o dublură inutilă. Pe termen lung, un singur bloc e mai curat și mai ușor de menținut. Nu e urgentă — nu afectează indexarea actuală.

În schema validată de Google apare autorul cu @type: Organization și @type: Person simultan pe același nod. Gabriel Șendrea e o persoană fizică, nu o organizație — ambiguitatea poate confuza Knowledge Graph-ul.

„Activ din 2012" în text vizibil nu e suficient — AI-ul are nevoie de proprietatea machine-readable pentru a calcula vechimea și experiența. worksFor cu referință spre clipe-dragi.ro/#organization închide cercul Person ↔ Business în Knowledge Graph.

Conexiunea dintre cele două domenii e unidirecțională momentan — sendreagabriel.ro trimite spre clipe-dragi.ro, dar clipe-dragi.ro nu confirmă explicit legătura inversă în schema machine-readable. Adăugarea în sameAs închide cercul pentru Knowledge Graph.

Linkul contextual din fiecare articol e semnalul principal prin care Google și AI-urile înțeleg că cele două site-uri sunt același om. Schema sameAs face treaba în fundal — linkul vizibil o confirmă și pentru cititor.

Profilurile externe care menționează sendreagabriel.ro confirmă că entitatea are o prezență digitală distinctă. Fără URL-ul în bio, legătura dintre profil și site nu e vizibilă pentru sistemele AI care citesc profilurile externe ca surse independente.

Consistența numelui e fundamentală pentru Knowledge Graph. „Gabriel Sendrea" și „Gabriel Șendrea" sunt entități diferite pentru algoritm. Ș cu sedilă, nu cu virgulă — și asta contează.

Google și sistemele AI evaluează consistența în timp, nu volumul de moment. 10 articole publicate odată nu valorează cât 10 articole publicate regulat pe parcursul unui an.

Cele 3 câmpuri de imagine din ACF (hero_bg_image, foto_lucrare, ganduri_hero_image) returnează acum URL-ul fișierului original — adică exact ce ai urcat tu, care la un export din cameră are 3–8MB. WordPress creează automat, la fiecare upload, copii mai mici ale imaginii, dar tema nu le folosește pe niciuna. srcset e o listă de mărimi din care browserul alege singur varianta potrivită ecranului: un telefon descarcă varianta de 800px, un desktop pe cea de 1920px — nimeni nu mai descarcă originalul. „Preload" e o instrucțiune care îi spune browserului „descarcă imaginea asta prima, e cea mai importantă" — și chiar e: hero-ul e elementul LCP (Largest Contentful Paint — metrica Google care măsoară când apare pe ecran cel mai mare element vizual; e unul dintre criteriile oficiale de ranking). Bonus specific site-ului tău: hero-ul e afișat la opacitate 0.35, cu efect gri/sepia, peste fundal închis — poate fi comprimat agresiv fără să se vadă vreo diferență. Aici e diferența între o pagină de 5MB și una de 300KB.

WebP e un format de imagine modern care arată identic cu JPEG dar cântărește cu 30–50% mai puțin. QUIC.cloud e serviciul gratuit al celor de la LiteSpeed care face conversia automat — pluginul trimite imaginile la ei, primește înapoi variantele WebP și le servește vizitatorilor. Din exportul de setări reiese că QUIC.cloud nu a fost conectat niciodată (cheia API e goală, nicio optimizare rulată), deci toate imaginile pleacă spre vizitatori ca JPEG-uri originale. Se combină perfect cu 05.01: aia rezolvă mărimea în pixeli, asta rezolvă compresia fișierului.

„Lazy loading" înseamnă că imaginile de jos pe pagină nu se descarcă decât când utilizatorul ajunge cu scroll-ul aproape de ele — economisește bandă. Tema face asta deja prin metoda nativă a browserului (loading="lazy" pe imagini), iar WordPress o adaugă automat și pe imaginile din articole. Opțiunea din LiteSpeed face același lucru, dar printr-un script JavaScript care rescrie HTML-ul — un strat în plus de complexitate fără niciun beneficiu, și cu risc: dacă scriptul amână și imaginea hero (cea mai importantă), strică exact LCP-ul pe care vrem să-l reparăm.

Cache-ul înseamnă că serverul păstrează o copie gata făcută a paginii și o servește instant, fără s-o reconstruiască la fiecare vizită. „Cache Mobile" creează o a doua copie, separată, pentru telefoane — util doar când site-ul trimite HTML diferit pe mobil. Tema ta e responsive: același HTML, doar CSS-ul îl aranjează diferit pe ecran mic. Deci acum se țin două copii identice — spațiu ocupat degeaba și mai multe situații în care un vizitator nimerește o copie încă negenerată (pagina se încarcă mai lent la prima vizită).

Browserul descoperă fonturile târziu: întâi descarcă HTML-ul, apoi CSS-ul, abia din CSS află că are nevoie de fonturi și abia atunci le cere. Între timp textul se afișează cu un font de sistem și „sare" în fontul corect când acesta sosește — flash-ul acela de schimbare se numește FOUT. Preload-ul îi spune browserului din prima linie de HTML: „vei avea nevoie de aceste două fișiere de font, descarcă-le acum, în paralel". Cele două fonturi sunt folosite above-the-fold (în partea vizibilă fără scroll) pe toate paginile, deci merită.

WordPress încarcă implicit, pe fiecare pagină, niște fișiere CSS pentru editorul de blocuri Gutenberg (wp-block-library, global-styles, classic-theme-styles) plus niște linkuri tehnice în <head> (oEmbed, RSD, shortlink) de care site-ul tău nu se folosește. În total ~30–80KB de CSS/JS inutil la fiecare încărcare. Scriptul de emoji era și el pe listă, dar e deja eliminat de LiteSpeed Cache din setări — punctul ăla e bifat din oficiu.

Browserul vizitatorului păstrează CSS-ul în cache-ul propriu 1 an (așa e setat în LiteSpeed — corect pentru viteză). Problema: când modifici main.css, un vizitator care a mai fost pe site continuă să vadă versiunea veche din cache-ul lui, pentru că adresa fișierului e identică (main.css?ver=1.0, mereu). „Cache busting" = schimbarea automată a acelui număr de versiune la fiecare modificare a fișierului. filemtime() e o funcție PHP care returnează data ultimei modificări a fișierului — folosită ca versiune, se schimbă singură exact când trebuie.

Când un articol nu are imagine proprie, tema încarcă una de rezervă direct de pe serverele Unsplash (hotlink extern). Costă: o căutare DNS în plus + o conexiune nouă spre un server străin + dependență de un terț — dacă Unsplash schimbă sau șterge acel URL, articolul rămâne cu imagine spartă, fără ca tu să afli.

(1) DNS prefetch: când cineva deschide lightbox-ul cu un video, browserul trebuie întâi să afle adresa serverului Vimeo (căutare DNS) și abia apoi să ceară playerul. Prefetch-ul face căutarea DNS din timp, în fundal, cât utilizatorul încă citește pagina — la click, playerul pornește mai repede. (2) Object cache: Redis e o memorie rapidă în care se păstrează rezultatele interogărilor către baza de date, ca WordPress să nu le refacă la fiecare vizită — ajută paginile care nu sunt în cache (admin, prima vizită după Purge). Disponibil doar dacă planul de găzduire îl include.

Cele două fișiere conțin exact același cod, linie cu linie. Asta înseamnă că orice modificare la lista de articole trebuie făcută de două ori — și la un moment dat, garantat, una dintre copii va fi uitată și vor diverge fără să-ți dai seama. Un „template part" e un fragment de cod pus într-un singur fișier, pe care celelalte doar îl includ — principiul DRY (Don't Repeat Yourself): orice lucru există într-un singur loc.

Separatorul grafic de hârtie ruptă e scris direct în HTML („inline") în 4 fișiere ale temei, în 3 variante ușor diferite între ele. Asta înseamnă ~3–4KB de markup care călătoresc cu fiecare pagină, la fiecare încărcare, și nu pot fi păstrați în cache separat. Mutat într-un singur fișier .svg referențiat din CSS, se descarcă o singură dată și browserul îl ține în cache 1 an. Bonus: la înălțimea de 55px la care e afișat, jumătate din punctele din desen sunt invizibile — path-ul poate fi simplificat fără nicio diferență vizuală.

Iconițele de social media sunt copiate în două fișiere — și deja s-a produs efectul previzibil al duplicării: iconița de Vimeo are desen (path SVG) diferit în cele două locuri. Același principiu ca la 06.01: ce există în două locuri va diverge.

Funcția care calculează „X min de citit" folosește str_word_count, o funcție PHP veche care nu știe de diacritice: tratează ă, â, î, ș, ț ca separatoare de cuvinte. „Mănăstire" e numărat ca 3 cuvinte („m", „n", „stire"). Rezultatul: toate articolele afișează un timp de citire mai mare decât cel real — un detaliu mic, dar vizibil pe fiecare articol, și incorect.

Trei lucruri mici, strânse la un loc: (1) $hero_bg în front-page.php și $total în archive sunt variabile calculate dar nefolosite niciodată — „cod mort" care derutează la editări viitoare; (2) când un articol nu are imagine, schema JSON-LD trimite "image": null — mai curat e ca proprietatea să lipsească de tot decât să fie goală; (3) numărătoarea „03 / 12" de pe articole încarcă lista tuturor ID-urilor la fiecare vizită — la volumul actual e ieftin, dar un COUNT simplu face același lucru mai elegant.

Skip-link-ul e un link ascuns, primul de pe pagină, care le permite celor ce navighează doar din tastatură (persoane cu dizabilități motorii, utilizatori de screen reader) să sară direct la conținut, fără să treacă cu Tab prin tot meniul. Tema îl are — dar e ascuns cu -9999px și rămâne ascuns inclusiv când primește focus, adică exact în momentul în care ar trebui să apară. Practic există, dar nu funcționează pentru nimeni. E și un semnal mic de calitate pentru audit-urile de accesibilitate (Lighthouse).

100vh înseamnă „înalt cât tot ecranul". Problema pe mobil: bara de adresă a browserului apare și dispare la scroll, iar „tot ecranul" își schimbă definiția din mers — hero-ul sare vizibil, mai ales în Safari pe iPhone. svh (small viewport height) e unitatea modernă care înseamnă „ecranul cu bara de adresă vizibilă" — o valoare stabilă, care nu se mai mișcă. Fallback-ul 100vh rămâne pentru browserele foarte vechi care nu știu de svh.

Când arhiva va avea destule articole pentru pagina 2, vizitatorul ajuns acolo nu are niciun link înapoi spre pagina 1 — singura opțiune e butonul Back al browserului. Și crawlerele preferă paginarea în ambele direcții pentru a parcurge complet arhiva.

„Focus" e elementul activ pentru tastatură — cel pe care îl acționezi cu Enter și de la care pleacă Tab. Acum, când se deschide lightbox-ul cu video, focusul rămâne pe pagina din spate: cine apasă Tab se plimbă prin conținut acoperit, invizibil, iar utilizatorii de screen reader nu află că s-a deschis ceva. Regula standard pentru orice fereastră modală: la deschidere focusul intră în ea, la închidere se întoarce de unde a plecat.