Mengapa Time to First Byte Anda lambat dan apa yang perlu dilakukan

Mulai dari apa yang sebenarnya diukur TTFB

Time to First Byte, biasanya disingkat TTFB, adalah waktu antara browser meminta sebuah resource dan menerima byte pertama dari respons.

Itu terdengar seperti metrik server, tetapi bukan hanya metrik server. TTFB mencakup beberapa langkah:

• DNS lookup, jika hostname belum di-resolve
• Penyiapan koneksi TCP
• Negosiasi TLS untuk HTTPS
• Waktu perjalanan request ke server atau CDN edge
• Antrean dan pemrosesan di server
• Waktu perjalanan respons kembali ke browser

Jadi TTFB yang tinggi bisa berarti backend Anda lambat. Ini juga bisa berarti pengguna jauh dari origin Anda, CDN Anda salah konfigurasi, cache Anda terus-menerus miss, atau server Anda menghabiskan terlalu banyak waktu untuk memutuskan apa yang harus dikirim.

Ini penting karena TTFB berada di dekat awal rantai pemuatan. Jika dokumen HTML datang terlambat, browser juga terlambat menemukan CSS, JavaScript, font, dan gambar. Anda bisa memiliki optimasi front-end yang sangat baik dan tetap terasa lambat jika respons dokumen pertama membutuhkan 1,5 detik.

Apa yang dianggap TTFB lambat?

Tidak ada angka universal yang cocok untuk setiap situs, wilayah, dan arsitektur. Namun, ambang praktis membantu.

Panduan web.dev dari Google mengklasifikasikan TTFB yang baik sebagai di bawah 800 ms, dengan 800–1800 ms perlu ditingkatkan dan di atas 1800 ms dianggap buruk. Untuk halaman marketing yang di-cache dengan baik dan disajikan dekat pengguna, Anda sering kali bisa jauh lebih baik dari itu. Untuk dashboard terautentikasi yang kompleks dan melakukan pekerjaan dinamis, angka yang dapat diterima mungkin lebih tinggi, tetapi tetap harus bisa dijelaskan.

Kebiasaan pentingnya adalah melakukan segmentasi angka. Rata-rata TTFB global sebesar 900 ms dapat menyembunyikan respons 150 ms untuk pengguna yang dekat dengan CDN edge Anda dan respons 2200 ms untuk pengguna di wilayah lain. Demikian pula, homepage Anda mungkin baik-baik saja sementara halaman pencarian, kategori, atau halaman logged-in diam-diam terasa menyakitkan.

Ukur dari lebih dari satu tempat

Jangan mendiagnosis TTFB dari satu kali menjalankan Lighthouse. Lighthouse berguna, tetapi itu hanya satu pengujian dari satu lingkungan. Jika Anda baru menafsirkan hasilnya, mulailah dengan membaca secara tenang cara membaca laporan Lighthouse tanpa panik — pelajaran utamanya adalah memisahkan sinyal lab dari realitas lapangan.

Untuk TTFB, Anda membutuhkan setidaknya tiga sudut pandang:

1. Browser developer tools

Buka panel Network, reload dengan cache dinonaktifkan, dan periksa request dokumen utama. Rincian timing menunjukkan fase DNS, koneksi, TLS, waiting, dan download. Fase “waiting” sering kali yang dimaksud orang sebagai waktu backend, meskipun ini dapat mencakup latensi upstream.

2. Pengujian sintetis dari beberapa wilayah

Jalankan pengujian dari lokasi yang dekat dan jauh dari pengguna Anda. Jika TTFB rendah di satu wilayah dan tinggi di wilayah lain, curigai geografi, routing CDN, penempatan origin, atau cakupan cache sebelum menulis ulang kode aplikasi.

3. Real user monitoring atau log server

