Optimizare on-site si performanta SEO: studiu de caz

Optimizare on-site si performanta SEO: studiu de caz

Un magazin de mobilier care se încărca în 17 secunde pe telefon

Nu era prost construit. Doar că nimeni nu se uitase vreodată la cifre. Povestea a ceea ce am găsit sub capotă la un magazin de mobilier italian din Timișoara — și de ce cea mai mare parte a muncii de optimizare on-site a însemnat măsurat, nu scris cod.

Casa Preziosa vinde mobilier italian în Timișoara. Site-ul arăta bine, produsele erau frumos fotografiate, textele scrise cu cap. Și totuși, pe un telefon cu conexiune obișnuită, imaginea principală a paginii de start apărea abia după 17,7 secunde. Nimeni nu așteaptă atât. Google cu atât mai puțin.

Am pornit de la un audit de optimizare on-site și am terminat cu o lecție pe care o repetăm des clienților: în optimizarea performanței pentru SEO, partea grea nu e să scrii cod, ci să afli exact ce anume încetinește pagina. Am greșit de câteva ori pe drum, tocmai pentru că am presupus în loc să măsurăm.

Regula care ne-a scutit de săptămâni de muncă

Prima tentație a oricui deschide un raport PageSpeed e să înceapă de sus și să bifeze recomandările una câte una. E o capcană: raportul îți arată simptomele, nu cauza.

La un moment dat, instrumentul ne indica o secțiune de bannere ca fiind elementul care „sare" pe ecran. Am fi putut petrece o zi întreagă reparând acea secțiune. În realitate, ea era doar victima: se mișca pentru că altceva, de deasupra ei, își schimba înălțimea. Diagnosticul corect a venit abia când am deschis tabelul detaliat și am urmărit lanțul până la sursă.

Fiecare oră petrecută pe măsurare corectă ne-a economisit o zi de reparat lucruri care nu erau stricate.

Trei megabytes ascunși într-o singură imagine

Cea mai mare descoperire a fost și cea mai simplă. Banner-ul de pe prima pagină cântărea 2,1 MB — mai mult decât tot restul site-ului la un loc. Motivul: fotografia fusese salvată în format PNG, potrivit pentru logo-uri și grafice, dar complet nepotrivit pentru o fotografie.

Am găsit apoi ceva și mai contraintuitiv. Sistemul genera automat o versiune de 1920 de pixeli lățime dintr-un original care avea doar 1099. Adică mărea forțat fotografia, producând un fișier mai greu și, în același timp, mai neclar decât originalul. Am corectat dimensiunile cerute și am lăsat sistemul să micșoreze, nu să umfle.

Apoi am trecut toate miniaturile de produs în format WebP, care comprimă mult mai eficient la aceeași calitate vizuală. Pe una dintre imaginile semnalate explicit de Google: de la 63,8 KB la 23,0 KB. Aceeași fotografie, aceeași claritate, o treime din greutate.

Lucrul pe care îl uită aproape toată lumea

Niciuna dintre cele 39 de imagini ale paginii nu avea declarate dimensiunile în cod. Fără ele, browserul nu știe cât spațiu să rezerve, așa că randează textul, apoi îl împinge în jos când sosește fiecare fotografie. Vizitatorul dă să apese un buton și butonul îi fuge de sub deget. Google măsoară exact acest lucru și îl penalizează.

Am adăugat dimensiunile peste tot și am activat încărcarea amânată pentru ce e sub pliu — imaginile de jos nu se mai descarcă până nu ajungi la ele.

De la 51 de cereri la 12

Fiecare fișier cerut de o pagină costă un drum dus-întors până la server. Pe fibră nu se simte; pe 4G în mișcare, se adună. Site-ul cerea 15 fișiere separate de stil și de cod.

Le-am combinat în câte unul singur, păstrând ordinea exactă — într-un CSS, ordinea decide care regulă câștigă, iar o inversiune ar fi stricat aspectul în locuri greu de observat. Am adăugat și un mecanism prin care adresa fișierului se schimbă automat la fiecare modificare, ca vizitatorii să nu rămână niciodată cu o versiune veche în memoria browserului.

Tot aici am găsit o bibliotecă din 2014, rămasă din șablonul original, care bloca afișarea paginii timp de o jumătate de secundă. Am verificat riguros înainte să o ștergem: adăuga 42 de clase în pagină, dar nicio regulă de stil și niciun cod nu le folosea. Șase kilobytes care costau 530 de milisecunde degeaba.

Partea cu adevărat fină: stilurile critice

După toate curățările, mai rămăsese un blocaj: browserul nu putea desena nimic până nu descărca întregul fișier de stiluri, 110 KB, ceea ce însemna aproape o secundă și jumătate de ecran alb.

