Ang 1920-pixel na lapad na larawan sa pahina ay buong dina-download din ng mga gumagamit ng phone, tapos pinaliliit sa 390 pixels sa screen — limang beses na bandwidth at mas mabagal na pag-load nang walang saysay. Hinahayaan ng srcset ang browser na pumili ng bersyong babagay sa screen, basta nagawa mo na ang mga bersyong iyon.
Bakit hindi sapat ang isang larawan
Ang LCP sa Core Web Vitals ay kadalasang ang malaking larawan sa itaas ng fold. Kapag 1920-wide, 400KB na file ang ibinigay sa phone, bihirang umabot sa 2.5 segundo ang LCP; ang 480-wide, 40KB na bersyon sa parehong koneksyon ay mas mabilis nang isang order of magnitude. Direktang binabasa ng page-experience signal ng Google ang numerong iyon.
Sa kabilang banda, mukhang malabo ang 768-wide na larawan sa malaking desktop. Kaya maraming sizes, at ang browser ang pipili.
Praktikal na breakpoint table
Sumusunod ang breakpoints sa lapad ng larawan kapag naka-render sa pahina, hindi sa viewport. Para sa dalawang karaniwang kaso, ang full-width banners at mga larawan sa loob ng artikulo:
- Full-width images (hero, banners): 480, 768, 1200, 1920. Phone, tablet, laptop, malaking display.
- Article figures (content column na hanggang mga 800): 400, 800, 1200; ang 1200 ang para sa 1.5x–2x na screens.
- Thumbnails at cards (naka-render sa mga 300): 300 at 600.
Hindi mas mabuti ang mas maraming hakbang. Bawat isa ay karagdagang export at karagdagang file na iimbakin, at kinukunsinti ng mga browser ang hindi eksaktong tugma, kaya ang mga hakbang na 1.5–2x ang pagitan ang sweet spot. Higit sa siyam sa sampung kombinasyon ng device ang saklaw ng apat na hakbang.
Kailangan ba ng 2x versions?
Tumatakbo ang Retina at karamihan ng phone screens sa 2x–3x density; ang larawang naka-render sa 400 ang lapad ay nangangailangan ng 800 pixels para maging matalas doon. Ang mas malalaking hakbang sa table ay umaaktong 2x version na ng mas maliliit — ang 768 ay 2x para sa 390-wide na phone, ang 1200 ay 2x para sa 600-wide na column.
Kaya hindi na kailangan ng hiwalay na “@2x” set. Panatilihin ang halos 2x na pagitan ng mga hakbang at ang browser na ang pipili ng mas mataas ayon sa density.
Format: WebP muna, JPG bilang fallback
Sa parehong quality, 25–35 porsyentong mas maliit ang WebP kaysa JPG at sinusuportahan ito ng lahat ng modernong browser. I-export ang WebP sa bawat size at magtabi ng JPG fallback gamit ang picture element para sa lumang browsers; kung hindi na mahalaga sa audience mo ang mga browser bago mag-2020, sapat na ang WebP lang.
Mas maliit pa ang AVIF pero mas mabagal itong i-encode sa browser, na problema sa malalaking batch. Nasa AVIF vs WebP vs JPEG ang detalye ng mga trade-off.
Batch-export ng buong set
Ilagay ang mga source image sa Batch Image Processing at mag-run nang isang beses kada hakbang, binabago ang width at suffix sa bawat pagkakataon:
- Laki: width 480, naka-off ang Payagang palakihin ang maliliit na larawan, output na WebP sa 80 porsyento, suffix -480.
- Parehong settings sa 768 na may suffix -768; pagkatapos 1200; pagkatapos 1920.
- Para sa JPG fallback, gawing JPG ang output, panatilihin ang mga suffix, at mag-run ulit.
Ilang segundo lang ang bawat run at nasa ZIP na ang hero-480.webp, hero-768.webp at iba pa, handa nang ilagay sa images folder. Panatilihing naka-off ang pag-upscale para hindi kailanman ma-stretch ang 1000-pixel na original sa 1920.
Para makita ang pagkakaiba ng laki sa bawat hakbang sa isang larawan, subukan ang Image Resizer sa iisang file.
Pagsulat ng HTML
Para sa full-width na larawan:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Para sa article figures, itakda ang sizes sa totoong lapad, hal. sizes="(max-width: 840px) 100vw, 800px". Laging isama ang width at height para magreserba ng espasyo ang browser at hindi tumalon ang pahina.
Kapag tapos na iyan, idagdag ang payo tungkol sa lazy-loading at compression sa how to make images load faster at halos sagad na ang bahagi ng larawan sa performance score mo.