Debugging & Optimasi
Lintas Stack

Sinyal diagnostik di balik Core Web Vitals

Core Web Vitals adalah metrik yang dinilai oleh Google, tetapi FCP, TTFB, dan TBT adalah metrik yang menjelaskan mengapa Core Web Vitals buruk — tanpa ketiganya, debugging terasa seperti menebak dalam gelap.

Ketika LCP sebuah halaman berada di zona merah, jawabannya tidak selalu jelas hanya dari angka LCP itu sendiri. Apakah server lambat mengirim byte pertama? Apakah ada rantai resource yang memblokir render? Apakah JavaScript terlalu banyak sehingga main thread tidak tersedia untuk merender? FCP, TTFB, TBT, dan Speed Index adalah instrumen diagnostik yang membantu menjawab pertanyaan-pertanyaan ini.

FCP (First Contentful Paint) mengukur kapan pertama kali browser merender konten apapun yang bisa dilihat — teks, gambar, elemen SVG, atau canvas non-putih. Ini berbeda dari LCP: FCP bisa dipicu oleh spinner loading, placeholder kosong, atau header navigasi, bukan konten utama halaman. FCP berguna sebagai sinyal bahwa “halaman sudah mulai merespons” — jika FCP juga lambat, berarti masalah ada di awal sekali, kemungkinan besar di server response atau resource yang memblokir rendering. Target FCP yang baik adalah ≤ 1.8 detik. Perlu dicatat bahwa FCP tidak masuk dalam Core Web Vitals yang dinilai Google untuk ranking, tetapi sangat berguna sebagai diagnostic signal di Lighthouse dan PageSpeed Insights.

TTFB (Time to First Byte) mengukur waktu dari user mengirim request URL sampai byte pertama dari response HTML tiba di browser. Ini adalah metrik server-side murni — semua yang terjadi antara request dan byte pertama adalah tanggung jawab infrastruktur kamu: pemrosesan di server, query database, cache hit/miss, jarak ke CDN, dan kualitas koneksi jaringan. Target TTFB menurut Lighthouse adalah ≤ 800ms, tetapi dalam praktik production, origin web yang baik seharusnya merespons dalam < 200ms sebelum CDN meneruskan ke user. TTFB yang tinggi hampir selalu merupakan masalah backend — bukan frontend.

TBT (Total Blocking Time) mengukur total waktu main thread JavaScript diblokir antara FCP dan TTI (Time to Interactive). Setiap tugas JavaScript yang berjalan lebih dari 50ms dianggap “long task”, dan TBT adalah jumlah dari (durasi task - 50ms) untuk semua long task yang terjadi dalam rentang tersebut. TBT adalah lab proxy untuk INP — jika TBT tinggi di Lighthouse, sangat besar kemungkinan INP juga tinggi di lapangan, karena long tasks yang sama yang menyumbang TBT juga yang akan menunda respons interaksi pengguna. Target TBT adalah ≤ 200ms dan bobotnya 30% dari Lighthouse Performance Score — ini bobot terbesar kedua setelah LCP.

Speed Index mengukur seberapa cepat konten visual halaman terisi secara progresif, dihitung dari rekaman video halaman loading. Speed Index yang rendah berarti pengguna melihat konten lebih cepat secara keseluruhan, bukan hanya pada satu momen tertentu. Ini berguna untuk membandingkan dua implementasi yang berbeda secara holistik, tetapi kurang berguna untuk debugging spesifik karena tidak menunjuk ke penyebab tunggal.

flowchart LR
  subgraph NETWORK
    A[Browser Request] --> B[TTFB: Byte Pertama Tiba]
  end
  subgraph PARSE AND RENDER
    B --> C[FCP: Render Pertama]
    C --> D[Long Tasks / TBT Accumulate]
    D --> E[LCP: Konten Utama Render]
    E --> F[TTI: Fully Interactive]
  end
  style A fill:#f5f0eb,stroke:#d4a574
  style B fill:#fde8d8,stroke:#e8845c
  style C fill:#fde8d8,stroke:#e8845c
  style D fill:#ffe0d0,stroke:#c96a3c
  style E fill:#fde8d8,stroke:#e8845c
  style F fill:#f0faf0,stroke:#5a9a5a