Soluția se numește CSS critic: extragi exact regulile necesare pentru prima ecranare, le pui direct în pagină, iar restul se încarcă în fundal, fără să blocheze nimic. Sună simplu. Nu e.

Am extras regulile automat, apoi le-am verificat pe cinci tipuri de pagină și la două lățimi de ecran, comparând poziția fiecărui element din prima ecranare cu și fără fișierul complet. Verificarea a prins trei lucruri pe care extragerea automată le ratase — printre care o categorie întreagă de reguli care se aplică doar înainte ca JavaScript-ul să pornească și pe care niciun instrument automat nu are cum să le vadă.

La final am aplicat același principiu și fontului. Un fișier de 1,4 KB de la Google Fonts bloca afișarea 750 de milisecunde, doar pentru că venea de pe alt domeniu. În loc să găzduim fontul local — ceea ce ar fi adăugat sute de kilobytes din cauza setului de caractere cu diacritice — am mutat doar declarațiile în pagină, lăsând fișierele acolo unde erau. Cererea care bloca a dispărut, traficul a rămas identic.

Saltul de 400 de pixeli

Cel mai persistent defect a fost un salt vizual pe care l-am reparat, l-am crezut rezolvat, apoi l-am văzut reapărând. Merită povestit, pentru că explică de ce testele repetate contează.

Carusel-ul de pe prima pagină avea două imagini. Până pornea codul care le transformă în slider, ambele stăteau una sub alta — 800 de pixeli. Când prelua controlul, rămânea una singură, iar pagina se scurta brusc cu 400 de pixeli, împingând în sus tot ce urma.

Am rezolvat-o făcând ca, până la pornirea codului, doar prima imagine să ocupe spațiu. Înălțimea e astfel corectă din prima secundă. Defectul a revenit o dată, când am mutat fișierul de stiluri în fundal și regula respectivă a început să ajungă prea târziu — exact genul de efect secundar pe care nu îl vezi decât dacă retestezi după fiecare schimbare.

Optimizare on-site: ce vede efectiv Google

Viteza e doar jumătate din poveste. Cealaltă jumătate ține de cum înțelege un motor de căutare pagina. Aici am lucrat pe mai multe planuri:

• Titluri și descrieri generate dinamic, cu limită de lungime, ca Google să nu le taie în rezultate. Fiecare pagină de produs sau categorie își compune titlul din denumire, categorie și oraș, alegând automat varianta care încape.
• Date structurate pentru produse, categorii, articole, firmă și fir de navigare — informația pe care Google o folosește pentru rezultatele îmbogățite și pe care motoarele bazate pe inteligență artificială o citesc când formulează răspunsuri.
• Un singur domeniu canonic. Site-ul răspundea și cu, și fără „www", ceea ce pentru Google înseamnă două site-uri identice care își fură reciproc relevanța.
• Texte alternative diferențiate la imagini. Aceeași descriere repetată de cinci ori nu ajută pe nimeni; una specifică fiecărei fotografii aduce trafic din căutarea de imagini.
• Durate de păstrare în memorie crescute de la 7 zile la un an pentru fișierele care nu se schimbă niciodată sub același nume.

Accesibilitatea, care nu e un capitol separat

Multe dintre corecturile de accesibilitate ajută direct și la SEO, pentru că rezolvă aceeași problemă: pagina trebuie să fie inteligibilă și pentru cine nu o vede.

Am dat nume descriptive butoanelor care conțineau doar o iconiță, am adăugat reperul principal de conținut care lipsea cu totul, am mărit zonele de atingere de pe telefon — de la 80 de elemente prea mici la 4, fără nicio schimbare vizibilă în aspect — și am corectat contrastul textelor gri deschis, de la 36 de cazuri sub prag la unul singur.

Unde am ajuns

Imaginea principală apare acum de aproape șase ori mai repede, iar pagina cântărește cât o cincime din ce cântărea. Pe desktop, toate categoriile sunt în verde.

Ce puteți lua de aici, chiar dacă nu ne sunați

Deschideți raportul detaliat, nu doar scorul. Lista de recomandări vă arată simptome. Tabelele din spatele fiecărei recomandări vă arată cauza, și de obicei sunt două-trei lucruri care explică aproape tot.

Verificați formatul fotografiilor. O singură imagine salvată greșit poate cântări mai mult decât restul site-ului. E cea mai ieftină reparație cu cel mai mare efect.

Declarați dimensiunile imaginilor. Două atribute în plus, și pagina nu mai sare sub degetul vizitatorului.

Măsurați de două ori. Unele defecte apar doar când codul apucă să ruleze într-o anumită ordine. Dacă un rezultat vi se pare ciudat, repetați testul înainte să trageți concluzii — noi am învățat-o pe pielea noastră.