Masa Respons Pelayan (TTFB): Cara Kurangkan & Faktor Utama Yang Mempengaruhi

Masa Respons Pelayan (TTFB) ialah tempoh antara pelayar menghantar permintaan untuk halaman web sehinggalah bait pertama data diterima daripada pelayan. Untuk memendekkannya, anda perlu menggunakan infrastruktur pengehosan berkualiti tinggi, melaksanakan cache halaman penuh, mengurangkan pertanyaan pangkalan data, menggunakan CDN, dan mengoptimumkan proses DNS serta SSL. Sebagai sasaran praktikal, nilai TTFB yang baik untuk halaman statik atau yang telah di-cache dengan sempurna adalah sekitar 100-300 ms, manakala halaman dengan kandungan dinamik selalunya di bawah 500 ms. Nilai melebihi 800 ms harus dilihat sebagai isyarat bahawa penambahbaikan diperlukan dari segi pengalaman pengguna dan kecekapan enjin carian.

TTFB sahaja tidak menjelaskan keseluruhan kelajuan laman web. Namun, ia adalah metrik permulaan yang kritikal kerana ia menentukan seawal mana elemen lain pada halaman akan mula dimuatkan. Terutamanya untuk laman WordPress, WooCommerce, portal berita, sistem keahlian, dan laman web korporat dengan trafik tinggi, kelewatan di bahagian pelayan secara langsung mempengaruhi LCP (Largest Contentful Paint) dan masa bukaan halaman secara keseluruhan. Dalam panduan ini, kami akan membincangkan faktor-faktor yang meningkatkan nilai TTFB, kaedah pengukuran, dan langkah-langkah pengoptimuman yang praktikal dengan gaya bahasa teknikal namun mudah difahami khas untuk blog Hostragons.

Apa Itu TTFB dan Apa Yang Diukurnya?

TTFB adalah singkatan daripada Time to First Byte. Dalam Bahasa Melayu, ia boleh diterjemahkan sebagai masa untuk bait pertama atau masa respons pelayan. Apabila pengguna membuka halaman, pelayar terlebih dahulu melakukan pencarian DNS, kemudian menyambung ke pelayan, melaksanakan proses jabat tangan TLS/SSL jika perlu, memproses permintaan oleh pelayan web, dan akhirnya menghantar cebisan data pertama. Pada penghujung rantaian proses inilah, TTFB dikira selesai sebaik bait pertama sampai ke pelayar.

Adalah kurang tepat untuk menganggap metrik ini hanya bergantung kepada kuasa pemprosesan pelayan semata-mata. TTFB mencerminkan kesan gabungan pelbagai lapisan seperti jarak rangkaian, kelajuan DNS, sambungan TCP, proses SSL, konfigurasi pelayan web, kod aplikasi, pertanyaan pangkalan data, I/O cakera, dan strategi cache. Oleh itu, pengoptimuman TTFB yang berjaya bukan sekadar memasang satu plugin tertentu; ia memerlukan kawalan sistematik daripada infrastruktur hinggalah ke aplikasi.

Berapakah Nilai TTFB Yang Baik (ms)?

Berdasarkan pendekatan prestasi yang diterima umum, sasaran ideal TTFB boleh ditafsirkan seperti berikut:

• 0-200 ms: Sangat baik. Biasanya melibatkan kandungan statik, cache yang mantap, atau pelayan CDN yang berdekatan.
• 200-500 ms: Baik. Julat yang boleh diterima untuk kebanyakan laman korporat dan pemasangan WordPress yang telah dioptimumkan.
• 500-800 ms: Boleh diperbaiki. Mungkin disebabkan oleh pertanyaan dinamik, pelayan yang jauh, atau cache yang tidak mencukupi.
• 800 ms dan ke atas: Isyarat masalah. Sumber pengehosan, kod aplikasi, pangkalan data, atau lapisan rangkaian perlu disiasat.

Perkara penting di sini adalah jangan membuat keputusan berdasarkan satu keputusan ujian sahaja. Pengukuran dari Kuala Lumpur mungkin berbeza dengan pengukuran dari Singapura, Jakarta, atau London. Selain itu, halaman utama, halaman produk, artikel blog, halaman troli, dan halaman log masuk mungkin tidak mempunyai nilai TTFB yang sama. Oleh itu, adalah lebih sihat untuk melakukan pengukuran pada jenis halaman yang berbeza, pada waktu yang berbeza, dan jika boleh, dari lokasi yang berbeza.

