Mengapa Imej Melambatkan Laman Web Anda (Dan Pembaikan Kelajuan Yang Berkesan)

Dikemaskini kali terakhir: June 28, 2026

Pada hampir setiap laman web perlahan yang saya audit, puncanya adalah sama: imej. Teks, fon, dan JavaScript semuanya penting, tetapi media adalah berat dominan pada halaman kandungan atau e-dagang biasa, dan ia adalah bahagian yang pasukan optimalkan paling akhir. Artikel ini memberi tumpuan sempit tentang bagaimana imej mempengaruhi kelajuan muat, dengan pembaikan yang telah saya ukur dalam pengeluaran (production). Untuk gambaran yang lebih luas, panduan pengoptimuman kelajuan laman web juga meliputi kod, fon, dan caching.

Jawapan ringkas: bagaimana imej melambatkan laman web?

Imej biasanya 60 hingga 80 peratus daripada berat halaman keseluruhan, dan pada halaman yang banyak imej, ia adalah tuas terbesar bagi masa muat. Empat pembaikan yang paling memberi impak ialah menghantar format moden pada saiz paparan yang tepat, memampatkan kepada kualiti yang munasabah, lazy-loading media di bawah lipatan (below-the-fold), dan meletakkan aset di belakang CDN.

Pada blog klien yang saya ukur, empat perubahan itu membawa berat halaman dari 3.4 MB kepada 690 KB dan Largest Contentful Paint dari 4.8 saat kepada 1.9 saat. Mulakan dengan imej terbesar dan ukur sebelum dan selepas.

Mengapa imej melambatkan laman web anda?

Setiap imej adalah permintaan rangkaian ditambah bait yang perlu dimuat turun, didekod, dan dilukis oleh pelayar (browser). Pada halaman biasa, bait-bait itu mengatasi segala-galanya. Saya memecahkan berat pada tapak klien yang sama, disusun mengikut kategori:

Imej lebih besar daripada gabungan setiap kategori lain, itulah sebabnya kerja imej memberikan pulangan yang lebih cepat daripada sebarang perubahan lain. Bait yang sama juga menelan belanja masa dekod: foto 4 MB menghalang main thread semasa pelayar mendecompresnya, walaupun selepas muat turun selesai.

Tiga mekanisme, mengikut kekerapan saya melihatnya, menerangkan perlambatan itu:

• Bait berlebihan — menghantar foto 4000-pixel ke slot 400-pixel.
• Format yang salah — PNG berwarna penuh untuk foto berbanding WebP.
• Penghantaran tidak dioptimumkan — tiada CDN, tiada caching, tiada varian responsif.

Dua yang pertama adalah tentang apa yang anda hantar. Yang ketiga adalah tentang bagaimana anda menghantarnya. Setiap satu mempunyai pembaikan yang mudah, dibincangkan di bawah.

Berapa kos sebenar berat halaman dalam saat?

Berat halaman diterjemahkan kepada saat melalui rangkaian. Peraturan kasar tetapi berguna: telefon pertengahan pada sambungan 4G memuat turun kira-kira 1 hingga 1.5 MB per saat dalam dunia nyata, bukan puncak teori. Jadi, halaman 3.4 MB mengambil masa kira-kira 3 saat hanya untuk diambil (fetch), sebelum pelayar melakukan sebarang kerja.

Saya mengukur ini secara langsung pada tapak klien, mengekalkan segala-galanya malar dan hanya mengubah berat imej:

Setiap megabyte yang anda kurangkan adalah kira-kira satu saat yang dijimatkan pada sambungan mudah alih biasa. Itulah sebabnya berat imej lebih penting daripada sebarang mikro-pengoptimuman dalam CSS atau JavaScript anda. Google mendokumentasikan hubungan antara berat halaman dan prestasi muat dalam panduan pantas web.dev, dan PageSpeed Insights menandakan imej bersaiz besar sebagai salah satu kegagalan audit teratasnya.

Bagaimana anda menghantar format dan saiz yang betul?

Kemenangan terbesar ialah menukar foto daripada JPG dan PNG kepada format moden dan mengubah saiznya kepada saiz paparan. WebP kira-kira 25 hingga 35 peratus lebih kecil daripada JPG pada kualiti persepsi yang sama; AVIF pergi lebih jauh tetapi mempunyai kelajuan pengekodan yang lebih berbintik (spottier). Saya menggunakan WebP kerana ia didekod dengan pantas dan berfungsi di mana-mana pada tahun 2026.