Timeline metrik performa. TTFB terjadi paling awal di fase jaringan; FCP adalah render pertama; TBT terakumulasi antara FCP dan TTI; LCP terjadi di tengah; TTI menandai akhir dari fase blocking.

Dengan memahami apa yang diukur masing-masing metrik pendukung ini, kita siap membangun workflow debug yang tidak sekadar reaktif, melainkan sistematis dan terukur.

Dari data lapangan ke fix produksi yang terverifikasi

Kesalahan terbesar dalam debugging performa adalah membuka Lighthouse terlalu awal — sebelum tahu halaman mana yang bermasalah, di segment pengguna mana, dan seberapa buruk kondisi lapangannya.

Lighthouse adalah alat lab yang sangat berguna, tetapi ia mengukur satu halaman, satu kali, dengan koneksi dan perangkat yang disimulasi. Data lapangan (field data) dari pengguna nyata seringkali sangat berbeda — terutama untuk pengguna dengan perangkat low-end atau koneksi lambat di Indonesia. Workflow debug yang baik selalu dimulai dari lapangan, bukan dari lab.

Permasalahan performa juga sering tersembunyi di balik agregasi. Halaman utama (/) mungkin terlihat cepat karena didominasi oleh pengguna desktop dengan koneksi cepat, sementara halaman produk (/product/[id]) yang justru paling banyak diakses oleh pengguna mobile mengalami LCP buruk secara konsisten. Tanpa segmentasi, masalah yang paling berdampak terhadap bisnis bisa terlewat.

flowchart TD
  A[Field Data: CrUX / PSI / Search Console] --> B[Identifikasi Halaman dengan Status Poor]
  B --> C[Segmentasi: Mobile vs Desktop / Slow vs Fast Connection]
  C --> D[Reproduce di Lab: DevTools Throttled / Lighthouse]
  D --> E[Trace Performance: Identifikasi Phase Bottleneck]
  E --> F{Kategori Bottleneck?}
  F --> G[Server / Network]
  F --> H[Render Blocking]
  F --> I[JavaScript]
  F --> J[Image / Font]
  F --> K[Third-party]
  G --> L[Fix Iteratif: Satu Fix Satu Ukur]
  H --> L
  I --> L
  J --> L
  K --> L
  L --> M[Deploy ke Produksi]
  M --> N[Verify: RUM atau Tunggu 28 Hari CrUX]

Workflow debug sistematis. Mulai dari field data, segmentasi, reproduce di lab, trace bottleneck, fix iteratif, lalu verifikasi kembali di lapangan. Jangan loncat dari A langsung ke L.

Setelah memahami cara menemukan masalah, saatnya melihat toolkit konkret untuk memperbaikinya — dimulai dari lapisan frontend.

Teknik-teknik yang bekerja di lapisan browser dan build pipeline

Sebagian besar perbaikan performa frontend bermuara ke dua hal: kirim lebih sedikit bytes, dan jalankan lebih sedikit JavaScript sebelum halaman bisa digunakan.

Frontend developer memiliki kendali langsung atas apa yang dikirim ke browser: ukuran bundle JavaScript, format dan dimensi gambar, urutan loading resource, dan font yang digunakan. Teknik-teknik di seksi ini bisa diterapkan secara independen — tidak perlu mengubah backend untuk mendapatkan manfaatnya.

Code splitting adalah teknik memecah bundle JavaScript yang besar menjadi potongan-potongan kecil yang hanya dimuat saat dibutuhkan. Tanpa code splitting, sebuah aplikasi single-page yang punya 50 halaman akan mengirim kode semua halaman itu kepada pengguna yang hanya membuka halaman beranda. Di React, ini dilakukan dengan React.lazy dan Suspense. Di Next.js, dynamic() dari next/dynamic otomatis melakukan code splitting per komponen. Di Vite, cukup menggunakan import() dinamis dan Rollup akan otomatis memisahkan chunk.

javascriptSalin
// React: lazy load komponen yang hanya dipakai di halaman tertentu
const ProductDetail = React.lazy(() => import('./ProductDetail'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <ProductDetail />
    </Suspense>
  );
}

// Next.js: dynamic import dengan no SSR untuk komponen browser-only
import dynamic from 'next/dynamic';
const HeavyChart = dynamic(() => import('../components/HeavyChart'), {
  ssr: false,
  loading: () => <p>Loading chart...</p>,
});

