Real User Monitoring: Mengapa Data Lab Menipu dan Data Lapangan Menang

Saya menjalankan audit Lighthouse pada matthewswong.com dan mendapat skor 98. Kemudian saya memeriksa data lapangan Chrome User Experience Report (CrUX) dan menemukan LCP saya 3,1 detik untuk pengguna nyata di ponsel. Kesenjangan itu mengejutkan saya. Pengalaman itulah yang membuat Real User Monitoring (RUM) bukan opsional — ini adalah satu-satunya cara untuk mengetahui apa yang benar-benar dialami pengguna. Algoritma peringkat Google menggunakan data lapangan CrUX, bukan skor Lighthouse Anda. Jika Anda mengoptimalkan untuk lab tetapi bukan untuk lapangan, Anda memainkan game yang berbeda dari yang dimainkan Google.

Lab vs Lapangan: Perbedaan Fundamental

Lighthouse berjalan di instance Chrome yang dikontrol dengan CPU throttled dan koneksi 4G yang disimulasikan. Ini adalah tes sintetis — berguna untuk menangkap regresi di CI, tetapi pada dasarnya terputus dari keragaman kondisi dunia nyata. RUM (Real User Monitoring) mengumpulkan data performa dari pemuatan halaman aktual di perangkat dan jaringan nyata. Library JavaScript Web Vitals, yang dipelihara oleh Google, dapat disematkan di situs mana pun untuk melaporkan LCP, INP, CLS, FCP, dan TTFB untuk setiap sesi nyata. Data dikumpulkan di CrUX dengan jendela bergulir 28 hari — skor hari ini mencerminkan empat minggu kunjungan pengguna aktual terakhir.

Dataset CrUX

CrUX (Chrome User Experience Report) adalah dataset publik yang mendukung penilaian Core Web Vitals Google di Search Console dan PageSpeed Insights. Ini dibangun dari pengguna Chrome opt-in di seluruh dunia. Agar situs Anda memiliki data CrUX, situs perlu lalu lintas yang cukup. Data diterbitkan sebagai dataset BigQuery, diekspos melalui CrUX API, dan terlihat di PageSpeed Insights. Persentil yang penting untuk peringkat Google adalah p75 — persentil ke-75 dari pengalaman pengguna Anda.

Library JavaScript web-vitals

Library web-vitals open-source Google adalah implementasi referensi untuk mengukur CWV di lapangan. Menginstalnya membutuhkan dua menit: `npm install web-vitals`. Kemudian impor pelapor metrik (onLCP, onINP, onCLS, onFCP, onTTFB) dan kirim data ke endpoint analitik Anda. Library menangani nuansa setiap metrik dengan benar. Untuk situs portofolio seperti milik saya, saya mengirim data ke Vercel Analytics.

Lab Data (Lighthouse)                Field Data (CrUX / RUM)
──────────────────────               ──────────────────────────────
Controlled Chrome instance           Real user browsers (Chrome opt-in)
Simulated 4G + mid-tier CPU          Actual device + network diversity
Single test run                      28-day rolling window (p75)
Build-time CI check                  Google Search ranking signal

web-vitals JS library flow:
  User visits page
       │
       ▼
  LCP measured (largest element renders)
  INP measured (worst interaction recorded)
  CLS measured (layout shift accumulated)
       │
       ▼
  onLCP / onINP / onCLS callbacks fire
       │
       ▼
  Send to: Vercel Analytics / GA4 / custom endpoint
       │
       ▼
  Aggregate → p75 per metric per URL

Menyiapkan RUM Tanpa Alat Berbayar

Anda tidak perlu Datadog atau New Relic untuk memulai dengan RUM. Untuk aplikasi Next.js, Vercel Analytics gratis hingga 2.500 event/bulan dan terintegrasi dengan satu instalasi paket. Untuk pengaturan self-hosted atau kustom, Anda dapat mengirim data web-vitals ke endpoint analitik apa pun — Google Analytics 4 mendukung event kustom.

Pengaturan RUM Aktual Saya

