Mempercepat TTFB WordPress untuk Publisher: Server, PHP, dan Database

Pembaca mengklik judul artikel Anda di hasil pencarian, lalu layar tetap kosong. Bukan karena gambarnya berat atau CSS-nya lambat, melainkan karena server belum mengirim satu byte pun. Itulah Time to First Byte, disingkat TTFB, dan bagi publisher WordPress ini sering menjadi penyebab tersembunyi di balik skor PageSpeed Insights yang buruk. Artikel ini menjelaskan apa itu TTFB, berapa nilai yang dianggap bagus menurut Google, cara mengukurnya dengan benar, dan langkah perbaikan yang paling berdampak — mulai dari page cache, versi PHP, sampai database — dengan urutan yang bisa dikerjakan satu per satu tanpa mematikan situs.

Poin Kunci

• TTFB mengukur waktu dari mulai navigasi sampai byte pertama respons tiba; komponennya meliputi redirect, DNS, koneksi TCP, TLS, dan waktu pemrosesan server.
• Menurut web.dev, TTFB 0,8 detik atau kurang tergolong bagus, 0,8–1,8 detik perlu perbaikan, dan di atas 1,8 detik buruk; penilaian memakai persentil ke-75 pengguna nyata.
• TTFB bukan Core Web Vital, tetapi ia menunda First Contentful Paint dan Largest Contentful Paint, sehingga TTFB yang lambat hampir selalu membuat LCP ikut lambat.
• Perbaikan paling berdampak bagi kebanyakan situs WordPress adalah page cache yang benar, PHP versi terbaru yang direkomendasikan WordPress.org (8.3 atau lebih baru), dan database yang bersih dari query berat.
• Ukur TTFB dalam dua kondisi — cache hit dan cache miss — karena angka yang terlihat bagus pada halaman yang sudah di-cache tidak menceritakan kondisi halaman yang harus dibangun server dari nol.

Daftar Isi

1. Apa Itu TTFB dan Mengapa Publisher Harus Peduli
2. Berapa TTFB yang Bagus? Ambang Resmi Google
3. Cara Mengukur TTFB dengan Benar
4. Peta Penyebab: Di Mana Waktu Anda Habis
5. Langkah 1: Page Cache — Perbaikan Paling Berdampak
6. Langkah 2: PHP — Versi, OPcache, dan Workers
7. Langkah 3: Database — Query Lambat dan Object Cache
8. Langkah 4: Hosting dan Server — Lokasi, Sumber Daya, dan Protokol
9. Langkah 5: Redirect, DNS, dan Koneksi
10. Langkah 6: Plugin dan Tema — Audit Beban per Halaman
11. Rencana Perbaikan 7 Hari untuk Publisher
12. Contoh Ilustrasi: Dari TTFB 2,4 Detik ke 0,6 Detik
13. Kesalahan Umum Saat Mempercepat TTFB
14. FAQ
15. Kesimpulan
16. Sumber Resmi yang Dirujuk

Apa Itu TTFB dan Mengapa Publisher Harus Peduli

Time to First Byte (TTFB) adalah metrik yang mengukur waktu antara browser mulai menavigasi ke sebuah halaman dan saat byte pertama respons mulai tiba. Definisi ini berasal dari dokumentasi web.dev milik Google, dan penting dipahami secara harfiah: yang diukur bukan waktu halaman selesai dimuat, bukan waktu gambar terbesar tampil, melainkan waktu tunggu pertama — momen ketika server akhirnya “menjawab”.

TTFB adalah jumlah dari beberapa fase permintaan. Menurut web.dev, fase-fase itu adalah redirect, pencarian DNS, pembuatan koneksi, negosiasi TLS, pengiriman permintaan, dan pemrosesan di server. Pada situs WordPress yang tidak di-cache, fase pemrosesan server biasanya mendominasi: WordPress harus menjalankan PHP, menanyakan database, memuat tema dan plugin, lalu merangkai HTML sebelum byte pertama bisa dikirim. Pada situs yang sudah di-cache dengan baik, pemrosesan server nyaris hilang dan yang tersisa adalah jarak jaringan dan waktu penyiapan koneksi.

Mengapa publisher harus peduli pada metrik yang tampak teknis ini? Ada tiga alasan. Pertama, TTFB berada di hulu semua metrik pengalaman pengguna. First Contentful Paint (FCP) dan Largest Contentful Paint (LCP) tidak bisa dimulai sebelum byte pertama tiba. Jika TTFB Anda 1,5 detik, sementara ambang LCP yang bagus adalah 2,5 detik, maka hanya tersisa 1 detik untuk segala hal lain — mengunduh HTML, CSS, font, dan gambar utama. Kedua, TTFB yang lambat terasa langsung oleh pembaca sebagai halaman kosong. Pembaca tidak melihat animasi loading yang meyakinkan; mereka melihat layar putih, dan layar putih adalah momen paling rawan bagi seseorang untuk menekan tombol kembali. Ketiga, bagi publisher yang hidup dari iklan, halaman yang lambat dibuka berarti lebih sedikit tayangan iklan yang sempat dimuat dan dibaca, terutama pada traffic dari pencarian seluler yang koneksinya beragam.

Perlu diluruskan satu hal sejak awal: TTFB bukan Core Web Vital. Core Web Vitals adalah LCP, INP, dan CLS. Namun web.dev menegaskan bahwa TTFB adalah metrik fondasional yang mendahului semua metrik pengalaman pengguna yang bermakna. Mengabaikan TTFB sambil mengoptimasi gambar dan font ibarat memoles cat mobil yang mesinnya tidak mau menyala.

Berapa TTFB yang Bagus? Ambang Resmi Google

