Mengapa Time to First Byte anda perlahan dan apa yang perlu dilakukan

Mulakan dengan apa yang sebenarnya diukur oleh TTFB

Time to First Byte, biasanya dipendekkan kepada TTFB, ialah masa antara pelayar meminta sesuatu sumber dan menerima bait pertama respons.

Kedengarannya seperti metrik pelayan, tetapi ia bukan hanya metrik pelayan. TTFB merangkumi beberapa langkah:

• Carian DNS, jika nama hos belum diselesaikan
• Penyediaan sambungan TCP
• Rundingan TLS untuk HTTPS
• Masa perjalanan permintaan ke pelayan atau edge CDN
• Penungguan dalam baris gilir dan pemprosesan pada pelayan
• Masa perjalanan respons kembali ke pelayar

Jadi TTFB yang tinggi boleh bermaksud backend anda perlahan. Ia juga boleh bermaksud pengguna jauh dari origin anda, CDN anda tersalah konfigurasi, cache anda sentiasa miss, atau pelayan anda mengambil masa terlalu lama untuk menentukan apa yang hendak dihantar.

Ini penting kerana TTFB berada hampir di permulaan rantaian pemuatan. Jika dokumen HTML tiba lewat, pelayar juga lewat menemui CSS, JavaScript, fon dan imej. Anda boleh mempunyai pengoptimuman front-end yang sangat baik tetapi masih terasa perlahan jika respons dokumen pertama mengambil masa 1.5 saat.

Apa yang dikira sebagai TTFB yang perlahan?

Tiada nombor sejagat yang sesuai untuk setiap laman, rantau dan seni bina. Namun, ambang praktikal membantu.

Panduan web.dev daripada Google mengklasifikasikan TTFB yang baik sebagai di bawah 800 ms, dengan 800–1800 ms memerlukan penambahbaikan dan lebih daripada 1800 ms dianggap lemah. Untuk halaman pemasaran yang dicache dengan baik dan disajikan dekat dengan pengguna, anda selalunya boleh mencapai angka yang jauh lebih baik daripada itu. Untuk papan pemuka berautentikasi yang kompleks dan melakukan kerja dinamik, angka yang boleh diterima mungkin lebih tinggi, tetapi ia masih perlu dapat dijelaskan.

Tabiat penting ialah membahagikan nombor itu kepada segmen. Purata TTFB global 900 ms mungkin menyembunyikan respons 150 ms untuk pengguna yang dekat dengan edge CDN anda dan respons 2200 ms untuk pengguna di rantau lain. Begitu juga, halaman utama anda mungkin baik-baik sahaja sementara halaman carian, kategori atau log masuk diam-diam menyakitkan.

Ukur dari lebih daripada satu tempat

Jangan mendiagnosis TTFB daripada satu larian Lighthouse sahaja. Lighthouse berguna, tetapi ia satu ujian daripada satu persekitaran. Jika anda baru belajar mentafsirkannya, mulakan dengan bacaan yang tenang tentang cara membaca laporan Lighthouse tanpa panik — pelajaran utamanya ialah memisahkan isyarat makmal daripada realiti medan.

Untuk TTFB, anda mahukan sekurang-kurangnya tiga pandangan:

1. Alat pembangun pelayar

Buka panel Network, muat semula dengan cache dilumpuhkan, dan periksa permintaan dokumen utama. Pecahan pemasaan menunjukkan fasa DNS, sambungan, TLS, penungguan dan muat turun. Fasa “waiting” selalunya ialah apa yang orang maksudkan sebagai masa backend, walaupun ia boleh merangkumi kependaman upstream.

2. Ujian sintetik dari beberapa rantau

Jalankan ujian dari lokasi yang dekat dan jauh daripada pengguna anda. Jika TTFB rendah di satu rantau dan tinggi di rantau lain, syaki geografi, penghalaan CDN, lokasi origin atau liputan cache sebelum menulis semula kod aplikasi.

3. Pemantauan pengguna sebenar atau log pelayan

