Mustahil Tapi Nyata! Angka Nol (0 ms) di Total Blocking Time Ternyata Bisa Dicapai dengan Trik Ini

Website terlihat sudah terbuka, tetapi ketika tombol diklik... tidak terjadi apa-apa. Scroll terasa patah-patah. Menu baru merespons beberapa saat kemudian. Padahal tampilannya sudah ada di layar. Apa yang sebenarnya sedang terjadi?

Ternyata masalahnya belum tentu berada pada koneksi internet.

Bisa jadi browser pengunjung sedang sibuk bekerja di belakang layar.

JavaScript sedang diproses.

Widget sedang dijalankan.

Library sedang dieksekusi.

Tracking sedang aktif.

Animasi sedang dihitung.

Sampai akhirnya browser tidak punya cukup waktu untuk segera merespons klik pengguna.

Di sinilah sebuah metrik bernama Total Blocking Time atau TBT menjadi sangat menarik.

Dalam sebuah pengujian performa, angka TBT bahkan bisa menyentuh:

0 ms

Mustahil?

Tidak juga.

Tetapi untuk mencapainya, kita harus memahami satu rahasia penting:

Website cepat bukan hanya soal seberapa cepat file selesai didownload. Browser juga harus punya waktu untuk bernapas.

Mari kita bongkar caranya.

Apa Itu Total Blocking Time?

Total Blocking Time mengukur total waktu ketika main thread browser terlalu sibuk sehingga tidak dapat segera merespons pengguna.

Main thread bisa kita bayangkan sebagai satu pekerja utama di browser.

Pekerja ini harus mengurus banyak hal:

• membaca HTML,

• memproses CSS,

• menjalankan JavaScript,

• membuat layout,

• merender halaman,

• menjalankan event,

• menangani klik,

• menjalankan animasi.

Masalah muncul ketika satu pekerjaan memakan waktu terlalu lama.

Dalam pengukuran TBT, sebuah pekerjaan dianggap Long Task ketika berlangsung lebih dari 50 milidetik.

Misalnya sebuah JavaScript membutuhkan:

180 ms

untuk selesai.

Maka bagian di atas ambang 50 ms berkontribusi terhadap blocking time.

Artinya, selama proses itu browser bisa terlihat seperti:

“sebentar, saya masih sibuk.”

Dan pengguna merasakannya sebagai lag.

Lalu Apa Artinya Kalau TBT = 0 ms?

Ini bagian yang menarik.

TBT 0 ms bukan berarti browser tidak mengerjakan apa pun.

Browser tetap bekerja.

HTML tetap diproses.

CSS tetap dirender.

JavaScript yang memang diperlukan tetap bisa berjalan.

Yang berbeda adalah:

tidak ada Long Task terukur yang cukup panjang untuk menghasilkan blocking time dalam periode pengujian tersebut.

Contohnya browser menjalankan:

20 ms → selesai
30 ms → selesai
12 ms → selesai
40 ms → selesai

Tidak ada yang melewati batas 50 ms.

Hasil blocking time bisa tetap:

0 ms.

Bandingkan dengan:

120 ms → blocking 70 ms
200 ms → blocking 150 ms
90 ms → blocking 40 ms

Totalnya sudah menjadi:

260 ms TBT.

Nah, bagaimana menurunkannya?

Jawabannya hampir selalu membawa kita ke tersangka utama.

JavaScript.

1. Jangan Kirim JavaScript yang Tidak Dibutuhkan

Kesalahan terbesar website modern adalah:

semua fitur dimuat sejak halaman pertama dibuka.

Padahal pengguna mungkin hanya ingin membaca satu artikel.

Tetapi browser dipaksa mengunduh:

• slider,

• popup,

• chat,

• analytics,

• social sharing,

• animasi,

• galeri,

• notification script,

• heatmap,

• iklan,

• tracking,

• library icon,

• library UI,

• dan berbagai plugin lainnya.

Lebih banyak JavaScript berarti browser harus melakukan lebih banyak pekerjaan:

download → parse → compile → execute.

Jadi prinsip pertama cukup sederhana:

Jika sebuah script tidak diperlukan saat halaman pertama dibuka, jangan buru-buru menjalankannya.

Google juga merekomendasikan mengurangi jumlah blocking script dan mengurangi total JavaScript sebagai salah satu cara utama memperbaiki TBT.

2. Jangan Membawa Truk untuk Mengantar Sebungkus Kopi

Bayangkan kita hanya membutuhkan fungsi untuk membuka menu mobile.

Tetapi untuk mendapatkannya, website mendownload sebuah library JavaScript raksasa.

Secara teknis mungkin bekerja.

Tetapi dari sisi performa?

Tidak efisien.

Kalau fungsi sederhana bisa dilakukan dengan beberapa baris JavaScript, tidak selalu perlu membawa library besar.

Ini bukan berarti framework JavaScript buruk.

React, Vue, dan framework modern sangat berguna.

Masalahnya adalah:

gunakan teknologi sesuai kebutuhan.

Website publik yang sebagian besar berisi artikel tidak selalu membutuhkan seluruh halaman menjadi Single Page Application yang penuh JavaScript.

Dan prinsip inilah yang menjadi sangat menarik pada arsitektur seperti HICCMS.

Kita akan membahasnya sebentar lagi.

3. Pecah JavaScript Besar Menjadi Bagian Kecil

Ada sebuah fungsi yang membutuhkan 300 ms untuk diproses?

Jangan selalu biarkan browser mengerjakannya dalam satu napas.

Salah satu solusi adalah memecah pekerjaan besar menjadi beberapa pekerjaan lebih kecil.

Misalnya daripada:

300 ms

menjadi satu tugas panjang, kita mencoba mengatur pekerjaan agar browser memiliki kesempatan menyelesaikan tugas penting di antara proses tersebut.

Konsep ini disebut breaking up long tasks.

Tujuannya bukan menghilangkan semua pekerjaan.

Tujuannya memberi kesempatan browser untuk berkata:

“Ada klik dari pengguna. Saya tangani dulu.”

Kemudian pekerjaan berikutnya bisa dilanjutkan.

Web.dev juga merekomendasikan pemecahan long task agar browser memiliki kesempatan menjalankan pekerjaan prioritas tinggi, termasuk merespons interaksi pengguna.

4. Gunakan Code Splitting: Download Saat Dibutuhkan

Bayangkan website memiliki lima fitur JavaScript.

Tetapi halaman yang sedang dibuka hanya menggunakan satu.

Mengapa semuanya harus dikirim?

Di sinilah code splitting berguna.

Alih-alih membuat satu file besar:

app.js = 900 KB

kita dapat memecahnya:

core.js
gallery.js
editor.js
chart.js
animation.js

Kemudian halaman hanya mengambil modul yang benar-benar diperlukan.

Konsepnya:

Need it? Load it.
Don't need it? Don't send it.

Google menjelaskan bahwa mengurangi JavaScript saat startup melalui code splitting dapat mengurangi pekerjaan main thread dan membantu halaman menjadi interaktif lebih cepat.

5. Gunakan defer untuk Script yang Bisa Menunggu

Perhatikan script seperti ini:

<script src="app.js"></script>

Dalam kondisi tertentu browser harus berhenti memproses HTML untuk menangani script tersebut.

Sekarang bandingkan:

<script src="app.js" defer></script>

Dengan defer, browser dapat melanjutkan parsing halaman dan mengeksekusi script setelah dokumen selesai diproses.

Hasilnya?

Konten penting bisa tampil lebih dahulu.

Untuk script tertentu, terdapat pula async, meskipun karakteristik eksekusinya berbeda.

Yang harus dipahami bukan sekadar atributnya, tetapi filosofinya:

Jangan hentikan browser kalau pekerjaan tersebut sebenarnya bisa menunggu.

Dokumentasi web.dev juga menjelaskan bahwa defer dan async dapat mengurangi sifat blocking JavaScript ketika memuat halaman.

6. Hati-Hati dengan Third-Party Script

Kadang kode website kita sudah sangat ringan.

Tetapi kemudian kita memasang:

Google Analytics.

Facebook Pixel.

Live Chat.

Heatmap.

Advertisement.

YouTube Embed.

