Gambar laman web: format, saiz dan kesan sebenar pada kelajuan

Gambar ialah bahagian paling berat pada hampir setiap laman web. Pembaca menilai laman daripada apa yang muncul dahulu pada skrin, dan gambar pembuka yang lambat muncul membuat seluruh laman nampak tidak kemas walaupun ayatnya elok dan susun aturnya teratur. Masalahnya, berat gambar tidak kelihatan. Fail gambar tidak memaparkan saiznya di mana-mana, jadi satu-satunya cara untuk tahu ialah mengukur, dan mengukur bermakna melihat angka yang nyata, bukan rasa.

Empat angka yang perlu difahami sebelum menyentuh apa-apa gambar

Bab Page Weight dalam Web Almanac 2025 yang diterbitkan HTTP Archive pada 15 Januari 2026 mengambil data Julai 2025 daripada berjuta laman. Halaman utama median pada telefon berjumlah 2,559 KB, dan 911 KB daripadanya ialah gambar, iaitu 35.6 peratus daripada jumlah. Pada komputer meja, jumlahnya 2,862 KB dengan 1,058 KB gambar, iaitu 37 peratus. Halaman dalam lebih ringan, 1,769 KB pada telefon dengan hanya 354 KB gambar.

• ▸ 911 KB gambar pada halaman utama median telefon, berbanding 632 KB JavaScript, 122 KB fon, 77 KB CSS dan 22 KB HTML.
• ▸ 6,288 KB, iaitu kira-kira 6.1 MB, gambar pada laman di persentil ke-90 untuk telefon. Persentil ke-90 bermaksud nilai yang memisahkan 90 peratus pelawat paling ringan daripada 10 peratus paling berat, jadi laman yang lebih berat daripada median bukan sekadar lebih 10 peratus berat.
• ▸ 186 KB saiz satu fail gambar di persentil ke-90 pada telefon, manakala median hanya 8 KB kerana banyak piksel penjejak analitik bersaiz kecil dikira sama.
• ▸ 45.8 peratus lebih berat halaman utama berbanding halaman dalam secara purata pada Julai 2025, dan gambar ialah penyumbang terbesar perbezaan itu.

Empat angka ini sudah cukup untuk menjawab satu persoalan yang selalu timbul, patutkah saya mulakan dengan gambar atau dengan sesuatu yang lain. Jawapannya gambar dahulu, kerana di situlah paling banyak bait boleh diselamatkan tanpa mengubah apa yang pembaca lihat.

Format: JPEG, PNG, WebP dan AVIF, bezanya diukur dalam bait

Kajian mampatan WebP oleh Google menunjukkan fail WebP lossy 25 hingga 34 peratus lebih kecil daripada JPEG pada kualiti yang sama, diukur dengan indeks SSIM yang sama. Angka itu datang daripada kajian kejuruteraan yang boleh disemak, bukan janji pemasaran. AVIF pula biasanya lebih kecil daripada WebP, tetapi masa pengekodannya lebih lama dan sokongan penyemak imbasnya lebih baru, jadi ia pilihan untuk laman yang sudah mengurus gambar secara automatik.

Gambar di web masih banyak format lama. Bab Performance dalam Web Almanac 2025 menunjukkan 57 peratus gambar unsur terbesar halaman atau LCP ialah JPEG, 26 peratus PNG, 11 peratus WebP dan AVIF hanya 0.7 peratus. Maksudnya, kalau anda tukar satu laman ke WebP, anda sudah mendahului sebahagian besar web, dan itu bukan kerja yang sia-sia.

Contoh sebenar dari dua laman berita Malaysia

Saya mengukur dua laman berita Malaysia pada 27 September 2026 dari satu pelayan di Jerman, menggunakan sambungan pusat data supaya keadaan rangkaian tidak menjadi pemboleh ubah yang mengacau. Ambil satu foto berita daripada Malay Mail, fail bernama 364953.jpg. Saiznya 1,000 x 666 piksel dan beratnya 586.2 KB. Bila dikod semula pada saiz piksel yang sama dengan kualiti 80, saiznya jadi 161.2 KB sebagai JPEG dan 124.1 KB sebagai WebP. Beza itu 72.5 peratus dan 78.8 peratus, dan tiada apa yang berubah pada saiz paparan.

