Imagini și viteza paginii: formate, dimensiuni, lazy loading

De ce imaginile decid timpul de încărcare

Google scrie că imaginile sunt adesea cel mai mare factor din mărimea totală a unei pagini, ceea ce poate face paginile lente și costisitoare la încărcare. Două dintre Core Web Vitals depind direct de imagini. Largest Contentful Paint (LCP) măsoară încărcarea: Google recomandă ca cel mai mare element să apară în primele 2,5 secunde după ce pagina începe să se încarce. Pe multe pagini, acest element este o imagine, de exemplu o fotografie mare în partea de sus. Cumulative Layout Shift (CLS) măsoară stabilitatea vizuală și ar trebui să rămână sub 0,1. Imaginile care sosesc fără spațiu rezervat împing textul în jos și cresc această valoare.

Formatul potrivit

• Fotografii: JPEG funcționează peste tot. WebP și AVIF sunt adesea vizibil mai mici la o calitate similară.
• Grafică cu margini clare sau transparență: PNG, ori WebP și AVIF, care pot fi și ele transparente.
• Logouri și pictograme: SVG, pentru că rămâne clar la orice mărime și este de obicei foarte mic.
• Căutarea Google acceptă imagini în atributul src în formatele BMP, GIF, JPEG, PNG, WebP, SVG și AVIF.

Dacă oferi WebP sau AVIF, poți păstra un JPEG ca rezervă într-un element picture. Browserul alege prima sursă pe care o înțelege.

Mărimea potrivită

O imagine lată de 2400 de pixeli, dar afișată la 600 de pixeli, irosește cea mai mare parte din octeții ei. Exportă imaginile cam la lățimea la care sunt afișate, iar pentru ecranele clare cam la dublul acesteia. Apoi comprimă-le. În multe programe de imagini, o setare de calitate pe la mijlocul scării este suficientă pentru fotografiile de pe web. Verifică rezultatul la mărime completă înainte să înlocuiești originalul.

srcset și sizes

Un singur fișier nu se potrivește niciodată pe toate ecranele. Cu srcset oferi mai multe fișiere ale aceleiași imagini și precizezi lățimea fiecăruia. Cu sizes îi spui browserului cât de lată va fi afișată imaginea. Browserul alege apoi cel mai mic fișier care este suficient de clar.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

În acest exemplu, imaginea umple ecranul pe ecranele înguste și are 700 de pixeli lățime pe cele mai late. Google recomandă să păstrezi mereu o rezervă în atributul src. Scrie un text alternativ real în locul celor trei puncte.

Width și height împotriva deplasărilor de layout

Fără width și height, browserul nu știe de cât spațiu are nevoie o imagine până nu sosește fișierul. Textul de dedesubt sare atunci în jos. Ghidul web.dev despre deplasările de layout recomandă: include mereu atributele width și height la imagini și la elementele video, cu mărimea în pixeli a fișierului sau cel puțin cu raportul de aspect corect. Browserele moderne stabilesc din aceste valori raportul de aspect implicit al unei imagini și rezervă spațiul. În CSS, width: 100% și height: auto păstrează imaginea flexibilă. Dacă nu poți seta atributele, ghidul numește proprietatea CSS aspect-ratio ca alternativă.

Lazy loading

Cu loading="lazy", browserul încarcă o imagine doar când aceasta se apropie de zona vizibilă. Asta economisește date pentru imaginile de mai jos în pagină. Google spune despre lazy loading: nu îl adăuga la conținutul care este probabil vizibil imediat când un utilizator deschide o pagină. Lazy loading-ul integrat în browser este disponibil pentru imagini și iframe-uri.

Imaginea LCP

Cea mai mare imagine din partea de sus, adesea o imagine hero sau fotografia principală a produsului, este cel mai important fișier al paginii. Ghidul web.dev despre LCP spune: nu încărca niciodată imaginea LCP cu lazy loading. fetchpriority="high" este un indiciu pentru browser să o încarce devreme. Potrivit ghidului, o prioritate mare pe mai mult de una sau două imagini nu mai ajută. Imaginile a căror adresă o ascunde o bibliotecă de scripturi în data-src sau care sunt doar un fundal CSS sunt găsite târziu de browser. Pentru o imagine de fundal, ghidul numește un preload cu link rel="preload" în HTML. AVIF sau WebP și un fișier mai mic scurtează și ele timpul de încărcare.

Ca să vezi cum se comportă paginile tale, Google trimite la raportul Core Web Vitals din Search Console. Pentru o singură pagină, instrumentele de performanță ale browserului îți arată care este elementul LCP și ce elemente deplasează layoutul. Măsoară înainte și după o schimbare, ca să știi dacă a ajutat.

O listă scurtă de verificare

• Cea mai mare imagine din partea de sus se încarcă normal, nu cu lazy loading?
• Are fiecare img width și height sau spațiul rezervat cu aspect-ratio?
• Este fiecare fișier cam la fel de lat cum este afișat și este comprimat?
• Fotografiile mari vin în mai multe lățimi, cu srcset și sizes?
• Există fișiere JPEG sau PNG care ar putea fi WebP sau AVIF?

Lucrează cu Do4U

Verificarea imaginilor citește o pagină și fiecare imagine de pe ea. Pentru fiecare fișier raportează formatul, mărimea fișierului și pixelii, iar din HTML width și height, loading, fetchpriority, srcset și sizes, sursele picture și imaginile de fundal din atributele style. Do4U ghicește din HTML imaginea LCP probabilă. Nu o măsoară, pentru că elementul LCP real îl decide browserul. Primești un tabel al imaginilor cu constatările, greutatea totală și un rezumat scurt. Imaginile pe care le inserează JavaScript și imaginile de fundal din fișiere CSS externe nu sunt incluse. Nu se folosește IA, iar verificarea este gratuită, cu o limită zilnică.

Do4U găsește indicii, tu verifici și decizi. Confirmă elementul LCP cu instrumentele de performanță ale browserului înainte să schimbi pagina.