Google tidak menetapkan satu angka tunggal yang berlaku untuk semua situs, tetapi web.dev memberi panduan yang jelas dan sudah dipakai luas sebagai patokan:

Penilaian	Nilai TTFB	Artinya
Bagus	0,8 detik atau kurang	Sebagian besar situs sebaiknya menargetkan angka ini
Perlu perbaikan	0,8–1,8 detik	Ada ruang perbaikan yang layak dikejar
Buruk	Di atas 1,8 detik	Pengguna menunggu terlalu lama sebelum melihat apa pun

Ada tiga catatan penting tentang angka-angka ini. Pertama, penilaian memakai persentil ke-75 pengguna nyata, bukan satu kali pengukuran dari laptop Anda. Artinya, 75 persen kunjungan harus berada di bawah ambang tersebut. Satu hasil tes yang bagus dari jaringan kantor tidak cukup; yang penting adalah pengalaman mayoritas pembaca, termasuk yang memakai HP dengan sinyal yang biasa saja.

Kedua, angka ini adalah panduan diagnostik, bukan syarat keras atau jaminan peringkat. Situs dengan TTFB 0,9 detik tidak otomatis kalah dari situs dengan TTFB 0,4 detik bila pengalaman pengguna keseluruhannya sehat. Sebaliknya, TTFB 0,3 detik tidak menyelamatkan situs yang gambarnya berat dan layout-nya bergeser. Gunakan ambang ini untuk menentukan prioritas, bukan sebagai obsesi angka tunggal.

Ketiga, ada satu garis lain yang patut diketahui: audit Lighthouse “Reduce initial server response time” gagal bila waktu respons server melebihi 600 milidetik. Jadi bila Anda menjalankan PageSpeed Insights dan melihat peringatan ini, itu artinya server Anda merespons lebih lambat dari 600 milidetik pada kondisi lab. Angka 600 milidetik ini berbeda dari ambang 0,8 detik di atas karena konteks pengukurannya berbeda — lab versus lapangan — tetapi keduanya menunjuk ke arah yang sama: di bawah satu detik adalah wilayah yang sehat.

Sebagai patokan praktik yang realistis untuk situs WordPress publisher di Indonesia: halaman artikel yang sudah di-cache dengan benar umumnya bisa mencapai TTFB 0,2–0,5 detik dari lokasi yang dekat dengan server, sementara halaman yang harus dibangun dari nol (cache miss) di kisaran 0,5–1 detik masih wajar tergantung kompleksitas tema dan plugin. Angka-angka ini adalah patokan praktik, bukan angka resmi Google, dan hasil aktual Anda akan berbeda tergantung hosting, lokasi pembaca, dan kondisi cache.

Cara Mengukur TTFB dengan Benar

Mengukur TTFB terdengar sederhana, tetapi kesalahan pengukuran adalah penyebab paling umum dari perbaikan yang salah sasaran. Berikut cara yang benar, dari yang paling mudah sampai yang paling teliti.

PageSpeed Insights: data lapangan dan data lab

PageSpeed Insights adalah titik awal yang paling mudah. Masukkan URL artikel Anda, lalu perhatikan dua bagian. Bagian atas, “Discover what your real users are experiencing”, menampilkan data lapangan dari Chrome User Experience Report (CrUX) bila URL tersebut memiliki cukup traffic. Di sinilah Anda melihat TTFB yang dialami pembaca sungguhan. Bagian bawah menampilkan hasil lab, termasuk diagnostik “Reduce initial server response time” bila respons server lambat. Data lapangan lebih penting daripada data lab, tetapi data lab lebih mudah diulang untuk membandingkan sebelum dan sesudah perubahan.

Perlu diingat bahwa data lapangan CrUX hanya tersedia untuk URL dan origin yang memiliki traffic cukup. Situs kecil yang baru mungkin belum memiliki data lapangan, dan itu normal. Dalam kondisi itu, gunakan data lab dan pengukuran manual sambil menunggu traffic terkumpul.

Pengukuran manual dengan curl

Untuk melihat TTFB mentah tanpa pengaruh browser, gunakan perintah curl dari terminal. Perintah berikut menampilkan waktu sampai byte pertama tiba:

curl -o /dev/null -s -w “TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n” https://bangekomedia.com/contoh-artikel/

Jalankan perintah ini beberapa kali dan pada jam yang berbeda, karena satu pengukuran bisa terpengaruh oleh kondisi jaringan sesaat. Ukur juga dengan dan tanpa cache: jalankan sekali untuk halaman yang baru saja dibersihkan cache-nya (cache miss), lalu jalankan lagi segera setelahnya (cache hit). Selisih keduanya memberi tahu Anda berapa besar kontribusi pemrosesan server terhadap TTFB Anda.

Ukur halaman yang tepat

Jangan hanya mengukur halaman depan. Halaman depan sering di-cache lebih agresif dan lebih ringan daripada halaman artikel. Ukurlah halaman artikel biasa yang dibaca pembaca dari pencarian, halaman kategori, dan satu halaman dengan banyak elemen dinamis bila ada. TTFB yang penting adalah TTFB halaman yang menerima traffic, bukan halaman yang paling mudah diukur.

Catat kondisi pengukuran

Setiap kali mengukur, catat empat hal: URL yang diukur, waktu pengukuran, apakah cache sedang hit atau miss, dan dari mana pengukuran dilakukan. Tanpa catatan ini, Anda akan membandingkan angka yang tidak sebanding — misalnya TTFB 0,3 detik dari server di Singapura dengan TTFB 1,2 detik dari jaringan seluler di kota lain — lalu mengambil kesimpulan yang salah.

Peta Penyebab: Di Mana Waktu Anda Habis