Lazy loading gambar berarti gambar yang berada di bawah viewport pertama tidak dimuat sampai pengguna mendekati area tersebut. Ini bisa dilakukan hanya dengan menambahkan atribut loading="lazy" pada elemen <img>. Penting: jangan lazy load gambar LCP, karena itu justru memperlambat metrik yang paling penting. Lazy load hanya untuk gambar yang tidak terlihat saat halaman pertama kali dibuka.

Preload, preconnect, dan dns-prefetch adalah hint kepada browser tentang resource yang akan dibutuhkan segera. <link rel="preload"> digunakan untuk resource yang pasti dipakai di halaman ini — terutama gambar LCP dan font kritikal. <link rel="preconnect"> digunakan untuk domain eksternal yang pasti dihubungi (CDN gambar, API, analytics) agar handshake TCP dan TLS sudah selesai sebelum request sebenarnya dibuat. <link rel="dns-prefetch"> adalah versi yang lebih ringan dan menjadi fallback untuk browser yang tidak mendukung preconnect.

HTMLSalin
<!-- Preload gambar LCP - WAJIB untuk hero image -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- Preconnect ke CDN gambar -->
<link rel="preconnect" href="https://cdn.skincare-backend.com" crossorigin>

<!-- Preconnect ke font provider -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

Critical CSS adalah CSS yang dibutuhkan untuk merender konten above-the-fold. Daripada memuat satu stylesheet besar yang memblokir rendering, inline CSS kritikal di dalam <style> di dalam <head>, lalu muat sisanya secara non-blocking. Tools seperti Critters (dipakai Next.js dan Angular) mengotomatiskan ekstraksi critical CSS.

Tree shaking mengeliminasi kode JavaScript yang tidak pernah dipanggil (dead code). Ini memerlukan modul ES Modules (import/export) — CommonJS (require) tidak bisa di-tree-shake. Pastikan library yang kamu pakai menyediakan ESM build, dan hindari import seperti import _ from 'lodash' yang menarik seluruh library; gunakan import debounce from 'lodash/debounce' atau lodash-es.

Image format dan responsivitas memiliki dampak besar pada LCP. WebP umumnya 25-35% lebih kecil dari JPEG dengan kualitas setara. AVIF lebih kecil lagi, tetapi dukungan browser masih lebih terbatas. Gunakan srcset dan sizes agar browser memilih resolusi yang tepat untuk layar dan DPR masing-masing perangkat.

HTMLSalin
<img
  src="/product.jpg"
  srcset="/product-400.webp 400w, /product-800.webp 800w, /product-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
  width="800"
  height="600"
  alt="Produk skincare"
  loading="lazy"
>

Font subsetting dan self-hosting menghilangkan ketergantungan pada Google Fonts CDN yang membutuhkan tambahan DNS lookup, TCP handshake, dan TLS handshake sebelum font bisa dimuat. Self-hosting font juga memungkinkan penggunaan font-display: optional atau font-display: swap dengan kontrol penuh, serta subsetting — hanya menyertakan karakter Latin yang benar-benar dipakai daripada seluruh Unicode set.

Audit third-party scripts adalah salah satu optimasi dengan ROI tertinggi. Setiap script di <head> berpotensi memblokir render, dan setiap script analytics atau marketing menambahkan long task di main thread. Tunda semua script yang tidak kritis dengan defer atau async, dan pertimbangkan apakah beberapa script betul-betul dibutuhkan atau bisa diganti dengan implementasi native yang lebih ringan.

Teknik-teknik frontend di atas efektif untuk bottleneck di sisi browser. Namun, jika TTFB sudah tinggi sejak awal, tidak ada teknik frontend yang bisa mengkompensasinya — itu adalah masalah backend dan infrastruktur.

TTFB adalah backend metric — sepenuhnya di kontrol server

Jika Lighthouse menampilkan peringatan “Reduce initial server response time”, itu bukan masalah CSS atau JavaScript — itu artinya server terlalu lambat mengirim HTML, dan solusinya ada di lapisan backend dan infrastruktur.

