NgodingSantai
Web Performance

Cara Mengoptimalkan Core Web Vitals

Mengubah laporan Core Web Vitals menjadi urutan kerja yang terukur, dari identifikasi elemen bermasalah sampai verifikasi melalui data pengguna nyata.

12 menit baca

Core Web Vitals membantu menilai tiga bagian pengalaman halaman: seberapa cepat konten utama terlihat, seberapa stabil layout, dan seberapa responsif halaman setelah pengguna berinteraksi. Nilai metrik bukan tujuan akhir; metrik dipakai untuk menemukan hambatan yang benar-benar dirasakan pengguna.

Ambang “baik” yang digunakan saat ini
  • LCP tidak lebih dari 2,5 detik.
  • INP tidak lebih dari 200 milidetik.
  • CLS tidak lebih dari 0,1.
  • Evaluasi data lapangan menggunakan persentil ke-75 dan dipisahkan menurut perangkat bila datanya tersedia.

Pahami apa yang diukur

Largest Contentful Paint (LCP) mengamati waktu render elemen konten terbesar yang terlihat. Pada blog, kandidatnya sering berupa judul besar, gambar hero, atau blok teks pembuka. Interaction to Next Paint (INP) mengukur latensi interaksi sepanjang kunjungan, bukan hanya interaksi pertama. Cumulative Layout Shift (CLS) menjumlahkan pergeseran layout tak terduga dalam window tertentu.

Jangan menganggap satu skor Lighthouse sebagai keadaan seluruh pengguna. Perangkat, jaringan, cache, lokasi server, dan pola interaksi pengguna nyata menciptakan hasil yang berbeda.

Bedakan data lapangan dan pengujian lab

Jenis dataKegunaanKeterbatasan
Field/CrUXMenunjukkan pengalaman pengguna nyata dalam rentang waktuTidak selalu tersedia untuk situs baru atau URL bertrafik kecil
PageSpeed Insights labMereproduksi kondisi terkontrol dan memberi diagnostikSatu simulasi tidak mewakili seluruh pengunjung
DevTools PerformanceMenganalisis main thread, network, layout shift, dan eventPerlu skenario pengujian yang konsisten

Mulai dari field data untuk menentukan metrik dan kelompok URL yang bermasalah. Gunakan lab untuk mencari penyebab dan menguji kandidat solusi. Setelah deploy, tunggu data lapangan baru untuk memastikan dampaknya.

Buat lembar audit sebelum menyentuh kode

Catat URL, jenis halaman, perangkat, metrik yang gagal, elemen kandidat, dan perubahan yang akan diuji. Satu contoh format:

URL: /articles/optimasi-core-web-vitals.html
Perangkat: mobile
Masalah utama: LCP
Kandidat LCP: gambar hero
Hipotesis: file terlalu besar dan ditemukan terlambat
Perubahan: ukuran responsif + preload hanya untuk gambar hero
Validasi: network waterfall, LCP breakdown, field data

Hipotesis membuat tim tidak menghapus animasi, gambar, atau library secara acak. Satu perubahan dapat memperbaiki metrik tertentu tetapi merusak UX lain, jadi ukur sebelum dan sesudah dengan skenario yang sama.

Perbaiki LCP dari rantai permintaan

LCP dipengaruhi waktu respons server, penemuan resource, waktu unduh, dan waktu render. Jika kandidat LCP adalah gambar, pastikan gambar sudah ada di HTML awal, tidak lazy-loaded, memiliki format dan ukuran yang sesuai, serta tidak menunggu JavaScript untuk dibuat.

<link rel="preload" as="image"
      href="/assets/hero-1280.webp"
      imagesrcset="/assets/hero-640.webp 640w,
                   /assets/hero-1280.webp 1280w"
      imagesizes="(max-width: 720px) 100vw, 50vw">

<img src="/assets/hero-1280.webp"
     srcset="/assets/hero-640.webp 640w,
             /assets/hero-1280.webp 1280w"
     sizes="(max-width: 720px) 100vw, 50vw"
     width="1280" height="720"
     fetchpriority="high"
     alt="Tampilan laporan performa halaman">

