Viteza pe telefon: imaginile, fonturile și scripturile

Când un site de prezentare merge greu pe telefon, vinovații sunt aproape mereu aceiași trei: o poză mare pusă sus, fonturile încărcate în prea multe variante și scripturi care opresc pagina până termină ele. Le iei în ordinea asta și, de cele mai multe ori, nu mai ai nevoie de altceva.

Ce măsoară Google și de ce contează telefonul

Google urmărește trei semnale de viteză și stabilitate, numite Core Web Vitals. Pentru două dintre ele pragurile sunt clare: LCP (cât durează până apare cel mai mare element de pe primul ecran, de obicei poza principală) ar trebui să fie sub 2,5 secunde, iar CLS (cât „sare” pagina în timp ce se încarcă) sub 0,1. Al treilea semnal, FID, măsoară reacția la primul clic. Google a anunțat în mai că din martie 2024 îl înlocuiește cu INP, care urmărește toate atingerile de pe pagină, cu pragul „bun” la 200 de milisecunde.

Valorile se citesc la percentila 75, separat pentru telefon și desktop. Pe scurt: trebuie să meargă bine pentru trei din patru vizitatori, pe telefoanele și conexiunile lor. Laptopul tău de pe WiFi-ul de la birou nu contează.

Imaginile: poza de sus decide

Poza mare din primul ecran e, de obicei, elementul LCP. Câteva reguli:

• Nu o încărca „leneș”. Atributul loading="lazy" amână încărcarea pozelor până ajung aproape de ecran. E foarte bun pentru galeria de mai jos, dar pus pe poza de sus o întârzie degeaba. Ghidul web.dev e direct: nu folosi lazy loading pe imaginea LCP.
• Spune-i browserului că e importantă. fetchpriority="high" pe poza de sus o pune în fața cozii. Pe una sau două imagini, nu pe toate.
• Format modern și compresie. WebP sau AVIF, comprimate, la mărimea la care se afișează. O poză de 4.000 de pixeli lățime pe un ecran de telefon e muncă irosită.
• Mai multe mărimi. Cu srcset, telefonul primește varianta mică, iar monitorul mare varianta mare.
• Lățime și înălțime în cod. Cu width și height puse pe fiecare imagine, browserul știe dinainte cât loc să păstreze, iar textul nu mai sare când apare poza. Asta îți ține CLS-ul jos.

Fonturile: mai puține și mai ușoare

Fiecare grosime și fiecare stil al unui font e un fișier separat. Un site care încarcă patru familii, fiecare în cinci grosimi, trage după el zeci de fișiere înainte să arate un rând de text.

Ce facem noi la site-urile de prezentare:

1. Două familii, cel mult. Una pentru titluri, una pentru text. Uneori una ajunge.
2. Doar grosimile folosite. Dacă textul e „regular” și „bold”, nu încarci „light”, „medium” și „black”.
3. WOFF2. Are cea mai bună compresie și merge în browserele de azi.
4. Subset. Păstrezi doar caracterele de care ai nevoie, cu diacriticele românești incluse. Verifici întâi licența fontului, nu toate permit asta.
5. font-display. Cu swap textul apare imediat cu un font de sistem și se schimbă când vine fontul tău. Cu optional browserul așteaptă cel mult în jur de 100 ms și, dacă fontul întârzie, rămâne la cel de sistem, fără ca pagina să sară.

Preîncărcarea fonturilor (preload) ajută doar la fontul principal; pusă pe toate, concurează cu poza de sus.

Scripturile: nimic sincron în antet

Un script pus în <head> fără nimic pe el oprește desenarea paginii până se descarcă și rulează. Ghidul Google spune că aproape niciodată nu e nevoie de scripturi sincrone acolo. Ce faci:

• pui defer pe scripturile tale, ca să ruleze după ce pagina e citită;
• pui async pe cele care nu depind de nimic, cum ar fi statisticile;
• scoți ce nu mai folosești: un slider vechi, un chat abandonat, două coduri de măsurare pentru același lucru.

Scripturile grele afectează și reacția la atingere, adică exact ce va măsura INP din martie. Un buton de meniu care răspunde după o secundă se simte stricat, chiar dacă pagina s-a încărcat repede.

CSS-ul: mic și la obiect

Foaia de stil blochează și ea afișarea. Dacă e mai mare decât poza de sus, o întârzie. Scoți regulile nefolosite (temele gata făcute vin cu mult surplus) și amâni ce nu ține de primul ecran.

Cum verifici

Deschide PageSpeed Insights, pune adresa și uită-te întâi la fila pentru telefon. Partea de sus arată datele reale ale vizitatorilor (dacă site-ul are destule vizite), partea de jos un test de laborator cu sugestii. Repară câte un lucru și măsoară din nou, ca să știi ce a ajutat. Despre ce înseamnă fiecare semnal am scris mai pe larg în articolul despre Core Web Vitals.

Dacă vrei un site făcut de la început cu viteza asta în minte, vezi serviciile de web design.