Gambar sudah diperkecil tetapi LCP hampir tidak berubah. Situasi ini masuk akal jika browser terlambat menemukan gambar atau halaman menyembunyikannya sampai JavaScript selesai. Ukuran file hanya satu bagian dari perjalanan menuju konten utama yang terlihat.
Saya menyarankan diagnosis yang dimulai dari elemen LCP dan garis waktunya. Dengan begitu, keputusan seperti mengganti format gambar, memperbaiki cache, atau mengurangi JavaScript memiliki alasan yang dapat diperiksa.
Temukan elemen LCP pada kondisi yang bermasalah
Elemen terbesar yang terlihat bisa berbeda antara desktop dan mobile. Hero yang dominan di desktop dapat berubah menjadi judul pada layar kecil. Jangan mengasumsikan gambar pertama selalu menjadi LCP.
Rekam halaman pada kondisi yang ingin diperbaiki. Catat elemen LCP, URL resource bila ada, waktu kemunculannya, ukuran viewport, dan versi halaman. Gunakan trace performa serta waterfall jaringan untuk melihat urutan kejadian.
Pisahkan pengujian kunjungan baru dan kunjungan dengan cache ketika keduanya relevan. Perubahan yang membantu satu kondisi belum tentu menjelaskan masalah pada kondisi lainnya.
Pecah waktu menjadi empat bagian
Untuk satu pemuatan halaman, LCP dapat diuraikan menjadi waktu hingga byte pertama, jeda penemuan resource, durasi transfer resource, dan jeda hingga elemen dirender. Jika elemen tidak membutuhkan resource terpisah, seperti teks dengan font sistem, bagian resource dapat bernilai nol. Panduan optimasi LCP.
Gunakan pembagian tersebut sebagai alat diagnosis, bukan kewajiban setiap bagian mencapai persentase tertentu.
| Bagian | Pertanyaan diagnosis | Bukti yang diperiksa |
|---|---|---|
| TTFB | Mengapa dokumen awal terlambat diterima? | Redirect, respons server, cache, lokasi permintaan |
| Resource load delay | Mengapa resource utama baru diminta belakangan? | HTML awal, CSS, JavaScript, prioritas request |
| Resource load duration | Mengapa transfer resource lama? | Ukuran, koneksi, cache, kompetisi bandwidth |
| Element render delay | Mengapa resource selesai tetapi elemen belum terlihat? | Main thread, style, kondisi tampil, animasi masuk |
Jangan menjumlahkan angka persentil dari empat distribusi terpisah lalu menyebutnya LCP persentil ke-75. Penjumlahan yang bermakna di sini berasal dari bagian-bagian pada pemuatan yang sama.
Contoh: hambatan ada sebelum gambar diminta
Bayangkan halaman katalog dengan LCP 3.200 milidetik pada satu trace ilustratif:
| Bagian | Durasi |
|---|---|
| TTFB | 600 ms |
| Jeda penemuan resource | 1.400 ms |
| Transfer gambar | 450 ms |
| Jeda render | 750 ms |
| Total satu pemuatan | 3.200 ms |
Gambar baru dibuat oleh komponen setelah data rekomendasi selesai. Mengurangi transfer sebanyak 150 milidetik tidak menyelesaikan jeda penemuan 1.400 milidetik. Kandidat perbaikannya adalah membuat resource utama dapat ditemukan lebih awal, bila arsitektur halaman memungkinkan.
Jeda render 750 milidetik juga perlu diperiksa. Jika gambar menunggu animasi atau pengolahan script, transfer yang lebih cepat dapat hanya memperpanjang waktu tunggu sebelum ditampilkan. Uji kedua hambatan secara terpisah agar pengaruh masing-masing terbaca.
Pilih tindakan sesuai bukti
Jika TTFB dominan, telusuri permintaan dokumen: apakah ada redirect berulang, pekerjaan server mahal, atau kebijakan cache yang tidak sesuai? Jangan langsung mengubah cache halaman personal karena halaman publik lain lambat.
Jika resource terlambat ditemukan, periksa apakah gambar penting tersedia melalui markup yang bisa diproses sejak awal. preload dan prioritas resource perlu digunakan selektif. Memberi prioritas tinggi kepada semua gambar menghilangkan tujuan prioritas dan dapat mengganggu resource lain.
Jika transfer dominan, sesuaikan ukuran gambar dengan kebutuhan tampilan, pilih kompresi yang menjaga keterbacaan, dan periksa pengiriman resource. Jika render dominan, cari pekerjaan main thread, stylesheet yang menghambat, atau aturan aplikasi yang menunda visibilitas.
Buat tiket yang bisa diuji developer
Tiket yang baik berisi URL, kondisi uji, elemen LCP, trace sebelum perubahan, dugaan hambatan, dan perilaku yang harus tetap berjalan. Contohnya: “Gambar utama baru diminta setelah komponen rekomendasi selesai. Uji agar gambar utama tersedia lebih awal, tanpa merusak pemilihan varian.”
Tambahkan acceptance criteria berupa penurunan jeda yang teramati pada kondisi sama. Jangan mensyaratkan kenaikan ranking sebagai kriteria selesainya pekerjaan frontend.
Verifikasi hasil dan efek samping
Ulangi beberapa pengujian dengan kondisi sebanding. Pastikan elemen LCP tidak sekadar berubah menjadi elemen lain karena konten penting disembunyikan. Periksa kualitas visual, fungsi interaktif, serta pemuatan pada layar kecil.
Bandingkan keempat bagian waktunya. Bila satu bagian turun tetapi bagian lain meningkat, diagnosis belum selesai. Sesudah hasil lab konsisten, pantau pengalaman lapangan sesuai cakupan data yang tersedia.
Simpan bukti sebelum dan sesudah bersama tanggal rilis. Dengan kebiasaan ini, optimasi LCP menjadi proses menemukan waktu yang terbuang, bukan perlombaan mengganti format file tanpa mengetahui penyebabnya.
