Hosting at pagganap
Paano namin pinapabilis ang WordPress: LiteSpeed Enterprise, LSCache at Redis para sa bawat site
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 tawagin ang PHP o MySQL, at kung ano ang kahulugan nito para sa Core Web Vitals.
Ang pinakamabilis na kahilingan ay ang hindi kailanman tumatakbo
Ang isang karaniwang kahilingan sa WordPress ay magastos sa resources. Ipinapasa ng web server ang proseso sa PHP, binubuksan ng PHP ang WordPress, pinapagana ang mga plugin, nagtatanong sa MySQL nang ilang dosenang beses, binubuo ang HTML, at saka pa lamang nagbabalik ng mga byte. Sa isang website na maraming trapiko, nangyayari ang buong prosesong ito para sa bawat bisita, at dito napupunta ang halos lahat ng inyong time-to-first-byte.
Ang aming sagot ay siguraduhin na, para sa karamihan ng mga pagbisita, wala sa mga ito ang mangyayari. Sa lahat ng site na aming hino-host — mahigit 100,000 PBN site kasama ang mainstream na pinamamahalaang WordPress — ang malaking mayorya ng mga view sa front-end page ay inihahatid bilang isang pre-rendered na buong pahina nang direkta mula sa cache, nang hindi nagpapagana ng PHP o humihipo sa database. Ang nalalabi sa post na ito ay tungkol sa kung paano nagtutugma ang mga layer na nagbibigay-daan dito, at kung saan nararapat ang bawat isa.
Ang mahalagang pananaw ay hindi ito magkakalabang cache na kailangan ninyong pagpilian. Ang full-page cache, object cache, at CDN edge ay bawat isa'y sumasalo ng magkakaibang uri ng request, at ang tunay na halaga ay nakasalalay sa kung paano sila nagpapasa sa isa't isa.
LiteSpeed Enterprise + LSCache: ang layer ng buong pahina
Tumatakbo ang bawat site sa LiteSpeed Enterprise na may antas-server na LSCache. Kapag ang isang tugon ng front-end ay maaaring i-cache, tinatatakan ito ng web server ng LiteSpeed cache-control at mga tag header, at direktang inihahatid ng LiteSpeed ang kumpletong pahina sa susunod na hit — walang proseso ng PHP na sinisimulan, walang tanong sa MySQL na ipinapadala. Iyan ang nag-iisang pinakamalaking paraan upang mapabuti ang WordPress TTFB, dahil inaalis nito ang buong pag-boot ng application mula sa hot path.
Dahil ang LSCache ay gumagana sa loob mismo ng web server sa halip na sa isang PHP plugin, nagsisimula itong gumana nang mas maaga sa request lifecycle at pinapanatili ang mga page sa anyong mabilis na maba-flush ng server. Pinapanatiling aktibo ng cache crawler ang mga sikat na page, kaya ang unang bisita pagkatapos ng purge ay hindi ang magpapasan sa pag-regenerate ng page. Ang resulta ay kapansin-pansing mas mababa at mas consistent na TTFB kumpara sa plugin-only na cache na ikinabit sa karaniwang stack, kung saan ang cache ay nananatili pa rin sa likod ng PHP.
Ang aming sariling plugin ng cache na may antas ng repo ay paunang naka-install at awtomatikong ina-update sa bawat site, na wastong nag-uugnay sa WordPress sa LSCache mula pa sa simula. Sa isang pinagmulan na hindi LiteSpeed, hindi lang ito naglalabas ng mga full-page header at hindi humahadlang, habang ang object cache at mga panuntunan sa pagbubukod ay patuloy na gumagana — kaya ang isang inilipat na site ay hindi kailanman naiiwan sa sira at kalahating-na-configure na estado.
Panatilihing mabilis nang hindi naghahatid ng lumang content: ESI at matalinong auto-purge
Ang agresibong buong-pahinang pag-cache ay may dalawang karaniwang paraan ng pagpalya: paghahatid sa isang naka-log in na user ng pahina ng ibang tao, at paghahatid sa sinuman ng pahina na dapat ay nagbago na. Pareho itong nareresolba sa antas ng pag-cache sa halip na sa pamamagitan ng pagbabawas ng pag-cache.
Nagbibigay-daan ang ESI (Edge Side Includes) na i-cache ang pahina habang nag-iiwan ng mga puwang para sa mga bahaging kailangang manatiling live. Sa isang WooCommerce store, inihahatid ang mga pahina ng catalog, produkto, at kategorya bilang full-page cache para sa pinakamabilis na posibleng TTFB, habang nirerender naman ng ESI ang fragment ng cart, mga kabuuan ng mini-cart, at lagay ng account bawat kahilingan. Naka-exclude bilang default ang cart, checkout, my-account, at anumang pahina ng nonce o session. Palaging nakikita ng mga mamimili ang kanilang sariling basket at ang isang gumaganang checkout; natatanggap pa rin ng lahat ang storefront mula sa cache.
Pinapamahalaan ang pagiging bago sa pamamagitan ng matalinong auto-purge. Awtomatikong gumagana ang mga purge hook kapag nagbago ang nilalaman, mga produkto, mga presyo, o mga order, kaya ang mga nauugnay na naka-cache na pahina ay agad na nagre-refresh sa halip na batay sa timer, at maaari ka ring mag-purge ayon sa pangangailangan mula sa dashboard o mula sa loob ng WordPress. Ang pag-purge batay sa tag ay nangangahulugang ang pag-edit ng isang post ay nag-aalis sa post na iyon at sa mga archive nito — hindi sa buong cache — kaya ang isang pag-edit ay hindi nagdudulot ng cold-start sa buong site.
Bawat-site na Redis object cache: para sa 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 cart ng WooCommerce, paghahanap, at ang mga dynamic na fragment na iniiwang live 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 nakakakuha ng sarili nitong nakalaang Redis object cache. Iniimbak ng WordPress ang mga resulta ng paulit-ulit na pagbasa sa database — mga opsyon, transient, paghahanap sa post at termino, data ng produkto at session ng WooCommerce — sa memory, kaya hindi pinapatakbo ang parehong query laban sa MySQL sa bawat pagbisita. Ang epekto ay pinaka-kapansin-pansin sa mga bahagi 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 ilalim ng mabigat na trapiko.
Ang object cache ay bawat site at hindi ibinabahagi, na mahalaga para sa parehong performance at isolation. Kasabay ng database throttling para sa bawat site, ang mabibigat o hindi maayos na pagkasulat na mga query ng isang site ay hindi maaaring umubos sa mga resource ng database para sa mga kapitbahay nito. Maaari kayong magbasa nang higit pa tungkol sa kung paano nagsasama-sama ang buong multi-layer setup sa aming page ng feature sa caching, at tungkol sa mga hangganan sa pagitan ng mga tenant sa ilalim ng isolation.
Ang edge at ang transport sa ilalim
Ang cache na nasa origin server ay kailangan pa ring dumaan sa network. Sa harap ng server nakalagay ang CDN edge, kaya ang mga static asset at mga pahinang maaaring i-cache ay inihahatid mula sa isang point of presence na malapit sa bisita, at nananatiling hindi nabibigatan ang origin kahit may mataas na karga. Para sa aming footprint-free hosting line, ang parehong edge ay isang multi-CDN pool na nakakalat sa ilang provider, na nagsisilbi sa layunin para sa footprint gayundin sa performance; sa karaniwang WordPress, ito ay isa lamang mabilis at maayos na layer na nagpapanatili sa mga origin na walang ginagawa.
Sa ilalim nito, hindi tinipid ang mga pangunahing aspeto. Tumatakbo ang mga site sa NVMe storage na may HTTP/3, kaya ang mga byte na ipinapadala ng cache ay dumarating sa pamamagitan ng isang makabago at multiplexed na transportasyon na may mabilis na storage sa likod ng anumang cache miss. Wala sa mga layer na ito ang add-on: Ang LiteSpeed, LSCache, Redis bawat site, NVMe at HTTP/3 ang pamantayan sa bawat plano, hindi isang upsell tier.
Kung ano talaga ang nakakapagpabago sa Core Web Vitals
Mahalagang maging tumpak, dahil ang hosting ay madalas na labis na ipinagmamalaki pagdating sa Core Web Vitals. Ang TTFB ang bahagi ng ekwasyon na hawak 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 ang pinakamababang antas na kayang marating ng TTFB. Dahil ang TTFB ang nangungunang bahagi ng Largest Contentful Paint, ang isang mabilis na pinagmulan ay nagbibigay sa bawat sumusunod na sukatan ng paunang bentahe na hindi nito makakamit sa ibang paraan.
Ngunit ang LCP, CLS, at INP ay kadalasang napagpapasyahan sa browser, ng mismong pahina: isang hindi na-optimize na hero image, render-blocking na CSS at JavaScript, layout na umuusog habang naglo-load ang mga font at ad, at mabigat na trabaho sa main-thread mula sa mga plugin. Walang dami ng server caching ang makakaayos sa isang 2 MB na hero image o isang temang nagpapadala ng mga megabyte ng JavaScript. Ginagawa ng tapat na hosting na epektibong libre at pare-pareho ang kontribusyon ng server, pagkatapos ay nasa site na ang pagpapanatiling magaan ng front end.
Ang ganoong paghahati ng gawain ang kapaki-pakinabang na modelo ng pag-iisip. Ginagarantiya namin na mabilis na makakarating ang kahilingan sa browser at mananatiling mabilis sa ilalim ng trapiko; pinapanatili ninyong maliit at matatag ang payload. Kung saan nagtatagpo ang dalawa — pag-init ng cache, edge delivery, at pagpapanatiling mabilis tumugon ng database upang hindi huminto ang mga dynamic na pahina — ay ang eksaktong bahagi kung saan nakatutok ang aming stack, at ito ang nagpapadali sa pinamamahalaang WordPress sa platform na ito nang mas mabilis kaysa sa parehong site sa isang pangkaraniwang host.
Mga madalas itanong
Kailangan ko pa ba ng caching plugin tulad ng WP Rocket?
Hindi. Ang pag-cache ng buong pahina ay pinangangasiwaan sa web server ng LSCache ng LiteSpeed, at ang sarili naming cache plugin — na paunang naka-install at awtomatikong ina-update — ay maayos na nag-uugnay sa WordPress dito, na may object cache ng Redis bawat site sa likod nito. Ang pagpapatong ng pangalawang plugin para sa pag-cache ng buong pahina ay karaniwang sumasalungat sa cache sa antas ng server sa halip na makatulong, kaya hindi ito kailangan at hindi inirerekomenda.
Masisisira ba ng pag-cache ang aking WooCommerce cart o ang mga page para sa naka-log in?
Hindi. Ang cart, checkout, my-account at anumang mga page ng nonce o session ay hindi kasama sa cache bilang default, at pinapanatiling live ng ESI ang fragment ng cart at mga kabuuan sa mga page na naka-cache. Palaging nakikita ng mga mamimili ang kanilang sariling basket at ang isang gumaganang checkout habang naglo-load pa rin ang storefront mula sa cache.
Paano nananatiling sariwa ang cache kapag nag-publish o nag-edit ako?
Pumupukaw ang smart na awtomatikong pag-purge sa mga kaugnay na hook ng WordPress, kaya ang paglalathala, pag-eedit ng nilalaman, o pagbabago ng produkto, presyo o order ay naglilinis lamang sa mga apektadong pahina at sa kanilang mga archive — hindi ang buong cache — at muli itong pinapainit ng isang crawler. Maaari ka ring mag-purge kapag kinakailangan mula sa dashboard o mula sa loob ng WordPress.
Kaya ba ng hosting lamang na magbigay sa akin ng perpektong Core Web Vitals?
Ibinibigay nito sa inyo ang pinakamahusay na posibleng TTFB, na siyang bahagi ng server at paunang bentahe para sa Largest Contentful Paint. Ngunit ang LCP, CLS, at INP ay higit na napapagpasyahan ng mismong pahina — laki ng imahe, mga asset na humaharang sa render, katatagan ng layout, at JavaScript ng main-thread. Ginagawang mabilis at pare-pareho ng aming stack ang kontribusyon ng server; ang pagpapanatiling magaang ng payload sa front-end ang sumasaklaw sa natitirang agwat.
Kaugnay
Subukan ito nang libre sa loob ng 14 na araw
I-spin up ang iyong mga unang site nang libre sa loob ng 14 na araw — walang kailangang card. Ililipat ang isang umiiral na network? Libre ang mga paglipat, nang walang limitasyon.
Magsimula nang libre