1. Ubah saiz kepada saiz paparan. Foto 4000-pixel dalam slot 400-pixel adalah sepuluh kali lebih besar daripada yang diperlukan. Hadkan imej kandungan pada 1600 hingga 1920 piksel pada tepi panjang.

2. Tukar kepada WebP pada kualiti 75 hingga 82. Julat ini hampir tidak dapat dibezakan daripada sumber untuk foto dan menjimatkan bait paling banyak. Tolak lebih rendah dan banding muncul di langit dan gradien.

3. Kekalkan varian AVIF hanya untuk hero jika anda menyokongnya, kerana pengekodan AVIF perlahan dan hanya berbaloi untuk imej yang menjadi elemen Largest Contentful Paint anda.

Untuk dimensi tepat mengikut kes penggunaan, panduan ubah saiz imej untuk web mempunyai nombornya. Untuk mencapai kualiti tanpa artifak, aliran kerja mampatkan imej tanpa kehilangan kualiti menerangkan tetapan WebP yang saya gunakan.

Bagaimana anda mampatkan dan menukar sebelum menghantar?

Pemampatan harus berlaku dalam binaan (build), tidak pernah di pelayar. Matlamatnya ialah satu imej sumber yang menjadi varian optimum secara automatik.

## Tukar hero ke WebP pada saiz paparan, kualiti 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

Untuk keseluruhan direktori saya menggunakan gelung kecil yang mengeluarkan pelbagai lebar. Disiplin utama ialah tidak pernah menghantar foto mentah 5 MB.

• Tetapkan lantai kualiti 70 untuk kandungan dan 75 untuk gambar produk, kemudian sesuaikan dengan mata pada imej sebenar.
• Buang metadata (EXIF, profil warna yang anda tak perlukan) — ia boleh menambah puluhan kilobyte tanpa faedah visual.
• Jana satu varian bagi setiap breakpoint berbanding satu imej gergasi untuk setiap peranti.
• Automasi dalam CI supaya imej tidak dioptimumkan tidak pernah sampai ke pengeluaran.

Kesilapan biasa ialah memampatkan muat naik tetapi terlupa setiap thumbnail dan varian responsif yang dijana oleh CMS. Jalankan paip itu merentasi semua saiz, bukan hanya asal. Inilah langkah di mana saya telah mengukur penurunan paling curam dalam berat halaman — sering kali 70 hingga 80 peratus daripada asal.

Bagaimana anda melakukan lazy-load di bawah lipatan?

Imej di bawah lipatan tidak boleh menghalang render pertama. Lazy loading asli melakukannya dengan satu atribut dan tiada JavaScript.

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Foto produk dalam cahaya semula jadi">

Dua atribut lebih penting daripada yang orang sedari:

1. loading="lazy" menangguhkan pengambilan sehingga imej menghampiri viewport, jadi ia tidak pernah bersaing dengan lukisan pertama.
2. width dan height membenarkan pelayar memperuntukkan kotak sebelum imej tiba, yang menghalang Cumulative Layout Shift.

Jangan lazy-load hero atau imej LCP anda — itu melambatkan elemen paling penting pada halaman. Peraturan yang saya ikuti: lazy-load segala-galanya di bawah lipatan, eager-load satu imej yang dilihat pengguna dahulu.

Bagaimana CDN mempercepatkan imej?

CDN menghantar imej dari pelayan berhampiran setiap pelawat, yang memotong perjalanan pergi balik rangkaian (network round-trip) yang mendominasi lukisan pertama pada mudah alih dan trafik antarabangsa. Pada tapak klien, menambah CDN di hadapan imej menurunkan LCP lagi 400 milisaat untuk pelawat di luar rantau asal.

CDN juga memberikan transformasi masa nyata: minta sebarang lebar atau format melalui URL, dan tepi (edge) menjana dan menyimpannya dalam cache. Itu menghilangkan keperluan untuk pra-menjana selusin varian. Panduan CDN imej meliputi header dan kunci cache secara terperinci.

Tetapkan Cache-Control: max-age=31536000, immutable yang panjang pada URL imej fingerprinted supaya pelawat kembali menggunakan semula. Bersihkan cache semasa deploy apabila fingerprint berubah.