Data medan memberitahu anda apa yang dialami pengguna sebenar merentas peranti, rangkaian dan sesi. Log pelayan boleh memberitahu sama ada origin menjana respons dengan cepat. Perbezaan antara TTFB yang diperhatikan klien dan masa pemprosesan origin selalunya ialah tempat isu CDN dan rangkaian muncul.

Punca biasa TTFB yang perlahan

HTML anda tidak dicache

Ini isu paling biasa pada laman kandungan dan laman ecommerce. Aset statik dicache secara agresif, tetapi dokumen HTML — perkara yang pelayar perlukan dahulu — dijana pada setiap permintaan.

Kadang-kadang itu perlu. Selalunya tidak.

Jika halaman awam berubah beberapa kali sehari, ia mungkin tidak sepatutnya memerlukan render pangkalan data baharu untuk setiap pelawat tanpa nama. Gunakan caching halaman penuh, edge caching, penjanaan statik atau corak stale-while-revalidate jika sesuai.

Periksa pengepala respons untuk isyarat seperti Cache-Control, CDN-Cache-Status, Age, Vary dan Set-Cookie. Halaman yang menghantar kuki unik kepada setiap pelawat mungkin secara tidak sengaja menjadikan dirinya tidak boleh dicache. Jika anda memerlukan cara praktikal untuk menilai lapisan ini, tabiat penyahpepijatan yang sama dalam panduan kami tentang redirects dan HTTP headers dalam produksi terpakai secara langsung pada kerja TTFB.

CDN anda hanya mencache aset

Banyak pasukan menambah CDN dan menganggap kerja prestasi sudah selesai. Tetapi jika CDN hanya menyajikan imej, CSS dan JavaScript, permintaan HTML pertama mungkin masih perlu bergerak sepanjang jalan ke satu pelayan origin.

Itu mungkin baik untuk laman perniagaan tempatan dengan pengguna tempatan. Ia tidak baik untuk khalayak antarabangsa. Semakin jauh pengguna daripada origin, semakin banyak kependaman yang anda bayar sebelum kerja backend pun bermula.

Konfigurasi CDN yang baik untuk TTFB biasanya bermaksud:

• Cache HTML awam apabila selamat
• Hormati peraturan pintasan yang disengajakan untuk halaman berautentikasi atau diperibadikan
• Elakkan pengepala Vary yang tidak perlu yang memecahkan cache terlalu halus
• Gunakan pembersihan cache atau revalidasi dan bukannya melumpuhkan cache sepenuhnya
• Sahkan bahawa lokasi edge benar-benar menyajikan hit, bukan meneruskan setiap permintaan

CDN bukan magik. Ia ialah lapisan cache dan penghalaan. Layani ia seperti itu.

Pelayan anda melakukan terlalu banyak kerja sebelum memberi respons

Laluan backend yang perlahan boleh datang daripada banyak kelewatan kecil: pertanyaan pangkalan data, panggilan API, render templat, semakan feature flag, autentikasi, pemperibadian, pengelogan dan cold start.

Corak paling teruk ialah kerja kebergantungan bersiri. Contohnya:

1. Ambil data halaman
2. Kemudian ambil produk berkaitan
3. Kemudian ambil harga
4. Kemudian panggil perkhidmatan cadangan
5. Kemudian render HTML

Jika setiap langkah menunggu langkah sebelumnya, TTFB berkembang dengan cepat. Selarikan kerja yang bebas, keluarkan panggilan tidak kritikal daripada respons pertama, dan cache hasil yang mahal.

Peraturan berguna: jika pengguna tidak boleh melihat atau menggunakan hasilnya dengan segera, ia mungkin tidak sepatutnya menyekat bait pertama.

Pertanyaan pangkalan data perlahan atau tidak boleh diramal

Pangkalan data sering menyebabkan masalah TTFB kerana ia berkelakuan baik dalam pembangunan dan buruk di bawah trafik sebenar. Indeks yang hilang, join besar, pertanyaan N+1, perebutan lock dan set hasil yang terlalu besar semuanya muncul sebagai “pelayan perlahan”.