Mengapa Masa Respons Pelayan (TTFB) Meningkat?

TTFB yang tinggi biasanya bukan berpunca daripada satu sebab tunggal, tetapi gabungan beberapa kelewatan kecil. Faktor-faktor berikut adalah punca yang paling kerap ditemui.

1. Sumber Pengehosan Yang Tidak Mencukupi

Pengehosan kongsi boleh menjadi cekap untuk laman bersaiz kecil dan sederhana jika dikonfigurasikan dengan betul. Namun, penggunaan padat pada pelayan yang sama, had CPU, kekangan RAM, atau prestasi cakera yang perlahan boleh meningkatkan nilai TTFB. Terutamanya trafik kempen serta-merta, trafik bot yang tinggi, atau transaksi dinamik seperti langkah pembayaran WooCommerce memerlukan lebih banyak sumber. Dalam kes ini, mungkin perlu beralih kepada pelan pengehosan web yang lebih optimum, menggunakan infrastruktur cakera NVMe, atau memilih penyelesaian VPS. Untuk pemilihan infrastruktur yang sesuai di Hostragons, anda boleh lihat Pakej Pengehosan Web dan untuk projek yang sedang berkembang, Penyelesaian Pelayan VPS.

2. Ketiadaan Sistem Cache

Membina halaman dari awal untuk setiap pelawat, menjalankan PHP, membuat pertanyaan pangkalan data, dan memproses semula komponen tema akan meningkatkan nilai TTFB secara drastik. Cache halaman penuh, cache objek, dan cache pelayar mengurangkan beban ini. Sebagai contoh, artikel blog berasaskan WordPress mungkin memberikan TTFB 900 ms tanpa cache, tetapi boleh turun ke julat 180-250 ms dengan konfigurasi cache yang betul.

3. Masalah Pertanyaan Pangkalan Data

Pertanyaan yang perlahan adalah punca utama TTFB tinggi, terutamanya dalam projek WordPress, Magento, Laravel, atau perisian tersuai. Jadual pilihan yang besar, carian yang tidak dioptimumkan, kekurangan indeks, operasi JOIN yang tidak perlu, dan penggunaan plugin yang berlebihan memanjangkan masa pemprosesan di bahagian pelayan. Di laman WooCommerce, transaksi troli, stok, penapisan, dan sesi pengguna adalah lebih "mahal" berbanding halaman blog statik.

4. Jarak Rangkaian dan Tiada Penggunaan CDN

Apabila jarak fizikal antara pengguna dan pelayan meningkat, latensi juga meningkat. Mengehoskan laman yang menyasarkan pengguna Malaysia di pusat data yang jauh, contohnya di Eropah atau AS, boleh meningkatkan nilai TTFB, terutamanya semasa fasa sambungan awal. CDN mengurangkan latensi ini dengan menyajikan fail statik dan, dalam beberapa kes, output HTML dari titik tepi (edge nodes) yang lebih dekat dengan pengguna. Walau bagaimanapun, CDN boleh memberi kesan sebaliknya jika salah konfigurasi; contohnya, jika cache HTML dimatikan, hanya imej yang dipercepatkan, dan peningkatan TTFB adalah terhad.

5. Kelewatan DNS dan SSL

Pencarian DNS yang perlahan atau konfigurasi SSL/TLS yang bergantung pada protokol lapuk juga boleh menjejaskan masa respons pertama. Sokongan TLS 1.3 moden, rantaian sijil yang betul, dan penyedia DNS yang pantas memendekkan masa sambungan. Penggunaan SSL adalah wajib untuk sambungan selamat; namun, pemasangan sijil yang salah boleh menyebabkan kehilangan prestasi. Untuk isu ini, anda boleh menilai halaman Sijil SSL dan untuk pengurusan domain, Semakan dan Pendaftaran Domain.

Bagaimana Mengukur TTFB?

Sebelum memulakan penambahbaikan TTFB, pengukuran yang tepat perlu dilakukan. Jika tidak, kesan perubahan yang dibuat tidak akan dapat difahami. Semasa mengukur, adalah disyorkan untuk mendapatkan keputusan daripada beberapa sumber berbeza dan bukannya bergantung pada satu alat sahaja.

Alat Yang Boleh Digunakan