Sinar Harian menunjukkan keadaan yang berbeza. Halaman utamanya sudah menghantar imej kecil dalam format WebP, 14 gambar yang saya ukur berjumlah 281.5 KB dengan yang terbesar 54.6 KB. Versi lebih besar pada laman yang sama, 1,000 x 670 piksel, berjumlah 107.2 KB dan masih boleh turun ke 62.4 KB pada kualiti 60, penjimatan 41.8 peratus. Laman ini bukan contoh masalah berat gambar, ia contoh bahagian yang sudah betul dan boleh jadi ukuran untuk laman lain.

Satu pemerhatian yang penting sebelum anda menilai mana-mana laman daripada HTML mentah. Halaman utama Malay Mail hanya membawa 23.2 KB gambar dalam HTML kerana majoriti gambar diletakkan sebagai pemegang tempat menerusi atribut data-src dengan lebar 30 piksel, dan fail sebenar dimuat kemudian. Jadi angka kecil pada HTML mentah tidak bermakna laman itu ringan. Ia bermakna anda belum melihat gambarnya.

Saiz piksel biasanya lebih besar kesannya daripada format

Ramai orang berdebat tentang format sedangkan punca paling besar ialah bilangan piksel. Foto 1,000 x 666 piksel mengandungi 666,000 piksel. Bila dikecilkan ke 450 x 300 piksel untuk kad senarai, ia menjadi 135,000 piksel, iaitu 20.3 peratus sahaja daripada piksel asal. Kurangkan piksel dan anda kurangkan data yang perlu dihantar, tidak kira format apa pun yang anda pilih.

Sisi lain pula telefon. Skrin berketumpatan tinggi menggandakan piksel yang diperlukan. Gambar yang dipaparkan 450 piksel lebar pada skrin tiga kali ganda memerlukan fail 1,350 piksel lebar untuk kelihatan tajam. Inilah sebabnya atribut srcset dan sizes wujud, supaya telefon menerima versi yang sesuai dan bukan versi terbesar yang ada di pelayan.

<img src="/gambar/hero-800.webp"
     srcset="/gambar/hero-450.webp 450w, /gambar/hero-800.webp 800w, /gambar/hero-1280.webp 1280w"
     sizes="(max-width: 700px) 100vw, 800px"
     width="800" height="533" alt="keterangan gambar"
     loading="lazy" decoding="async">

Tetapkan atribut width dan height supaya ruang gambar dikhaskan sebelum fail tiba. Tanpa kedua-dua atribut itu, susun atur halaman bergerak semasa gambar muncul, dan pembaca boleh tersalah tekan pautan kerana butang berpindah di bawah jarinya.

Bila TIDAK patut buat begini

Ada keadaan yang usaha ini tidak berbaloi, atau lebih buruk, merosakkan laman. Lima keadaan di bawah ialah yang paling kerap saya temui.

• ▸ Lazy loading pada gambar utama. Web Almanac mengukur kira-kira 16 hingga 17 peratus halaman telefon melakukannya pada gambar LCP, dan 10.4 peratus daripadanya menggunakan loading=lazy asli. Melengah gambar utama bermakna melengah perkara pertama yang pembaca tunggu. Gambar di atas lipatan patut dimuat segera dan boleh diberi fetchpriority=high, walaupun teknik itu baru dipakai pada 17.3 peratus halaman telefon.
• ▸ Menukar ikon dan gambar kecil di bawah 10 KB. Penjimatan baitnya terlalu kecil untuk dirasai pembaca, tetapi anda menambah satu langkah dalam saluran kerja yang perlu dijaga setiap kali gambar baharu naik.
• ▸ Tangkapan skrin yang mengandungi teks halus. Pengekodan lossy membuat huruf bertindih kabur dan laman nampak murah. Untuk gambar sebegini, PNG atau WebP lossless lebih sesuai, dan pilihan terbaik ialah menulis semula maklumat itu sebagai teks biasa yang boleh dibaca mesin.
• ▸ Gambar daripada domain lain tanpa persediaan. 16 peratus halaman telefon menghantar gambar LCP daripada hos yang berbeza, dan setiap hos baharu memerlukan persediaan DNS, TCP dan TLS sebelum sebarang bait gambar tiba.
• ▸ Menukar seluruh gambar tanpa mengukur dahulu. Ukur masa LCP dahulu, kenal pasti gambar mana yang menjadi unsur terbesar, barulah tukar. Kerja buta boleh mengambil masa berjam-jam untuk penjimatan yang tidak dapat diukur.

Cara menyemak laman sendiri dalam sepuluh minit