Data lapangan memberi tahu Anda apa yang dialami pengguna nyata di berbagai perangkat, jaringan, dan sesi. Log server dapat memberi tahu apakah origin menghasilkan respons dengan cepat. Perbedaan antara TTFB yang diamati klien dan waktu pemrosesan origin sering kali menjadi tempat munculnya masalah CDN dan jaringan.

Penyebab umum TTFB lambat

HTML Anda tidak di-cache

Ini adalah masalah paling umum pada situs konten dan situs ecommerce. Aset statis di-cache secara agresif, tetapi dokumen HTML — hal yang pertama dibutuhkan browser — dibuat pada setiap request.

Kadang-kadang itu memang perlu. Sering kali tidak.

Jika sebuah halaman publik berubah beberapa kali per hari, kemungkinan besar halaman itu tidak seharusnya membutuhkan render database baru untuk setiap pengunjung anonim. Gunakan caching halaman penuh, edge caching, static generation, atau pola stale-while-revalidate jika sesuai.

Periksa header respons untuk sinyal seperti Cache-Control, CDN-Cache-Status, Age, Vary, dan Set-Cookie. Halaman yang mengirim cookie unik ke setiap pengunjung mungkin secara tidak sengaja membuat dirinya tidak dapat di-cache. Jika Anda membutuhkan cara praktis untuk memahami lapisan ini, kebiasaan debugging yang sama dalam panduan kami tentang redirect dan HTTP header di production berlaku langsung untuk pekerjaan TTFB.

CDN Anda hanya melakukan cache aset

Banyak tim menambahkan CDN dan berasumsi pekerjaan performa sudah selesai. Namun jika CDN hanya menyajikan gambar, CSS, dan JavaScript, request HTML pertama mungkin tetap berjalan sepenuhnya ke satu server origin.

Itu bisa baik-baik saja untuk situs bisnis lokal dengan pengguna lokal. Itu tidak baik untuk audiens internasional. Semakin jauh pengguna dari origin, semakin besar latensi yang Anda bayar bahkan sebelum pekerjaan backend dimulai.

Konfigurasi CDN yang baik untuk TTFB biasanya berarti:

• Cache HTML publik jika aman
• Hormati aturan bypass yang disengaja untuk halaman terautentikasi atau terpersonalisasi
• Hindari header Vary yang tidak perlu yang membagi cache terlalu halus
• Gunakan cache purging atau revalidation alih-alih menonaktifkan cache sepenuhnya
• Pastikan lokasi edge benar-benar melayani hit, bukan meneruskan setiap request

CDN bukan sihir. Ini adalah lapisan cache dan routing. Perlakukan seperti itu.

Server Anda melakukan terlalu banyak hal sebelum merespons

Jalur backend yang lambat dapat berasal dari banyak penundaan kecil: query database, panggilan API, rendering template, pemeriksaan feature flag, autentikasi, personalisasi, logging, dan cold start.

Pola terburuk adalah pekerjaan dependensi yang serial. Misalnya:

1. Ambil data halaman
2. Lalu ambil produk terkait
3. Lalu ambil harga
4. Lalu panggil layanan rekomendasi
5. Lalu render HTML

Jika setiap langkah menunggu langkah sebelumnya, TTFB tumbuh dengan cepat. Paralelkan pekerjaan yang independen, hapus panggilan non-kritis dari respons pertama, dan cache hasil yang mahal.

Aturan yang berguna: jika pengguna tidak dapat langsung melihat atau menggunakan hasilnya, kemungkinan besar itu tidak seharusnya memblokir byte pertama.

Query database lambat atau tidak dapat diprediksi

Database sering menyebabkan masalah TTFB karena berperilaku baik di development dan buruk di bawah traffic nyata. Index yang hilang, join besar, query N+1, lock contention, dan result set yang terlalu besar semuanya muncul sebagai “server lambat”.

Jangan menebak di sini. Tangkap timing query untuk request yang lambat. Lihat p95 dan p99, bukan hanya rata-rata. Satu halaman yang biasanya merespons dalam 120 ms tetapi sesekali terblokir selama 4 detik tetap akan menciptakan pengalaman pengguna yang buruk.

