Ang mga imahe ay kadalasang pinakamabigat na bagay sa isang pahina, na ginagawa silang pinakamalaking lever ng bilis na kontrolado mo. Tamaan nang tama ang kanilang sukat at bigat ng file at parang agad-agad ang mga pahina. Mali ang mga ito at bumabagsak ka sa Core Web Vitals gaano man kalinis ang iyong code. Narito ang mga target at ang workflow para maabot ang mga ito.
Mga target sa sukat
Itugma ang pixel size ng imahe sa kung saan ito aktwal na lumalabas. Magaspang na gabay:
- Full-width hero: 1600–2000 px ang lapad ay sumasaklaw sa karamihan ng desktop layout. Bihirang makatulong ang mas malapad at gumagastos ng maraming byte.
- In-content na larawan: ang lapad ng iyong content column, karaniwang 800–1200 px.
- Thumbnail / card na imahe: 300–500 px.
- Avatar / icon: 48–200 px sa laking ipinapakita nito.
Ang pagbibigay ng 4000px na imahe sa 800px na slot ay nangangahulugang nada-download at nade-decode ng browser ang 25× na pixels na ipapakita lang nito kailanman. Purong aksaya iyon — at ang pag-decode ng malalaking imahe ay nagju-jank din sa main thread.
Mga target sa bigat
Itinatakda ng sukat ang kisame; itinatakda ng compression ang aktwal na bigat. Layunin:
- Hero image: wala pang 200 KB (mas mainam ang 100–150 KB).
- In-content na larawan: 80–150 KB.
- Thumbnail: 10–30 KB.
- Kabuuang imahe kada pahina: subukang manatili sa ilalim ng ~1 MB para sa buong pahina.
Kung ang isang imahe ay lumampas sa ~300 KB, ituring itong bug na iimbestigahan.
Bakit nito pinapatakbo ang Core Web Vitals
Ang Largest Contentful Paint (LCP) ng Google ay sinusukat kung gaano katagal bago ma-render ang pinakamalaking elemento sa screen — at sa karamihan ng pahina, ang pinakamalaking elementong iyon ay isang imahe (kadalasan ang hero). Ang mabigat, sobrang laking hero ay direktang nagpapalobo sa LCP. Ang magandang LCP ay wala pang 2.5 segundo; ang lobong hero ay maaaring lumampas doon sa mobile na koneksyon nang mag-isa.
Dalawa pang panalo na may kaugnayan sa imahe:
- Itakda ang width at height attributes para makapaglaan ng espasyo ang browser — pinoprotektahan niyon ang iyong Cumulative Layout Shift (CLS) na iskor.
- Bigyang-priyoridad ang hero (huwag i-lazy-load ang LCP na imahe) at i-lazy-load ang lahat sa ibaba ng fold.
Ang dalawang-hakbang na workflow
Hakbang 1 — i-resize sa tunay na display width. Gamitin ang Image Resizer para ibaba ang bawat imahe sa laking lumalabas ito. Aspect-lock naka-on, high-quality na downscale. Ito lang ay madalas nagbabawas ng bigat nang 80–90%.
Hakbang 2 — mag-compress. Ibigay ang mga na-resize na file sa Image Compressor: kalidad 75–85 para sa larawan (visually lossless), 256-color quantization para sa PNG. Hindi ito kailanman naglalabas ng file na mas malaki kaysa orihinal, humahawak ng batch, at may opsyonal na width cap para epektibong magawa mo ang dalawang hakbang nang sabay. Para sa makabagong browser, ang pag-convert ng larawan sa WebP ay pumipiga ng dagdag na 25–35%.
Sukatin ito, huwag hulaan
Kapag na-optimize na ang iyong mga imahe, kumpirmahin na aktwal na bumilis ang pahina. Ang Page QA ng IMG.DIY ay ina-audit ang isang live na URL sa pamamagitan ng Google PageSpeed Insights at inuulat ang bigat ng imahe ng pahina para makita mo ang anumang file na masyado pa ring mabigat. Isang caveat: kailangan ng Page QA ng koneksyon sa internet — hindi tulad ng mga image tool, tinatawagan nito ang PageSpeed API ng Google, kaya hindi ito tumatakbo offline. Gamitin ito pagkatapos mong mag-deploy para tsekan ang iyong tunay na LCP at image budget.
Pribado bilang default
Ang resize, compress, at convert na tool ay tumatakbo nang buo sa iyong browser gamit ang Canvas at WebAssembly — walang ina-upload, at pagkatapos ng iyong unang pagbisita, naka-cache sila at gumagana offline. Kaya mong ihanda ang halaga ng imahe ng buong site nang walang koneksyon, tapos patakbuhin ang Page QA online kapag buhay na ang pahina.
Mabilisang balik-tanaw: tamang-sukatin ang mga sukat, i-compress sa mga target na bigat, bigyang-priyoridad ang hero para sa LCP, at i-verify gamit ang Page QA.