Buka PageSpeed Insights pada pagespeed.web.dev dan masukkan alamat laman anda. Lihat audit Serve images in next-gen formats serta senarai peluang yang diberi nilai dalam saat. Kemudian buka tab Network dalam DevTools penyemak imbas, tapis mengikut jenis Img, susun mengikut saiz, dan lihat lima fail teratas. Dua arahan terminal di bawah sudah cukup untuk tahu sama ada pelayan anda menghantar WebP atau JPEG kepada pelawat.

curl -sS -o /dev/null -w 'saiz: %{size_download} bait, jenis: %{content_type}\n' https://contoh.my/gambar.jpg
curl -sS -H 'Accept: image/webp,image/avif,*/*' -o /dev/null -w 'jenis diberi: %{content_type}\n' https://contoh.my/gambar.jpg

Arahan kedua itu yang penting. Pelayan yang menyokong WebP melalui content negotiation akan menjawab dengan jenis image/webp apabila pelawat menyokongnya, dan itu bermakna anda tidak perlu menyimpan dan menamakan dua versi fail secara manual untuk setiap gambar.

Laman ini sendiri: 40 gambar utama, purata 76.7 KB

Untuk pos ini saya periksa gambar blog thalhah.my sendiri. Terdapat 40 gambar utama bersaiz 1,280 piksel dalam format WebP dengan purata 76.7 KB, paling kecil 26.9 KB dan paling besar 319.6 KB. Versi kad 450 piksel pula purata 14.4 KB. Gambar 319.6 KB itu calon pertama untuk dikod semula kerana ia 4.2 kali ganda purata laman ini, dan ia datang daripada gambar pemandangan yang mempunyai banyak daun serta air, dua jenis tekstur yang paling mahal untuk pengekodan lossy.

Kalau anda mahu urutan pemeriksaan yang lebih menyeluruh daripada sekadar gambar, saya pernah tulis urutan diagnosis penuh dalam pos kenapa laman web lambat, dan versi kerja sebenar dalam pos urutan diagnosis yang saya guna, kedua-duanya di laman ini.

Senarai semak sebelum naik gambar baharu

• ▸ Kecilkan gambar di komputer sebelum naik ke pelayan. Lebar 1,280 piksel untuk gambar utama dan 450 piksel untuk kad senarai sudah cukup pada kebanyakan paparan.
• ▸ Simpan sebagai WebP kualiti 70 hingga 80. Nilai itu jarang menunjukkan beza yang ketara pada foto, tetapi menjimatkan puluhan kilobait setiap fail.
• ▸ Guna PNG atau WebP lossless untuk tangkapan skrin, logo dan gambar rajah yang mempunyai garisan tajam atau teks.
• ▸ Tetapkan atribut width dan height dalam HTML supaya ruang gambar dikhaskan dan susun atur tidak bergerak.
• ▸ Guna loading=lazy hanya untuk gambar di bawah lipatan, dan jangan sesekali pada gambar utama.
• ▸ Berikan fetchpriority=high kepada satu gambar utama sahaja, kerana menandakan semua gambar sebagai keutamaan sama dengan tidak menandakan apa-apa.
• ▸ Isi atribut alt dengan ayat yang menerangkan gambar, kerana ia membantu pembaca skrin dan memberi konteks kepada enjin carian.
• ▸ Selepas tiga bulan, semak semula lima gambar paling berat. Gambar baharu masuk lebih kerap daripada yang anda sangka.

Apa yang belum jelas

Angka dalam pos ini datang daripada data agregat HTTP Archive dan pengukuran saya sendiri pada dua laman berita Malaysia dan laman ini. Saya tidak mengukur daripada telefon di Malaysia menggunakan data mudah alih, jadi laju sebenar di menara tempatan boleh berbeza. Apa yang boleh dikatakan dengan yakin ialah turutan keutamaannya, iaitu gambar dahulu, kemudian JavaScript, kemudian fon. JavaScript pun tidak kecil, halaman utama median telefon membawa 632 KB JavaScript, jadi membersihkan gambar bukan bermakna masalah kelajuan selesai.

Yang pasti, mengurangkan berat gambar ialah kerja yang paling selamat untuk dimulakan kerana ia jarang mengubah rupa laman, tiada kod aplikasi perlu ditulis semula, dan hasilnya boleh diukur dalam bait serta saat. Mulakan dengan satu gambar paling berat pada laman anda, ukur sebelum dan selepas, dan keputusan itu akan memberitahu sama ada baki laman berbaloi melalui proses yang sama.