Saya menggunakan pembungkus tipis di sekitar library web-vitals yang mengirim metrik ke event kustom Vercel Analytics. Implementasinya kurang dari 20 baris. Bidang kunci yang saya tangkap: nama metrik, nilai metrik, rating metrik (good/needs-improvement/poor), jenis navigasi, dan debug target. Bidang terakhir — debug target — sangat berharga: ini memberi tahu Anda bukan hanya bahwa LCP lambat, tetapi elemen spesifik mana yang menjadi penyebabnya.

// app/layout.tsx — RUM setup for Next.js
import { onCLS, onFCP, onINP, onLCP, onTTFB } from 'web-vitals'

function sendToAnalytics({ name, value, rating, navigationType, id }: {
  name: string; value: number; rating: string;
  navigationType: string; id: string
}) {
  // Vercel Analytics (free tier)
  if (typeof window !== 'undefined' && window.va) {
    window.va('event', { name: `cwv_${name.toLowerCase()}`, value, rating })
  }

  // Or send to your own endpoint
  fetch('/api/metrics', {
    method: 'POST',
    body: JSON.stringify({ name, value, rating, navigationType, id }),
    keepalive: true, // survives page unload
  })
}

// Call in a useEffect in your root layout client component
export function WebVitalsReporter() {
  useEffect(() => {
    onLCP(sendToAnalytics)
    onINP(sendToAnalytics)
    onCLS(sendToAnalytics)
    onFCP(sendToAnalytics)
    onTTFB(sendToAnalytics)
  }, [])
  return null
}

// CrUX API query (weekly monitoring script)
const response = await fetch(
  `https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=${API_KEY}`,
  {
    method: 'POST',
    body: JSON.stringify({
      url: 'https://matthewswong.com/',
      metrics: ['largest_contentful_paint', 'interaction_to_next_paint', 'cumulative_layout_shift'],
    }),
  }
)
const data = await response.json()
// Check: data.record.metrics.largest_contentful_paint.percentiles.p75

Membaca Data RUM: Apa yang Harus Diperhatikan

Ketika saya menganalisis data RUM untuk situs produksi, saya melihat tiga dimensi: distribusi nilai metrik (bukan hanya rata-rata — p75 dan p95 penting), segmentasi berdasarkan jenis perangkat dan jenis koneksi, dan korelasi dengan bounce rate. Sebuah situs dapat memiliki LCP p50 yang sangat baik (2,0d) tetapi p95 yang mengerikan (8,0d) — artinya sebagian besar pengguna baik-baik saja tetapi ekor pengguna di koneksi lambat memiliki pengalaman yang buruk.

Menghubungkan RUM dengan Metrik Bisnis

Penelitian Google menunjukkan peningkatan 0,1d dalam LCP berkorelasi dengan peningkatan tingkat konversi 5-10% untuk e-commerce. Untuk situs konten, peningkatan 100ms dalam FCP berkorelasi dengan penurunan 7% dalam bounce rate. Ini bukan hasil yang dijamin — ini adalah korelasi tingkat populasi — tetapi mereka memberi peningkatan RUM sebuah kasus bisnis.

Mengotomatiskan Peringatan RUM

Tujuannya adalah mengetahui regresi data lapangan sebelum memengaruhi peringkat. Siapkan pekerjaan mingguan yang mengkueri API CrUX untuk URL Anda dan membandingkan nilai p75 terhadap ambang batas Anda. Beri peringatan jika LCP p75 melebihi 2,5d, INP p75 melebihi 200ms, atau CLS p75 melebihi 0,1. API CrUX gratis dan hanya memerlukan kunci API Google.

Sumber & Bacaan Lebih Lanjut

• Google — Core Web Vitals Measurement Getting Started — https://web.dev/articles/vitals-measurement-getting-started
• DebugBear — Real User Monitoring for Web Performance — https://www.debugbear.com/docs/rum/real-user-monitoring
• Datadog — Optimize Core Web Vitals with RUM — https://www.datadoghq.com/blog/rum-optimization/