Cara Memeriksa Kecepatan Blog: Arti LCP, INP, CLS dan Perbaikannya

Untuk memeriksa performa blog, analisis URL publik di PageSpeed Insights, bandingkan hasil seluler dan desktop, lalu gunakan LCP, INP, dan CLS untuk menilai pemuatan, respons, serta kestabilan tata letak. Pisahkan data pengguna nyata dari diagnostik laboratorium, kemudian perbaiki penyebab metrik yang buruk, bukan hanya mengejar satu skor performa.

Apa itu LCP, INP, dan CLS?

Core Web Vitals adalah ukuran utama Google untuk pengalaman pengguna web. Saat ini, kelompok tersebut mencakup tiga metrik berikut. Nilai yang lebih rendah lebih baik untuk ketiganya, tetapi hal yang diukur dan satuannya berbeda.

Panduan Web Vitals Google menggunakan persentil ke-75, yang dinilai terpisah untuk seluler dan desktop. Secara sederhana, ini menanyakan nilai yang dicapai atau tidak dilampaui oleh sekitar 75% kunjungan yang diamati. Angka itu bukan rata-rata atau hasil tercepat dari satu pengujian. Jika data ketiga metrik memadai, semuanya harus berada dalam kategori Baik agar penilaian lulus; LCP yang baik saja tidak cukup.

Sebuah artikel mungkin cepat terlihat, tetapi menunya lambat merespons saat dibuka. Artikel lain bisa responsif, tetapi isinya terdorong ke bawah ketika iklan muncul. Tentukan pengalaman mana yang bermasalah sebelum berulang kali mengompresi gambar untuk mengatasi masalah “kecepatan” yang belum jelas.

Jalankan pemeriksaan PageSpeed Insights

1. Pilih URL artikel yang dapat dibuka tanpa login. Hindari alamat editor dan pratinjau.
2. Masukkan alamat tersebut ke PageSpeed Insights, lalu jalankan analisis.
3. Pada hasil seluler, baca pengalaman pengguna nyata secara terpisah dari diagnostik performa.
4. Periksa juga desktop. Catat URL, tanggal, kategori perangkat, metrik yang buruk, dan temuan utamanya.

Jangan hanya memeriksa artikel terbaru; pilih beberapa jenis halaman yang mewakili blog. Artikel teks biasa, artikel dengan banyak gambar, dan halaman berisi tabel atau kode membantu membedakan masalah templat bersama dari masalah konten tertentu. Gunakan format yang memang ada di blog Anda.

Periksa apakah URL yang dianalisis berbeda dari alamat yang dimasukkan. Jika pengalihan membawa pengujian ke halaman lain, pakai tujuan akhir yang sama dalam perbandingan berikutnya. Pencatatan yang konsisten berguna untuk menilai perubahan, bukan sekadar membuat skor tampak lebih baik.

Bedakan data pengguna nyata dan skor performa

Data pengguna nyata berasal dari Chrome User Experience Report, disingkat CrUX, untuk 28 hari terakhir. Jika sampelnya kurang, hasil dapat menampilkan data tingkat origin atau tidak menampilkan data lapangan sama sekali. Origin mewakili asal situs, bukan hanya satu artikel. Sebaliknya, diagnostik laboratorium menggunakan Lighthouse dalam lingkungan simulasi. Dokumentasi PageSpeed Insights menjelaskan perbedaannya.

Skor performa 90 dan kelulusan Core Web Vitals berdasarkan pengguna nyata merupakan dua penilaian berbeda. Periksa apakah data lapangan mewakili URL tertentu atau seluruh origin. Ketiadaan data bukan sertifikat performa baik maupun bukti adanya masalah.

Periode CrUX yang bergulir dan pengujian Lighthouse saat ini memakai sampel serta kondisi berbeda. Diagram berikut memisahkan bukti dan tujuan keduanya agar Anda tahu apa yang perlu dibandingkan sesudah perubahan.

