Pagpaphosting at pagganap
Paano namin pinapabilis ang WordPress: LiteSpeed Enterprise, LSCache at per-site Redis
Ang pinakamabilis na kahilingan sa WordPress ay ang hindi kailanman tumatakbo — narito kung paano sinasagot ng aming stack ang karamihan sa mga pagbisita mula sa cache bago pa man ma-invoke ang PHP o MySQL, at kung ano ang ibig sabihin nito para sa Core Web Vitals.
Ang pinakamabilis na hiling ay ang hindi kailanman tumatakbo
Ang karaniwang kahilingan sa WordPress ay mabigat. Ibinibigay ng web server sa PHP, pinaandar ng PHP ang WordPress, pinatatakbo ang mga plugin, nagtatanong sa MySQL nang ilang dosenang beses, binubuo ang HTML, at saka lamang nagpapadala ng mga byte pabalik. Sa isang abalang site, nangyayari ang buong sayaw na iyon para sa bawat bisita, at dito napupunta ang halos lahat ng iyong time-to-first-byte.
Ang aming solusyon ay tiyakin na, sa karamihan ng mga pagbisita, wala sa mga ito ang mangyayari. Sa kabuuan ng mga site na aming hinohost — mahigit 100,000 PBN site kasama ang pangunahing managed WordPress — ang malaking mayorya ng mga front-end page view ay sineserbisyuhan bilang isang pre-rendered na buong pahina direkta mula sa cache, nang hindi nagpapatawag ng PHP o humahipo sa database. Ang natitirang bahagi ng post na ito ay tungkol sa kung paano nagsasama-sama ang mga layer na nagiging dahilan nito, at kung saan nagiging kapaki-pakinabang ang bawat isa.
Ang mahalagang balangkas ay ang mga ito ay hindi naglalabanang mga cache na pagpipilian mo lang. Ang full-page cache, object cache, at ang CDN edge ay bawat isa ay sumasalo ng iba't ibang klase ng kahilingan, at ang halaga ay nakasalalay sa kung paano nila ipinapasa ang isa't isa.
LiteSpeed Enterprise + LSCache: ang full-page layer
Ang bawat site ay tumatakbo sa LiteSpeed Enterprise na may server-level na LSCache. Kapag ang isang front-end na tugon ay nahihimod, tinatatakan ito ng web server ng mga LiteSpeed cache-control at tag header, at direktang inihahain ng LiteSpeed ang kumpletong pahina sa susunod na hit — walang proseso ng PHP na pinapagana, walang query sa MySQL na inilalabas. Iyon ang pinakamalaking salik sa WordPress TTFB, dahil tinatanggal nito ang buong application boot mula sa hot path.
Dahil ang LSCache ay nasa loob ng web server kaysa sa isang PHP plugin, nagsisimula itong gumana nang mas maaga sa request lifecycle at nag-iimbak ng mga pahina sa anyong madaling mai-flush ng server agad-agad. Pinapanatiling mainit ng isang cache crawler ang mga sikat na pahina, kaya ang unang bisita pagkatapos ng purge ay hindi ang magbabayad para buuin muli ang pahina. Ang resulta ay kapansin-pansing mas mababa at mas pare-parehong TTFB kaysa sa cache na plugin-only lamang na nakadikit sa isang generic stack, kung saan ang cache ay nasa likod pa rin ng PHP.
Ang aming sariling repo-grade cache plugin ay pre-installed at awtomatikong ina-update sa bawat site, na nagkokonekta sa WordPress sa LSCache nang tama agad pagka-install. Sa isang non-LiteSpeed origin, hindi lamang ito naglalabas ng mga full-page header at umiiwas ito, habang patuloy na gumagana ang object cache at exclusion rules — kaya ang isang nailipat na site ay hindi kailanman naiiwan sa sira at kalahating naka-configure na estado.
Pananatiling mabilis nang hindi nagsisilbi ng luma: ESI at matalinong auto-purge
Ang agresibong full-page caching ay may dalawang klasikong uri ng pagkabigo: ang pagpapakita sa naka-log in na user ng pahina ng iba, at ang pagpapakita sa sinuman ng pahinang dapat ay nagbago na. Ang parehong ito ay nalulutas sa caching layer sa halip na bawasan ang pag-cache.
Ang ESI (Edge Side Includes) ay nagbibigay-daan sa amin na i-cache ang pahina habang lumilikha ng mga butas para sa mga bahaging dapat manatiling live. Sa isang tindahan ng WooCommerce, ang katalogo, mga pahina ng produkto at kategorya ay inihahain bilang full-page cache para sa pinakamabilis na posibleng TTFB, habang ang ESI naman ang nag-render ng cart fragment, mga kabuuang halaga ng mini-cart, at estado ng account sa bawat kahilingan. Ang cart, checkout, my-account, at anumang pahina ng nonce o session ay awtomatikong ibinubukod. Palaging nakikita ng mga mamimili ang kanilang sariling basket at gumaganang checkout; nakukuha pa rin ng lahat ang storefront mula sa cache.
Ang kasariwaan ay pinamamahalaan ng matalinong auto-purge. Kusang gumagana ang mga purge hook kapag nagbabago ang nilalaman, mga produkto, mga presyo, o mga order, kaya agad na nagre-refresh ang mga kaugnay na naka-cache na pahina sa halip na sa pamamagitan ng timer, at maaari ka ring mag-purge on demand mula sa dashboard o mula sa loob ng WordPress. Ang tag-based purging ay nangangahulugan na ang pag-e-edit ng isang post ay naglilinis sa post na iyon at sa mga archive nito — hindi sa buong cache — kaya ang isang pag-e-edit ay hindi nagco-cold-start sa buong site.
Object cache ng Redis bawat site: para sa mga hindi maaaring maging buong pahina
Hindi bawat kahilingan ay maaaring maging isang static na buong pahina. Ang mga naka-log-in na session, ang WordPress admin, ang mga WooCommerce cart, paghahanap, at ang mga dinamikong fragment na iniwan ng ESI ay kailangang magpatakbo ng PHP. Para sa mga iyon, ang layunin ay lumilipat mula sa 'laktawan ang application' patungo sa 'laktawan ang database'.
Ang bawat site ay may sariling nakalaang Redis object cache. Nag-cache ang WordPress ng mga resulta ng paulit-ulit na pagbasa ng database — mga opsyon, transient, paghahanap ng post at term, data ng produkto at session sa WooCommerce — sa memorya, kaya hindi na pinapatakbo ang parehong query sa MySQL sa bawat hit. Pinakamaraming epekto ito kung saan hindi makakatulong ang full-page cache: mas mabilis na mga dashboard, mas mabilis na mga cart, at mas mababang karga sa database sa panahon ng trapiko.
Ang object cache ay bawat site, hindi ibinabahagi, na mahalaga para sa parehong performance at isolation. Kasama ng per-site database throttling, ang mabibigat o masamang pagkakasulat na query ng isang site ay hindi makakabawas sa database para sa mga kapitbahay nito. Mababasa mo ang higit pa tungkol sa kung paano magkakasama ang buong multi-layer setup sa aming caching feature page, at tungkol sa mga hangganan sa pagitan ng mga tenant sa ilalim ng isolation.
Ang edge at ang transport sa ilalim nito
Ang cache na nananatili sa origin ay kailangan pa ring dumaan sa network. Nasa harap ng server ang CDN edge, kaya ang mga static asset at cacheable na pahina ay sineserbisyuhan mula sa isang point of presence malapit sa bisita, at nananatiling tahimik ang origin kahit na mabigat ang load. Para sa aming linya ng host na Footprint-Free, ang mismong edge na ito ay isang multi-CDN pool na nakalatag sa ilang provider, na nagsisilbi sa layunin ng footprint pati na rin sa performance; sa mainstream na WordPress, ito ay isang mabilis at maayos na layer lamang na nagpapanatiling idle sa mga origin.
Sa ilalim, hindi tinitipid ang mga pundasyon. Tumatakbo ang mga site sa NVMe imbakan na may HTTP/3, kaya ang mga byte na ipinadala ng cache ay dumarating sa pamamagitan ng moderno at naka-multiplex na transport na may mabilis na imbakan sa likod ng anumang cache miss. Ang alinman sa mga layer na ito ay hindi add-on: ang LiteSpeed, LSCache, per-site na Redis, NVMe, at HTTP/3 ay ang baseline sa bawat plan, hindi isang upsell tier.
Ano talaga ang nagpapagalaw sa Core Web Vitals
Sulit na maging tumpak, dahil ang hosting ay madalas na labis na ipinagmamalaki pagdating sa Core Web Vitals. Ang TTFB ay ang bahagi ng ekwasyon na pag-aari ng server, at ang caching stack sa itaas ang nagpapababa nito — ang isang naka-cache na buong pahina na inihahatid sa pamamagitan ng HTTP/3 mula sa edge ay halos kasingbaba ng nararating ng TTFB. Dahil ang TTFB ang nangungunang bahagi ng Largest Contentful Paint, ang isang mabilis na pinagmulan ay nagbibigay sa bawat downstream na sukatan ng kalamangan na hindi nito makukuha sa iba pang paraan.
Ngunit ang LCP, CLS, at INP ay kadalasang nagmumula sa browser, sa mismong pahina: isang hindi na-optimize na hero image, render-blocking na CSS at JavaScript, layout na nagbabago habang naglo-load ang mga font at ad, at mabigat na gawain sa main-thread mula sa mga plugin. Walang dami ng server caching ang makakapag-ayos sa 2 MB na hero o isang theme na nagpapadala ng mga megabyte ng JavaScript. Ginagawang epektibong libre at tuloy-tuloy ng tapat na hosting ang kontribusyon ng server, pagkatapos ay nakasalalay na sa site na panatilihing magaan ang front end.
Ang dibisyon ng paggawa na iyon ay ang kapaki-pakinabang na mental model. Ginagarantiya naming mabilis na makakarating ang request sa browser at mananatiling mabilis sa kabila ng trapiko; pinapanatili mong maliit at matatag ang payload. Kung saan nagtatagpo ang dalawa — cache warm-up, edge delivery, at pagpapanatiling tumutugon ang database para hindi maantala ang mga dynamic na pahina — ay eksaktong kung saan naka-tune ang aming stack, at ito ang dahilan kung bakit mas mabilis ang managed WordPress sa platform na ito kaysa sa parehong site sa isang generic na host.
Madalas itanong
Kailangan ko pa ba ng caching plugin tulad ng WP Rocket?
Hindi. Ang full-page caching ay pinamamahalaan sa web server ng LSCache ng LiteSpeed, at ang aming sariling cache plugin — na pre-installed at awtomatikong ina-update — ay iniuugnay ang WordPress dito nang maayos, kasama ang isang per-site na Redis object cache sa likod nito. Ang pagpapatong ng pangalawang full-page caching plugin ay karaniwang nakikipaglaban sa cache sa antas ng server sa halip na makatulong, kaya hindi ito kailangan at hindi inirerekomenda.
Masisira ba ng caching ang aking WooCommerce cart o mga naka-log in na pahina?
Hindi. Ang cart, checkout, my-account, at anmang nonce o session page ay awtomatikong ibinubukod sa cache, at pinapanatili ng ESI na live ang cart fragment at totals sa mga naka-cache na page. Laging nakikita ng mga mamimili ang sarili nilang basket at gumaganang checkout habang nag-a-load pa rin ang storefront mula sa cache.
Paano nananatiling sariwa ang cache kapag nag-publish o nag-edit ako?
Gumagana ang matalinong auto-purge sa mga nauugnay na WordPress hook, kaya ang pag-publish, pag-edit ng nilalaman, o pagbabago ng produkto, presyo, o order ay naglilinis lamang sa mga apektadong pahina at sa kanilang mga archive — hindi sa buong cache — at ibinabalik ito ng isang crawler. Maaari ka ring mag-purge on demand mula sa dashboard o mula sa loob ng WordPress.
Maaari ba akong bigyan ng hosting lamang ng perpektong Core Web Vitals?
Binibigyan ka nito ng pinakamahusay na posibleng TTFB, na siyang bahagi ng server at maagang simula para sa Largest Contentful Paint. Ngunit ang LCP, CLS at INP ay higit na tinutukoy ng mismong pahina — mga laki ng larawan, mga asset na nakaharang sa pag-render, katatagan ng layout, at JavaScript sa main-thread. Ginagawang mabilis at tuloy-tuloy ng ating stack ang kontribusyon ng server; ang pagpapanatiling payat sa front-end payload ang siyang pumupuno sa natitirang agwat.
Kaugnay
Subukan nang libre sa loob ng 14 na araw
Simulan nang libre ang iyong mga unang site sa loob ng 14 na araw — walang kailangang card. Lumilipat ng umiiral na network? Sagot namin ang iyong unang migrasyon.
Magsimula nang libre