Cara Memperbaiki LCP Lambat Akibat Gambar

Perbaiki gambar Largest Contentful Paint (LCP) yang lambat dalam 4 langkah: ubah ukurannya ke ukuran tampilan, konversikan ke WebP atau AVIF, lakukan preload, dan atur fetchpriority ke high. Dua langkah pertama memberikan sebagian besar peningkatan dan tidak memerlukan perubahan pada markup halaman Anda.

Pada sebagian besar halaman, elemen largest contentful paint adalah satu gambar hero, yang berarti LCP sebenarnya adalah pertanyaan tentang satu berkas alih-alih seluruh situs Anda. Memperbaiki satu berkas tersebut biasanya mengubah pengukuran lebih banyak daripada optimasi lain yang tersedia.

Apa yang diukur oleh LCP

LCP mencatat berapa lama elemen kasatmata terbesar selesai dirender, diukur dari saat halaman mulai dimuat. Google menganggap 2,5 detik atau kurang sebagai baik, 2,5 hingga 4 detik memerlukan peningkatan, dan lebih dari 4 detik sebagai buruk.

Elemen yang diukur biasanya berupa gambar, terkadang blok teks judul, dan selalu sesuatu yang terlihat tanpa menggulir. Elemen dapat berubah antarperangkat, karena gambar hero yang mendominasi tata letak desktop mungkin berada di bawah lipatan (below the fold) pada ponsel.

Menemukan elemen yang bertanggung jawab

Jalankan Lighthouse dan baca entri elemen Largest Contentful Paint, yang menyebutkan elemen pasti yang sedang diukur. Menebak-nebak hanya membuang waktu, karena elemen tersebut sering kali bukan yang diperkirakan orang.

Periksa pada seluler serta desktop, karena tata letak dan hasilnya bisa berbeda. Data lapangan dari pengunjung asli lebih andal daripada satu pengujian laboratorium, karena kondisi jaringan jauh lebih bervariasi di dunia nyata daripada dalam pengujian. Jika keduanya berbeda, percayai data lapangan dan gunakan pengujian laboratorium untuk diagnosis.

Perbaiki gambar berdasarkan urutan dampaknya

Untuk meningkatkan LCP pada gambar, kerjakan 6 langkah ini secara berurutan.

1. Ubah ukuran gambar ke ukuran terbesar yang akan ditampilkan, digandakan untuk layar berdensitas tinggi.
2. Konversikan ke WebP, atau ke AVIF jika gambarnya besar dan berupa fotografi.
3. Kompres ke target di bawah 200 KB untuk gambar hero, yang dapat dicapai pada lebar penuh di sebagian besar desain.
4. Tambahkan atribut width dan height agar peramban memesan ruang dan tidak terjadi pergeseran tata letak (layout shift).
5. Preload gambar di bagian head halaman agar peramban mulai mengambilnya dengan segera.
6. Atur fetchpriority ke high pada elemen gambar, yang memberi tahu peramban bahwa berkas ini paling penting.

Langkah 1 dan 2 biasanya memberikan sebagian besar peningkatan, dan keduanya tidak memerlukan perubahan pada markup halaman sama sekali.

Mengapa mengubah ukuran lebih efektif daripada mengompresi

Dimensi mengontrol sebagian besar ukuran berkas, sehingga mengubah ukuran mengurangi lebih banyak beban daripada pengaturan kualitas apa pun. Foto 4000 piksel yang ditampilkan pada 1200 piksel membawa 11 kali lebih banyak data piksel daripada yang dapat ditampilkan halaman.

Baris ketiga menunjukkan mengapa mengubah ukuran harus diutamakan. Mengubah ukuran saja mengalahkan mengompresi saja, dan kombinasinya mengalahkan keduanya. Angka-angka ini bervariasi menurut gambar dan koneksi, sementara urutannya tetap konsisten.

Preload dan fetchpriority

Preloading memberi tahu peramban untuk mengambil gambar hero sebelum selesai mengurai halaman, yang biasanya menghemat 200 hingga 500 milidetik. Pengaturan ini penting karena peramban baru menemukan gambar di akhir proses penguraian.

Lakukan preload untuk satu gambar saja. Melakukan preload untuk beberapa gambar sekaligus akan menghilangkan manfaatnya, karena peramban akan membagi perhatiannya sama seperti biasanya. Mengatur fetchpriority ke high mencapai hasil serupa dengan markup lebih sedikit dan sering kali sudah cukup untuk gambar yang sudah ada di HTML awal.

Kesalahan yang memperburuk LCP

• Menerapkan lazy loading pada gambar hero. Lazy loading menunda berkas yang justru paling Anda butuhkan pertama kali. Terapkan hanya di bawah lipatan (below the fold).
• Memuat gambar hero melalui JavaScript. Gambar yang dimasukkan lewat skrip tidak dapat mulai diunduh sebelum skrip tersebut berjalan.
• Menggunakan gambar latar belakang CSS. Gambar latar belakang ditemukan lebih lambat daripada elemen img dan tidak dapat diprioritaskan dengan mudah.
• Melakukan preload beberapa gambar. Prioritas yang saling bersaing menghilangkan keunggulan ini sepenuhnya.
• Omencantumkan width dan height. Pergeseran tata letak merusak pengukuran lain ketika pengukuran ini ditingkatkan.

