Hosting & performa
Bagaimana kami membuat WordPress cepat: LiteSpeed Enterprise, LSCache, dan Redis per-situs
Permintaan WordPress tercepat adalah yang tidak pernah berjalan — begitulah cara stack kami menjawab sebagian besar kunjungan dari cache sebelum PHP atau MySQL sempat dipanggil, dan artinya bagi Core Web Vitals.
Permintaan tercepat adalah permintaan yang tidak pernah berjalan
Permintaan WordPress standar membutuhkan banyak sumber daya. Server web menyerahkan proses ke PHP, PHP mem-boot WordPress, menjalankan plugin, melakukan kueri ke MySQL puluhan kali, merakit HTML, dan baru setelah itu mengirimkan byte kembali. Pada situs yang sibuk, seluruh proses tersebut terjadi untuk setiap pengunjung, dan di situlah hampir seluruh waktu time-to-first-byte Anda dihabiskan.
Solusi kami adalah memastikan bahwa, untuk sebagian besar kunjungan, hal tersebut tidak terjadi sama sekali. Di seluruh situs yang kami hosting — lebih dari 100.000 situs PBN ditambah managed WordPress utama — sebagian besar tampilan halaman front-end disajikan sebagai halaman penuh yang dirender sebelumnya langsung dari tembolok, tanpa memanggil PHP atau menyentuh database. Sisa dari postingan ini membahas tentang bagaimana lapisan-lapisan yang mewujudkannya saling berpadu, dan di mana masing-masing lapisan membuktikan kelayakannya.
Kerangka pemikiran yang penting adalah ini bukanlah tembolok (cache) pesaing yang harus Anda pilih salah satu. Tembolok halaman penuh, tembolok objek, dan tepi CDN masing-masing menangani kategori permintaan yang berbeda, dan nilainya terletak pada bagaimana mereka saling meneruskan tugas.
LiteSpeed Enterprise + LSCache: lapisan halaman penuh
Setiap situs berjalan di LiteSpeed Enterprise dengan LSCache tingkat server. Ketika respons front-end dapat di-cache, web server menandainya dengan header cache-control dan tag LiteSpeed, dan LiteSpeed menyajikan halaman secara lengkap langsung pada kunjungan berikutnya — tidak ada proses PHP yang dijalankan, tidak ada kueri MySQL yang dikirim. Itu adalah faktor terbesar tunggal pada TTFB WordPress, karena hal tersebut menghilangkan seluruh proses boot aplikasi dari jalur utama.
Karena LSCache berada di dalam server web alih-alih di dalam plugin PHP, cache ini mulai bekerja lebih awal dalam siklus hidup permintaan dan menyimpan halaman dalam bentuk yang dapat langsung dibersihkan oleh server. Pemindai cache menjaga halaman populer tetap hangat, sehingga pengunjung pertama setelah pembersihan tidak harus menanggung waktu untuk membuat ulang halaman tersebut. Hasilnya adalah TTFB yang jauh lebih rendah dan lebih konsisten daripada cache khusus plugin yang dipasang pada tumpukan generik, di mana cache tersebut masih berada di belakang PHP.
Plugin cache tingkat repo kami sudah terpasang sebelumnya dan diperbarui otomatis di setiap situs, yang menghubungkan WordPress ke LSCache secara benar langsung dari kotaknya. Pada origin non-LiteSpeed, plugin ini tidak memancarkan header halaman penuh dan langsung menyingkir, sementara cache objek dan aturan pengecualian terus menjalankan tugasnya—sehingga situs yang dimigrasikan tidak akan pernah tertinggal dalam kondisi rusak dan setengah dikonfigurasi.
Tetap cepat tanpa menyajikan basi: ESI dan pembersihan otomatis yang cerdas
Caching halaman penuh yang agresif memiliki dua mode kegagalan klasik: menyajikan halaman orang lain kepada pengguna yang sedang masuk, dan menyajikan halaman yang seharusnya sudah berubah kepada siapa pun. Keduanya diselesaikan pada lapisan caching daripada dengan mengurangi caching.
ESI (Edge Side Includes) memungkinkan kita untuk melakukan cache pada halaman sekaligus menyisipkan bagian-bagian yang harus tetap aktif. Pada toko WooCommerce, halaman katalog, produk, dan kategori disajikan sebagai cache halaman penuh untuk TTFB tercepat, sementara ESI merender fragmen keranjang, total keranjang mini, dan status akun per permintaan. Keranjang, checkout, akun saya, serta halaman nonce atau sesi apa pun dikecualikan secara default. Pembeli selalu melihat keranjang belanja mereka sendiri dan checkout yang berfungsi; semua orang tetap mendapatkan halaman toko dari cache.
Kesegaran dikelola oleh pembersihan otomatis yang cerdas. Hook pembersihan aktif secara otomatis saat konten, produk, harga, atau pesanan berubah, sehingga halaman cache yang relevan langsung diperbarui alih-alih berdasarkan timer, dan Anda juga dapat melakukan pembersihan sesuai permintaan dari dasbor atau dari dalam WordPress. Pembersihan berbasis tag berarti mengedit satu pos akan menghapus pos tersebut beserta arsipnya—bukan seluruh cache—sehingga satu kali pengeditan tidak melakukan cold-start pada seluruh situs.
Objek cache Redis per-situs: untuk apa yang tidak bisa menjadi halaman penuh
Tidak semua permintaan bisa berupa halaman penuh yang statis. Sesi yang masuk log, admin WordPress, keranjang belanja WooCommerce, pencarian, dan fragmen dinamis yang ditinggalkan oleh ESI semuanya harus menjalankan PHP. Untuk kasus tersebut, tujuannya bergeser dari 'lewati aplikasi' ke 'lewati database'.
Setiap situs mendapatkan cache objek Redis khususnya sendiri. WordPress menyimpan hasil pembacaan database yang berulang secara in-memory — opsi, transient, pencarian post dan term, serta data produk dan sesi WooCommerce — sehingga kueri yang sama tidak perlu dijalankan ke MySQL pada setiap akses. Efeknya paling terlihat persis di area yang tidak dapat dibantu oleh cache halaman penuh: dasbor yang lebih cepat, keranjang belanja yang lebih cepat, dan beban database yang jauh lebih rendah saat lalu lintas padat.
Cache objek bersifat per-situs, tidak dibagikan, yang penting untuk performa dan isolasi. Dikombinasikan dengan pembatasan database per-situs, kueri yang berat atau ditulis secara buruk dari satu situs tidak akan menghabiskan database untuk situs-situs tetangganya. Anda dapat membaca lebih lanjut tentang bagaimana keseluruhan penyiapan multi-lapis ini saling terhubung di halaman fitur cache kami, dan tentang batasan antar penyewa di bawah isolasi.
Edge dan transport di bawahnya
Cache yang berada di origin tetap harus melalui jaringan. Di depan server terdapat edge CDN, sehingga aset statis dan halaman yang dapat di-cache disajikan dari point of presence di dekat pengunjung, dan origin tetap tenang bahkan di bawah beban. Untuk lini hosting footprint-free kami, edge yang sama adalah kumpulan multi-CDN yang tersebar di beberapa penyedia, yang melayani tujuan footprint serta performa; pada WordPress mainstream, ini hanyalah lapisan yang cepat dan berperilaku baik yang menjaga origin tetap idle.
Di balik itu semua, dasar-dasarnya tidak diabaikan. Situs berjalan pada penyimpanan NVMe dengan HTTP/3, sehingga bita yang dikirim oleh tembolok tiba melalui transportasi modern yang dimultipleks dengan penyimpanan cepat di balik setiap kegagalan tembolok (cache miss). Tidak ada satupun lapisan ini yang merupakan tambahan: LiteSpeed, LSCache, Redis per-situs, NVMe, dan HTTP/3 adalah standar dasar pada setiap paket, bukan tingkat penambahan biaya (upsell).
Apa yang sebenarnya menggerakkan Core Web Vitals
Hal ini patut dicermati secara saksama, karena hosting sering kali dijual berlebihan terkait Core Web Vitals. TTFB adalah bagian dari persamaan yang dikendalikan oleh server, dan penumpukan *caching* di atasnyalah yang memangkasnya hingga serendah mungkin — halaman penuh yang di-cache dan disajikan melalui HTTP/3 dari *edge* adalah titik terendah yang dapat dicapai oleh TTFB. Karena TTFB merupakan ujung tombak dari Largest Contentful Paint, *origin* yang cepat memberikan keunggulan awal bagi setiap metrik hilir yang tidak mungkin didapatkan dengan cara lain.
Namun LCP, CLS, dan INP sebagian besar ditentukan di dalam browser, oleh halaman itu sendiri: gambar utama yang tidak dioptimalkan, CSS dan JavaScript yang menghambat rendering, tata letak yang bergeser saat fon dan iklan dimuat, serta kerja utas utama yang berat dari plugin. Seberapa banyak cache server pun tidak akan memperbaiki gambar utama 2 MB atau tema yang memuat megabita JavaScript. Hosting yang jujur membuat kontribusi server menjadi sangat murah dan konsisten, selanjutnya tugas situs web-lah untuk menjaga agar bagian depan tetap ringan.
Pembagian tugas tersebut adalah model mental yang berguna. Kami menjamin permintaan sampai ke peramban dengan cepat dan tetap cepat di bawah lalu lintas tinggi; Anda menjaga muatan data tetap kecil dan stabil. Titik temu keduanya — pemanasan tembolok, pengiriman tepi, dan menjaga basis data tetap responsif agar halaman dinamis tidak tersendat — adalah tepat di mana tumpukan teknologi kami disetel, dan itulah yang membuat WordPress terkelola di platform ini lebih cepat daripada situs yang sama di hos generik.
Pertanyaan yang sering diajukan
Apakah saya masih memerlukan plugin cache seperti WP Rocket?
Caching halaman penuh ditangani di server web oleh LSCache dari LiteSpeed, dan plugin cache kami sendiri — yang telah terinstal sebelumnya dan diperbarui secara otomatis — menghubungkan WordPress ke cache tersebut dengan benar, didukung oleh cache objek Redis per situs di belakangnya. Menumpuk plugin caching halaman penuh kedua di atasnya biasanya akan berbenturan dengan cache tingkat server alih-alih membantu, sehingga hal tersebut tidak diperlukan dan tidak disarankan.
Apakah caching akan merusak keranjang WooCommerce atau halaman masuk saya?
Tidak. Keranjang, *checkout*, akun saya, serta halaman *nonce* atau sesi apa pun dikecualikan dari tembolok secara default, dan ESI menjaga agar fragmen keranjang serta total tetap aktif pada halaman yang ada dalam tembolok. Pembeli selalu dapat melihat keranjang mereka sendiri dan proses *checkout* yang berfungsi sementara halaman toko tetap dimuat dari tembolok.
Bagaimana cache tetap diperbarui saat saya memublikasikan atau mengedit?
Pembersihan otomatis cerdas berjalan pada hook WordPress yang relevan, sehingga mempublikasikan, mengedit konten, atau mengubah produk, harga, atau pesanan akan menghapus halaman yang terdampak saja beserta arsipnya—bukan seluruh cache—dan crawler akan memuatnya kembali. Anda juga dapat melakukan pembersihan sesuai permintaan dari dasbor atau dari dalam WordPress.
Bisakah hosting saja memberi saya Core Web Vitals yang sempurna?
Fitur ini memberikan TTFB terbaik yang mungkin, yaitu bagian dari server dan keunggulan awal untuk Largest Contentful Paint. Namun, LCP, CLS, dan INP sebagian besar ditentukan oleh halaman itu sendiri — ukuran gambar, aset yang memblokir rendering, stabilitas tata letak, dan JavaScript utas utama. Stack kami membuat kontribusi server menjadi cepat dan konsisten; menjaga payload front-end tetap ringan adalah cara untuk menutupi sisa kesenjangan tersebut.
Terkait
Coba gratis selama 14 hari
Buat situs pertamamu secara gratis selama 14 hari — tanpa kartu. Memindahkan jaringan yang sudah ada? Migrasi pertamamu gratis dari kami.
Mulai gratis