Bagaimana imej responsif sesuai?

Imej responsif memberitahu pelayar dengan tepat varian mana yang perlu dimuat turun untuk viewport semasa, jadi telefon tidak pernah mengambil hero desktop. Atribut srcset dan sizes adalah cara asli bebas kebergantungan untuk melakukan ini.

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Imej hero komputer riba melayari laman web">

Pelayar memilih varian terkecil yang masih mengisi slot pada nisbah piksel peranti. Pada telefon yang sering kali fail 640w, seperempat bait daripada fail 1920w. Tambah fetchpriority="high" kepada imej LCP supaya pelayar mementingkannya semasa muat awal.

Bagaimana saya mengukur impak imej?

Anda tidak boleh meningkatkan apa yang anda tidak ukur. Dua alat meliputi kerja khusus imej dengan baik.

• PageSpeed Insights — jalankannya di pagespeed.web.dev. Ia melaporkan data medan daripada pengguna sebenar dan menandakan imej bersaiz besar dan format next-gen yang hilang secara langsung.
• Lighthouse — audit makmal di belakang PageSpeed Insights. Chrome mendokumentasikan semakan imejnya dalam panduan pembangun Lighthouse. Ia menamakan imej tertentu yang membazir bait.
• Tab Network DevTools Chrome — tapis mengikut Img, susun mengikut saiz, dan catat pelanggar teratas. Beginilah cara saya mencari satu atau dua imej yang perlu diperbaiki dahulu.
• WebPageTest — air terjun (waterfall) dan filmstrip yang menunjukkan dengan tepat bila setiap imej dimuat turun dan bagaimana ia mengubah susun atur.

Apabila makmal dan medan tidak bersetuju, percayai data medan. Skor makmal yang bersih pada mesin pantas melalui Wi-Fi bermakna sedikit jika pengguna mudah alih sebenar pada 4G masih menunggu. Oleh kerana imej mendorong Largest Contentful Paint pada kebanyakan halaman, kerja imej juga adalah kerja Core Web Vitals — panduan mengoptimumkan imej untuk Core Web Vitals menyatukan kedua-duanya.

Apa yang perlu saya elakkan?

• Mengejar skor sempurna, bukan pengguna. 100 dalam makmal adalah sia-sia jika LCP medan masih 4 saat.
• Memampatkan berlebihan. Menurunkan kualiti terlalu jauh menjimatkan bait tetapi merosakkan foto produk. Uji pada imej sebenar, bukan sampel.
• Mengabaikan mudah alih. Kebanyakan trafik dan kebanyakan muat perlahan adalah mudah alih. Optimumkan untuk telefon pertengahan pada 4G, bukan komputer riba dev anda.
• Mengoptimumkan sekali sahaja. Prestasi merosot apabila imej dan ciri baharu dihantar. Uji semula selepas setiap keluaran.
• Satu imej gergasi untuk setiap peranti. Tanpa srcset, telefon memuat turun hero desktop.

Pengambilan utama

Imej adalah tuas terbesar pada kelajuan laman web kerana ia merupakan bahagian berat halaman yang paling besar. Empat pembaikan — format moden pada saiz paparan, pemampatan, lazy-loading, dan CDN — tidak glamor tetapi itulah yang membawa tapak klien saya dari 3.4 MB dan LCP 4.8 saat kepada 690 KB dan LCP 1.9 saat. Lakukan dalam susunan itu, ukur setiap langkah, dan perbaiki imej terbesar dahulu.

Satu pengecualian jujur: nombor bait dan saat yang tepat di atas adalah daripada satu tapak klien, dan milik anda akan berbeza mengikut kandungan, trafik, dan CDN. Jalankan PageSpeed Insights pada URL anda sendiri sebelum dan selepas, dan biarkan data medan daripada pengguna sebenar — bukan skor makmal yang kemas — menjadi hakim sama ada ia berhasil.

Kredit Imej

• Monitor komputer moden memaparkan kerja reka web dalam ruang kerja kreatif — foto oleh Tranmautritam di Pexels
• Close-up skrin komputer riba menunjukkan halaman enjin carian sedang dimuatkan — foto oleh cottonbro studio di Pexels
• Pembangun menaip kod pada komputer riba dalam ruang kerja yang fokus — foto oleh olia danilevich di Pexels