Ketika elemen LCP berupa teks

LCP berbasis teks biasanya tertunda oleh font web daripada oleh teks itu sendiri. Peramban sudah memiliki kata-katanya dengan segera dan menunggu berkas font sebelum merendernya.

Atur font-display ke swap agar teks dirender dengan font cadangan (fallback) lalu beralih saat font web tiba. Preload satu berkas font yang paling penting, dan buat subset font hanya untuk karakter yang benar-benar digunakan halaman Anda, yang sering kali mengurangi ukuran font dari 200 KB menjadi di bawah 30 KB. Menyajikan font dari domain Anda sendiri menghilangkan koneksi tambahan ke pihak ketiga.

Waktu respons server menetapkan batas minimum

LCP tidak bisa lebih cepat dari waktu yang dibutuhkan server Anda untuk mengembalikan byte pertama, jadi server yang lambat membatasi setiap peningkatan lainnya. Targetkan di bawah 600 milidetik untuk byte pertama (TTFB).

Periksa angka tersebut sebelum mengoptimalkan gambar, karena respons server selama 2 detik membuat target LCP 2,5 detik mustahil dicapai apa pun yang Anda lakukan pada berkas. Caching, penyedia hosting yang lebih cepat, atau jaringan pengiriman konten (CDN) mengatasi lapisan tersebut. Pekerjaan optimasi gambar kemudian meningkatkan apa yang tersisa daripada melawan batas yang ditetapkan di tempat lain.

Skrip pihak ketiga juga menunda gambar

Analitik, spanduk persetujuan, widget obrolan, dan skrip iklan bersaing dengan gambar hero Anda untuk mendapatkan bandwidth dan waktu pemrosesan. Gambar yang dioptimalkan dengan sempurna tetap akan dirender terlambat ketika ada 12 skrip dimuat sebelumnya.

Spanduk persetujuan adalah yang paling merusak, karena banyak di antaranya memblokir rendering hingga pengunjung membuat pilihan. Muat skrip pihak ketiga dengan atribut defer atau async agar tidak menahan halaman, dan audit berapa banyak yang benar-benar dibutuhkan. Menghapus 3 skrip pelacak yang tidak digunakan sering kali meningkatkan LCP lebih banyak daripada babak kompresi gambar berikutnya.

Menguji perubahan dengan benar

Uji di jendela pribadi (incognito) dengan ekstensi dinonaktifkan, dan jalankan pengukuran 3 kali daripada mempercayai satu hasil saja. Skor bervariasi antar-pengujian dengan selisih yang nyata.

Verifikasi bahwa peramban benar-benar menerima berkas yang lebih kecil. Buka alat pengembang (developer tools), beralih ke tab Network, filter berdasarkan gambar, lalu muat ulang. Ukuran yang ditransfer dan formatnya akan muncul dalam daftar. Halaman yang masih menyajikan berkas lama biasanya berarti lapisan caching menahan versi sebelumnya, bukan berarti optimasi gagal.

Menjaga LCP tetap cepat setelah perbaikan

Tetapkan aturan untuk gambar hero daripada memperbaikinya satu per satu, karena halaman baru akan memunculkan kembali masalah tersebut. Situs yang diperbaiki sekali akan mengalami penurunan performa dalam beberapa bulan jika editor mengunggah langsung dari kamera.

Sepakati lebar maksimum dan ukuran berkas maksimum untuk gambar hero, tuliskan, dan terapkan ke setiap halaman baru. Aturan seperti lebar 1920 piksel dan di bawah 200 KB mudah diperiksa dan mencakup hampir setiap desain. Jika ada beberapa orang yang mempublikasikan konten, aturan tertulis lebih penting daripada tekniknya, karena pengukuran mencerminkan halaman terburuk alih-alih yang terbaik.

Menyiapkan gambar hero dalam satu langkah

Proses setiap gambar hero di situs secara bersamaan, karena gambar-gambar tersebut berbagi satu spesifikasi dan satu ukuran target. Sebagian besar situs memiliki antara 10 hingga 100 gambar hero di seluruh landing page, halaman kategori, dan artikel.

Atur lebar dan target KB sekali, masukkan gambar-gambarnya, dan setiap berkas dikembalikan dalam kondisi sesuai. Hingga 500 gambar berjalan per tumpukan (batch), seluruhnya di dalam peramban pada prosesor Anda sendiri. Tidak ada yang diunggah, sehingga aset staging, halaman kampanye yang belum dipublikasikan, dan pekerjaan klien tetap berada di komputer Anda saat seluruh pustaka disiapkan.