Sebelum mengubah apa pun, petakan dulu di mana waktu habis. TTFB adalah jumlah dari beberapa fase, dan setiap fase punya penyebab dan obat yang berbeda:

Fase	Yang terjadi	Penyebab umum pada WordPress	Tanda-tandanya
Redirect	Browser dialihkan ke URL lain	Rantai redirect berlapis, http ke https lalu ke www, redirect plugin yang berlebihan	TTFB tinggi bahkan sebelum server memproses
DNS	Nama domain diterjemahkan ke alamat IP	DNS lambat, TTL terlalu pendek, DNS tanpa Anycast	Keterlambatan konsisten di awal, terlihat di waterfall
Koneksi TCP dan TLS	Saluran aman dibuat ke server	Server jauh dari pembaca, TLS 1.2 tanpa session resumption, handshake berulang	TTFB tinggi dari lokasi jauh, normal dari lokasi dekat
Pemrosesan server	WordPress membangun halaman	Tanpa page cache, PHP lama, query database berat, plugin boros	Selisih besar antara cache hit dan cache miss
Antrean server	Permintaan menunggu giliran	CPU penuh, PHP workers habis, traffic melonjak	TTFB naik pada jam sibuk, normal di jam sepi

Cara paling cepat memetakan penyebab adalah membandingkan TTFB cache hit dan cache miss. Jika cache hit cepat tetapi cache miss lambat, masalahnya ada pada pemrosesan server: PHP, database, atau plugin. Jika keduanya sama-sama lambat, masalahnya ada pada jaringan atau server itu sendiri: lokasi, DNS, atau sumber daya. Jika TTFB naik hanya pada jam sibuk, masalahnya kemungkinan antrean: server kehabisan kapasitas saat traffic naik.

Pengukuran waterfall di tab Network pada DevTools browser juga membantu. Perhatikan segmen “Waiting (TTFB)” pada permintaan dokumen HTML pertama. Jika segmen ini panjang, masalahnya di server. Jika segmen DNS atau SSL yang panjang, masalahnya di jaringan.

Langkah 1: Page Cache — Perbaikan Paling Berdampak

Bagi kebanyakan situs WordPress publisher, page cache adalah satu perubahan dengan dampak terbesar pada TTFB. Alasannya sederhana: tanpa page cache, setiap kunjungan memaksa WordPress menjalankan PHP dan menanyakan database untuk membangun halaman yang sama persis dengan yang sudah dibangun satu menit lalu. Dengan page cache, server cukup mengirim file HTML yang sudah jadi — dan itu bisa sepuluh kali lebih cepat.

Cara kerja page cache

Saat pengunjung pertama membuka sebuah artikel, WordPress membangun halaman tersebut seperti biasa, lalu salinan HTML hasil akhirnya disimpan sebagai file statis. Pengunjung berikutnya yang membuka artikel yang sama menerima file statis itu langsung, tanpa menjalankan PHP dan tanpa menyentuh database. Inilah perbedaan antara cache hit dan cache miss yang dibahas sebelumnya. TTFB cache hit umumnya berada di kisaran ratusan milidetik rendah; TTFB cache miss bisa beberapa detik pada server yang sibuk.

Pilih satu sistem cache, bukan tiga

Kesalahan umum adalah memasang dua atau tiga plugin cache sekaligus dengan harapan hasilnya berlipat. Yang terjadi justru sebaliknya: plugin-plugin itu saling menimpa, aturan .htaccess bentrok, dan debugging menjadi mustahil. Pilih satu plugin page cache yang tepercaya dan pelajari pengaturannya, atau gunakan cache di tingkat server bila hosting Anda menyediakannya (misalnya Nginx FastCGI cache atau Varnish). Cache di tingkat server umumnya lebih cepat karena permintaan tidak perlu sampai ke PHP sama sekali, tetapi pengaturannya membutuhkan akses server dan lebih sulit diubah oleh pemula.

Atur apa yang boleh dan tidak boleh di-cache

Tidak semua halaman boleh di-cache. Halaman yang berisi konten yang berubah per pengunjung — halaman keranjang belanja, halaman akun, halaman checkout, dan halaman admin — tidak boleh disajikan dari cache statis, karena satu pengunjung bisa melihat data pengunjung lain. Plugin cache yang baik sudah memiliki pengecualian bawaan untuk halaman-halaman ini, tetapi periksa daftar pengecualiannya, terutama bila Anda memasang plugin membership, forum, atau toko di kemudian hari. Untuk situs publisher murni berisi artikel, hampir semua halaman depan boleh di-cache dengan aman.

Masa berlaku cache dan pembersihan

Cache yang tidak pernah dibersihkan akan menyajikan artikel lama setelah Anda memperbaruinya. Cache yang dibersihkan terlalu sering akan membuat server bekerja keras terus. Sebagai patokan praktik: atur masa berlaku cache 24 jam untuk artikel yang sudah lama terbit, dan pastikan cache artikel dibersihkan otomatis setiap kali artikel itu diperbarui. Sebagian besar plugin cache melakukan ini secara otomatis; periksa apakah pembersihan otomatis itu benar-benar berjalan dengan menguji: perbarui satu kalimat pada artikel, muat ulang halaman dalam mode penyamaran, dan pastikan perubahan itu terlihat.

Periksa apakah cache benar-benar aktif

Memasang plugin cache tidak sama dengan cache yang aktif. Periksa header respons halaman Anda. Bila Anda melihat header seperti x-cache: HIT atau cf-cache-status: HIT, cache bekerja. Bila selalu MISS atau tidak ada header cache sama sekali, ada sesuatu yang salah — mungkin plugin belum diaktifkan, mungkin ada cookie yang membuat plugin melewatkan cache, atau mungkin aturan server menimpa aturan plugin. Jangan lanjut ke langkah berikutnya sebelum memastikan cache aktif, karena semua pengukuran setelah ini akan menyesatkan bila cache ternyata mati.