• Chrome DevTools: Di tab Rangkaian (Network), bahagian Timing untuk permintaan dokumen boleh menyemak ruang "Waiting for server response".
• PageSpeed Insights: Memberikan gambaran prestasi umum dengan data pengguna sebenar dan data makmal.
• WebPageTest: Menawarkan analisis waterfall terperinci di lokasi, pelayar, dan kelajuan sambungan yang berbeza.
• GTmetrix: Memudahkan untuk melihat permintaan mana yang tertunda, terutamanya melalui graf waterfall.
• Arahan curl: Untuk pasukan teknikal, ia menyediakan pengukuran terminal pantas. Contohnya, arahan curl -w '%{time_starttransfer}' -o /dev/null -s https://namasite.com memberikan masa permulaan pemindahan yang serupa dengan TTFB.

Semasa mengukur, pilih jenis URL yang berbeza seperti halaman utama, kategori, produk, artikel blog, troli, dan halaman log masuk. Selain itu, sebelum ujian, catatkan sama ada status CDN dan cache adalah 'panas' atau 'sejuk'. Permintaan pertama mungkin perlahan kerana cache sejuk, manakala permintaan seterusnya pantas; perbezaan ini penting dalam strategi pengoptimuman.

Kaedah Memendekkan TTFB: Panduan Langkah Demi Langkah

Langkah-langkah berikut disusun mengikut urutan yang memberikan impak paling besar dalam amalan. Melakukan pengukuran semula selepas setiap langkah membantu anda memahami berapa banyak sumbangan setiap perubahan.

1. Pilih Infrastruktur Pengehosan Yang Tepat

Asas pengoptimuman TTFB adalah pelayan yang boleh memproses permintaan dengan pantas. Pelayan harus mempunyai pemproses terkini, RAM yang mencukupi, NVMe SSD, LiteSpeed atau konfigurasi Nginx/Apache yang dioptimumkan, versi PHP terkini, dan isolasi sumber yang baik. Pengehosan kongsi berkualiti mungkin mencukupi untuk laman korporat kecil, manakala laman e-dagang bertrafik tinggi lebih sesuai menggunakan VPS atau pelayan terurus. Sebagai contoh, keperluan sumber laman web profil dengan 500 pelawat harian tidak sama dengan kedai yang mempunyai 200 pengguna sedang memproses troli secara serentak.

Apabila memilih pengehosan, hanya melihat ruang cakera adalah satu kesilapan. Had CPU, RAM, had inode, prestasi I/O, struktur sandaran, lokasi pusat data, dan kualiti sokongan juga mesti dinilai. Jika audiens sasaran anda adalah di Malaysia atau Asia Tenggara, memilih pusat data yang berdekatan selalunya memberi kesan positif kepada nilai TTFB.

2. Gunakan Versi PHP dan Protokol HTTP Terkini

Perbezaan prestasi yang ketara dapat dilihat antara PHP 7.4 dan PHP 8.2 atau 8.3, terutamanya dalam WordPress dan framework moden. Jika tema dan plugin adalah serasi, beralih kepada versi PHP terkini akan mengurangkan masa pemprosesan pelayan. Sokongan HTTP/2 dan HTTP/3 juga boleh meningkatkan kecekapan sambungan. HTTP/3, melalui protokol QUIC, berpotensi mengurangkan latensi sambungan, terutamanya pada rangkaian mudah alih.

Walaupun begitu, ujian di persekitaran staging mesti dilakukan sebelum menaik taraf versi. Jika plugin lapuk atau kod tersuai memberikan ralat pada versi PHP baharu, anda akan menghadapi masalah kebolehcapaian dan bukannya peningkatan prestasi. Oleh itu, buat sandaran dahulu, kemudian semak keserasian.

3. Laksanakan Cache Halaman Penuh

Salah satu kaedah yang memberi kesan terpantas ke atas TTFB ialah menggunakan cache halaman penuh. Untuk laman WordPress, output HTML boleh disimpan dengan penyelesaian seperti LiteSpeed Cache, WP Rocket, W3 Total Cache, atau yang serupa. Dengan ini, proses PHP dan MySQL tidak perlu berjalan semula untuk setiap lawatan ke halaman yang sama. Untuk laman yang berjalan di atas LiteSpeed Web Server, LiteSpeed Cache biasanya memberikan hasil yang sangat mantap.

Peraturan cache mesti ditetapkan dengan teliti. Artikel blog, halaman kategori, dan halaman korporat statik sesuai untuk di-cache. Troli, pembayaran, akaun pengguna, dan panel peribadi kebiasaannya harus dikecualikan daripada cache. Peraturan cache yang salah boleh menyebabkan ralat serius seperti menunjukkan troli pengguna lain kepada pengguna yang sedang aktif.

