Pagganap
Ang bawat WordPress site ay nakakakuha ng full-page cache at bawat-site na Redis object cache, na kasama sa hosting at tumatakbo sa server sa halip na sa isang plugin na kailangan ninyong i-configure. Parehong switch ang mga ito sa Performance tab ng site, at sinusukat ng parehong tab kung ano ang binabago ng mga ito: Core Web Vitals mula sa mga totoong bisita, mga timing ng kahilingan na kinuha sa server, at pag-profile sa antas ng code na nagpapangalan sa plugin o query na umuubos ng oras.
Kasama ang mga ito sa hosting. Hindi ang mga ito isang tier at ang pag-off sa bayad na pag-upgrade ay hindi kailanman nag-aalis sa mga ito — na mahalaga, dahil ang isang downgrade na tahimik na nag-alis ng iyong caching ay kukuha ng isang bagay na hindi mo kailanman binili at hindi mo kailanman tinigilang bayaran.
Ang mga nai-render na pahina ay direktang inihahatid mula sa cache, ganap na nilalagpasan ang PHP para sa mga bisitang hindi naka-log in. Para sa isang site ng nilalaman o brochure, ito ang nag-iisang pinakamalaking tagumpay na magagamit, at ito ang pagkakaiba sa pagitan ng isang server na madaling humahawak sa biglaang pagdami ng trapiko at ng isa na bumabagsak.
Pinipigilan ng persistent object cache ang WordPress sa muling pagbuo ng parehong database query sa bawat kahilingan, kaya mas mabilis na nabubuo ang mga pahina kahit mabigat ang karga at nananatiling magaan ang database. Bawat site, hindi ibinabahagi — ang inyong cache ay hindi mabubura dahil sa iba.
Ang mga cart, checkout, page ng account, at anumang inilalabas para sa isang naka-log in na bisita ay hindi kasama bilang default, para sa WordPress at WooCommerce. Ang cache na nagpapakita sa isang customer ng basket ng ibang customer ay hindi isang feature para sa performance.
Mag-publish ng post at lilinisin nito ang post na iyon at ang mga listahang kinabibilangan nito; nililinis ng komento ang pinagmulan nito; nililinis ng pagpapalit ng tema ang lahat.
Ginagawang mas matipid ng caching ang pag-serve ng isang page. Hindi nito ginagawang mas magaan ang mabigat na larawan o pinapahinto ang pag-block ng isang blocking script — iyon ay trabaho sa mismong site, at iyon ang layunin ng expert speed-up.
| Kasama ang pag-cache | Ekspertong pampabilis | |
|---|---|---|
| Cache ng buong page (LiteSpeed LSCache) | Oo | Configured for how the site is built |
| Redis object cache bawat site | Oo | Configured and tuned |
| Pag-compress ng imahe at mga modernong format | Hindi | Oo |
| Mga CSS at script na humaharang sa Render | Hindi | Deferred; critical CSS on the heaviest tier |
| Isang CDN sa harap ng site | From the CDN tab | From the CDN tab |
| Paano ito sinisingil | With the hosting | One-off, by how complex the site is |
| Sino ang gumagawa ng trabaho | You switch it on | Our engineers |
| Kung paano mo ito makukuha | The Performance tab | Bought as an add-on |
Nakatakda ang presyo ng bilis ng eksperto batay sa kung gaano kakomplikado ang site, dahil ang pagiging kumplikado ang nagdidikta sa dami ng oras — tingnan ang pahina ng speed-up para sa kung ano ang saklaw ng bawat antas.
Mayroon ang bawat site nito. Ipinapakita nito ang pag-cache na naka-on na, kung ano ang nararanasan ng mga totoong bisita, at kung saan napupunta ang oras ng iyong site.
Kasama at nakalista doon ang page cache at object cache. May sariling switch ang bawat isa, kaya ang site na kailangang i-off ang isa ay mananatili ang isa pa.
Basahin muna ang Core Web Vitals card at ang mga timing sa panig ng server, upang mayroon kayong mapaghahambingan sa halip na isang impresyon lamang.
Kung nakakadismaya pa rin ang mga numero, karaniwang hindi ang cache ang sanhi — ito ay mga imahe, isang plugin, o isang query. Ang bilis mula sa eksperto ay ang paghahanap at pag-aayos mismo niyon ng aming mga developer.
Katibayan, hindi kutob
Nagmumula ang Core Web Vitals sa aktwal na naranasan ng mga totoong bisita, na awtomatikong sinusuri para sa inyong homepage at kapag hiniling para sa anumang iba pang page. Ang mga timing sa bahagi ng server ay mga totoong kahilingang pinagsilbihan ng inyong site, na inorasan sa server bago pa may makarating sa isang browser — kaya ang mabagal na page ay naihihiwalay mula sa mabagal na network.
Ang pag-profile sa antas ng code ang nagbabago sa susunod ninyong gagawin: bawat kahilingan ay pino-profile sa server, at sinasabi ng kasaysayan kung aling mga pahina ang pinakamabagal, aling plugin o query ang umuubos ng oras, at kung ito ay lumalala. Ang markang mula sa isang daan ay nagsasabi sa inyo na may problema; ito naman ang nagsasabi kung kanino ito.
Ang pagkakaiba sa pagitan ng mga ito ay kung sino ang gumagawa ng trabaho. Madali at magastos ang pagpili ng mali, kaya narito ang tapat na gabay.
Ang page cache at object cache ay kasama sa iyong plano at inililipat mula sa tab na «Performance». Angkop para sa karamihan ng mga site ng nilalaman at brochure, at wala itong karagdagang gastos para sa iyo.
Paano gumagana ang pag-cache →Isang minahang serbisyo kung saan ikinukumpigura namin ang pag-cache batay sa inyong aktwal na site — ang mga pagbubukod na kailangan nito at ang mga panuntunang nais nito — at ibinabalik ito nang gumagana.
Tingnan ang mga serbisyo sa pagpapabilis →Nagtatrabaho ang aming mga developer sa kung ano talaga ang mabagal: isang query na walang index, isang plugin na gumagawa ng mabigat na proseso sa bawat pag-load ng page, isang theme na nagre-render ng buong katalogo. Nakadepende ang presyo sa kung gaano kakomplikado ang site.
Ekspertong pag-optimize ng bilis →Ang page cache ay mula sa LiteSpeed, at LiteSpeed Enterprise ang pinapatakbo ng aming fleet. Kung nagho-host kayo sa ibang lugar at gusto ninyo ang parehong engine, pinapamahalaan din namin iyon.
LiteSpeed, pinamamahalaan →Isang server-side caching layer para sa WordPress, na pinamamahalaan sa antas ng hosting sa halip na sa pamamagitan ng plugin na ini-install at inaayos ninyo. Isa itong full-page cache at per-site object cache, parehong kasama sa inyong plano at parehong inililipat mula sa Performance tab ng site. Walang hiwalay na lisensyang bibilhin at walang configuration file na ie-edit.
Dalawang antas ng caching, at ang mga ito ay magkahiwalay na switch sa halip na iisang setting lang. Inihahatid ng page cache ang mga na-render na page nang direkta mula sa LSCache ng LiteSpeed, ganap na nilalagpasan ang PHP para sa mga bisitang hindi naka-log in — ang nag-iisang pinakamalaking bentaha para sa isang content o brochure site. Ang object cache ay isang bawat-site na instance ng Redis na pumipigil sa WordPress na buuin muli ang parehong database query sa bawat kahilingan. Parehong kasama ang dalawa sa bawat plano, at ang pag-off sa bayad na tier ay hindi kailanman mag-aalis sa mga ito.
Hindi. Ang pag-cache at ang mga pag-optimize ay tumatakbo sa server, sa ilalim ng WordPress. Ipinapadala namin ang Zinn® Cache plugin bilang bahagi ng pag-deploy ng isang site, ngunit ito ay isang cache controller sa halip na isang cache engine — umiiral ito upang ang pag-publish ng isang post ay mag-clear nang eksakto sa mga page kung saan lumalabas ang post na iyon, at mag-utos sa aming edge na gawin din ang pareho, sa halip na kayo ang mag-clear ng mga cache nang manu-mano.
Tumatakbo ang mga pag-optimize sa server at cache layer at may kasamang mga ligtas na default, kabilang ang mga pagbubukod para sa mga path ng WordPress at WooCommerce na hindi dapat ma-cache kailanman — mga cart, checkout, page ng account, at anumang inihahatid sa isang naka-log in na user. Kung may kailangang ibukod, binibigyang-daan ka ng cache controller na ibukod ito sa halip na i-off ang buong layer.
Sinusukat ito ng parehong tab sa tatlong paraan. Nagmumula ang Core Web Vitals sa naranasan ng mga totoong bisita. Ang mga timing sa panig ng server ay mga totoong kahilingang pinagsilbihan ng iyong site, na orasan sa server bago pa may makarating sa browser. At tinutukoy ng code-level profiling ang plugin, query, o piraso ng code na umubos ng oras — na siyang tanging paraan sa tatlo na nagsasabi sa iyo kung ano talaga ang dapat baguhin.
Batay sa kung sino ang gumagawa ng trabaho. Naka-on na ang caching sa pahinang ito, at kayo mismo ang magpapalit nito. Ang serbisyo sa pag-setup ay ang aming maayos na pag-configure nito para sa inyong partikular na site, nang isang beses. Ang pagpapabilis ng eksperto ay ang aming mga developer na gumagawa sa mga aktwal na problema ng inyong site — mga imahe, mabagal na query, mabigat na plugin, temang gumagawa ng magastos sa bawat pag-load ng pahina. Ang mga ito ay hindi mga bersyon ng iisang produkto; maaaring ang isa sa mga ito ang eksaktong kailangan ninyo at ang iba ay walang silbi.
Bawat WordPress site na aming hino-host ay nagtataglay ng parehong caching layer — kasama ang mga ito sa hosting, hindi sa isang partikular na tier. Ang nag-iiba ay ang makina sa ilalim nito: gumagana ang caching kung saan namin kinokontrol ang server, kaya ang isang site sa package na pinapamahalaan ng vendor ay nakakakuha ng ibinibigay ng platform ng vendor na iyon bilang kapalit.
Ang object cache ay binuo para sa WordPress at doon ito pinakamabisang gumagana. Ang full-page cache ay hindi partikular sa WordPress lamang — ang isang PHP application o isang static site sa aming fleet ay pinagsisilbihan ng parehong LiteSpeed page cache, at ang isang static site ay mabilis sa mga dahilang ginagawang hindi na kailangan ang karamihan dito.
Hindi sa ngayon. Ang pag-cache sa pahinang ito ang pinapatakbo ng bawat WordPress site na aming hino-host, at ito ay kasama na. Kung mabagal pa rin ang inyong mga pahina kapag naka-on na ito, ang dahilan ay karaniwang mga larawan, isang plugin, o isang query sa halip na ang cache — na siyang gawaing manu-manong isinasagawa ng eksperto sa pagpapabilis para sa inyong partikular na site.
Walang kailangang subukan: kasama ang caching sa hosting at aktibo mula sa unang deploy. Ang hosting mismo ay may kasamang 14-araw na pagsubok nang walang kinakailangang card.
Hindi, at sinadya ito. May kasamang pinagsamang CDN ang AccelerateWP at hindi namin ito kailanman binubuksan, dahil ang bawat Zinn® site ay pinangungunahan na ng isang edge na aming pinili — ang pangalawang CDN sa harap nito ay mangangahulugan ng dalawang cache na magkasunod, at ang pag-purge sa isa ay mag-iiwan sa isa pa na naghahatid ng lumang page. Ang iyong CDN ay nagmumula sa CDN tab ng site.
Oo. Ang parehong layer ay mga switch sa sariling tab ng Pagganap ng bawat site, at independyente ang mga ito sa isa't isa — ang isang site na kailangang panatilihing naka-off ang page cache ay nagpapanatili pa rin ng object cache nito.
Magsimula ng 14 na araw na pagsubok nang walang credit card. Naka-on ang caching mula sa unang deploy — buksan ang Performance tab at panoorin ang nagagawa nito sa sarili ninyong mga numero.
Magsimula nang libre