Langkah 2: PHP — Versi, OPcache, dan Workers

Setelah page cache, PHP adalah tuas terbesar berikutnya. Setiap cache miss — dan setiap halaman yang memang tidak boleh di-cache — harus melewati PHP. Tiga hal yang perlu diperhatikan: versi PHP, OPcache, dan jumlah workers.

Naikkan versi PHP ke yang direkomendasikan

Halaman persyaratan resmi WordPress.org saat ini merekomendasikan PHP versi 8.3 atau lebih baru, dengan MariaDB 10.11 atau lebih baru atau MySQL 8.0 atau lebih baru, serta HTTPS untuk setiap instalasi. WordPress masih bisa berjalan pada PHP 7.4 dan MySQL 5.5.5, tetapi versi-versi itu sudah mencapai akhir masa dukungan resmi dan dapat membuat situs rentan terhadap masalah keamanan. Pernyataan ini dikutip langsung dari halaman persyaratan WordPress.org yang diperbarui pada 2026.

Praktiknya: sebelum menaikkan versi PHP, periksa kompatibilitas tema dan plugin Anda. Sebagian besar tema dan plugin modern sudah mendukung PHP 8.3, tetapi plugin lama yang tidak dirawat bisa menampilkan error. Cara aman adalah menaikkan versi di situs staging terlebih dahulu, atau menaikkan di jam sepi sambil memantau log error selama 24 jam. Bila hosting Anda memakai panel seperti hPanel atau cPanel, penggantian versi PHP biasanya hanya beberapa klik di menu “PHP Version” atau “Select PHP Version”, dan bisa dikembalikan bila terjadi masalah.

Aktifkan OPcache

OPcache adalah fitur bawaan PHP yang menyimpan hasil kompilasi script PHP di memori, sehingga server tidak perlu mengompilasi ulang file PHP yang sama pada setiap permintaan. Pada situs WordPress dengan puluhan file PHP yang dimuat per halaman, OPcache dapat memangkas waktu pemrosesan server secara signifikan. Di sebagian besar hosting modern, OPcache sudah aktif secara default; periksa melalui menu PHP Info atau Site Health di WordPress (Peralatan → Kesehatan Situs → Info → Server) dan pastikan OPcache tercatat aktif. Bila tidak aktif, mintalah hosting Anda mengaktifkannya — ini adalah pengaturan server, bukan pengaturan WordPress, dan tidak ada plugin yang bisa menggantikannya.

PHP workers: kapasitas antrean Anda

PHP workers adalah jumlah permintaan PHP yang bisa diproses server secara bersamaan. Bila workers habis, permintaan berikutnya harus mengantre — dan antrean itulah yang membuat TTFB melonjak pada jam sibuk. Pada shared hosting, jumlah workers ditentukan oleh paket hosting dan tidak bisa diubah sendiri; pada VPS atau hosting managed, jumlahnya bisa diatur. Sebagai patokan praktik, situs publisher kecil dengan traffic beberapa ribu kunjungan per hari biasanya cukup dengan workers dalam jumlah belasan, tetapi angka yang tepat bergantung pada seberapa cepat setiap permintaan selesai. Workers yang sedikit tetapi permintaan yang cepat sering mengalahkan workers yang banyak tetapi permintaan yang lambat. Karena itu, menaikkan workers tanpa memperbaiki query lambat hanya menunda masalah, bukan menyelesaikannya.

Memory limit PHP

WordPress.org menyebut memory limit 256 MB sebagai patokan yang wajar untuk instalasi modern, dan beberapa panduan hosting mencantumkan angka yang sama. Nilai ini bisa diperiksa di Kesehatan Situs WordPress. Bila memory limit Anda masih 64 MB atau 128 MB dan situs sering menampilkan error kehabisan memori, naikkan ke 256 MB melalui wp-config.php atau pengaturan hosting. Namun perlu diingat: memory limit yang besar bukan obat untuk plugin yang boros memori; ia hanya memberi ruang lebih sebelum error muncul.

Langkah 3: Database — Query Lambat dan Object Cache

Database adalah tempat ketiga waktu hilang. WordPress menyimpan hampir semua hal di database: artikel, komentar, pengaturan, metadata, dan — yang sering dilupakan — transient dan autoloaded options yang dibaca pada setiap permintaan.

Autoloaded options: beban yang dibaca setiap kali

Setiap kali WordPress memuat halaman, ia membaca semua baris di tabel wp_options yang ditandai autoload. Bila total ukurannya membengkak — karena plugin yang menyimpan data besar di options, atau karena data lama dari plugin yang sudah dihapus — setiap permintaan menjadi lebih berat. Periksa ukuran ini lewat plugin Query Monitor atau lewat query langsung ke database. Sebagai patokan praktik, total autoloaded options di bawah 1 MB umumnya sehat; di atas itu layak diselidiki baris mana yang paling besar. Jangan menghapus baris options secara membabi buta: hapus hanya data milik plugin yang sudah tidak terpasang, dan selalu buat backup database sebelum mengubah tabel options.

Transient yang kedaluwarsa dan menumpuk

Transient adalah data sementara yang disimpan WordPress untuk menghindari perhitungan berulang, misalnya hasil panggilan API eksternal. Transient yang sudah kedaluwarsa seharusnya terhapus sendiri, tetapi pada praktiknya banyak yang menumpuk, terutama bila cron WordPress tidak berjalan dengan benar. Pembersihan transient secara berkala — misalnya mingguan — adalah perawatan rutin yang aman, dan sudah dibahas lebih detail pada artikel optimasi database di situs ini.

