Belajar Frontend - Web Performance (Core Web Vitals)

#Pendahuluan

Setelah di episode 11 TokoKita punya data yang robust, episode 12 menjawab pertanyaan yang menentukan: seberapa cepat halaman ini terasa bagi pengguna? Performa bukan sekadar angka teknis — Google menggunakannya untuk peringkat pencarian, dan yang lebih penting, performa buruk langsung terasa sebagai pengalaman buruk.

Inti performa modern adalah Core Web Vitals, tiga metrik yang mengukur pengalaman nyata pengguna, bukan sekadar waktu server. Memahami ketiganya — LCP, INP, dan CLS — plus teknik optimasinya, adalah kompetensi wajib frontend di 2026.

#Core Web Vitals

Metrik	Mengukur	Target "Good"
LCP (Largest Contentful Paint)	Seberapa cepat konten utama terlihat	≤ 2,5 detik
INP (Interaction to Next Paint)	Seberapa cepat respons terhadap interaksi	≤ 200 ms
CLS (Cumulative Layout Shift)	Seberapa banyak layout "melompat"	≤ 0,1

LCP — biasanya gambar hero atau heading besar. Mengukur dari awal navigasi sampai elemen terbesar ter-render.
INP — menggantikan FID; mengukur latensi dari klik sampai halaman merespons. Buruk jika main thread sibuk (ingat: JS single-threaded dari episode 5).
CLS — skor ketidakstabilan layout. Gambar tanpa ukuran, font yang swap, dan iklan yang muncul belakangan adalah penyebab umum.

Note

INP adalah pengingat mengapa episode 5 menekankan async dan episode 11 menekankan optimistic update: interaksi yang terasa "lambat" hampir selalu karena main thread diblokir atau UI menunggu server tanpa umpan balik.

#Mengukur: Lighthouse dan web-vitals

Langkah pertama sebelum optimasi adalah mengukur — jangan menebak.

Audit dengan Lighthouse CLI

bunx @lhci/cli autorun --collect.url=http://localhost:3000 --collect.numberOfRuns=3

Di browser: DevTools → Lighthouse → Generate report. Atau untuk pemantauan real user, gunakan library web-vitals:

Memantau CWV di produksi

import { onLCP, onINP, onCLS } from "web-vitals";
 
onLCP((m) => console.log("LCP:", m.value));
onINP((m) => console.log("INP:", m.value));
onCLS((m) => console.log("CLS:", m.value));

Metrik dari pengguna nyata (field data) lebih jujur daripada lab — itulah yang dilihat Google Search Console.

#Code-Splitting dan Lazy Loading

Bundle JavaScript raksasa adalah biang LCP/INP buruk. Solusinya: kirim hanya yang dibutuhkan layar ini.

Lazy load komponen besar

import { lazy, Suspense } from "react";
 
const CheckoutForm = lazy(() => import("./CheckoutForm"));
 
// CheckoutForm hanya dimuat saat dialog checkout dibuka
<Suspense fallback={<p>Memuat…</p>}>
  {isOpen && <CheckoutForm />}
</Suspense>

Praktik terkait:

Route-level splitting — Next.js memecah otomatis per halaman; jangan import semua komponen di satu bundle.
next/dynamic untuk komponen besar yang jarang dipakai (chart, editor).
Native lazy loading gambar: <img loading="lazy"> atau next/image dengan priority untuk hero.

#Optimasi Gambar dan Font

Gambar biasanya menyumbang 50-70% ukuran halaman. Prinsipnya:

next/image dengan ukuran eksplisit

import Image from "next/image";
 
<Image
  src="/kopi.jpg"
  alt="Kemasan kopi arabika 250 gram"
  width={640}
  height={480}
  priority
/>

width/height eksplisit mencegah layout shift (CLS), priority mempercepat LCP hero, dan Next.js otomatis mengubah format ke modern (WebP/AVIF) + responsive sizes.

Font: gunakan next/font (self-host, font-display: swap dengan fallback yang dekat) supaya teks tidak melompat saat font termuat:

next/font tanpa CLS

import { Inter } from "next/font/google";
 
const inter = Inter({ subsets: ["latin"], display: "swap" });

#Workflow Audit TokoKita

Urutan kerja yang realistis:

Ukur baseline — Lighthouse + field data (web-vitals).
Temukan LCP — inspeksi panel Network: apa elemen LCP, seberapa besar, bisa kompres/pindah?
Turunkan INP — cari long tasks di Performance panel; pindahkan kerja berat ke worker (episode 21) atau pecah.
Hilangkan CLS — beri ukuran semua gambar, stabilkan font, jangan inject konten di atas fold.
Ulangi — ukur lagi setelah setiap perubahan.

Analisis bundle untuk menemukan pembengkakan

bunx next build   # lihat ukuran tiap route di output

Tip

Optimasi dimulai dari pengukuran: jika LCP kalian sudah 1,8 detik, jangan habiskan waktu mengoptimasi hal yang tidak menyentuh LCP. Kerjakan yang berdampak paling besar pada metrik yang paling buruk.

#Penutup

Inti yang harus dibawa pulang:

Core Web Vitals = LCP (muat cepat), INP (responsif), CLS (stabil) — target "good": ≤2,5s, ≤200ms, ≤0,1.
Ukur dulu dengan Lighthouse dan web-vitals, baru optimasi.
Code-splitting & lazy loading mengecilkan bundle; gambar dan font self-host menjaga LCP dan CLS.
Workflow: ukur → identifikasi metrik terburuk → optimasi → ukur ulang.

Di episode 13 selanjutnya kita memastikan kualitas: testing frontend — unit test dengan Vitest, component test, dan end-to-end dengan Playwright/Cypress, sehingga TokoKita bisa diubah tanpa takut rusak. Sampai jumpa di episode 13!