Maps.

Social widget.

Tag manager.

Satu per satu mungkin terlihat kecil.

Setelah semuanya digabung?

Browser bisa bekerja lembur.

Masalah third-party script adalah sebagian pekerjaan berada di luar kontrol kita.

Karena itu tanyakan:

Apakah script ini benar-benar diperlukan pada initial page load?

Jika tidak:

tunda.

Lazy load.

Aktifkan setelah interaksi.

Atau hapus.

Jangan biarkan seluruh pengalaman pengguna dikorbankan hanya karena dashboard marketing ingin menjalankan sepuluh tracking script sekaligus.

7. Kurangi Animasi JavaScript yang Tidak Perlu

Website modern memang harus menarik.

Tetapi menarik tidak selalu berarti:

semua elemen harus bergerak.

Parallax.

Particle effect.

Animated counter.

Custom cursor.

Floating elements.

Scroll animation.

Background animation.

Semuanya membutuhkan sumber daya.

Untuk animasi sederhana, CSS sering kali sudah cukup.

Browser modern dapat menangani properti seperti:

transform

dan:

opacity

dengan sangat efisien.

JavaScript sebaiknya digunakan ketika interaksi memang membutuhkan logic.

Bukan karena:

“Biar kelihatan canggih.”

Website yang sederhana tetapi responsif sering terasa jauh lebih premium daripada website penuh animasi tetapi tersendat-sendat.

8. Pisahkan Website Publik dan Dashboard Admin

Sekarang kita masuk ke salah satu strategi yang digunakan HICCMS.

HICCMS menggunakan pendekatan Headless CMS.

Bagian admin dan website publik tidak dipaksa menjadi satu aplikasi besar.

Arsitekturnya secara sederhana:

Admin Dashboard → Core API → Database/Storage

dan:

Website Publik → Core API → Konten

Dashboard HICCMS menggunakan React karena dashboard membutuhkan interaktivitas tinggi.

Tetapi website publik menggunakan Astro.

Ini keputusan yang penting.

Kenapa?

Karena pengguna yang hanya ingin membaca sebuah artikel tidak perlu membawa seluruh JavaScript dashboard CMS ke browser mereka.

9. HICCMS Menggunakan Astro dengan Static Output

Frontend publik HICCMS dikonfigurasi menggunakan:

output: 'static'

Ini berarti halaman publik dapat dibangun menjadi file statis ketika proses build dilakukan.

Browser mendapatkan HTML yang sudah siap disajikan.

Tidak semua halaman harus berubah menjadi JavaScript application besar terlebih dahulu.

Inilah salah satu filosofi performa yang sangat kuat:

Kalau konten bisa menjadi HTML, biarkan menjadi HTML. Jangan paksa JavaScript mengerjakan pekerjaan yang sebenarnya tidak membutuhkan JavaScript.

Semakin sedikit JavaScript yang dikirim ke browser, semakin kecil kemungkinan main thread sibuk melakukan parsing dan execution yang tidak diperlukan.

10. Backend HICCMS Juga Tidak Membebani Browser

HICCMS menggunakan:

Hono.js + Cloudflare Workers

untuk Core API.

Database menggunakan:

Cloudflare D1

sedangkan media menggunakan:

Cloudflare R2.

Dengan pendekatan ini, logic backend tetap berada di backend.

Browser pengguna tidak perlu menjalankan proses database atau logic CMS.

Tugas frontend adalah:

menampilkan halaman secepat mungkin.

Tugas API adalah:

mengelola data.

Tugas D1 adalah:

menyimpan data.

Tugas R2 adalah:

menyimpan media.

Masing-masing mengerjakan bagiannya.

Dan browser tidak dijadikan tempat membuang seluruh pekerjaan.

11. Apakah TBT 0 ms Berarti Pengunjung Tidak Akan Pernah Lag?

Tidak.

Ini penting supaya kita tidak salah memahami angka.

TBT adalah metrik laboratorium.

Google saat ini lebih menyarankan Interaction to Next Paint atau INP untuk mengevaluasi responsivitas nyata pengguna.

