Pengehosan & prestasi
Cara kami mempercepat WordPress: LiteSpeed Enterprise, LSCache dan Redis setiap tapak
Permintaan WordPress yang paling pantas ialah permintaan yang tidak pernah berjalan — berikut ialah cara tindanan kami menjawab kebanyakan lawatan daripada cache sebelum PHP atau MySQL dipanggil, dan maksudnya untuk Core Web Vitals.
Permintaan paling pantas ialah permintaan yang tidak pernah dijalankan
Permintaan WordPress standard adalah mahal. Pelayan web menyerahkan tugas kepada PHP, PHP memulakan WordPress, menjalankan palam (plugin), membuat pertanyaan kepada MySQL beberapa dozen kali, menghimpunkan HTML, dan hanya selepas itu menghantar semula bait. Pada sesebuah tapak yang sesak, keseluruhan proses itu berlaku untuk setiap pelawat, dan di situlah hampir keseluruhan masa-ke-bait-pertama anda dihabiskan.
Penyelesaian kami adalah memastikan bahawa, untuk kebanyakan lawatan, tiada satu pun daripada itu berlaku. Merentasi tapak yang kami hoskan — lebih 100,000 tapak PBN berserta WordPress terurus arus perdana — sebahagian besar paparan halaman bahagian hadapan disajikan sebagai halaman penuh prasekolahnya terus daripada cache, tanpa memanggil PHP atau menyentuh pangkalan data. Selebihnya hantaran ini adalah mengenai cara lapisan yang membolehkan perkara tersebut digabungkan, dan tempat setiap lapisan memainkan peranannya.
Kerangka pentingnya ialah ini bukanlah cache bersaing yang boleh anda pilih. Cache halaman penuh, cache objek dan tepi CDN masing-masing menangkap kelas permintaan yang berbeza, dan nilainya terletak pada cara ia menyerahkan tugas antara satu sama lain.
LiteSpeed Enterprise + LSCache: lapisan halaman penuh
Setiap tapak web berjalan di atas LiteSpeed Enterprise dengan LSCache peringkat pelayan. Apabila tindak balas bahagian hadapan boleh didenda, pelayan web mengecapnya dengan kawalan cache dan pengepala tag LiteSpeed, dan LiteSpeed menyampaikan keseluruhan halaman secara terus pada hit seterusnya — tiada proses PHP dicambahkan, tiada pertanyaan MySQL dikeluarkan. Itu adalah tuil terbesar tunggal pada TTFB WordPress, kerana ia mengalih keluar keseluruhan but aplikasi daripada laluan panas.
Kerana LSCache wujud di dalam pelayan web dan bukannya dalam plugin PHP, ia mula berfungsi lebih awal dalam kitaran hayat permintaan dan menyimpan halaman dalam bentuk yang boleh dibilas serta-merta oleh pelayan. Pengangkak cache memastikan halaman popular sentiasa panas, jadi pelawat pertama selepas pembersihan bukanlah orang yang menanggung kos untuk menjana semula halaman tersebut. Hasilnya ialah TTFB yang jauh lebih rendah dan lebih konsisten berbanding cache berasaskan plugin semata-mata yang dipasang pada tindanan generik, di mana cache tersebut masih berada di belakang PHP.
Plugin cache peringkat repo kami dipratonton dan dikemas kini secara automatik pada setiap tapak, menyambungkan WordPress ke LSCache dengan betul sejak mula. Pada asal bukan LiteSpeed, ia sekadar tidak mengeluarkan pengecas halaman penuh dan terus berfungsi, manakala cache objek dan peraturan pengecualian terus berjalan — jadi tapak yang dimigrasikan tidak akan ditinggalkan dalam keadaan separa konfigurasinya rosak.
Kekal pantas tanpa menyajikan data lapuk: ESI dan pembersihan auto pintar
Caching halaman penuh yang agresif mempunyai dua mod kegagalan klasik: menyampaikan halaman orang lain kepada pengguna yang telah log masuk, dan menyampaikan halaman yang sepatutnya berubah kepada sesiapa sahaja. Kedua-duanya diselesaikan pada lapisan pengecapan imbasan dan bukannya dengan mengurangkan pengecapan.
ESI (Edge Side Includes) membolehkan kami mengehoskan cache halaman sambil menyediakan ruang untuk bahagian yang mesti kekal aktif. Pada kedai WooCommerce, halaman katalog, produk dan kategori disajikan sebagai cache halaman penuh untuk TTFB yang paling pantas, manakala ESI merender fragmen troli, jumlah mini-troli dan status akaun bagi setiap permintaan. Troli, pembayaran, akaun-saya dan sebarang halaman nonce atau sesi dikecualikan secara lalai. Pembeli sentiasa melihat bakul mereka sendiri dan proses pembayaran yang berfungsi; semua orang tetap mendapat storefront daripada cache.
Kesegaran diuruskan oleh pembersihan auto pintar. Cekelan pembersihan dicetuskan secara automatik apabila kandungan, produk, harga atau pesanan berubah, supaya halaman yang di-cache yang berkaitan disegarkan serta-merta dan bukannya pada pemasa, dan anda juga boleh membersihkan atas permintaan dari papan pemuka atau dari dalam WordPress. Pembersihan berasaskan tag bermaksud mengedit satu hantaran akan mengosongkan hantaran tersebut dan arkibnya — bukan keseluruhan cache — jadi satu suncatan tunggal tidak memulakan sejuk seluruh tapak.
Objek cache Redis setiap tapak: untuk apa yang tidak boleh menjadi halaman penuh
Tidak setiap permintaan boleh menjadi halaman penuh statik. Sesi log masuk, pentadbir WordPress, troli WooCommerce, carian, dan serpihan dinamik yang ditinggalkan oleh ESI semuanya perlu menjalankan PHP. Untuk kes tersebut, matlamatnya beralih daripada 'melangkau aplikasi' kepada 'melangkau pangkalan data'.
Setiap tapak web mendapat cache objek Redis khusus sendiri. WordPress menyimpan cache hasil bacaan pangkalan data yang berulang — pilihan, transient, carian hantaran dan terma, produk WooCommerce serta data sesi — dalam memori, supaya pertanyaan yang sama tidak dijalankan pada MySQL setiap kali ia dicapai. Kesannya paling ketara tepat pada bahagian yang tidak dapat dibantu oleh cache halaman penuh: papan pemuka yang lebih pantas, troli yang lebih pantas dan beban pangkalan data yang jauh lebih rendah ketika trafik sesak.
Cache objek adalah khusus untuk setiap tapak, bukan dikongsi bersama, yang penting untuk prestasi dan pengasingan. Digabungkan dengan pendikatan pangkalan data setiap tapak, pertanyaan yang berat atau ditulis dengan buruk oleh satu tapak tidak boleh melumpuhkan pangkalan data untuk tapak-tapak jirannya. Anda boleh membaca lebih lanjut tentang cara keseluruhan persediaan berbilang lapisan ini digabungkan pada halaman ciri pengecapan kami, dan tentang batasan antara penyewa di bawah pengasingan.
Tepi dan pengangkutan di bawahnya
Cache yang berada di pelayan asal masih perlu merentasi rangkaian. Di hadapan pelayan terletak pinggir CDN, jadi aset statik dan halaman boleh cache disajikan dari titik kehadiran berhampiran pelawat, dan pelayan asal kekal senyap walaupun di bawah beban. Untuk barisan hos bebas footprint kami, pinggir yang sama ialah kumpulan multi-CDN yang merentasi beberapa pembekal, yang memenuhi matlamat footprint serta prestasi; pada WordPress arus perdana, ia hanyalah lapisan yang pantas dan berfungsi baik yang memastikan pelayan asal melahu.
Di bawahnya, aspek asas tidak diabaikan. Tapak web berjalan pada storan NVMe dengan HTTP/3, jadi bait yang dihantar oleh cache tiba melalui pengangkutan moden yang dimultiplekskan dengan storan pantas di sebalik sebarang miss cache. Tiada satu pun daripada lapisan ini merupakan add-on: LiteSpeed, LSCache, Redis setiap tapak, NVMe dan HTTP/3 adalah asas pada setiap pelan, bukannya peringkat tambah nilai.
Apa yang sebenarnya menggerakkan Core Web Vitals
Adalah wajar untuk bersikap teliti, kerana pengehosan sering kali dijual berlebihan pada Core Web Vitals. TTFB ialah bahagian persamaan yang dikuasai oleh pelayan, dan tindanan caching di atas ialah perkara yang memacunya turun — halaman penuh yang dicaj disajikan melalui HTTP/3 dari edge adalah serendah TTFB yang boleh dicapai. Oleh kerana TTFB ialah bahagian hadapan Largest Contentful Paint, origin yang pantas memberikan setiap metrik hiliran permulaan awal yang tidak mungkin diperolehi dengan cara lain.
Tetapi LCP, CLS dan INP kebanyakannya ditentukan dalam pelayar, oleh halaman itu sendiri: imej utama yang tidak dioptimumkan, CSS dan JavaScript yang menyekat paparan, susun atur yang beralih semasa fon dan iklan dimuatkan, serta kerja benang utama yang berat daripada pelagak. Tiada jumlah pengecilan pelayan yang dapat membetulkan imej utama bersaiz 2 MB atau tema yang menghantar megabait JavaScript. Pengehosan jujur menjadikan sumbangan pelayan benar-benar percuma dan konsisten, kemudian tugas laman web pula untuk memastikan bahagian hadapan kekal ringkas.
Pembahagian tugas itu adalah model mental yang berguna. Kami menjamin permintaan sampai ke pelayar dengan pantas dan kekal pantas di bawah trafik; anda pastikan muatan kecil dan stabil. Tempat bertemunya kedua-dua perkara itu — pemanasan cache, penghantaran edge, dan memastikan pangkalan data responsif supaya halaman dinamik tidak tergendala — adalah tepat di mana tindanan kami ditala, dan itulah yang menjadikan WordPress terurus pada platform ini lebih pantas berbanding tapak yang sama pada hos generik.
Soalan lazim
Adakah saya masih memerlukan palam masuk pencacatan seperti WP Rocket?
Tidak. Pengecasan halaman penuh dikendalikan pada pelayan web oleh LSCache daripada LiteSpeed, dan palam masuk cache kami sendiri — diprapasang dan dikemas kini secara automatik — menyambungkan WordPress kepadanya dengan betul, beserta cache objek Redis setiap tapak di belakangnya. Menindan palam masuk pengecasan halaman penuh yang kedua di atasnya biasanya akan bertentangan dengan cache peringkat pelayan dan bukannya membantu, jadi ia tidak diperlukan dan tidak disyorkan.
Adakah caching akan merosakkan troli WooCommerce atau halaman log masuk saya?
No. Cart, checkout, my-account dan sebarang halaman nonce atau sesi dikecualikan daripada cache secara lalai, dan ESI memastikan fragmen troli dan jumlah kekal aktif pada halaman yang dicache. Pembeli sentiasa melihat bakul mereka sendiri dan pembayaran yang berfungsi semasa storefront masih dimuatkan daripada cache.
Bagaimanakah cache kekal segar apabila saya menerbitkan atau mengedit?
Pembersihan auto pintar dicetuskan pada cangkuk WordPress yang berkaitan, jadi menerbitkan, mengedit kandungan, atau menukar produk, harga atau pesanan hanya mengosongkan halaman yang terjejas dan arkibnya — bukan keseluruhan cache — dan perangkak memanaskannya semula. Anda juga boleh membersihkan atas permintaan dari papan pemuka atau dari dalam WordPress.
Bolehkah pengehosan sahaja memberi saya Core Web Vitals yang sempurna?
Ia memberikan anda TTFB yang terbaik, iaitu sumbangan pelayan dan permulaan pantas untuk Largest Contentful Paint. Tetapi LCP, CLS dan INP sebahagian besar ditentukan oleh halaman itu sendiri — saiz imej, aset menyekat paparan, kestabilan susun atur dan JavaScript benang utama. Bertih teknologi kami menjadikan sumbangan pelayan pantas dan konsisten; mengekalkan beban muatan bahagian hadapan yang ringan adalah cara untuk merapatkan baki jurang tersebut.
Berkaitan
Cuba percuma selama 14 hari
Lancarkan tapak web pertama anda secara percuma selama 14 hari — tanpa kad. Memindahkan rangkaian sedia ada? Migrasi pertama anda adalah percuma daripada kami.
Mula secara percuma