TBT dan Speed Index: Budget Performa yang Wajib Dimiliki Setiap Landing Page Bisnis

TL;DR: Total Blocking Time (TBT) dan Speed Index adalah dua lab metric Lighthouse yang memprediksi pengalaman pengguna sebelum halaman dirilis. Untuk landing page bisnis, target sehat: TBT di bawah 200 ms dan Speed Index di bawah 3,4 detik di mobile mid-tier. Set keduanya sebagai budget performa di CI/CD agar regresi tidak lolos ke produksi.

Banyak tim marketing dan developer hanya memantau Web Vitals di field via PageSpeed Insights atau Search Console. Masalahnya, data field baru muncul 28 hari setelah halaman live. Saat skor turun, kerusakan SEO dan konversi sudah terjadi.

Lab metric memberi early warning. Total Blocking Time dan Speed Index adalah dua yang paling prediktif. Keduanya bisa diukur di environment staging sebelum deploy, dipasang di pipeline CI, dan dijadikan gate yang menahan PR jika regresi terjadi.

Kenapa Lab Metric Penting untuk Marketer

Marketer sering menganggap performa adalah urusan developer. Realitanya, performa berbanding lurus dengan revenue. Studi Deloitte 2020 menunjukkan, perbaikan 0,1 detik di mobile retail meningkatkan conversion rate 8,4%. Untuk lead gen B2B, lift bisa mencapai 10,1%.

Lab metric memungkinkan marketer ikut menetapkan budget performa tanpa harus paham detail teknis JavaScript. Cukup sepakati threshold di awal, sisanya ditegakkan oleh tooling.

TBT: Proxy Lab untuk INP

Total Blocking Time menjumlahkan seluruh durasi main thread terblokir oleh long task (lebih dari 50 ms) antara FCP dan TTI. Skor di bawah 200 ms artinya halaman responsif terhadap input. Skor di atas 600 ms artinya halaman terasa beku.

TBT diukur di simulasi mobile mid-tier dengan throttling 4x CPU. Realita di perangkat low-end Indonesia bisa lebih buruk 2-3 kali lipat. Targetkan budget TBT 200 ms agar field INP ikut sehat.

Penyebab TBT tinggi yang paling sering ditemui dalam audit beberapa proyek client:

• JavaScript bundle besar tanpa code-splitting (React/Next.js)
• Tag manager dengan 10+ tag pihak ketiga
• Hydration mismatch yang memicu re-render mahal
• Library analytics yang dieksekusi sinkron di head

Speed Index: Persepsi Kecepatan Visual

Speed Index merekam frame video pemuatan halaman, lalu menghitung area yang ter-render di setiap interval. Semakin cepat seluruh viewport terisi, semakin rendah skornya. Target sehat: di bawah 3,4 detik di mobile.

Speed Index berbeda dengan LCP yang fokus pada satu elemen terbesar. Speed Index lebih holistik dan mencerminkan persepsi kecepatan yang sebenarnya dirasakan pengguna.

Studi Kasus: Landing Page Atmo dari 4,2 ke 1,9 Detik

Saat membangun landing page kursus untuk Atmo, audit Lighthouse awal menunjukkan TBT 850 ms dan Speed Index 4,2 detik. Bounce rate mobile saat itu 68%, conversion ke trial sangat rendah.

Tiga perbaikan utama yang dilakukan:

Pertama, ganti seluruh image hero dari static tag ke next/image dengan priority hint dan format AVIF. Speed Index turun dari 4,2 ke 2,8 detik.

Kedua, defer dan async semua tag pihak ketiga (analytics, chat widget, pixel) ke setelah onLoad. TBT turun dari 850 ms ke 320 ms.

Ketiga, code-split komponen interaktif (carousel, video player) pakai dynamic import dengan suspense boundary. TBT turun lagi ke 180 ms, Speed Index ke 1,9 detik.

Hasil bisnis: bounce rate mobile turun ke 41%, conversion ke trial naik 2,3 kali lipat dalam 30 hari. Skor Lighthouse Performance dari 52 ke 94.

Cara Set Budget Performa di CI/CD

Set threshold di Lighthouse CI atau equivalent. Contoh konfigurasi minimal:

{
  "ci": {
    "assert": {
      "assertions": {
        "total-blocking-time": ["error", {"maxNumericValue": 200}],
        "speed-index": ["error", {"maxNumericValue": 3400}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}

Pasang di GitHub Actions atau Vercel deploy hook. Setiap PR yang memburuk score akan ditolak otomatis. Ini cara paling efektif menjaga performa stabil seiring penambahan fitur. Referensi setup di web.dev/lighthouse-ci.

Pertanyaan Umum

Apakah lab metric menggantikan field metric?

Tidak. Lab untuk early warning dan testing, field untuk realita pengguna. Keduanya saling melengkapi.

Berapa sering harus audit Lighthouse?

Idealnya setiap PR via CI. Minimal mingguan untuk halaman live. Audit penuh kuartalan dengan analisa tren.

Apakah skor Lighthouse 100 berarti halaman sempurna?

Tidak. Lighthouse hanya mengukur sebagian aspek. UX, konversi, dan content quality tetap perlu diukur terpisah.

Apakah TBT tinggi pasti bikin INP buruk?

Sering, tapi tidak selalu. INP dipengaruhi interaksi nyata pengguna yang variatif. TBT baik tetap fondasi penting.

Bisakah Tailwind atau CSS framework memperburuk Speed Index?

Bisa, jika CSS bundle tidak di-purge. Tailwind v4 dengan PurgeCSS atomic biasanya hanya 8-15 KB minified, dampaknya minimal.

Penutup

Performa bukan sekadar urusan engineering. Marketer dan developer perlu sepakat di awal soal budget performa, lalu menegakkannya lewat tooling. TBT dan Speed Index adalah dua angka paling penting untuk dipantau. Tanpa lab metric yang sehat, hampir mustahil mempertahankan field metric yang baik di skala produksi.