Perbaikan umum mencakup:

• Menambahkan atau memperbaiki index
• Menghapus pola query N+1
• Melakukan cache data yang banyak dibaca
• Melakukan paginasi query besar
• Memindahkan query pelaporan atau analytics keluar dari waktu request
• Menetapkan timeout yang masuk akal untuk panggilan downstream

Aplikasi Anda mengalami cold start

Platform serverless dan berbasis container bisa sangat baik, tetapi cold start dapat merusak TTFB ketika traffic bersifat bursty atau wilayah kurang diprovisikan.

Jika request pertama setelah waktu idle jauh lebih lambat daripada request berikutnya, investigasi cold start. Anda mungkin membutuhkan provisioned concurrency, bundle yang lebih kecil, lebih sedikit dependensi startup, function yang lebih hangat, atau bentuk deployment yang berbeda untuk route yang sensitif terhadap latensi.

Ini bukan argumen melawan serverless. Ini adalah argumen melawan berpura-pura bahwa model runtime tidak terlihat.

Redirect membuang request pertama

Redirect menambahkan siklus request-response lain sebelum browser menerima dokumen akhir. Satu redirect dari http:// ke https:// mungkin tidak terhindarkan untuk link lama, tetapi rantai redirect boros.

Rantai umum mencakup:

• http://example.com → https://example.com → https://www.example.com
• normalisasi trailing slash setelah normalisasi protokol
• redirect geo atau bahasa sebelum cache lookup
• link campaign lama yang melompat melalui beberapa URL

Perbaiki link sumber jika memungkinkan, gabungkan aturan redirect, dan buat URL kanonis langsung. Waktu redirect tidak selalu dilaporkan sebagai TTFB untuk request akhir, tetapi pengguna tetap membayarnya.

Urutan debugging yang praktis

Ketika TTFB terlihat lambat, gunakan urutan ini. Ini menghindari kesalahan umum berupa mengoptimasi kode aplikasi sebelum mengonfirmasi perilaku cache dan routing.

Step 1: Uji dokumen utama, bukan hanya seluruh halaman

Temukan request untuk dokumen HTML. Catat total TTFB dan rincian timing. Ulangi dengan dan tanpa cache browser. Uji halaman publik, halaman dinamis, dan halaman logged-in jika relevan.

Step 2: Bandingkan wilayah

Jalankan URL yang sama dari beberapa lokasi geografis. Jika wilayah yang lambat berkorelasi dengan jarak dari origin, prioritaskan CDN dan edge caching. Jika setiap wilayah lambat, lihat pemrosesan backend dan kapasitas origin.

Step 3: Periksa header respons

Cari header cache, cookie, Age, status CDN, dan Vary. Header Age yang hilang atau cache miss yang berulang adalah petunjuk. Header Vary: Cookie yang luas pada HTML publik sering menjadi pembunuh cache.

Step 4: Periksa timing origin

Tambahkan instrumentasi timing server. Header Server-Timing dapat mengekspos fase backend seperti waktu database, waktu render, dan waktu API upstream. Bahkan label sederhana pun berguna:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Sekarang timing browser Anda dapat menunjukkan apakah server menghabiskan 300 ms untuk pekerjaan nyata atau apakah penundaan terjadi sebelum request mencapai aplikasi Anda.

Step 5: Perbaiki penundaan terbesar yang sudah terkonfirmasi

Ini terdengar jelas, tetapi tim sering memperbaiki hal yang familiar alih-alih hal yang terukur. Jika cache miss mendominasi, perbaiki caching. Jika database mendominasi, perbaiki query. Jika TLS dan penyiapan koneksi mendominasi untuk pengguna global, perbaiki routing, cakupan CDN, atau geografi origin.