Misalnya, mengganti gambar dapat segera memperbaiki hasil laboratorium, sementara periode data lapangan masih mencakup kunjungan sebelum perubahan. Pertama, pastikan gambar pengganti dimuat dengan benar dan pengujian yang sebanding menunjukkan tanda perbaikan. Tinjau tren pengguna nyata secara terpisah dari waktu ke waktu.

Nilai INP yang tidak tersedia bukan berarti nol milidetik. PSI dapat menyatakan lulus ketika data INP kurang, asalkan persentil ke-75 LCP dan CLS sama-sama Baik. Jika data LCP atau CLS tidak memadai, penilaian tidak dapat dilakukan. Aturan penilaian PSI menjelaskan pengecualian ini. Baca data yang benar-benar tersedia, bukan hanya label kelulusannya.

Jika LCP buruk, cari penyebab konten utama terlambat tampil

Mulailah dengan mengenali elemen yang dilaporkan sebagai konten terbesar. Elemen itu bisa berupa gambar di bagian atas artikel, blok teks besar, atau konten lain. Jangan menerapkan pengaturan gambar yang sama di semua halaman tanpa memeriksa elemen sebenarnya.

• Jika berupa gambar, bandingkan dimensi berkas yang dikirim dengan ukuran tampilnya.
• Gunakan dimensi, kompresi, dan format yang sesuai sambil memeriksa detail penting serta kejelasan teks.
• Periksa apakah gambar LCP pada layar awal memakai lazy loading, yaitu pemuatan yang ditunda. Pengaturan yang berguna untuk gambar jauh di bawah dapat justru menunda gambar utama.
• Jika diagnostik menunjukkan masalah respons server atau sumber daya yang menghalangi perenderan, periksa penyebab tersebut juga.

Panduan optimasi LCP membedakan keterlambatan penemuan, pengiriman, dan penampilan konten. Jika perubahan format memang tepat, baca cara mengonversi gambar ke WebP. Jika pengunjung masih menerima berkas lama sesudahnya, periksa cache dan sumber daya yang benar-benar diminta.

Buka rincian LCP pada diagnostik untuk mengetahui bagian yang paling banyak menghabiskan waktu. Mulai dari penundaan terbesar atau yang dapat dihindari, bukan memberi perlakuan sama pada semua bagian:

1. Time to First Byte (TTFB): waktu sejak navigasi dimulai hingga byte pertama respons HTML diterima. Periksa respons server, rangkaian pengalihan, dan penggunaan cache.
2. Resource load delay: jeda setelah respons tersebut sebelum gambar utama atau sumber daya LCP lain mulai diunduh. Periksa lazy loading atau penemuan sumber daya yang terlambat.
3. Resource load duration: waktu untuk mengunduh sumber daya itu sendiri. Dimensi yang sesuai dan kompresi langsung menargetkan bagian ini.
4. Element render delay: waktu menunggu elemen tampil setelah berkas diterima. Skrip atau kondisi penampilan masih dapat menghalanginya, sehingga gambar yang lebih kecil belum tentu memperbaiki total LCP.

Elemen LCP berupa teks yang tidak memerlukan unduhan sumber daya terpisah mungkin tidak memiliki interval pemuatan sumber daya. Terapkan rincian tersebut pada elemen yang benar-benar ditemukan dalam pengujian.

Jika INP buruk, periksa pekerjaan setelah interaksi

INP menilai respons hingga pembaruan visual berikutnya sesudah interaksi. Tugas JavaScript yang panjang dapat memenuhi main thread browser, yaitu jalur utama untuk menjalankan skrip dan pekerjaan layar, sehingga penanganan masukan tertunda. Panduan optimasi INP membahas penundaan masukan, pemrosesan peristiwa, dan penundaan penampilan.

Sebagai pengelola blog, mulailah dengan mengulangi tindakan nyata di ponsel: membuka menu, memakai pencarian, dan mengikuti tautan daftar isi. Catat tindakan yang terasa lambat, lalu tinjau plugin yang tidak perlu atau berfungsi ganda, widget, dan skrip eksternal yang aktif pada halaman itu.

