Хостинг ба гүйцэтгэл
Бид WordPress-ийг хэрхэн хурдан болгодог вэ: LiteSpeed Enterprise, LSCache болон сайт бүрд зориулсан Redis
Хамгийн хурдан WordPress хүсэлт бол хэзээ ч ажилладаггүй хүсэлт юм — PHP эсвэл MySQL ажиллахаас өмнө манай стек ихэнх хандалтуудад кэшээс хэрхэн хариулдаг болон энэ нь Core Web Vitals-д ямар ач холбогдолтой болохыг энд тайлбарлав.
Хамгийн хурдан хүсэлт бол хэзээ ч ажилладаггүй хүсэлт юм
Энгийн WordPress хүсэлт нь зардал өндөртэй байдаг. Веб сервер PHP рүү шилжүүлж, PHP нь WordPress-ийг ачаалан, залгаасуудыг ажиллуулж, MySQL-ээс хэдэн арван удаа асуулга хийж, HTML-ийг угсраад, зөвхөн үүний дараа л байтуудыг буцаан илгээдэг. Ачаалал ихтэй сайтын хувьд энэхүү бүх үйл явц нь зочин бүрийн хувьд явагддаг бөгөөд таны time-to-first-byte-ийн бараг бүх хугацаа энд зарцуулагддаг.
Бидний хариулт бол ихэнх хандалтын хувьд эдгээрийн аль нь ч огт тохиолдохгүй байх явдал юм. Манай байршуулж буй сайтуудын хувьд — 100,000 гаруй PBN сайтууд болон үндсэн удирдлагатай WordPress — хэрэглэгчийн талын хуудас үзэлтийн дийлэнх нь PHP-г ажиллуулахгүйгээр эсвэл өгөгдлийн санд хандахгүйгээр кэшээс шууд урьдчилан боловсруулсан бүтэн хуудас хэлбэрээр хүргэгддэг. Энэ нийтлэлийн үлдсэн хэсэг нь үүнийг бодит болгодог давхаргууд хоорондоо хэрхэн нийцэж, тус бүр өөрийн байр сууриа хэрхэн олж авдаг тухай юм.
Энд анхаарах гол зүйл бол эдгээр нь хоорондоо өрсөлддөг, аль нэгийг нь сонгох ёстой кэшүүд биш юм. Бүтэн хуудасны кэш, объектын кэш болон CDN edge нь тус бүрдээ өөр өөр төрлийн хүсэлтийг хүлээн авдаг бөгөөд гол үнэ цэнэ нь тэдгээр нь хүсэлтийг бие биедээ хэрхэн дамжуулж ажилладагт оршино.
LiteSpeed Enterprise + LSCache: бүрэн хуудасны түвшин
Бүх сайт сервер түвшний LSCache бүхий LiteSpeed Enterprise дээр ажилладаг. Фронтенд хариуг кэшлэх боломжтой үед вэб сервер үүнийг LiteSpeed-ийн кэш хяналт болон шошгын толгой хэсгүүдээр тэмдэглэдэг бөгөөд LiteSpeed дараагийн хандалтаар бүрэн хуудсыг шууд дамжуулдаг — ямар ч PHP процесс үүсэхгүй, ямар ч MySQL хүсэлт илгээгдэхгүй. Энэ нь програмын бүрэн ачаалалтыг гол замаас хасдаг тул WordPress TTFB-д хамгийн том нөлөө үзүүлдэг хүчин зүйл юм.
LSCache нь PHP залгааст бус харин вэб серверийн дотор байрладаг тул хүсэлтийн амьдралын мөчлөгт илүү эрт ажиллаж эхэлдэг бөгөөд серверийн хувьд шууд цэвэрлэх боломжтой хэлбэрээр хуудсуудыг хадгалдаг. Кэш мөлхөгч нь эрэлттэй хуудсуудыг байнга бэлэн байдалд хадгалдаг тул кэшийг цэвэрлэсний дараах анхны зочин хуудсыг дахин үүсгэхэд цаг алдах шаардлагагүй болно. Үүний үр дүнд кэш нь PHP-ийн ард байрласан хэвээр байдаг ерөнхий стек дээр суурилуулсан зөвхөн залгаас бүхий кэштэй харьцуулахад хамаагүй бага бөгөөд илүү тогтвортой TTFB бий болдог.
Манай өөрийн репозиторын түвшний кэш залгаас нь бүх сайтуудад урьдчилан суулгагдсан бөгөөд автоматаар шинэчлэгдэж, анхнаасаа л WordPress-ийг LSCache-тэй зөв холбодог. LiteSpeed биш эх сервер дээр энэ нь бүрэн хуудасны толгой мэдээллийг дамжуулахгүйгээр ажиллахаа больдог бол объектын кэш болон хасалтын дүрмүүд хэвийн ажилласаар байх болно — иймээс шилжүүлсэн сайт хэзээ ч эвдэрсэн, дутуу тохируулагдсан төлөвт үлдэхгүй.
Хуучирсан контент нийлүүлэхгүйгээр хурдаа хадгалах нь: ESI ба ухаалаг автоматаар цэвэрлэх систем
Бүтэн хуудсыг идэвхтэй кэшлэхэд хоёр сонгодог алдааны горим байдаг: нэвтэрсэн хэрэглэгчид өөр хүний хуудсыг харуулах, мөн өөрчлөгдсөн байх ёстой хуудсыг хэн нэгэнд харуулах. Аль алиныг нь бага кэшлэх замаар биш, харин кэшлэх түвшинд шийддэг.
ESI (Edge Side Includes) нь динамик хэвээр байх ёстой хэсгүүдэд зай үлдээхийн зэрэгцээ хуудсыг кэшлэх боломжийг бидэнд олгодог. WooCommerce дэлгүүрт каталог, бүтээгдэхүүн болон ангиллын хуудсуудыг хамгийн хурдан TTFB-ээр хангахын тулд бүтэн хуудасны кэшээр үйлчилдэг бол ESI нь хүсэлт бүрд сагсны хэсэг, жижиг сагсны дүн болон бүртгэлийн төлөвийг дүрсэлдэг. Сагс, тооцоо хийх, миний бүртгэл болон аливаа nonce эсвэл сессийн хуудсуудыг анхдагч тохиргоогоор хасдаг. Худалдан авагчид үргэлж өөрсдийн сагс болон ажиллаж буй тооцооны хуудсыг хардаг; харин дэлгүүрийн нүүр хуудсыг бүгд кэшээс авсан хэвээр байна.
Шинэлэг байдлыг ухаалаг автоматаар цэвэрлэх (auto-purge) системээр зохицуулдаг. Агуулга, бүтээгдэхүүн, үнэ эсвэл захиалга өөрчлөгдөх үед цэвэрлэх дэгээнүүд автоматаар ажилладаг тул холбогдох кэшлэгдсэн хуудсууд цаг хүлээлгүйгээр шууд шинэчлэгддэг бөгөөд та хяналтын самбар эсвэл WordPress дотроос хүссэн үедээ цэвэрлэх боломжтой. Шошгонд суурилсан цэвэрлэгээ нь нэг нийтлэлийг засахад бүх кэшийг биш, зөвхөн тухайн нийтлэл болон түүний архивыг цэвэрлэнэ гэсэн үг бөгөөд ингэснээр ганцхан засвар хийснээс болж сайтыг бүхэлд нь хүйтэн эхлүүлэлт (cold-start) хийлгэхэд хүргэхгүй.
Сайт бүрийн Redis объектын кэш: бүтэн хуудас байх боломжгүй зүйлсэд зориулав
Хүсэлт бүр статик бүтэн хуудас байх боломжгүй. Нэвтэрсэн сэшнүүд, WordPress админ, WooCommerce сагснууд, хайлт болон ESI-ийн шууд үлдээдэг динамик хэсгүүд бүгд PHP ажиллуулах шаардлагатай. Тэдгээрийн хувьд зорилго нь 'програмыг алгасах'-аас 'өгөгдлийн санг алгасах' болж өөрчлөгддөг.
Вэбсайт бүр өөрийн гэсэн зориулалтын Redis объект кэштэй болно. WordPress нь өгөгдлийн сангийн давтагдах уншилтуудын үр дүнг — сонголтууд, түр зуурын өгөгдлүүд, нийтлэл болон нэр томьёоны хайлтууд, WooCommerce-ийн бүтээгдэхүүн болон сессийн өгөгдлүүдийг — санах ойд кэшлэдэг тул хандалт бүрд нэг ижил хүсэлтийг MySQL рүү ажиллуулах шаардлагагүй болдог. Энэхүү үр нөлөө нь бүтэн хуудасны кэш тусалж чаддаггүй хэсэгт хамгийн тод мэдрэгддэг: хяналтын самбар илүү хурдан ажиллаж, сагс илүү түргэн шинэчлэгдэж, өндөр ачааллын үед өгөгдлийн сангийн ачаалал эрс буурдаг.
Объект кэш нь дундаа хуваалцдаггүй бөгөөд сайт тус бүрд зориулагдсан байдаг нь гүйцэтгэл болон тусгаарлалтын аль алиных нь хувьд чухал юм. Сайт тус бүрийн өгөгдлийн сангийн хязгаарлалттай хосолсноор нэг сайтын хүнд эсвэл буруу бичигдсэн хүсэлтүүд нь зэргэлдээх сайтуудын өгөгдлийн сангийн нөөцийг хомсдуулах боломжгүй болно. Бүх олон түвшний тохиргоо хэрхэн уялдаж ажилладаг талаар манай кэшлэх боломжийн хуудаснаас, мөн тусгаарлалтын үе дэх хэрэглэгчид хоорондын зааг ялгааны талаар дэлгэрэнгүй унших боломжтой.
Зах хязгаар ба түүний доорх тээвэрлэлт
Үндсэн сервер (origin) дээр байрлах кэш нь сүлжээгээр дамжих шаардлагатай хэвээр байдаг. Серверийн өмнө CDN edge байрладаг тул статик файлууд болон кэшлэх боломжтой хуудсуудыг зочинд ойр байрлах цэгээс (point of presence) хүргэдэг бөгөөд үүний ачаар ачаалал ихтэй үед ч үндсэн сервер тайван хэвээр үлддэг. Манай footprint-free хостингийн хувьд уг edge нь хэд хэдэн нийлүүлэгчид тархсан multi-CDN сан байх бөгөөд энэ нь бүтээмжээс гадна footprint-ийн зорилгод үйлчилдэг; харин нийтлэг WordPress дээр энэ нь үндсэн серверүүдийг сул зогсолттой байлгадаг хурдан, тогтвортой ажилладаг давхарга юм.
Үндсэн дэд бүтцэд огт хасалт хийгээгүй. Вебсайтууд нь HTTP/3 бүхий NVMe санах ой дээр ажилладаг тул кэшээс илгээгдэх байтууд нь аливаа кэш алдагдахад ард нь түргэн шуурхай санах ой бүхий орчин үеийн, мультиплексжүүлсэн дамжуулалтаар хүрдэг. Эдгээр давхаргуудын аль нь ч нэмэлт төлбөрт үйлчилгээ биш юм: LiteSpeed, LSCache, сайт бүрийн Redis, NVMe болон HTTP/3 нь нэмэлт үнээр зарах түвшин бус, харин бүх багцын үндсэн суурь үзүүлэлт юм.
Core Web Vitals-д чухам юу нөлөөлдөг вэ
Core Web Vitals-ийн хувьд хостингийг хэт дөвийлгөн борлуулах нь элбэг тул нарийн тодорхой байх нь чухал. TTFB бол тэгшитгэлийн серверийн хариуцдаг хэсэг бөгөөд дээр дурдсан кэшлэх стек нь түүнийг бууруулдаг гол хүчин зүйл юм — edge-ээс HTTP/3-аар дамжуулан хүргэсэн кэшлэгдсэн бүтэн хуудас нь TTFB-ийн хүрч болох хамгийн доод түвшин юм. TTFB нь Largest Contentful Paint-ийн эхний үе шат тул хурдан эх сервер нь дараагийн бүх үзүүлэлтэд өөр ямар ч аргаар олж авч чадахгүй давуу талыг олгодог.
Гэвч LCP, CLS болон INP нь ихэвчлэн хөтөч дээр, хуудас өөрөө шийддэг: оновчлоогүй hero зураг, дүрслэлийг саатуулах CSS болон JavaScript, фонт болон зарын ачааллаас шалтгаалан шилжих бүтэц, мөн залгаасуудын үндсэн урсгалын хүнд ажиллагаа. Серверийн кэш хичнээн байсан ч 2 МБ хэмжээтэй hero зураг эсвэл олон мегабайт JavaScript дамжуулдаг загварыг засаж чадахгүй. Шударга хостинг нь серверийн нөлөөллийг үндсэндээ үнэ төлбөргүй бөгөөд тогтвортой болгодог тул үүний дараа front end-ийг хөнгөн байлгах нь тухайн сайтын үүрэг юм.
Энэхүү ажлын хуваарилалт нь туйлын оновчтой арга барил юм. Бид хүсэлтийг хөтөч рүү хурдан хүргэж, ачаалал ихтэй үед ч хурдаа алдахгүй байх баталгааг өгдөг; харин та өгөгдлийн хэмжээг бага, тогтвортой байлгах хэрэгтэй. Энэ хоёрын огтлолцол болох кэш бэлтгэх (cache warm-up), edge хүргэлт, динамик хуудсууд гацахгүй байхын тулд өгөгдлийн санг шуурхай ажиллуулах зэрэг нь яг манай системийн нарийн тааруулсан хэсэг бөгөөд энэ платформ дээрх удирдлагатай WordPress-ийг энгийн хостинг дээрх ижил сайтаас илүү хурдан болгодог гол хүчин зүйл юм.
Түгээмэл асуултууд
Надад WP Rocket шиг кэш хийх залгаас одоо ч хэрэгтэй юу?
Үгүй. Хуудсыг бүхэлд нь кэшлэх үйлдлийг вэб сервер дээр LiteSpeed-ийн LSCache гүйцэтгэдэг бөгөөд урьдчилан суулгасан бөгөөд автоматаар шинэчлэгддэг манай өөрийн кэш залгаас нь WordPress-ийг үүнтэй зөв холбож, цаана нь сайт тус бүрийн Redis объектын кэш ажилладаг. Дээр нь бүрэн хуудас кэшлэх хоёр дахь залгаасыг давхарлан ашиглах нь тус болохоос илүү серверийн түвшний кэштэй зөрчилдөх хандлагатай байдаг тул энэ нь шаардлагагүй бөгөөд зөвлөдөггүй.
Кэш хийх нь миний WooCommerce сагс эсвэл нэвтэрсэн хуудсуудыг эвдэх үү?
Үгүй. Cart, checkout, my-account болон аливаа nonce эсвэл session хуудсууд анхдагч тохиргоогоор кэшээс хасагддаг бөгөөд ESI нь бусад кэшлэгдсэн хуудсууд дээр сагсны хэсэг болон нийт дүнг бодит цаг хугацаанд шинэчилж харуулдаг. Дэлгүүрийн нүүр хуудас кэшээс ачаалагдсан хэвээр байх үед худалдан авагчид үргэлж өөрсдийн сагс болон хэвийн ажиллаж буй тооцооны хуудсыг харах болно.
Би нийтлэх эсвэл засах үед кэш хэрхэн шинэ хэвээр үлдэх вэ?
Ухаалаг автомат цэвэрлэгээ нь холбогдох WordPress дэгээнүүд дээр ажилладаг тул контент нийтлэх, засах, эсвэл бүтээгдэхүүн, үнэ, захиалгыг өөрчлөх үед бүх кэшийг бус зөвхөн нөлөөлөлд өртсөн хуудсууд болон тэдгээрийн архивыг цэвэрлэдэг бөгөөд автомат хайгч тэдгээрийг дахин урьдчилан ачаалдаг. Та мөн хянах самбараас эсвэл WordPress дотроос хүссэн үедээ цэвэрлэх боломжтой.
Зөвхөн хостинг надад төгс Core Web Vitals өгч чадах уу?
Энэ нь танд боломжит хамгийн сайн TTFB-г олгох бөгөөд энэ нь серверийн хувь нэмэр бөгөөд Largest Contentful Paint-ийн эхлэлийн давуу тал болно. Гэвч LCP, CLS болон INP нь ихэвчлэн хуудаснаас өөрөөс нь — зургийн хэмжээ, рендерийг саатуулах хөрөнгүүд, бүтцийн тогтвортой байдал болон үндсэн урсгалын JavaScript зэргээс хамаардаг. Манай систем серверийн ажиллагааг хурдан бөгөөд тогтвортой болгодог; үлдсэн зөрүүг арилгах гол хүчин зүйл бол фронт-энд ачааллыг бага байлгах явдал юм.
Холбогдох
14 хоног үнэгүй туршиж үзнэ үү
Эхний сайтуудаа 14 хоногийн турш үнэ төлбөргүй ажиллуулаарай — карт шаардлагагүй. Одоо байгаа сүлжээгээ шилжүүлж байна уу? Шилжүүлэг ямар ч хязгаарлалтгүйгээр үнэ төлбөргүй явагдана.
Үнэгүй эхлэх