Pekerjaan front-end tetap penting. Font, gambar, dan JavaScript memengaruhi apa yang terjadi setelah HTML tiba. Namun itu bukan pengganti respons pertama yang cepat. Jika Anda juga sedang memperbaiki performa render, web fonts tetap menjadi salah satu kemenangan termudah di banyak situs karena memengaruhi seberapa cepat teks dapat digunakan setelah dokumen tiba.

Perbaikan yang biasanya berhasil

Cache HTML publik di edge

Untuk halaman marketing, dokumentasi, blog, landing page, dan halaman kategori, edge caching sering menjadi peningkatan TTFB terbesar. Gunakan TTL pendek jika konten sering berubah. Gunakan stale-while-revalidate jika konten yang sedikit basi dapat diterima sementara cache disegarkan di latar belakang.

Berhati-hatilah dengan personalisasi. Jika halaman bervariasi berdasarkan mata uang, bahasa, status login, atau grup eksperimen, definisikan varian tersebut secara eksplisit. Variasi per pengguna yang tidak disengaja menghancurkan efisiensi cache.

Pindahkan pekerjaan non-kritis keluar dari jalur request

Pengiriman email, pengayaan analytics, pembuatan rekomendasi, panggilan webhook, dan logging berat jarang sekali harus memblokir byte pertama. Masukkan ke antrean atau jalankan setelah respons dimulai.

Kurangi rantai dependensi backend

Paralelkan panggilan yang independen. Cache respons dari API yang lambat. Tetapkan timeout. Rancang konten fallback untuk layanan yang membantu tetapi tidak esensial.

Widget rekomendasi yang lambat tidak seharusnya menunda seluruh halaman produk.

Tempatkan compute lebih dekat ke pengguna

Jika pengguna Anda global dan origin Anda berada di satu wilayah, latensi bersifat struktural. Caching CDN dapat menyembunyikan banyak hal ini untuk konten publik. Untuk konten dinamis, pertimbangkan deployment regional, edge rendering untuk route yang sesuai, atau memindahkan API lebih dekat ke audiens.

Jaga redirect tetap membosankan

Kanonikalisasi URL dalam satu hop. Perbarui link internal agar pengguna dan crawler langsung menuju tujuan akhir. Audit URL campaign lama dan migrasi platform. Redirect mudah diabaikan karena tidak terlihat ketika berhasil, tetapi tetap memakan waktu.

Apa yang tidak perlu dilakukan

Jangan mengejar angka TTFB sempurna untuk setiap route. Laporan terautentikasi yang melakukan komputasi nyata tidak akan berperilaku seperti posting blog yang di-cache.

Jangan gunakan TTFB rata-rata sebagai satu-satunya metrik. Persentil penting. Geografi penting. Jenis halaman penting.

Jangan berasumsi CDN berarti HTML Anda di-cache. Verifikasi.

Dan jangan perlakukan TTFB sebagai sesuatu yang terpisah dari keputusan produk. Personalisasi, eksperimen, inventaris real-time, dan layanan pihak ketiga semuanya memiliki biaya latensi. Sebagian layak. Sebagian hanya kebiasaan.

<!-- tool-cta:start -->

💡 Coba ini: Saat mendiagnosis TTFB, Get Headers mengungkap status cache, timing server, dan pengalihan yang sering menjelaskan dari mana keterlambatan berasal.

<!-- tool-cta:end -->

Versi tenang dari rencananya

TTFB yang lambat biasanya dapat diperbaiki setelah Anda berhenti memperlakukannya sebagai “masalah server” yang samar. Ukur request dokumen. Segmentasikan berdasarkan wilayah dan jenis halaman. Periksa header. Bandingkan timing klien dengan timing origin. Lalu perbaiki bottleneck terbesar yang sudah terkonfirmasi.

Sebagian besar situs tidak membutuhkan arsitektur eksotis. Mereka membutuhkan lebih sedikit cache miss yang dapat dihindari, lebih sedikit pekerjaan backend yang memblokir, redirect yang lebih bersih, dan gagasan yang lebih jelas tentang apa yang harus terjadi sebelum byte pertama dikirim.