Query lambat: temukan dulu, baru perbaiki

Jangan menebak query mana yang lambat; ukur. Plugin Query Monitor menampilkan semua query yang dijalankan untuk satu halaman, lengkap dengan waktunya, dan menandai query yang lambat atau yang dipanggil berulang kali. Penyebab klasiknya antara lain: plugin yang menjalankan query tanpa indeks pada kolom yang difilter, widget “artikel populer” yang menghitung dari tabel besar pada setiap muat halaman, dan pencarian internal yang tidak memakai indeks. Perbaikan spesifik bergantung pada temuan: kadang cukup menambahkan indeks, kadang mengganti widget hitung langsung dengan nilai yang di-cache, kadang menonaktifkan fitur plugin yang tidak dipakai.

Object cache: Redis atau Memcached

Page cache menyimpan hasil akhir berupa HTML. Object cache menyimpan hasil antara berupa objek database, sehingga bila sebuah halaman harus dibangun dari nol, sebagian besar datanya sudah tersedia di memori dan tidak perlu ditanyakan lagi ke database. Redis dan Memcached adalah dua layanan object cache yang paling umum. Keduanya membutuhkan layanan yang berjalan di server, jadi ketersediaannya bergantung pada hosting Anda — shared hosting murah sering tidak menyediakannya, sementara VPS dan hosting managed umumnya menyediakan. Object cache paling terasa manfaatnya pada halaman yang memang tidak bisa di-page-cache dan pada situs dengan banyak konten dinamis. Bila situs Anda sudah cepat berkat page cache, object cache adalah penyempurnaan, bukan kebutuhan mendesak.

Langkah 4: Hosting dan Server — Lokasi, Sumber Daya, dan Protokol

Ada batas seberapa cepat sebuah server bisa merespons, dan batas itu ditentukan oleh hosting Anda. Optimasi di tingkat aplikasi tidak akan menyelamatkan server yang sudah kehabisan sumber daya atau terlalu jauh dari pembaca.

Lokasi server dan CDN

Jarak fisik antara server dan pembaca menambah waktu pada setiap fase jaringan. Untuk publisher yang pembacanya mayoritas di Indonesia, server yang berlokasi di Singapura umumnya memberi latensi yang jauh lebih baik daripada server di Amerika atau Eropa, dan ini sudah dibahas pada artikel memilih hosting di situs ini. Bila pembaca Anda tersebar, CDN menjadi penting: CDN menyajikan file statis dari edge server yang dekat dengan pembaca, dan beberapa CDN juga dapat meng-cache HTML sehingga TTFB ikut membaik. Perlu dicatat bahwa CDN tidak memperbaiki pemrosesan server yang lambat — ia hanya memperpendek jarak jaringan. Bila origin server Anda membutuhkan 2 detik untuk membangun halaman, CDN tidak bisa mengubahnya menjadi 0,2 detik.

CPU dan RAM yang cukup

Pada shared hosting, sumber daya CPU dan RAM dibagi dengan situs lain di server yang sama. Pada jam sibuk, tetangga yang boros bisa memperlambat situs Anda — inilah yang sering disebut efek “tetangga berisik”. Tanda-tandanya: TTFB yang berfluktuasi tanpa pola, lambat di jam sibuk tetapi cepat di tengah malam, dan tidak membaik meski cache sudah aktif. Bila pola ini muncul dan traffic Anda sudah konsisten, inilah saatnya mempertimbangkan paket yang lebih tinggi atau pindah ke VPS atau hosting managed. Keputusan ini adalah keputusan bisnis, bukan sekadar teknis: hitung berapa penghasilan iklan yang hilang karena halaman lambat dibuka, lalu bandingkan dengan selisih biaya hosting.

Web server dan protokol modern

WordPress.org merekomendasikan Apache atau Nginx sebagai web server. Nginx umumnya lebih hemat sumber daya untuk melayani banyak koneksi bersamaan, tetapi Apache dengan konfigurasi yang benar juga bisa cepat; yang lebih penting adalah konfigurasi dan sumber dayanya, bukan sekadar nama softwarenya. Di atas itu, pastikan situs memakai HTTP/2 atau HTTP/3 dan TLS versi terbaru yang didukung hosting Anda, serta sertifikat yang valid — HTTPS kini wajib untuk setiap instalasi WordPress menurut halaman persyaratan resminya. Protokol modern mengurangi waktu handshake dan memungkinkan multiplexing, yang membantu TTFB terutama pada koneksi baru.

Early Hints dan 103

Fitur 103 Early Hints memungkinkan server memberi tahu browser tentang sumber daya penting (misalnya stylesheet) sebelum respons utama selesai dibangun. Ini tidak mengurangi TTFB itu sendiri, tetapi dapat mempersingkat waktu sampai konten pertama tampil karena browser bisa mulai mengunduh sumber daya lebih awal. Beberapa CDN dan hosting sudah mendukung Early Hints; bila tersedia, aktifkan dan ukur dampaknya, tetapi jangan menganggapnya pengganti perbaikan server.

Langkah 5: Redirect, DNS, dan Koneksi

Fase jaringan sering dilupakan karena tidak terlihat di dasbor WordPress, tetapi pada situs yang servernya sudah cepat, fase inilah yang tersisa dan membedakan TTFB 0,3 detik dari 0,8 detik.

Singkirkan rantai redirect

Setiap redirect menambah satu putaran penuh permintaan-respons sebelum server sempat memproses halaman yang benar. Rantai yang umum terjadi: http dialihkan ke https, lalu https tanpa www dialihkan ke https dengan www, lalu URL lama dialihkan ke URL baru. Tiga redirect berarti tiga kali waktu jaringan sebelum pemrosesan dimulai. Periksa dengan curl atau alat redirect checker: satu URL artikel seharusnya mencapai tujuan akhirnya dalam maksimal satu redirect. Perbaiki rantai ini di tingkat server atau plugin redirect, dan pastikan aturan redirect di .htaccess atau konfigurasi Nginx tidak saling menimpa.