Jangan meneka di sini. Tangkap pemasaan pertanyaan untuk permintaan perlahan. Lihat p95 dan p99, bukan hanya purata. Satu halaman yang biasanya memberi respons dalam 120 ms tetapi kadang-kadang tersekat selama 4 saat masih akan mencipta pengalaman pengguna yang buruk.

Pembaikan biasa termasuk:

• Menambah atau membetulkan indeks
• Menghapuskan corak pertanyaan N+1
• Mencache data yang banyak dibaca
• Memecahkan pertanyaan besar kepada halaman
• Mengalihkan pertanyaan pelaporan atau analitik daripada masa permintaan
• Menetapkan timeout yang munasabah untuk panggilan downstream

Aplikasi anda mengalami cold start

Platform serverless dan berkontena boleh menjadi sangat baik, tetapi cold start boleh menjejaskan TTFB apabila trafik datang secara berkelompok atau rantau kurang diperuntukkan.

Jika permintaan pertama anda selepas masa melahu jauh lebih perlahan daripada permintaan selepasnya, siasat cold start. Anda mungkin memerlukan provisioned concurrency, bundle yang lebih kecil, kebergantungan permulaan yang lebih sedikit, fungsi yang lebih hangat, atau bentuk deployment yang berbeza untuk laluan sensitif kependaman.

Ini bukan hujah menentang serverless. Ini hujah menentang berpura-pura bahawa model runtime tidak kelihatan.

Redirect membazirkan permintaan pertama

Redirect menambah satu lagi kitaran permintaan-respons sebelum pelayar menerima dokumen akhir. Satu redirect daripada http:// ke https:// mungkin tidak dapat dielakkan untuk pautan lama, tetapi rantaian adalah membazir.

Rantaian biasa termasuk:

• http://example.com → https://example.com → https://www.example.com
• normalisasi trailing slash selepas normalisasi protokol
• redirect geo atau bahasa sebelum carian cache
• pautan kempen lama yang melompat melalui beberapa URL

Betulkan pautan sumber jika boleh, ringkaskan peraturan redirect, dan jadikan URL kanonik terus. Masa redirect tidak selalu dilaporkan sebagai TTFB untuk permintaan akhir, tetapi pengguna masih membayarnya.

Urutan penyahpepijatan yang praktikal

Apabila TTFB kelihatan perlahan, gunakan susunan ini. Ia mengelakkan kesilapan biasa mengoptimumkan kod aplikasi sebelum mengesahkan tingkah laku cache dan penghalaan.

Step 1: Uji dokumen utama, bukan hanya keseluruhan halaman

Cari permintaan untuk dokumen HTML. Rekod jumlah TTFB dan pecahan pemasaan. Ulang dengan dan tanpa cache pelayar. Uji halaman awam, halaman dinamik dan halaman log masuk jika berkaitan.

Step 2: Bandingkan rantau

Jalankan URL yang sama dari beberapa lokasi geografi. Jika rantau perlahan berkorelasi dengan jarak dari origin, utamakan CDN dan edge caching. Jika setiap rantau perlahan, lihat pemprosesan backend dan kapasiti origin.

Step 3: Periksa pengepala respons

Cari pengepala cache, kuki, Age, status CDN dan Vary. Pengepala Age yang hilang atau cache miss berulang ialah petunjuk. Pengepala Vary: Cookie yang luas pada HTML awam sering menjadi pembunuh cache.

Step 4: Semak pemasaan origin

Tambah instrumentasi pemasaan pelayan. Pengepala Server-Timing boleh mendedahkan fasa backend seperti masa pangkalan data, masa render dan masa API upstream. Label ringkas pun berguna:

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

Kini pemasaan pelayar anda boleh menunjukkan sama ada pelayan menghabiskan 300 ms untuk kerja sebenar atau sama ada kelewatan berlaku sebelum permintaan sampai ke aplikasi anda.

Step 5: Baiki kelewatan terbesar yang disahkan

Ini kedengaran jelas, tetapi pasukan sering membaiki perkara yang biasa bagi mereka dan bukannya perkara yang diukur. Jika cache miss mendominasi, baiki caching. Jika pangkalan data mendominasi, baiki pertanyaan. Jika TLS dan penyediaan sambungan mendominasi untuk pengguna global, baiki penghalaan, liputan CDN atau geografi origin.

