Core Web Vitals di 2026
Google terus memperbarui metrik Core Web Vitals sebagai sinyal ranking yang semakin berpengaruh. Di 2026, tiga metrik utama adalah Largest Contentful Paint (LCP), Interaction to Next Paint (INP), dan Cumulative Layout Shift (CLS). INP menggantikan First Input Delay (FID) sejak Maret 2024, mengukur responsivitas keseluruhan halaman sepanjang lifecycle-nya, bukan hanya interaksi pertama.
Mencapai skor hijau di ketiga metrik bukan hanya soal SEO ranking. Data dari berbagai studi menunjukkan korelasi langsung: halaman yang cepat dan responsif menghasilkan engagement 20-30% lebih tinggi, bounce rate yang lebih rendah, dan conversion rate yang measurably lebih baik. Ini adalah investasi teknis yang memberikan return langsung ke business metrics.
Artikel ini membahas strategi yang actionable untuk setiap metrik, bukan teori abstrak. Setiap teknik yang disebutkan sudah terbukti efektif di production sites dengan traffic jutaan pageviews per bulan.
Largest Contentful Paint (LCP)
LCP mengukur waktu yang dibutuhkan untuk merender elemen konten terbesar yang visible di viewport saat initial load. Target: di bawah 2.5 detik untuk pengalaman yang baik. Elemen yang biasanya menjadi LCP candidate: hero image, heading text besar, video poster frame, atau background image yang prominent. Optimasi LCP fokus pada mengurangi setiap millisecond antara navigation start dan render elemen tersebut.
Optimasi Server Response
Time to First Byte (TTFB) adalah fondasi LCP karena browser tidak bisa mulai merender sebelum menerima byte pertama dari server. Gunakan CDN untuk mendekatkan content ke user secara geografis, implementasikan server-side caching (Redis, Varnish) untuk halaman yang jarang berubah, dan optimalkan database queries yang blocking response generation.
Untuk Next.js, gunakan ISR (Incremental Static Regeneration) untuk halaman yang bisa di-cache dengan revalidation period. Static pages memiliki TTFB mendekati nol karena served langsung dari CDN edge tanpa server computation. Untuk dynamic pages, streaming SSR memungkinkan browser mulai rendering sebelum seluruh response selesai.
Optimasi Resource Loading
Preload LCP image menggunakan link rel="preload" di document head agar browser mulai download segera tanpa menunggu parser menemukan img tag di body. Gunakan format modern (WebP untuk broad support, AVIF untuk maximum compression) dengan fallback via picture element. Implementasikan responsive images dengan srcset dan sizes agar browser memilih ukuran yang tepat untuk viewport dan DPR.
Untuk font yang menjadi bagian dari LCP element (heading text), gunakan font-display: swap agar text visible segera dengan fallback font, dan preload font file yang dibutuhkan. Pertimbangkan menggunakan system font stack untuk above-the-fold text jika font loading menjadi bottleneck.
Render-Blocking Resources
CSS dan synchronous JavaScript memblokir rendering: browser tidak akan merender apapun sampai semua render-blocking resources selesai di-download dan di-parse. Inline critical CSS yang dibutuhkan untuk above-the-fold content langsung di document head, defer non-critical CSS menggunakan media="print" trick atau rel="preload", dan gunakan async atau defer attribute untuk JavaScript yang tidak essential untuk initial render.
Setiap kilobyte CSS yang di-inline dan setiap script yang di-defer langsung mengurangi render-blocking time dan mempercepat LCP. Audit render-blocking resources menggunakan Lighthouse atau WebPageTest waterfall chart.
Interaction to Next Paint (INP)
INP mengukur latency dari interaksi user (click, tap, key press) hingga browser merender visual feedback yang merespons interaksi tersebut. Target: di bawah 200ms untuk pengalaman yang responsif. INP menangkap worst-case interaction sepanjang lifecycle halaman (bukan average), yang berarti satu event handler yang lambat akan mempengaruhi skor keseluruhan.
INP terdiri dari tiga fase: input delay (waktu menunggu main thread available), processing time (eksekusi event handler), dan presentation delay (waktu untuk render update ke screen). Optimasi perlu menargetkan ketiga fase.
Mengidentifikasi Slow Interactions
Gunakan Chrome DevTools Performance panel untuk merekam interaksi dan mengidentifikasi long tasks yang memblokir main thread. Web Vitals Chrome extension menampilkan INP secara real-time saat berinteraksi dengan halaman, highlighting interaksi yang melebihi threshold. Di production, gunakan PerformanceObserver API dengan type "event" untuk mengumpulkan INP data dari real users dan mengidentifikasi halaman atau komponen yang bermasalah.
Optimasi Event Handlers
Pisahkan visual feedback dari heavy computation. Pattern yang efektif: update UI state segera (optimistic update), lalu jalankan heavy processing secara asynchronous. Gunakan requestAnimationFrame untuk memastikan visual update terjadi di frame berikutnya, lalu setTimeout atau queueMicrotask untuk processing yang bisa di-defer.
Hindari forced synchronous layout (layout thrashing) dalam event handlers: batch semua DOM reads sebelum DOM writes. Untuk React, gunakan useTransition untuk menandai state updates yang bisa di-defer tanpa blocking urgent UI updates seperti input responses.
Yield to Main Thread
Long tasks (lebih dari 50ms continuous execution) memblokir main thread dan membuat interaksi terasa laggy karena browser tidak bisa memproses pending input events. Break long tasks menjadi chunks yang lebih kecil menggunakan scheduler.yield() (modern API), atau fallback ke setTimeout(fn, 0) yang memberikan browser kesempatan untuk memproses pending interactions di antara chunks.
Untuk React applications, concurrent features (useTransition, useDeferredValue) secara otomatis yield ke main thread selama rendering, mencegah long tasks dari complex re-renders. Ini adalah salah satu keuntungan terbesar React 18+ untuk INP optimization.
Cumulative Layout Shift (CLS)
CLS mengukur seberapa banyak layout bergeser secara unexpected selama lifecycle halaman. Target: di bawah 0.1. Layout shift terjadi ketika elemen yang sudah visible berubah posisi tanpa dipicu oleh interaksi user (click, tap). Shift yang terjadi dalam 500ms setelah user interaction tidak dihitung.
Penyebab umum CLS: images dan videos tanpa explicit dimensions, web fonts yang mengubah text metrics saat loading, dynamic content (ads, embeds, cookie banners) yang di-inject di atas existing content, dan lazy-loaded components yang mengubah layout saat muncul.
Mencegah Layout Shift
Selalu definisikan width dan height attributes (atau CSS aspect-ratio property) untuk semua images dan videos. Browser menggunakan dimensi ini untuk reserve space sebelum resource selesai di-download. Gunakan CSS contain: layout untuk elemen yang ukurannya bisa berubah secara dynamic agar perubahan tidak mempengaruhi surrounding elements.
Reserve space untuk dynamic content menggunakan min-height pada container, skeleton placeholder yang match dimensi final content, atau CSS content-visibility: auto untuk off-screen content. Untuk web fonts, gunakan size-adjust dan ascent-override descriptors agar fallback font memiliki metrics yang identik dengan web font, eliminating font swap shift.
Animasi yang CLS-Safe
Animasi yang mengubah layout properties (width, height, top, left, margin, padding) menyebabkan layout shift yang dihitung oleh CLS. Gunakan transform (translate, scale) dan opacity yang berjalan di compositor thread tanpa mempengaruhi document layout. Untuk expand/collapse animations, animasikan max-height atau gunakan View Transitions API yang secara eksplisit excluded dari CLS calculation.
Jika harus menganimasi layout properties (misalnya accordion expand), pastikan animasi triggered oleh user interaction sehingga shift terjadi dalam 500ms window dan tidak dihitung sebagai unexpected shift.
Monitoring dan Continuous Improvement
Core Web Vitals bukan one-time optimization project. Implementasikan Real User Monitoring (RUM) untuk tracking metrik dari actual users di berbagai devices, networks, dan geographies. Google CrUX (Chrome User Experience Report) menyediakan aggregated field data dari Chrome users yang bisa diakses via PageSpeed Insights atau BigQuery.
Combine field data (what users actually experience) dengan lab data (Lighthouse, WebPageTest) untuk debugging. Field data menunjukkan where problems exist, lab data membantu diagnose why. Set performance budgets di CI pipeline: gagalkan build atau PR jika LCP regression melebihi threshold yang ditentukan.
Pendekatan yang sustainable: prioritaskan halaman dengan traffic tertinggi dan worst scores, fix regressions segera setelah terdeteksi di monitoring, dan jadikan performance review sebagai bagian dari code review process. Performa web adalah tanggung jawab seluruh engineering team, bukan satu dedicated performance engineer.