DNS yang cepat dan stabil

DNS yang lambat menambah waktu di awal setiap kunjungan pertama. Pilih penyedia DNS yang memiliki jaringan Anycast dan latensi rendah dari Indonesia, dan pastikan TTL record Anda tidak terlalu pendek. TTL yang terlalu pendek memaksa resolver menanyakan ulang terlalu sering; TTL yang terlalu panjang membuat perubahan DNS sulit disebarkan. Sebagai patokan praktik, TTL 300 detik untuk record yang sering berubah dan 3600 detik untuk record yang stabil adalah titik awal yang wajar. Bila Anda memakai DNS bawaan registrar yang lambat, memindahkan DNS ke penyedia khusus sering menjadi perbaikan murah dengan dampak nyata.

Jaga koneksi tetap hidup

Pastikan server mengaktifkan HTTP keep-alive, sehingga browser dapat memakai ulang koneksi yang sudah ada untuk permintaan berikutnya, bukan membuka koneksi baru setiap kali. Sebagian besar server modern sudah mengaktifkan ini secara default, tetapi pada beberapa konfigurasi shared hosting, keep-alive dimatikan untuk menghemat sumber daya. Periksa header respons: bila ada Connection: keep-alive, pengaturan ini aktif.

TLS yang efisien

Gunakan TLS 1.3 bila hosting Anda mendukungnya, karena handshake-nya lebih singkat daripada TLS 1.2. Aktifkan juga OCSP stapling dan session resumption bila tersedia. Perbaikan-perbaikan ini masing-masing hanya memangkas puluhan milidetik, tetapi pada koneksi baru dari jaringan seluler, puluhan milidetik itu terasa.

Langkah 6: Plugin dan Tema — Audit Beban per Halaman

Plugin dan tema adalah penyebab paling sering dari TTFB yang lambat pada situs yang hostingnya sebenarnya memadai. Setiap plugin yang aktif menambah kode PHP yang dijalankan, query database yang ditanyakan, atau keduanya — dan banyak plugin memuat kodenya di semua halaman, termasuk halaman yang tidak membutuhkannya.

Audit plugin dengan Query Monitor

Pasang Query Monitor sementara, lalu buka beberapa halaman penting situs Anda: halaman depan, satu artikel, satu halaman kategori. Perhatikan tiga hal: berapa banyak query yang dijalankan, berapa lama total waktu query, dan plugin mana yang paling banyak memanggil fungsi berat. Plugin yang menambahkan 20–30 query pada setiap halaman tanpa alasan jelas adalah kandidat untuk diganti atau dimatikan. Ulangi audit ini setiap kali Anda memasang plugin baru, dan hapus plugin yang sudah tidak dipakai daripada sekadar menonaktifkannya — plugin yang dinonaktifkan tidak membebani, tetapi plugin yang terpasang dan terlupakan sering diaktifkan kembali tanpa sengaja atau menjadi celah keamanan.

Nonaktifkan pemuatan aset yang tidak perlu

Banyak plugin memuat script dan stylesheet di semua halaman, padahal fiturnya hanya dipakai di satu halaman. Beberapa plugin menyediakan pengaturan untuk membatasi pemuatan per halaman; untuk yang lain, Anda bisa memakai plugin asset management untuk menonaktifkan script tertentu di halaman tertentu. Lakukan ini dengan hati-hati: menonaktifkan script yang ternyata dibutuhkan akan merusak fitur. Uji setiap perubahan di staging atau di jam sepi, dan periksa halaman yang bersangkutan setelahnya.

WP-Cron dan Heartbeat API

WordPress menjalankan tugas terjadwal — memeriksa update, mempublikasikan artikel terjadwal, membersihkan data — lewat WP-Cron, yang dipicu oleh kunjungan. Pada situs dengan traffic tinggi, WP-Cron yang berjalan pada setiap kunjungan bisa menambah beban. Solusi yang umum dipakai adalah menonaktifkan WP-Cron bawaan dan menjalankan cron lewat cron job server yang sebenarnya. Demikian pula Heartbeat API, yang membuat permintaan berkala dari editor dan dasbor, bisa dibatasi intervalnya atau dimatikan di halaman depan. Kedua pengaturan ini termasuk perawatan lanjutan: lakukan setelah page cache dan PHP beres, bukan sebagai langkah pertama.

Tema yang ringan dan terawat

Tema yang berat — dengan banyak query kustom, builder yang menghasilkan markup berlapis, dan puluhan file yang dimuat — akan memperlambat setiap cache miss. Bila Anda memakai page builder, periksa apakah builder itu menjalankan query tambahan pada setiap halaman. Tema yang baik untuk publisher adalah tema yang sederhana, diperbarui secara teratur, dan tidak memuat fitur yang tidak dipakai. Mengganti tema adalah pekerjaan besar, jadi jadikan ini pertimbangan saat Anda memang sudah berencana mengganti tema, bukan langkah pertama perbaikan TTFB.

Rencana Perbaikan 7 Hari untuk Publisher

Perbaikan TTFB tidak harus dilakukan sekaligus. Berikut rencana tujuh hari yang memisahkan pekerjaan berisiko rendah dari yang berisiko tinggi, dengan pengukuran di awal dan akhir setiap langkah:

