Optimasi Core Web Vitals di Situs Statis

Situs statis punya keunggulan awal yang besar di Core Web Vitals — tidak ada server yang perlu berpikir sebelum mengirim halaman. Tapi keunggulan itu gampang dibuang, dan biasanya oleh tiga hal yang sama: gambar yang terlalu besar, font yang menghambat, dan JavaScript yang tidak perlu.

Panduan ini membahas tiap metrik: apa yang diukur, apa penyebab tersering di situs statis, dan perbaikan mana yang paling berdampak.

Tiga metriknya

Ketiganya diukur dari pengalaman pengunjung sungguhan, bukan dari uji laboratorium. Ini penting untuk memahami kenapa skor Lighthouse-mu bisa 100 sementara data lapanganmu jelek.

LCP: elemen terbesar tampil

Di situs statis, LCP hampir selalu ditentukan oleh satu elemen: gambar utama di bagian atas halaman. Kalau halamanmu tidak punya gambar, biasanya blok teks besar — dan itu jarang jadi masalah.

Perbaikan yang paling berdampak

1. Jangan pasang lazy loading pada gambar utama. Ini kesalahan yang sangat sering terjadi. Orang memasang loading="lazy" ke semua gambar demi performa, termasuk yang di atas layar — dan justru menunda elemen yang menentukan LCP.

<!-- Gambar utama: jangan lazy -->
<img src="hero.webp" alt="..." width="1200" height="600"
     fetchpriority="high">

<!-- Gambar di bawah: boleh lazy -->
<img src="lain.webp" alt="..." width="800" height="400"
     loading="lazy">

2. Pakai format modern. WebP biasanya 25 sampai 35 persen lebih kecil dari JPEG dengan kualitas setara. AVIF lebih kecil lagi.

3. Jangan kirim gambar lebih besar dari yang ditampilkan. Gambar 4000 piksel yang ditampilkan selebar 800 piksel membuang bandwidth pengunjung tanpa memberi apa-apa.

4. Muat font lebih awal. Kalau LCP-mu berupa teks, font yang lambat menundanya:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Dan pastikan font-display: swap aktif, supaya teks tampil dengan font cadangan lebih dulu alih-alih menunggu.

CLS: tata letak yang bergeser

CLS mengukur seberapa sering elemen melompat setelah halaman mulai tampil. Ini metrik yang paling mudah diperbaiki — dan paling menyebalkan buat pengunjung kalau dibiarkan.

Penyebab nomor satu: gambar tanpa ukuran

Kalau kamu tidak menuliskan width dan height, browser tidak tahu berapa ruang yang harus disediakan. Ia menyusun halaman tanpa gambar itu, lalu mendorong semuanya ke bawah begitu gambarnya tiba.

<!-- Salah -->
<img src="foto.webp" alt="...">

<!-- Benar -->
<img src="foto.webp" alt="..." width="800" height="450">

Angkanya tidak harus sama dengan ukuran tampilnya — browser cuma butuh rasionya. Pasangkan dengan CSS:

img { max-width: 100%; height: auto; }

Penyebab kedua: font yang menggeser teks

Saat font khusus selesai dimuat dan menggantikan font cadangan, ukuran hurufnya berbeda — dan seluruh paragraf bergeser.

Perbaikannya: pilih font cadangan yang metriknya mirip, dan sesuaikan dengan properti size-adjust di @font-face. Atau lebih sederhana, terima font sistem untuk teks isi.

Penyebab ketiga: elemen yang disisipkan di atas

Banner kuki, notifikasi, atau iklan yang muncul di atas konten akan mendorong semuanya ke bawah. Sediakan ruangnya sejak awal lewat CSS, atau tampilkan sebagai lapisan mengambang yang tidak mengganggu aliran halaman.

INP: respons terhadap interaksi

INP menggantikan FID sebagai metrik responsivitas. Ia mengukur jeda antara pengunjung mengklik sesuatu dan halaman benar-benar bereaksi.

Untuk situs statis yang isinya sebagian besar teks dan gambar, INP jarang bermasalah — tidak banyak JavaScript yang berjalan.