4. Optimumkan Pangkalan Data

Selalunya, pangkalan data adalah punca di sebalik TTFB yang perlahan. Untuk WordPress, membersihkan semakan (revisions), komen spam, data sementara (transients), dan pilihan autoload yang tidak perlu adalah langkah permulaan yang berkesan. Di laman besar, rekod yang tidak perlu dalam jadual wp_options yang ditandakan sebagai autoload=yes akan dimuatkan ke dalam memori setiap kali halaman dimuatkan dan boleh meningkatkan nilai TTFB.

Untuk pengoptimuman peringkat lanjutan, log pertanyaan perlahan harus diperiksa, indeks perlu ditambah pada medan penapisan dan carian yang kerap digunakan, plugin yang tidak perlu harus dibuang, dan bilangan pertanyaan harus dikurangkan. Sebagai contoh, jika halaman kategori menjalankan 180 pertanyaan, struktur tema dan plugin boleh disemak semula untuk mengurangkan bilangan ini ke julat 60-80. Perbezaan ini memberikan peningkatan prestasi yang ketara pada trafik tinggi.

5. Gunakan Cache Objek

Penyelesaian cache objek seperti Redis atau Memcached menyimpan hasil yang kerap diambil dari pangkalan data di dalam memori. Cache objek memberikan kelebihan besar, terutamanya untuk laman keahlian, e-dagang, iklan, LMS, dan laman berbilang bahasa. Cache halaman penuh tidak selalu boleh digunakan pada halaman dinamik; namun, cache objek boleh mengurangkan pertanyaan berulang walaupun dalam transaksi dinamik.

Di sini, kapasiti RAM pelayan adalah penting. Konfigurasi cache objek yang agresif pada RAM yang tidak mencukupi boleh memberi kesan sebaliknya. Oleh itu, statistik penggunaan harus dipantau, dan kadar 'cache hit' serta penggunaan memori mesti dikawal.

6. Kurangkan Latensi Geografi dengan CDN

CDN menyajikan imej, CSS, JavaScript, dan dalam beberapa kes, kandungan HTML dari titik yang lebih dekat dengan pengguna. Kesan CDN yang paling kuat terhadap TTFB dilihat apabila HTML edge caching atau reverse proxy cache digunakan. Hanya memindahkan fail statik ke CDN meningkatkan jumlah kelajuan halaman; tetapi jika permintaan HTML utama masih datang dari pelayan asal yang jauh, peningkatan TTFB adalah terhad.

Semasa menyediakan CDN, rekod DNS, mod SSL, maklumat header cache, dan peraturan pengecualian (bypass rules) mesti dikonfigurasikan dengan betul. Panel pengurusan, skrin pembayaran, dan halaman khusus pengguna harus dikecualikan daripada cache. Selain itu, alamat IP pelayan asal harus dilindungi dari segi keselamatan, dan peraturan harus ditulis untuk membenarkan akses hanya melalui CDN.

7. Kurangkan Beban Tema dan Plugin

Struktur tema yang berat, pembina halaman yang tidak perlu, terlalu banyak plugin, dan panggilan API luaran boleh meningkatkan nilai TTFB di laman WordPress. Bukan semua plugin tidak baik; tetapi setiap plugin bermakna potensi pemprosesan PHP, pertanyaan pangkalan data, dan permintaan luaran. Plugin yang tidak digunakan bukan sahaja patut dinyahaktifkan, tetapi harus dipadamkan sepenuhnya.

Sebagai ujian praktikal, di persekitaran staging, nyahaktifkan plugin satu persatu dan ukur TTFB. Sebagai contoh, plugin keselamatan, sandaran, analitik, SEO, borang, terjemahan, dan pembina halaman harus dinilai secara berasingan. Jika modul kadar pertukaran, suapan media sosial, atau alat sembang langsung yang bersambung ke API luaran menyebabkan penantian di pelayan, ia harus dijadikan tak segerak (asynchronous) atau di-cache.

8. Kawal Trafik Bot dan Permintaan Berniat Jahat

Trafik bot yang padat, cubaan brute force, serangan XML-RPC, dan permintaan crawler yang tidak perlu menghabiskan sumber pelayan dan meningkatkan nilai TTFB untuk pengguna sebenar. WAF (Web Application Firewall), had kadar (rate limiting), plugin keselamatan, pengoptimuman robots.txt, dan analisis log adalah penting di sini. Terutamanya, cubaan log masuk yang intensif ke halaman log masuk WordPress boleh meningkatkan penggunaan CPU.