TTFB sering diabaikan oleh frontend developer karena terasa seperti “bukan urusan saya”. Padahal TTFB adalah komponen pertama dari LCP — setiap milisecond TTFB adalah milisecond yang ditambahkan ke LCP sebelum browser bahkan bisa mulai merender apapun. Jika backend kamu membutuhkan 1.2 detik untuk merespons, LCP tidak mungkin bisa di bawah 1.2 detik, tidak peduli seberapa optimal frontend-nya.

Database query performance adalah penyebab paling umum TTFB yang tinggi. Setiap page render di server yang membutuhkan query database — terutama tanpa index yang tepat atau dengan N+1 query problem — akan memperlambat response secara proporsional. Gunakan EXPLAIN ANALYZE di PostgreSQL atau EXPLAIN di MySQL untuk mengidentifikasi query lambat. Pasang index pada kolom yang digunakan di klausa WHERE, JOIN, dan ORDER BY. Untuk proyek seperti github.com/kamu/skincare-backend, query yang mengambil produk beserta variannya harus di-index pada product_id dan mungkin perlu di-eager-load untuk menghindari N+1.

SQLSalin
-- Identifikasi query lambat dengan EXPLAIN ANALYZE
EXPLAIN ANALYZE
SELECT p.*, v.*, r.average_rating
FROM products p
JOIN variants v ON v.product_id = p.id
LEFT JOIN product_ratings r ON r.product_id = p.id
WHERE p.category_id = $1
ORDER BY p.created_at DESC
LIMIT 20;

-- Indeks yang kemungkinan dibutuhkan
CREATE INDEX idx_products_category_created ON products(category_id, created_at DESC);
CREATE INDEX idx_variants_product ON variants(product_id);

Server-side caching adalah cara paling efektif untuk memangkas TTFB. Ada tiga lapisan caching yang bisa diterapkan:

• Full-page cache: cache seluruh HTML response untuk halaman yang tidak personalized. Ini bisa dilakukan di level CDN atau di aplikasi dengan Redis. Halaman kategori produk, blog, landing page — semua kandidat utama.
• Database query cache: cache hasil query yang sering dieksekusi tetapi datanya tidak berubah setiap detik. Redis sangat cocok untuk ini.
• API response cache: jika halaman bergantung pada API upstream untuk merender, cache response API tersebut di sisi server.

CDN (Content Delivery Network) tidak hanya untuk static assets. CDN modern seperti Cloudflare, Fastly, dan Akamai bisa meng-cache HTML response di edge node yang dekat dengan user, sehingga request tidak perlu sampai ke origin server. Strategi stale-while-revalidate di cache-control header memungkinkan CDN menyajikan cache yang sedikit lama sambil memperbarui di background — keseimbangan antara freshness dan kecepatan.

plaintextSalin
# Header untuk caching HTML di CDN dengan SWR
Cache-Control: public, max-age=60, stale-while-revalidate=600

Static Site Generation (SSG) membawa TTFB ke level terendah yang bisa dicapai: HTML di-pre-render pada saat build, disimpan sebagai file statis, dan disajikan langsung dari CDN tanpa pemrosesan server apapun. TTFB mendekati nol karena hanya melibatkan transfer file. Ini cocok untuk konten yang tidak berubah terlalu sering, seperti halaman produk, artikel blog, atau landing page.

Edge Functions dan Edge SSR adalah pendekatan modern yang menggabungkan keunggulan SSR (konten dinamis dan personalized) dengan keunggulan CDN (eksekusi dekat user). Dengan Cloudflare Workers, Vercel Edge Functions, atau Deno Deploy, kamu bisa menjalankan logika rendering di ratusan edge node di seluruh dunia, sehingga TTFB tetap rendah meski konten dinamis.

Kompresi Brotli memberikan rasio kompresi yang lebih baik dibanding Gzip untuk teks (HTML, CSS, JS), terutama untuk file berukuran sedang ke besar. Brotli menghasilkan file 15-25% lebih kecil dari Gzip dengan kecepatan dekompresi yang sebanding. Pastikan server atau CDN kamu mengaktifkan Brotli dan menyajikannya ke browser yang mendukung (semua browser modern mendukung Brotli).

HTTP/2 multiplexing memungkinkan browser mengirim banyak request secara paralel melalui satu koneksi TCP, menghilangkan head-of-line blocking yang ada di HTTP/1.1. Ini sangat membantu halaman dengan banyak resource kecil. HTTP/3 (QUIC) membawa ini lebih jauh dengan menghilangkan TCP head-of-line blocking sama sekali.