Ia jadi masalah begitu ada JavaScript berat. Penyebab tersering:

• Terlalu banyak JavaScript dimuat sekaligus. Situs statis yang menyertakan framework penuh untuk satu tombol interaktif membayar mahal untuk sedikit manfaat.
• Skrip pihak ketiga. Widget analitik, chat, dan iklan sering jadi penyumbang terbesar — dan paling sering luput dari perhatian karena bukan kodemu.
• Penanganan event yang berat. Perhitungan panjang di dalam fungsi yang dipanggil tiap klik atau ketikan.

Perbaikan yang paling berdampak

Kurangi JavaScript. Ini terdengar terlalu sederhana, tapi memang itu jawabannya. Astro punya pendekatan yang bagus untuk ini — komponen dikirim sebagai HTML biasa kecuali kamu menandainya perlu interaktif:

<!-- HTML saja, nol JavaScript -->
<Komponen />

<!-- JavaScript dimuat setelah halaman siap -->
<Komponen client:idle />

<!-- JavaScript dimuat saat komponennya terlihat -->
<Komponen client:visible />

Tunda skrip pihak ketiga. Muat widget chat dan analitik setelah halaman siap, bukan bersamaan dengan konten utama.

Cara mengukur dengan benar

Ini bagian yang paling sering salah, dan menyebabkan orang mengejar angka yang keliru.

Data lab vs data lapangan

Skor Lighthouse 100 tidak berarti Core Web Vitals-mu baik. Lighthouse menguji satu kali, dari satu tempat, dengan kondisi simulasi. Data lapangan mengumpulkan pengalaman pengunjung sungguhan selama 28 hari.

Yang menentukan adalah data lapangan. Lihat di Google Search Console pada laporan Core Web Vitals, atau di bagian atas hasil PageSpeed Insights.

Kalau data lapanganmu kosong

Situs baru atau yang sepi tidak punya cukup data untuk ditampilkan. Ini normal dan bukan masalah — pakai data lab sebagai panduan sampai trafikmu cukup.

Uji dari kondisi yang realistis

Menguji dari laptop cepat di WiFi kantor akan selalu memberi hasil bagus. Di DevTools, buka tab Network dan aktifkan pembatasan kecepatan, atau pakai profil perangkat seluler di Lighthouse.

Sebagian besar pengunjungmu datang dari ponsel dengan jaringan yang tidak selalu bagus. Itu kondisi yang perlu kamu uji.

Urutan pengerjaan yang masuk akal

Kalau kamu memulai dari nol, kerjakan dengan urutan ini — dari yang paling berdampak per usaha:

1. Beri width dan height pada semua gambar. Perbaikan CLS terbesar, dan paling murah.
2. Ubah gambar ke WebP dan kecilkan sesuai ukuran tampilnya.
3. Hapus loading="lazy" dari gambar utama, dan tambahkan fetchpriority="high".
4. Audit skrip pihak ketiga. Buang yang tidak dipakai, tunda sisanya.
5. Preconnect ke host font dan pastikan font-display: swap.
6. Kurangi JavaScript untuk komponen yang sebenarnya tidak interaktif.

Empat langkah pertama biasanya sudah cukup untuk membawa situs statis ke zona hijau.

Yang tidak perlu kamu khawatirkan

• Skor Lighthouse yang tidak sempurna. 90 dan 100 tidak berbeda di mata Google — yang dinilai adalah ambang batas data lapangan.
• Selisih beberapa milidetik. Perbedaan antara LCP 1,2 dan 1,4 detik tidak berarti apa-apa. Yang penting berada di bawah 2,5 detik.
• Angka yang berubah-ubah tiap pengujian. Data lab memang berfluktuasi. Jalankan beberapa kali dan lihat kecenderungannya.

Ringkasan

Keunggulan situs statis di Core Web Vitals itu nyata, tapi bukan otomatis. Yang paling sering membuangnya adalah gambar — jadi mulailah dari sana.

Untuk memahami kenapa arsitektur statis membantu sejak awal, lihat SSG vs SSR vs CSR dan apa itu CDN dan edge network.