Pengunjung biasanya tidak menunggu sampai seluruh halaman selesai dimuat. Mereka menilai website dari beberapa detik pertama: apakah judul utama segera terlihat, apakah gambar pembuka muncul tanpa tersendat, dan apakah halaman terasa siap digunakan. Karena itu, gambar utama yang terlambat muncul bisa membuat website terasa lambat meskipun server sebenarnya cukup cepat.
Salah satu metrik yang menangkap pengalaman ini adalah Largest Contentful Paint (LCP), yaitu waktu yang dibutuhkan sampai elemen terbesar di area tampilan—biasanya gambar hero, judul besar, atau blok video—terlihat. Target “baik” untuk LCP adalah 2,5 detik atau kurang pada persentil ke-75 kunjungan. Penjelasan web.dev tentang LCP juga mengingatkan bahwa angka ini dipengaruhi bukan hanya oleh ukuran gambar, tetapi juga waktu respons server, koneksi, dan urutan browser mengambil resource.
Masalahnya sering bukan sekadar gambar terlalu besar
Kesalahan umum adalah langsung mengompres semua gambar. Kompresi memang penting, tetapi belum tentu menyelesaikan masalah jika browser baru menemukan gambar utama setelah membaca banyak JavaScript atau setelah CSS selesai diproses.
Bayangkan browser seperti petugas dapur yang menerima banyak pesanan. Gambar hero, font, analytics, widget chat, dan gambar carousel masuk hampir bersamaan. Jika semuanya dianggap penting, tidak ada yang benar-benar mendapat perhatian utama. Website akhirnya bukan hanya membawa terlalu banyak data, tetapi juga salah mengatur urutan pekerjaan.
Untuk mencari penyebabnya, buka DevTools browser, masuk ke tab Network, lalu muat ulang halaman dengan cache dinonaktifkan. Perhatikan tiga hal:
- Kapan request gambar utama mulai dikirim.
- Berapa besar ukuran file dan berapa lama proses download-nya.
- Apakah gambar utama baru muncul setelah JavaScript atau resource lain selesai.
Jika jarak antara awal halaman dibuka dan dimulainya request gambar cukup panjang, masalahnya kemungkinan besar adalah discoverability—browser terlambat menemukan resource penting—bukan hanya ukuran file.
Kirim ukuran gambar yang sesuai perangkat
Jangan mengirim gambar desktop selebar 2.000 piksel ke ponsel yang hanya menampilkan area 360 piksel. Browser dapat memilih file yang lebih sesuai jika kita menyediakan beberapa kandidat melalui srcset dan sizes. Teknik ini disebut responsive images.
<img src="hero-1280.jpg"
srcset="hero-480.jpg 480w,
hero-800.jpg 800w,
hero-1280.jpg 1280w"
sizes="100vw"
width="1280"
height="720"
alt="Tampilan utama produk"
fetchpriority="high">Atribut srcset memberi daftar pilihan file, sedangkan sizes memberi petunjuk tentang lebar gambar di layar. Dengan begitu, browser tidak perlu mengunduh file terbesar jika versi yang lebih kecil sudah cukup. Panduan responsive images dari web.dev menyebutkan bahwa pengiriman gambar sesuai perangkat dapat mengurangi data yang harus diunduh dan membantu mempercepat LCP.
Tambahkan juga width dan height. Keduanya membantu browser menyediakan ruang sebelum gambar selesai dimuat, sehingga posisi teks tidak tiba-tiba bergeser. Ini bukan hanya soal kecepatan, tetapi juga membantu mengurangi risiko Cumulative Layout Shift.
Gunakan fetchpriority hanya untuk elemen yang benar-benar penting
fetchpriority="high" adalah petunjuk kepada browser bahwa resource tertentu layak didahulukan. Untuk halaman artikel, gambar utama atau elemen visual pertama bisa menjadi kandidat yang masuk akal.
<img src="hero.webp"
alt="Ilustrasi artikel"
fetchpriority="high">Namun, jangan memasang nilai high pada semua gambar. Jika sepuluh gambar diberi prioritas tinggi, browser kembali menghadapi antrean yang sama. Gunakan nilai tersebut pada satu elemen paling penting di area awal halaman. Gambar carousel kedua, avatar komentar, atau banner yang belum terlihat justru bisa diberi prioritas rendah atau dimuat belakangan.
Menurut dokumentasi Fetch Priority web.dev, atribut ini adalah hint, bukan perintah mutlak. Browser tetap menggunakan pertimbangannya sendiri. Hasilnya juga dapat berbeda antara jaringan cepat, jaringan seluler, HTTP/2, dan HTTP/3. Karena itu, perubahan harus diuji, bukan diasumsikan berhasil.
Kapan perlu preload?
preload berguna ketika browser sulit menemukan resource penting dari HTML awal. Contohnya gambar LCP yang dipasang sebagai background-image di CSS, atau gambar yang baru dimunculkan setelah JavaScript berjalan.
<link rel="preload"
as="image"
href="hero.webp"
fetchpriority="high">Untuk gambar yang sudah ditulis langsung sebagai <img> di HTML, preload belum tentu diperlukan. Browser biasanya dapat menemukannya sendiri melalui parser. Preload yang tidak dibutuhkan malah bisa membuat file yang salah ikut diunduh atau bersaing dengan CSS dan font penting.
Jika gambar menggunakan srcset, preload juga harus dirancang hati-hati agar perangkat tidak mengunduh versi yang tidak sesuai. Panduan preload responsive images menjelaskan bahwa preload sebaiknya dipakai untuk resource yang sulit ditemukan, bukan dijadikan hiasan di setiap halaman.
Jangan lazy-load gambar yang menjadi LCP
loading="lazy" cocok untuk gambar di bawah area tampilan, seperti gambar lanjutan dalam artikel atau thumbnail yang baru terlihat setelah pengguna menggulir. Tetapi memasangnya pada gambar hero dapat menunda request yang justru paling penting.
<!-- Gambar utama: jangan lazy-load -->
<img src="hero.webp" fetchpriority="high" alt="...">
<!-- Gambar jauh di bawah halaman -->
<img src="related-article.webp" loading="lazy" alt="...">Aturan sederhananya: gambar yang terlihat saat halaman pertama kali dibuka biasanya tidak perlu lazy-load. Gambar setelahnya boleh ditunda, selama tidak membuat pengguna melihat ruang kosong terlalu lama ketika menggulir.
Yang bisa dilakukan sekarang
- Tentukan elemen yang menjadi LCP pada halaman penting, bukan hanya halaman beranda.
- Pastikan gambar tersebut tidak memakai
loading="lazy". - Sediakan beberapa ukuran gambar dengan
srcsetdansizes. - Tambahkan
widthdanheightagar layout tidak melompat. - Gunakan
fetchpriority="high"hanya pada satu atau sedikit resource yang benar-benar utama. - Pakai preload jika resource sulit ditemukan dari HTML awal, misalnya background image.
- Uji ulang melalui DevTools, Lighthouse, dan data pengguna nyata bila tersedia.
Apa artinya bagi kita?
Mempercepat LCP tidak selalu berarti mengganti server atau memasang plugin optimasi tambahan. Sering kali perbaikannya lebih sederhana: kirim gambar dengan ukuran yang tepat, bantu browser menentukan prioritas, dan jangan menunda elemen yang seharusnya tampil pertama.
Yang penting, jangan mengejar satu angka tanpa melihat pengalaman nyata. Gambar yang sedikit lebih kecil tetapi muncul tepat waktu biasanya lebih berguna daripada gambar beresolusi tinggi yang baru terlihat setelah pengguna hampir menyerah. Tuning performa yang baik bukan membuat semua resource dipercepat, melainkan memastikan pekerjaan yang paling penting selesai lebih dulu.
Sumber & bacaan lebih lanjut
- Largest Contentful Paint (LCP) — web.dev
- Serve responsive images — web.dev
- Optimize resource loading with the Fetch Priority API — web.dev
- Preload responsive images — web.dev
- Optimize Largest Contentful Paint — web.dev
– Rio Yotto @rioyotto