Langkah keselamatan diperlukan bukan sahaja untuk menyekat serangan, tetapi juga untuk melindungi prestasi. SSL, DNS selamat, perisian terkini, dan peraturan firewall yang betul harus difikirkan bersama. Untuk kandungan keselamatan yang berkaitan, anda boleh merujuk pautan Panduan Keselamatan Laman Web.

Jadual Perbandingan Untuk Pengoptimuman TTFB

Tip Khas TTFB Untuk Laman WordPress

WordPress adalah infrastruktur fleksibel yang boleh berjalan pantas jika dikonfigurasikan dengan betul; tetapi ia mudah menjadi berat disebabkan oleh ekosistem tema dan plugin. Pertama sekali, gunakan versi PHP terkini, tema yang boleh dipercayai, bilangan plugin yang terhad, dan cache peringkat pelayan. Kemudian, lakukan pembersihan pangkalan data, cache objek, pengoptimuman imej, dan kawalan cron.

WP-Cron secara lalai dicetuskan apabila pelawat tiba. Tingkah laku ini boleh menyebabkan kelewatan yang tidak perlu di laman bertrafik tinggi. Adalah lebih cekap untuk mentakrifkan cron job sebenar dan menjalankan tugas berjadual pada selang waktu tertentu. Selain itu, kekerapan Heartbeat API, penggunaan admin-ajax.php, dan serpihan troli WooCommerce (cart fragments) harus dikawal. Penyesuaian kecil dalam bidang ini boleh memberikan peningkatan yang ketara, terutamanya pada panel pentadbiran dan halaman dinamik.

Mengapa TTFB Lebih Kritikal Untuk Laman E-Dagang?

Laman e-dagang melakukan lebih banyak transaksi dinamik berbanding laman kandungan standard. Troli, pembayaran, semakan stok, pengiraan penghantaran, pengesahan kupon, sesi pengguna, dan cadangan peribadi selalunya dikecualikan daripada cache. Oleh itu, bergantung kepada cache halaman penuh sahaja tidak mencukupi. Untuk e-dagang, pengehosan yang mantap, pangkalan data yang dioptimumkan, cache objek, tema yang dikodkan dengan baik, dan API pembayaran/penghantaran yang responsif adalah perlu.

Sebagai contoh, jika maklumat harga, stok, dan penapis pada halaman senarai produk dikira dengan pertanyaan kompleks untuk setiap permintaan, TTFB akan meningkat. Data ini boleh disediakan terlebih dahulu pada selang waktu tertentu, pertanyaan boleh diindekskan, atau enjin carian khusus boleh digunakan untuk carian/penapisan. Semasa tempoh kempen, pelan penskalaan sumber harus dibuat lebih awal.

Hubungan Antara TTFB dan Core Web Vitals

Metrik Core Web Vitals memberi tumpuan secara langsung kepada pengalaman pengguna. Walaupun TTFB bukan metrik rasmi Core Web Vitals, ia mempunyai kesan yang signifikan terutamanya terhadap LCP. Jika HTML tiba lewat dari pelayan, pelayar juga akan lewat menemui sumber CSS, imej, dan JavaScript yang kritikal. Ini boleh menyebabkan elemen kandungan terbesar dimuatkan lewat.

Ringkasnya, jika TTFB buruk, mengoptimumkan baki halaman menjadi sukar. Walaupun imej telah dimampatkan, CSS telah diminimumkan, dan JavaScript telah ditunda, jika HTML pertama tiba lewat, pengguna akan berhadapan dengan skrin kosong untuk tempoh yang lebih lama. Oleh itu, dalam kerja-kerja prestasi, respons pelayan harus diutamakan, diikuti oleh sumber yang menyekat pemaparan (render-blocking) dan pengoptimuman imej secara bersama.

Senarai Semak TTFB Yang Praktikal

• Lakukan pengukuran TTFB untuk halaman utama dan halaman penting dari lokasi yang berbeza.
• Periksa versi PHP dan teknologi pelayan web.
• Konfigurasikan tetapan cache halaman penuh dan cache pelayar.
• Periksa rekod yang tidak perlu, pertanyaan perlahan, dan beban autoload dalam pangkalan data.
• Nilaikan pilihan cache objek seperti Redis atau Memcached.
• Gunakan pusat data yang berdekatan dengan audiens sasaran dan CDN jika perlu.
• Periksa sokongan DNS, SSL, dan HTTP/2-HTTP/3.
• Buang plugin, tema, dan integrasi perkhidmatan luaran yang tidak digunakan.
• Lakukan analisis log untuk trafik bot dan cubaan serangan.
• Uji semula dalam keadaan yang sama selepas setiap perubahan.