Total Blocking Time (TBT), atau total waktu pemblokiran, pada pengujian pemuatan dasar Lighthouse dapat menunjukkan tugas panjang, tetapi bukan INP. INP memerlukan klik, ketukan, atau interaksi keyboard; kunjungan yang hanya menggulir halaman atau tidak berinteraksi bisa tidak memiliki nilai. Bedakan pula umpan balik visual berikutnya setelah tombol pencarian ditekan, misalnya indikator pemuatan, dari selesainya seluruh pencarian di server. Definisi dan cakupan pengukuran INP menjelaskan batas-batas ini.

Hindari menonaktifkan banyak plugin sekaligus. Siapkan cadangan atau lingkungan uji, lalu lakukan satu perubahan pada satu waktu agar dampaknya dapat dikenali. Jika Anda menunda eksekusi JavaScript, pastikan menu, pencarian, dan kontrol persetujuan tetap bekerja, selain memeriksa skor.

Jika CLS buruk, sediakan ruang untuk konten yang bergerak

Gambar, iklan, dan sematan yang muncul terlambat dapat mendorong artikel atau tautan yang hampir diketuk pembaca. Panduan optimasi CLS menekankan dimensi gambar dan penyediaan ruang bagi konten yang dimuat belakangan.

• Tetapkan width dan height gambar atau sediakan rasio aspek yang sesuai.
• Sediakan ruang yang tepat untuk iklan dan video sematan pada setiap ukuran perangkat.
• Periksa agar slot iklan yang tidak terisi tidak mendadak menyusut dan menimbulkan pergeseran lain.
• Amati pergerakan teks dan tombol ketika font atau banner muncul.

Elemen yang tercantum dalam diagnostik pergeseran belum tentu penyebabnya. Iklan yang disisipkan di atas artikel bisa membuat artikel di bawahnya tercatat sebagai elemen yang bergeser. Periksa konten di sekitarnya dan elemen yang baru muncul tepat di atasnya. Pengujian pemuatan awal juga dapat melewatkan pergeseran akibat iklan atau gambar yang muncul setelah halaman digulir. Baca artikel publik sampai selesai dan uji pula menu serta kontrol persetujuan.

Mengurangi ruang kosong sambil mempertahankan kestabilan tata letak dapat memerlukan kompromi. Jangan menganggap tinggi iklan desktop cocok untuk ponsel. Buka artikel sebenarnya dan periksa pergerakan di dekat bagian atas, tengah, serta bawah layar.

Periksa ulang dengan kondisi yang sebanding

1. Simpan pengaturan, berkas, dan hasil pengujian awal.
2. Pilih satu penyebab penting dan lakukan perubahan yang menargetkannya.
3. Perbarui cache yang terkait dan pastikan sumber daya yang berubah digunakan pada halaman publik.
4. Uji ulang URL dan kategori perangkat yang sama, lalu periksa menu, gambar, iklan, serta tata letak artikel.
5. Jika fungsi rusak atau metrik lain memburuk, pulihkan perubahan dan persempit kembali penyebabnya.

Saat mengubah pengaturan cache, bedakan penyajian sumber daya yang tersimpan dari penundaan eksekusi skrip. Baca fungsi plugin cache WordPress dan cara memilihnya. Catat pengaturan yang perlu dipulihkan, alih-alih mengaktifkan beberapa optimasi sekaligus.

Jangan menyatakan berhasil hanya dari selisih kecil pada satu pengujian. Bandingkan catatan dan masalah yang berulang sebelum melakukan perubahan berikutnya. Skor lebih tinggi yang diperoleh dengan merusak fungsi yang dibutuhkan pembaca bukan perbaikan yang berguna.

Skor kecepatan saja tidak menentukan visibilitas pencarian. Panduan pengalaman halaman Google menyatakan bahwa Core Web Vitals digunakan oleh sistem peringkat, tetapi hasil baik tidak menjamin posisi teratas. Perbaiki juga kemampuan pembaca untuk membaca artikel dan menyelesaikan tindakan yang berguna.