Redirect chains adalah musuh tersembunyi TTFB. Setiap redirect (HTTP 301/302) menambahkan satu round-trip ke waktu loading — termasuk DNS lookup baru, TCP handshake, dan TTFB tambahan. Pola umum yang harus dieliminasi: http:// → https:// → www. → non-www.. Konfigurasi server untuk mengarahkan langsung ke URL final.

flowchart LR
  A[Browser] -->|"DNS + TCP + TLS"| B[CDN Edge Node]
  B -->|"Cache HIT"| A
  B -->|"Cache MISS: origin fetch"| C[Load Balancer]
  C --> D[App Server]
  D -->|"DB query"| E[Database]
  E -->|"result"| D
  D -->|"rendered HTML"| C
  C -->|"HTML response"| B
  B -->|"store in edge cache"| B
  B -->|"HTML ke browser"| A
  style B fill:#fde8d8,stroke:#e8845c
  style E fill:#ffe0d0,stroke:#c96a3c

Request chain dari browser ke CDN ke origin. Cache HIT di CDN edge berarti TTFB sangat rendah — hanya latency jaringan. Cache MISS membutuhkan perjalanan penuh ke origin, termasuk query database, yang bisa menambahkan ratusan milidetik TTFB.

Memahami bagaimana backend memengaruhi Web Vitals membuka pertanyaan yang lebih luas: bagaimana framework populer — yang masing-masing punya opini kuat tentang rendering dan data fetching — membentuk karakteristik Web Vitals secara keseluruhan?

Bagaimana pilihan framework membentuk karakteristik LCP, INP, dan CLS

Tidak ada framework yang “otomatis cepat” — setiap framework memiliki gotcha Web Vitals tersendiri, dan mengetahui gotcha ini lebih penting daripada memilih framework yang “tercepat” secara teoritis.

Framework modern memang menyediakan banyak abstraksi yang membantu — optimasi gambar otomatis, code splitting per route, server-side rendering — tetapi abstraksi tersebut juga menyembunyikan biaya yang kadang tidak terlihat sampai di produksi dengan traffic nyata. Bagian ini membahas karakteristik Web Vitals yang spesifik untuk React/Next.js, Astro, Vue/Nuxt, dan Laravel Inertia.js.

React dan Next.js adalah kombinasi yang paling umum untuk aplikasi web skala besar. React memiliki satu karakteristik yang sangat memengaruhi INP: hydration cost. Saat halaman yang di-render server pertama kali dibuka, React harus menjalankan JavaScript untuk “menghidupkan” semua komponen — event listener dipasang, state diinisialisasi, dan React merender ulang seluruh tree untuk memastikan hasilnya konsisten dengan HTML yang dikirim server. Proses ini bisa menjadi long task besar yang menyumbang TBT tinggi dan membuat INP buruk di load awal.

React Server Components (RSC) di Next.js App Router adalah respons terhadap masalah ini. Komponen yang tidak membutuhkan interaktivitas dirender di server dan dikirim sebagai HTML — tidak ada JavaScript untuk komponen tersebut yang dikirim ke browser. Hanya Client Components yang membutuhkan hydration. Ini bisa mengurangi ukuran bundle JavaScript secara drastis, yang langsung memperbaiki TBT dan INP.

jsxSalin
// Server Component — tidak ada JS yang dikirim ke browser
// app/ProductList.tsx
import { db } from '@/lib/db';

export default async function ProductList() {
  const products = await db.query('SELECT * FROM products LIMIT 20');
  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>{p.name} — Rp {p.price.toLocaleString('id-ID')}</li>
      ))}
    </ul>
  );
}

// Client Component — hanya ini yang perlu dihydrate
'use client';
export function AddToCartButton({ productId }: { productId: string }) {
  const [loading, setLoading] = useState(false);
  return (
    <button onClick={() => handleAddToCart(productId, setLoading)}>
      {loading ? 'Menambahkan...' : 'Tambah ke Keranjang'}
    </button>
  );
}

Fitur next/image mengotomatiskan beberapa optimasi kritis: mengkonversi ke WebP/AVIF, menambahkan dimensi width/height untuk mencegah CLS, menerapkan lazy loading untuk gambar di bawah fold, dan menyajikan ukuran yang sesuai dengan viewport. next/script memungkinkan kontrol atas waktu eksekusi script pihak ketiga: strategy="afterInteractive" menunda eksekusi sampai halaman interaktif, dan strategy="lazyOnload" menunggu sampai semua resource lain selesai dimuat.