Kesilapan Yang Sering Dilakukan

Kesilapan paling lazim dalam pengoptimuman TTFB ialah memasang plugin secara rawak tanpa mengukur punca masalah. Menggunakan lebih daripada satu plugin cache secara serentak, memilih mod SSL CDN yang salah, atau men-cache halaman dinamik secara salah boleh merosakkan laman dan bukannya mempercepatkannya. Satu lagi kesilapan ialah hanya memberi tumpuan kepada skor PageSpeed. Skor adalah petunjuk yang berguna; tetapi tanpa analisis waterfall, log pelayan, dan data pengguna sebenar, sukar untuk mencari punca utama.

Selain itu, mengharapkan keajaiban dengan pengoptimuman lanjutan di atas pengehosan kongsi yang murah tetapi sangat padat adalah tidak realistik. Walau sebaik mana pun bahagian perisian, jika sumber pelayan tidak mencukupi, TTFB tidak akan turun di bawah tahap tertentu. Oleh itu, pengoptimuman infrastruktur dan aplikasi mesti dirancang bersama.

Kesimpulan: Penambahbaikan Sistematik Penting Untuk TTFB Lebih Rendah

Masa Respons Pelayan (TTFB) adalah salah satu titik permulaan asas prestasi web. TTFB yang rendah bermakna respons pertama yang lebih pantas, pengalaman pengguna yang lebih baik, perangkakan yang lebih cekap, dan asas yang lebih kukuh untuk Core Web Vitals. Untuk hasil terbaik, pengehosan berkualiti, sistem cache yang betul, pengoptimuman pangkalan data, perisian terkini, CDN, dan langkah keselamatan mesti dilaksanakan bersama.

Jika nilai TTFB semasa laman web anda tinggi, ukur dahulu, kemudian mulakan dengan kesesakan paling besar dan teruskan langkah demi langkah. Jika anda memerlukan infrastruktur yang lebih mantap untuk trafik yang semakin meningkat, anda boleh menyemak penyelesaian pengehosan, VPS, domain, dan SSL Hostragons untuk membina asas yang tepat untuk laman anda: Penyelesaian Pengehosan Hostragons.

Soalan Lazim

Apakah perkara pertama yang perlu dilakukan untuk mengurangkan TTFB?

Langkah pertama adalah membuat pengukuran yang tepat. Uji halaman yang berbeza seperti halaman utama, kategori, produk, atau blog. Kemudian, semak sumber pengehosan, status cache, pertanyaan pangkalan data, dan konfigurasi CDN secara berurutan.

Berapakah nilai TTFB yang baik dalam ms?

Sasaran umum adalah dalam julat 200-500 ms. Nilai di bawah 200 ms dianggap sangat baik, manakala nilai melebihi 800 ms biasanya menunjukkan keperluan pengoptimuman. Untuk halaman e-dagang dinamik, sasaran mungkin berbeza mengikut jenis halaman.

Adakah penggunaan CDN sentiasa menurunkan nilai TTFB?

Tidak. CDN mempercepatkan fail statik; tetapi jika permintaan HTML masih datang dari pelayan asal, penurunan TTFB adalah terhad. Untuk TTFB, ciri HTML cache atau reverse proxy CDN mesti dikonfigurasikan dengan betul.

Adakah plugin WordPress meningkatkan nilai TTFB?

Ya, terutamanya tema berat, plugin yang tidak perlu, panggilan API luaran, dan bilangan pertanyaan pangkalan data yang tinggi boleh meningkatkan nilai TTFB. Plugin yang tidak digunakan harus dibuang, dan komponen yang menghasilkan pertanyaan perlahan harus dianalisis.

Adakah TTFB pasti turun jika menukar pengehosan?

Pengehosan adalah faktor penting; tetapi ia bukan jaminan tunggal. Jika sumber pelayan tidak mencukupi, pertukaran pengehosan boleh membuat perbezaan besar. Namun, jika masalahnya terletak pada kod aplikasi, pangkalan data, atau konfigurasi cache yang salah, bidang tersebut juga mesti dioptimumkan.