Jangan memberi fetchpriority="high" atau preload pada banyak gambar. Prioritas berlebihan membuat resource bersaing dan menghilangkan manfaatnya. Jika kandidat LCP berupa teks, periksa font web, stylesheet blocking, dan waktu respons HTML.

Perbaiki CLS dengan memesan ruang

Pergeseran sering terjadi ketika gambar, iframe, banner, atau font berubah ukuran setelah konten awal tampil. Tambahkan dimensi intrinsik pada media agar browser dapat menghitung rasio sebelum file selesai diunduh.

img,
video {
  display: block;
  max-width: 100%;
  height: auto;
}

.video-frame {
  aspect-ratio: 16 / 9;
}

.notice-slot {
  min-height: 4rem;
}

Konten yang muncul akibat tindakan pengguna biasanya tidak dianggap pergeseran tak terduga jika responsnya langsung, tetapi transisi panjang atau penyisipan konten di atas posisi baca tetap terasa mengganggu. Untuk notifikasi, pertimbangkan overlay atau ruang yang sudah dipesan.

Perbaiki INP dengan memendekkan pekerjaan utama

Ketika pengguna mengetuk filter dan browser menjalankan satu tugas JavaScript panjang, browser tidak dapat segera menggambar hasil. Profilkan interaksi di Performance panel, lalu cari long task, handler yang melakukan terlalu banyak DOM read/write, atau render daftar yang tidak perlu.

async function renderManyCards(items) {
  const batchSize = 40;

  for (let start = 0; start < items.length; start += batchSize) {
    const batch = items.slice(start, start + batchSize);
    appendCards(batch);

    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

Memecah pekerjaan memberi browser kesempatan memproses input dan menggambar. Sebelum melakukan ini, cari penghematan yang lebih sederhana: kurangi item yang dirender, cache hasil perhitungan, gunakan event delegation, dan hapus pekerjaan yang tidak diperlukan.

Audit script pihak ketiga

Analytics, iklan, widget, animasi, dan font eksternal dapat menambah koneksi, transfer, serta eksekusi. Buat inventaris semua origin pihak ketiga dan catat fungsi bisnisnya. Muat script dengan defer atau async sesuai ketergantungan, dan jangan menjalankan widget yang tidak terlihat pada halaman.

AdSense sendiri merupakan script pihak ketiga yang diperlukan untuk monetisasi. Optimasi yang sehat bukan memodifikasi script Google, melainkan menjaga script lain tetap ringan, memberi ruang untuk unit iklan, dan memastikan konten utama tidak bergantung pada iklan.

Urutan perbaikan yang efisien

  1. Pilih satu template halaman dengan dampak pengguna terbesar.
  2. Identifikasi satu metrik yang gagal dan kandidat elemennya.
  3. Reproduksi di lab menggunakan profil perangkat dan jaringan yang konsisten.
  4. Buat satu perubahan yang menguji hipotesis.
  5. Bandingkan waterfall, main thread, dan visual stability.
  6. Uji regresi aksesibilitas serta tampilan responsif.
  7. Deploy bertahap dan pantau data lapangan.

Kesalahan interpretasi yang perlu dihindari

  • Mengejar skor 100 sambil menghapus fitur yang dibutuhkan pengguna.
  • Menyamakan Total Blocking Time di lab dengan INP; keduanya berhubungan tetapi bukan metrik yang sama.
  • Memakai lazy loading pada kandidat LCP.
  • Mengubah seluruh gambar menjadi satu ukuran kecil sehingga buram di layar besar.
  • Melihat nilai rata-rata dan mengabaikan pengguna pada perangkat lambat.
  • Menganggap perbaikan selesai sebelum data lapangan memperlihatkan perubahan.

Referensi resmi

Tentang materi ini

Nilai metrik mengikuti dokumentasi Core Web Vitals yang berlaku saat artikel diperbarui. Selalu periksa dokumentasi resmi karena definisi dan status metrik dapat berkembang.

Artikel terkait