Astro mengambil pendekatan yang lebih radikal: zero JavaScript by default. Semua komponen dirender di server dan dikirim sebagai HTML murni — tidak ada hydration, tidak ada client-side JavaScript, tidak ada bundle. Ini menghasilkan LCP dan INP yang sangat baik secara by default karena tidak ada long tasks dari JavaScript yang perlu dieksekusi.

Untuk komponen yang membutuhkan interaktivitas, Astro menggunakan Islands Architecture: hanya komponen tersebut yang dihydrate, dan dengan direktif seperti client:idle atau client:visible, kamu bisa mengontrol kapan hydration terjadi — saat browser idle atau saat komponen masuk viewport.

astroSalin
---
// Komponen Astro — dirender di server, tidak ada JS dikirim
import ProductCard from './ProductCard.astro';
const products = await fetch('/api/products').then(r => r.json());
---

<section>
  {products.map(p => <ProductCard product={p} />)}
</section>

<!-- Hanya komponen interaktif yang dihydrate -->
<SearchBar client:idle />
<ShoppingCart client:visible />

Vue dan Nuxt memiliki karakteristik hidration yang lebih ringan dari React — Vue’s hydration algorithm lebih efisien untuk tree yang sama. Nuxt dengan SSR menghasilkan LCP yang baik karena HTML sudah siap dari server. useLazyFetch di Nuxt memungkinkan data fetching di-defer agar tidak memblokir initial render: halaman dimuat dengan placeholder, dan data diisi setelah render awal selesai.

javascriptSalin
// Nuxt: defer data fetching agar tidak block render awal
const { data: products, pending } = useLazyFetch('/api/products');

// Template bisa render loading state dulu
// <div v-if="pending">Loading...</div>
// <ProductGrid v-else :products="products" />

Laravel dengan Inertia.js adalah pola yang populer di komunitas PHP. First load adalah full SSR page — server merender HTML lengkap, yang menghasilkan LCP yang baik. Navigasi berikutnya adalah SPA-style: Inertia mengganti konten halaman tanpa full page reload, yang terasa cepat secara perseptual tetapi bisa memperkenalkan INP issues karena JavaScript harus menjalankan logika navigasi dan render di client.

phpSalin
// Laravel controller: Inertia merender via SSR pada first load
public function index() {
    return Inertia::render('Products/Index', [
        'products' => Product::with('variants')
            ->latest()
            ->paginate(20),
    ]);
}

Yang wajib menempel dari chapter ini

Debugging Web Vitals yang efektif membutuhkan pemahaman metrik pendukung sebagai kompas diagnostik, workflow yang bergerak dari data lapangan ke lab ke fix, dan pengetahuan bahwa bottleneck bisa berada di semua lapisan stack — browser, JavaScript, gambar, font, server, database, hingga CDN.

Chapter ini memulai dengan meletakkan FCP, TTFB, TBT, dan Speed Index sebagai instrumen diagnostik yang membantu mengidentifikasi lapisan mana yang menjadi sumber masalah sebelum melihat angka Core Web Vitals secara mentah. Workflow debug sistematis kemudian memastikan kamu tidak membuang waktu mengoptimasi hal yang salah: mulai dari data lapangan, segmentasi, reproduce di lab dengan kondisi realistis, trace bottleneck secara kategoris, fix iteratif, dan verifikasi kembali di field. Pola optimasi frontend memberikan toolkit konkret dari preload LCP image sampai code splitting, sementara seksi backend memperjelas bahwa TTFB adalah masalah server — bukan sesuatu yang bisa di-workaround dari sisi CSS atau JavaScript. Terakhir, setiap framework populer dilihat dari perspektif CWV: apa yang mereka permudah, dan apa gotcha yang perlu dikelola secara eksplisit.

Di Chapter 7 kita membahas babak terakhir: bagaimana membangun sistem monitoring produksi berkelanjutan — Real User Monitoring, performance budget, alerting otomatis, dan cara memastikan regresi performa tertangkap sebelum memengaruhi pengguna nyata dalam skala besar.