Hosting & performa
Cara kami membuat WordPress cepat: LiteSpeed Enterprise, LSCache, dan Redis per situs
Permintaan WordPress tercepat adalah permintaan yang tidak pernah dijalankan — berikut adalah cara tumpukan kami merespons sebagian besar kunjungan dari cache sebelum PHP atau MySQL dipanggil, dan apa artinya bagi Core Web Vitals.
Permintaan tercepat adalah permintaan yang tidak pernah dijalankan
Permintaan WordPress standar membutuhkan banyak sumber daya. Server web meneruskannya ke PHP, PHP menjalankan WordPress, mengeksekusi plugin, mengueri MySQL beberapa lusin kali, menyusun HTML, dan baru kemudian mengirimkan kembali data bita. Pada situs yang sibuk, seluruh proses ini terjadi untuk setiap pengunjung, dan di sinilah hampir semua time-to-first-byte Anda terbuang.
Jawaban kami adalah memastikan bahwa, untuk sebagian besar kunjungan, tidak ada satu pun dari hal tersebut yang terjadi. Di seluruh situs yang kami kelola — lebih dari 100.000 situs PBN ditambah WordPress terkelola arus utama — sebagian besar tampilan halaman front-end disajikan sebagai halaman penuh yang telah dirender sebelumnya langsung dari cache, tanpa memanggil PHP atau menyentuh basis data. Sisa tulisan ini membahas tentang bagaimana lapisan-lapisan yang mewujudkannya saling terhubung, dan mengapa masing-masing lapisan memiliki peran penting.
Hal penting yang perlu dipahami adalah bahwa ini bukanlah jenis cache yang saling bersaing untuk Anda pilih salah satunya. Cache seluruh halaman, cache objek, dan CDN edge masing-masing menangani jenis permintaan yang berbeda, dan nilai utamanya terletak pada bagaimana ketiganya saling meneruskan proses satu sama lain.
LiteSpeed Enterprise + LSCache: lapisan satu halaman penuh
Setiap situs berjalan di LiteSpeed Enterprise dengan LSCache tingkat server. Ketika respons front-end dapat di-cache, server web menandainya dengan header kontrol cache dan tag LiteSpeed, dan LiteSpeed menyajikan halaman lengkap secara langsung pada kunjungan berikutnya — tidak ada proses PHP yang dimuat, tidak ada kueri MySQL yang dijalankan. Ini adalah pengungkit tunggal terbesar untuk TTFB WordPress, karena menghapus seluruh booting aplikasi dari jalur utama.
Karena LSCache berada di dalam server web dan bukan di dalam plugin PHP, sistem ini mulai bekerja lebih awal dalam siklus proses permintaan dan menyimpan halaman dalam format yang dapat dihapus seketika oleh server. Perayap cache menjaga halaman-halaman populer tetap siap diakses, sehingga pengunjung pertama setelah pembersihan cache tidak perlu menanggung waktu tunggu pembuatan ulang halaman. Hasilnya adalah TTFB yang jauh lebih rendah dan lebih konsisten dibandingkan cache berbasis plugin saja yang ditambahkan pada konfigurasi umum, yang mana cache tersebut masih berada di belakang PHP.
Plugin cache tingkat repo kami hadir dalam kondisi telah terinstal dan diperbarui secara otomatis di setiap situs, menghubungkan WordPress ke LSCache dengan benar sejak awal. Pada server asal non-LiteSpeed, plugin ini tidak memunculkan header halaman penuh dan tidak mengganggu alur kerja, sementara cache objek dan aturan pengecualian tetap berjalan sebagaimana mestinya — sehingga situs yang dimigrasikan tidak akan pernah tertinggal dalam kondisi rusak atau setengah terkonfigurasi.
Tetap cepat tanpa menyajikan konten kedaluwarsa: ESI dan pembersihan otomatis cerdas
Caching satu halaman penuh yang agresif memiliki dua mode kegagalan klasik: menyajikan halaman milik orang lain kepada pengguna yang sedang masuk, dan menyajikan halaman yang seharusnya sudah berubah kepada siapa pun. Keduanya diselesaikan pada lapisan caching alih-alih dengan mengurangi caching.
ESI (Edge Side Includes) memungkinkan kami melakukan cache pada halaman sembari membuat celah untuk bagian-bagian yang harus tetap dinamis. Pada toko WooCommerce, halaman katalog, produk, dan kategori disajikan sebagai cache halaman penuh untuk TTFB secepat mungkin, sementara ESI merender fragmen keranjang, total keranjang mini, dan status akun per permintaan. Halaman keranjang, checkout, akun saya, serta halaman nonce atau sesi apa pun dikecualikan secara default. Pembeli selalu melihat keranjang mereka sendiri dan proses checkout yang berfungsi; semua orang tetap mendapatkan tampilan etalase dari cache.
Kesegaran konten ditangani oleh pembersihan otomatis pintar. Kait pembersihan dipicu secara otomatis saat konten, produk, harga, atau pesanan berubah, sehingga halaman cache yang relevan langsung diperbarui alih-alih berdasarkan pengatur waktu, dan Anda juga dapat melakukan pembersihan sesuai kebutuhan dari dasbor atau dari dalam WordPress. Pembersihan berbasis tag berarti mengedit satu kiriman hanya akan membersihkan kiriman tersebut dan arsipnya — bukan seluruh cache — sehingga satu pengeditan tidak memicu cold-start pada seluruh situs.
Cache objek Redis per situs: untuk konten yang tidak dapat menjadi halaman penuh
Tidak setiap permintaan dapat berupa halaman penuh statis. Sesi yang masuk, admin WordPress, keranjang WooCommerce, pencarian, dan fragmen dinamis yang dibiarkan aktif oleh ESI semuanya harus menjalankan PHP. Untuk itu, tujuannya bergeser dari 'lewati aplikasi' menjadi 'lewati basis data'.
Setiap situs mendapatkan cache objek Redis khusus tersendiri. WordPress menyimpan hasil pembacaan database yang berulang — opsi, transien, pencarian postingan dan istilah, data produk dan sesi WooCommerce — di dalam memori, sehingga kueri yang sama tidak dijalankan ke MySQL pada setiap kunjungan. Efeknya paling terlihat justru di tempat cache halaman penuh tidak dapat membantu: dasbor yang lebih cepat, keranjang belanja yang lebih responsif, dan beban database yang jauh lebih rendah saat lalu lintas tinggi.
Cache objek bersifat per situs dan tidak dibagikan, yang penting untuk performa sekaligus isolasi. Dikombinasikan dengan pembatasan basis data per situs, kueri yang berat atau dibuat dengan buruk dari satu situs tidak akan menghabiskan sumber daya basis data untuk situs di sekitarnya. Anda dapat membaca lebih lanjut tentang bagaimana seluruh konfigurasi berlapis ini bekerja bersama pada halaman fitur caching kami, serta batas-batas antar tenant pada bagian isolasi.
Edge dan transportasi di bawahnya
Cache yang berada di server asal (origin) masih harus melintasi 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 server asal tetap tenang bahkan saat beban tinggi. Untuk lini hosting bebas-footprint kami, edge yang sama merupakan kumpulan multi-CDN yang tersebar di beberapa penyedia, yang berfungsi untuk tujuan footprint sekaligus performa; pada WordPress arus utama, ini hanyalah lapisan yang cepat dan terkelola dengan baik yang menjaga server asal tetap idle.
Di balik layar, hal-hal mendasar tidak dikurangi. Situs berjalan di penyimpanan NVMe dengan HTTP/3, sehingga bita yang dikirimkan oleh cache tiba melalui transportasi modern yang termultipleks dengan penyimpanan cepat di balik setiap cache miss. Tak satu pun dari lapisan ini merupakan add-on: LiteSpeed, LSCache, Redis per situs, NVMe, dan HTTP/3 adalah standar dasar pada setiap paket, bukan tingkatan upsell.
Apa yang benar-benar memengaruhi Core Web Vitals
Perlu diperjelas secara tepat, karena hosting sering kali dipasarkan secara berlebihan terkait Core Web Vitals. TTFB adalah bagian dari persamaan yang dikontrol oleh server, dan susunan caching di atas adalah faktor yang menurunkannya — halaman lengkap yang di-cache dan disajikan melalui HTTP/3 dari edge merupakan performa TTFB serendah mungkin. Karena TTFB merupakan tahap awal dari Largest Contentful Paint, origin yang cepat memberikan setiap metrik downstream keunggulan awal yang tidak dapat diperoleh dengan cara lain.
Namun LCP, CLS, dan INP sebagian besar ditentukan di peramban, oleh halaman itu sendiri: gambar hero yang belum dioptimalkan, CSS dan JavaScript yang memblokir perenderan, tata letak yang bergeser saat font dan iklan dimuat, serta beban kerja utas utama yang berat dari plugin. Sebanyak apa pun caching server tidak akan memperbaiki gambar hero berukuran 2 MB atau tema yang memuat megabita JavaScript. Hosting yang jujur membuat kontribusi server praktis gratis dan konsisten, kemudian menjadi tanggung jawab situs untuk menjaga front end tetap ramping.
Pembagian tugas tersebut merupakan model mental yang berguna. Kami menjamin permintaan mencapai peramban dengan cepat dan tetap cepat dalam kondisi lalu lintas padat; Anda menjaga ukuran payload tetap kecil dan stabil. Titik temu keduanya — pemanasan cache, pengiriman edge, dan menjaga responsivitas basis data agar halaman dinamis tidak terhenti — adalah tepat di mana tumpukan sistem kami dioptimalkan, dan itulah yang membuat managed WordPress di platform ini lebih cepat dibandingkan situs yang sama pada hosting generik.
Pertanyaan yang sering diajukan
Apakah saya masih memerlukan plugin caching seperti WP Rocket?
Tidak. Caching halaman penuh ditangani di server web oleh LSCache milik LiteSpeed, dan plugin cache kami sendiri — yang sudah terpasang sebelumnya dan diperbarui secara otomatis — menghubungkan WordPress ke sana dengan benar, didukung oleh cache objek Redis per situs di belakangnya. Menumpuk plugin caching halaman penuh kedua di atasnya biasanya justru berbenturan dengan cache tingkat server alih-alih membantu, sehingga tidak diperlukan dan tidak disarankan.
Apakah penembolokan (caching) akan merusak keranjang WooCommerce atau halaman yang memerlukan proses masuk saya?
Tidak. Keranjang, checkout, my-account, serta halaman nonce atau sesi apa pun dikecualikan dari cache secara default, dan ESI menjaga fragmen keranjang serta total belanja tetap aktif di halaman yang dicache. Pembeli selalu melihat keranjang mereka sendiri dan proses checkout yang berfungsi sementara etalase toko tetap dimuat dari cache.
Bagaimana cache tetap baru saat saya memublikasikan atau mengedit?
Pembersihan otomatis cerdas terpicu pada hook WordPress yang relevan, sehingga memublikasikan, mengedit konten, atau mengubah produk, harga, atau pesanan hanya membersihkan halaman yang terdampak beserta arsipnya — bukan seluruh cache — dan perayap akan menghangatkannya kembali. Anda juga dapat melakukan pembersihan sesuai kebutuhan dari dasbor atau dari dalam WordPress.
Bisakah hosting saja memberi saya Core Web Vitals yang sempurna?
Ini memberi Anda TTFB terbaik, yang merupakan bagian server dan awal yang baik 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 pada thread utama. Tumpukan teknologi kami membuat kontribusi server menjadi cepat dan konsisten; menjaga beban front-end tetap ringan adalah hal yang menutup sisa celah tersebut.
Terkait
Coba gratis selama 14 hari
Jalankan situs pertama Anda secara gratis selama 14 hari — tanpa kartu. Memindahkan jaringan yang sudah ada? Migrasi gratis, tanpa batas.
Mulai gratis