Hari	Pekerjaan	Yang diukur
1	Ukur TTFB baseline: PageSpeed Insights, curl cache hit dan cache miss, catat angkanya	TTFB awal per halaman
2	Pastikan page cache aktif dan benar; periksa header cache, pengecualian halaman dinamis	TTFB cache hit sesudah cache
3	Audit plugin dengan Query Monitor; nonaktifkan atau ganti plugin yang boros	Jumlah query dan waktu query per halaman
4	Bersihkan database: transient kedaluwarsa, revisi lama, autoloaded options yang membengkak; backup dulu	Ukuran autoload, TTFB cache miss
5	Naikkan versi PHP ke 8.3 atau lebih baru (di staging dulu bila memungkinkan); pastikan OPcache aktif	TTFB cache miss sesudah PHP baru
6	Perbaiki redirect berantai, periksa DNS dan keep-alive; aktifkan object cache bila hosting mendukung	TTFB dari lokasi pembaca utama
7	Ukur ulang semua halaman dari Hari 1, bandingkan, dan catat hasilnya; jadwalkan pengukuran ulang bulanan	TTFB akhir dan daftar perubahan

Dua aturan selama rencana ini berjalan. Pertama, buat backup sebelum setiap perubahan yang menyentuh database, PHP, atau konfigurasi server. Kedua, ubah satu hal dalam satu waktu dan ukur sesudahnya. Bila Anda mengubah lima hal sekaligus dan TTFB membaik, Anda tidak tahu perubahan mana yang bekerja — dan bila TTFB memburuk, Anda tidak tahu perubahan mana yang merusaknya.

Contoh Ilustrasi: Dari TTFB 2,4 Detik ke 0,6 Detik

Contoh berikut adalah ilustrasi yang disusun dari pola umum situs publisher kecil, bukan hasil pengukuran situs tertentu. Angka-angkanya dipakai untuk menunjukkan urutan besarnya dampak setiap langkah, bukan sebagai janji hasil.

Sebuah situs berita kecil dengan 60 artikel dan 25 plugin aktif mengeluhkan skor PageSpeed Insights yang buruk. Pengukuran awal menunjukkan TTFB 2,4 detik pada cache miss dan 1,1 detik pada cache hit. Investigasi menemukan tiga masalah: plugin cache terpasang tetapi tidak aktif karena aturan .htaccess tertimpa plugin keamanan, PHP masih versi 7.4, dan satu plugin statistik menjalankan 18 query pada setiap halaman.

Perbaikannya dilakukan berurutan. Hari pertama, aturan cache diperbaiki sehingga cache benar-benar aktif: TTFB cache hit turun ke 0,35 detik. Hari kedua, plugin statistik diganti dengan layanan analitik eksternal: TTFB cache miss turun dari 2,4 detik menjadi 1,5 detik. Hari ketiga, PHP dinaikkan ke 8.3 dan OPcache diaktifkan: TTFB cache miss turun lagi menjadi 0,9 detik. Hari keempat, object cache Redis diaktifkan: TTFB cache miss turun menjadi 0,6 detik. Hasil akhirnya adalah TTFB 0,35 detik untuk halaman yang di-cache dan 0,6 detik untuk halaman yang harus dibangun dari nol — keduanya berada dalam wilayah yang oleh web.dev digolongkan bagus.

Pelajaran dari ilustrasi ini bukan angkanya, melainkan urutannya: cache dulu, lalu kurangi beban, lalu naikkan PHP, lalu object cache. Membalik urutan — misalnya memasang Redis sebelum cache aktif — akan memberi hasil yang jauh lebih kecil dengan usaha yang lebih besar.

Kesalahan Umum Saat Mempercepat TTFB

Kesalahan	Mengapa merugikan	Yang sebaiknya dilakukan
Memasang banyak plugin cache sekaligus	Aturan saling menimpa, debugging mustahil	Satu sistem cache, dipahami pengaturannya
Mengukur hanya sekali dari satu lokasi	Angka tidak mewakili pembaca nyata	Ukur berulang, dari beberapa kondisi, catat cache hit dan miss
Mengejar TTFB di bawah 100 milidetik	Target yang tidak realistis untuk konten dinamis; mengorbankan hal lain	Targetkan wilayah bagus web.dev: 0,8 detik atau kurang
Menonaktifkan semua plugin sekaligus	Sulit mengetahui penyebab bila situs rusak	Nonaktifkan satu per satu, uji setiap perubahan
Meng-cache halaman yang tidak boleh di-cache	Pengunjung melihat data orang lain	Periksa daftar pengecualian cache secara berkala
Menaikkan PHP tanpa memeriksa kompatibilitas	Plugin lama error, situs rusak	Uji di staging atau jam sepi, pantau log error 24 jam
Mengabaikan database sambil menambah cache	Cache menutupi masalah yang tumbuh di bawahnya	Bersihkan transient dan autoload secara berkala
Mengganti hosting sebelum mengoptimasi	Membayar lebih untuk masalah yang sebenarnya ada di aplikasi	Optimasi dulu, pindah hosting bila pola jam sibuk menunjukkan kapasitas habis

Satu kesalahan yang layak ditegaskan: TTFB yang sangat rendah pada halaman yang di-cache tidak berarti situs Anda cepat. Bila cache hit 0,2 detik tetapi cache miss 3 detik, maka setiap artikel baru, setiap halaman yang cache-nya baru dibersihkan, dan setiap pengunjung pertama setelah update akan mengalami kelambatan. Kedua angka itu penting, dan keduanya harus diperbaiki.

FAQ

Apakah TTFB memengaruhi peringkat Google?

TTFB bukan Core Web Vital dan Google tidak pernah menyatakan TTFB sebagai faktor peringkat langsung. Namun TTFB memengaruhi LCP, dan LCP adalah Core Web Vital yang menjadi bagian dari sinyal pengalaman halaman. Selain itu, halaman yang lambat dibuka cenderung membuat pengunjung pergi lebih cepat. Jadi pengaruh TTFB terhadap SEO bersifat tidak langsung tetapi nyata: lewat LCP dan lewat perilaku pembaca.