Kerja front-end masih penting. Fon, imej dan JavaScript mempengaruhi apa yang berlaku selepas HTML tiba. Tetapi ia bukan pengganti untuk respons pertama yang pantas. Jika anda juga sedang mengusahakan prestasi render, web fonts masih antara kemenangan paling mudah di banyak laman kerana ia mempengaruhi seberapa cepat teks menjadi boleh digunakan selepas dokumen tiba.

Pembaikan yang biasanya berkesan

Cache HTML awam di edge

Untuk halaman pemasaran, dokumentasi, blog, landing page dan halaman kategori, edge caching selalunya penambahbaikan TTFB terbesar. Gunakan TTL pendek jika kandungan kerap berubah. Gunakan stale-while-revalidate jika kandungan yang sedikit lapuk boleh diterima sementara cache disegarkan di latar belakang.

Berhati-hati dengan pemperibadian. Jika halaman berubah mengikut mata wang, bahasa, keadaan log masuk atau kumpulan eksperimen, takrifkan varian tersebut dengan jelas. Variasi per pengguna yang tidak disengajakan memusnahkan kecekapan cache.

Alihkan kerja tidak kritikal keluar daripada laluan permintaan

Penghantaran e-mel, pengayaan analitik, penjanaan cadangan, panggilan webhook dan pengelogan berat jarang sekali patut menyekat bait pertama. Letakkan dalam baris gilir atau jalankan selepas respons dimulakan.

Kurangkan rantaian kebergantungan backend

Selarikan panggilan yang bebas. Cache respons daripada API perlahan. Tetapkan timeout. Reka kandungan fallback untuk perkhidmatan yang membantu tetapi tidak penting.

Widget cadangan yang perlahan tidak sepatutnya melambatkan seluruh halaman produk.

Letakkan compute lebih dekat dengan pengguna

Jika pengguna anda global dan origin anda berada di satu rantau, kependaman adalah struktur. Caching CDN boleh menyembunyikan banyak perkara ini untuk kandungan awam. Untuk kandungan dinamik, pertimbangkan deployment serantau, edge rendering untuk laluan yang sesuai, atau memindahkan API lebih dekat dengan khalayak.

Pastikan redirect membosankan

Kanonikkan URL dalam satu hop. Kemas kini pautan dalaman supaya pengguna dan crawler pergi terus ke destinasi akhir. Audit URL kempen lama dan migrasi platform. Redirect mudah diabaikan kerana ia tidak kelihatan apabila berfungsi, tetapi ia masih menelan masa.

Apa yang tidak patut dilakukan

Jangan mengejar nombor TTFB sempurna untuk setiap laluan. Laporan berautentikasi yang melakukan pengiraan sebenar tidak akan berkelakuan seperti catatan blog yang dicache.

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

Jangan anggap CDN bermaksud HTML anda dicache. Sahkan.

Dan jangan layan TTFB sebagai terpisah daripada keputusan produk. Pemperibadian, eksperimen, inventori masa nyata dan perkhidmatan pihak ketiga semuanya mempunyai kos kependaman. Ada yang berbaloi. Ada yang sekadar kebiasaan.

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

💡 Cuba ini: Semasa mendiagnosis TTFB, Get Headers mendedahkan status cache, pemasaan pelayan dan pengalihan yang sering menjelaskan dari mana kelewatan itu datang.

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

Versi pelan yang tenang

TTFB yang perlahan biasanya boleh dibaiki sebaik sahaja anda berhenti melayannya sebagai “masalah pelayan” yang kabur. Ukur permintaan dokumen. Segmentasikan mengikut rantau dan jenis halaman. Periksa pengepala. Bandingkan pemasaan klien dengan pemasaan origin. Kemudian baiki bottleneck terbesar yang disahkan.

Kebanyakan laman tidak memerlukan seni bina eksotik. Mereka memerlukan lebih sedikit cache miss yang boleh dielakkan, kurang kerja backend yang menyekat, redirect yang lebih bersih, dan idea yang lebih jelas tentang apa yang mesti berlaku sebelum bait pertama dihantar.