TBT tetap sangat berguna untuk mendeteksi apakah JavaScript atau pekerjaan main thread membuat halaman berat ketika loading, tetapi 0 ms dalam sebuah tes tidak menjamin semua perangkat, jaringan, dan interaksi akan selalu menghasilkan pengalaman sempurna.

Namun demikian, TBT 0 ms memberi sebuah sinyal yang sangat bagus:

browser tidak menemukan blocking task signifikan selama periode pengujian tersebut.

Dan itu pencapaian yang layak dikejar.

Formula Mendekati TBT 0 ms

Jika seluruh pembahasan tadi diringkas:

Kurangi JavaScript + buang script tidak terpakai + code splitting + defer script + kurangi third-party code + pecah long task + gunakan HTML/CSS ketika cukup + arsitektur frontend ringan = TBT semakin kecil.

Bukan dengan satu plugin.

Bukan dengan satu tombol.

Dan bukan dengan trik sulap.

Yang dilakukan sebenarnya adalah:

berhenti memberikan pekerjaan yang tidak perlu kepada browser.

Mau Membangun Website dengan Pendekatan Seperti Ini? Coba HICCMS

Kalau Anda ingin mencoba CMS yang sejak arsitekturnya memisahkan website publik, dashboard, API, database, dan media storage, Anda bisa mencoba HICCMS — Henri Ilham Caniago Content Management System.

HICCMS menggunakan teknologi modern seperti:

• Astro untuk website publik

• React + Vite untuk Admin Dashboard

• Hono.js untuk Core API

• Cloudflare Workers untuk serverless backend

• Cloudflare D1 untuk database

• Cloudflare R2 untuk media storage

• TypeScript

• Tailwind CSS

• arsitektur Headless CMS

Cara Mencoba HICCMS

Buka repository:

https://github.com/ozivanu-del/hiccms

Kemudian clone:

git clone https://github.com/ozivanu-del/hiccms.git
cd hiccms
npm install

Jalankan development environment:

npm run dev

Secara default Anda dapat mengembangkan:

Web Frontend
http://localhost:4321

Admin Dashboard
http://localhost:5173

Core API
http://localhost:8787

Jika ingin menggunakannya untuk project sendiri, pendekatannya sederhana:

1. Clone HICCMS dari GitHub.

2. Buat akun Cloudflare.

3. Siapkan Cloudflare D1 untuk database.

4. Siapkan R2 Bucket untuk media.

5. Hubungkan konfigurasi menggunakan Wrangler.

6. Sesuaikan tema dan identitas website.

7. Build frontend Astro.

8. Deploy API ke Cloudflare Workers dan frontend ke Cloudflare Pages.

Dari sana Anda dapat mengembangkan HICCMS untuk website organisasi, sekolah, perguruan tinggi, portal informasi, company profile, blog, maupun kebutuhan lainnya.

Dan karena source code dapat dipelajari langsung dari GitHub, Anda tidak hanya menggunakan CMS.

Anda bisa melihat bagaimana dapurnya bekerja.

Kesimpulan: Jangan Paksa Browser Kerja Lembur

Mengejar TBT 0 ms sebenarnya mengajarkan satu prinsip penting dalam web development:

Kecepatan bukan hanya tentang server yang kuat. Kecepatan juga tentang seberapa sedikit pekerjaan yang kita berikan kepada browser.

Ketika JavaScript hanya digunakan ketika diperlukan, long task dipangkas, third-party script dikontrol, dan frontend dibuat ringan, browser memiliki lebih banyak kesempatan untuk segera merespons pengguna.

Hasil akhirnya bukan sekadar angka hijau pada GTmetrix atau Lighthouse.

Yang dirasakan pengunjung jauh lebih sederhana:

Klik langsung merespons.

Scroll terasa mulus.

Menu langsung terbuka.

Dan website terasa ringan sejak detik pertama.

Jadi pertanyaan sebenarnya bukan:

“Berapa banyak JavaScript yang bisa kita masukkan ke sebuah website?”

Tetapi:

“Berapa banyak JavaScript yang sebenarnya tidak perlu kita kirim?”

Dan mungkin, dari sanalah perjalanan menuju Total Blocking Time 0 ms dimulai.