Berapa TTFB yang wajar untuk shared hosting?

Sebagai patokan praktik, halaman artikel yang di-cache dengan benar pada shared hosting yang sehat umumnya bisa mencapai TTFB 0,3–0,8 detik dari lokasi yang dekat dengan server. Bila TTFB cache hit Anda konsisten di atas 1 detik, ada sesuatu yang salah — mungkin cache tidak aktif, mungkin server kelebihan beban, atau mungkin ada plugin yang memaksa setiap permintaan melewati PHP. Jangan menerima TTFB di atas 1 detik untuk halaman yang di-cache sebagai kondisi normal.

Apakah CDN bisa memperbaiki TTFB?

CDN bisa memperbaiki komponen jaringan dari TTFB, terutama jarak dan waktu koneksi, karena edge server CDN lebih dekat dengan pembaca. Beberapa CDN juga bisa meng-cache HTML sehingga TTFB ikut membaik. Namun CDN tidak bisa memperbaiki pemrosesan server yang lambat: bila origin server membutuhkan 2 detik untuk membangun halaman, CDN hanya akan menyajikan halaman lambat itu dari lokasi yang lebih dekat. Perbaiki origin dulu, lalu tambahkan CDN.

Apakah saya perlu Redis atau Memcached?

Tidak selalu. Bila situs Anda sudah cepat berkat page cache dan sebagian besar halaman disajikan dari cache, object cache memberi manfaat tambahan yang kecil. Object cache paling terasa pada situs dengan banyak konten dinamis, halaman yang tidak bisa di-page-cache, atau traffic tinggi dengan banyak cache miss. Bila hosting Anda menyediakannya, aktifkan dan ukur; bila tidak, jangan memaksakan instalasi sendiri di shared hosting.

Mengapa TTFB saya berbeda antara PageSpeed Insights dan curl?

Karena keduanya mengukur hal yang berbeda. PageSpeed Insights data lab diukur dari lokasi dan kondisi jaringan tertentu dengan throttling yang disimulasikan, sedangkan curl dari server Anda mengukur dari lokasi Anda tanpa throttling. Data lapangan PageSpeed Insights diukur dari pengguna nyata dengan perangkat dan jaringan yang beragam. Perbedaan ini normal; yang penting adalah trennya dan konsistensi pengukuran Anda sendiri dari waktu ke waktu, bukan menyamakan dua alat yang berbeda.

Apakah menaikkan versi PHP aman untuk situs yang sudah berjalan?

Aman bila dilakukan dengan persiapan: periksa kompatibilitas tema dan plugin, buat backup, dan bila memungkinkan uji di staging terlebih dahulu. WordPress.org merekomendasikan PHP 8.3 atau lebih baru, dan sebagian besar tema serta plugin modern sudah mendukungnya. Risiko terbesar berasal dari plugin lama yang tidak dirawat; bila satu plugin terbukti tidak kompatibel, cari penggantinya daripada menahan seluruh situs pada PHP yang sudah mencapai akhir masa dukungan.

Kesimpulan

TTFB adalah waktu tunggu pertama antara klik dan respons, dan ia menentukan seberapa cepat segala hal lain bisa dimulai. Ambang resmi Google dari web.dev memberi target yang jelas: 0,8 detik atau kurang tergolong bagus, 0,8–1,8 detik perlu perbaikan, dan di atas 1,8 detik buruk, dinilai pada persentil ke-75 pengguna nyata. TTFB bukan Core Web Vital, tetapi ia berada di hulu LCP dan FCP, sehingga memperbaikinya adalah cara paling efisien untuk memperbaiki skor kecepatan secara keseluruhan.

Urutan perbaikan yang paling masuk akal bagi publisher WordPress adalah: pastikan page cache aktif dan benar, audit dan kurangi beban plugin, bersihkan database, naikkan PHP ke versi yang direkomendasikan WordPress.org dan aktifkan OPcache, perbaiki redirect dan DNS, lalu pertimbangkan object cache dan peningkatan hosting bila pola jam sibuk menunjukkan kapasitas habis. Ukur sebelum dan sesudah setiap langkah, catat kondisi cache hit dan cache miss, dan jadwalkan pengukuran ulang secara berkala — karena TTFB yang baik hari ini bisa memburuk pelan-pelan seiring bertambahnya plugin, artikel, dan traffic.

Sumber Resmi yang Dirujuk

• web.dev — “Time to First Byte (TTFB)”: definisi TTFB, fase-fase permintaan, ambang bagus 0,8 detik dan buruk di atas 1,8 detik, serta peran persentil ke-75. https://web.dev/articles/ttfb
• web.dev — “Optimize Time to First Byte”: cara mengukur TTFB lewat PageSpeed Insights dan data lapangan CrUX, serta cara-cara optimasi. https://web.dev/articles/optimize-ttfb
• WordPress.org — “Requirements”: PHP versi 8.3 atau lebih baru, MariaDB 10.11 atau lebih baru atau MySQL 8.0 atau lebih baru, HTTPS wajib, serta catatan bahwa PHP 7.4 dan MySQL 5.5.5 masih berjalan tetapi sudah mencapai akhir masa dukungan. https://wordpress.org/about/requirements/
• Google Search Central dan web.dev — Ambang Core Web Vitals: LCP 2,5 detik atau kurang, INP 200 milidetik atau kurang, CLS 0,1 atau kurang, pada persentil ke-75. (Dirujuk dari artikel Core Web Vitals di situs ini; angka yang sama dipakai pada artikel-artikel Teknologi sebelumnya.)