Хостинг ба гүйцэтгэл
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 ирмэг тус бүр нь өөр өөр ангиллын хүсэлтийг хүлээн авдаг бөгөөд тэдгээрийн үнэ цэнэ нь бие биетэйгээ хэрхэн уялдаж байгаадаа оршино.
LiteSpeed Enterprise + LSCache: бүтэн хуудасны давхарга
Бүх сайт сервер түвшний LSCache бүхий LiteSpeed Enterprise дээр ажилладаг. Урд талын хариуг кэшлэх боломжтой үед вэб сервер үүнийг LiteSpeed cache-control болон tag толгой хэсгээр тэмдэглэж, дараагийн хандалтад LiteSpeed бүтэн хуудсыг шууд үйлчилдэг бөгөөд PHP процесс үүсэхгүй, MySQL асуулга илгээгдэхгүй. Энэ бол WordPress TTFB-ийн хамгийн том хөшүүрэг юм, учир нь энэ нь халуун замаас бүх аппликейшнийг ачаалах процессыг бүхэлд нь хасдаг.
LSCache нь PHP залгаас дотор биш, харин вэб сервер дотор ажилладаг тул хүсэлтийн амьдралын циклийн илүү эхэн үед ажиллаж эхэлдэг ба серверийн шууд устгаж чадах хэлбэрээр хуудсуудыг хадгалдаг. Кэш мөлхөгч (cache crawler) нь түгээмэл хуудсуудыг идэвхтэй байлгадаг тул кэшийг цэвэрлэсний дараа зочилсон анхны хэрэглэгч хуудсыг шинээр үүсгэх ачааллыг үүрдэггүй. Үүний үр дүнд кэш нь PHP-ийн цаана байрладаг ерөнхий стек дээр суурилуулсан зөвхөн залгаас бүхий кэштэй харьцуулахад TTFB нь мэдэгдэхүйц бага бөгөөд тогтвортой байдаг.
Манай хувийн репозиторийн түвшний кэш залгаас нь бүх сайтууд дээр урьдчилан суулгагдсан бөгөөд автоматаар шинэчлэгдэж ирдэг ба WordPress-ийг LSCache-тэй шууд зөв холбож өгдөг. LiteSpeed-ийн бус эх үүсвэр дээр энэ нь бүрэн хуудасны толгой хэсгийг гаргалгүйгээр саад болохгүйгээр ажилладаг бол объект кэш болон хасах дүрэм нь ажлаа үргэлжлүүлэн хийсээр байх тул шилжүүлсэн сайт хэзээ ч эвдэрсэн, дутуу тохируулагдсан төлөвт үлдэхгүй.
Хурдаа алдалгүйгээр хуучирснаас зайлсхийх нь: ESI болон ухаалаг автоматаар цэвэрлэх (auto-purge)
Бүтэн хуудасны түрэмгий кэшлэлт нь сонгодог хоёр алдаатай горимтой байдаг нь нэвтэрсэн хэрэглэгчдэд өөр хүний хуудсыг харуулах, мөн өөрчлөгдөх ёстой байсан хуудсыг хэн нэгэнд харуулах юм. Эдгээрийг бага кэшлэх замаар биш, харин кэшлэх түвшинд шийддэг.
ESI (Edge Side Includes) нь шууд харагдах ёстой хэсгүүдэд зай гаргахын зэрэгцээ хуудсыг кэшлэх боломжийг бидэнд олгодог. WooCommerce дэлгүүрийн хувьд каталог, бүтээгдэхүүн болон ангиллын хуудсууд нь TTFB-ийг хамгийн хурдан байлгахын тулд бүтэн хуудасны кэш хэлбэрээр үйлчилдэг бол ESI нь сагсны хэсэг, мини сагсны нийт дүн болон хэрэглэгчийн төлөвийг хүсэлт тус бүрээр үзүүлдэг. Сагс, тооцоо хийх хэсэг, миний бүртгэл болон аливаа нонс эсвэл сессийн хуудсууд нь анхдагчаар хасагдсан байна. Худалдан авагчид үргэлж өөрсдийн сагс болон ажиллаж буй тооцооны хэсгийг харах ба хүн бүр дэлгүүрийн нүүр хуудсыг кэшээс авах болно.
Мэдээллийн шинэчлэлтийг ухаалаг автоматаар цэвэрлэх функцээр зохицуулдаг. Агуулга, бүтээгдэхүүн, үнэ эсвэл захиалга өөрчлөгдөхөд цэвэрлэх үйлдэл автоматаар ажилладаг бөгөөд ингэснээр хугацааны хязгаарлалттай бус, холбогдох кэшлэгдсэн хуудсууд шууд шинэчлэгдэх ба та хяналтын самбар эсвэл WordPress дотроос хүссэн үедээ цэвэрлэх боломжтой. Шошгонд суурилсан цэвэрлэгээ гэдэг нь нэг нийтлэлийг засахад бүтэн кэшийг бус, зөвхөн тухайн 3 нийтлэл болон түүний архивыг цэвэрлэдэг тул нэг засвар хийхэд бүх сайтын кэш алдагдахгүй.
Site туus бүрийн Redis объектын кэш: бүтэн хуудас байж чадахгүй зүйлд зориулав
Бүх хүсэлт статик бүрэн хуудас байж чадахгүй. Нэвтэрсэн сессүүд, WordPress админ, WooCommerce сагс, хайлт болон ESI үлдээдэг динамик хэсгүүд бүгд PHP ажиллуулах шаардлагатай байдаг. Эдгээрийн хувьд зорилго нь 'аппликейшнийг алгасах'-аас 'өгөгдлийн санг алгасах' руу шилждэг.
Site бүр өөрийн гэсэн зориулалтын Redis объект кэштэй байдаг. WordPress нь давтагдсан өгөгдлийн сангийн уншилтын үр дүнгүүд болох тохиргоонууд, түр зуурын өгөгдлүүд, пост болон шошгоны хайлт, WooCommerce бүтээгдэхүүн болон сессийн өгөгдлийг санах ойд кэшлэдэг тул хүсэлт бүрийн үед MySQL рүү ижил асуулга ажиллахгүй. Энэхүү үр нөлөө нь бүтэн хуудасны кэш тусалж чадахгүй хэсэгт буюу хурдан хяналтын самбар, хурдан сагс болон ачааллын үеийн өгөгдлийн сангийн ачааллыг эрс багасгахад хамгийн тод харагддаг.
Объект кэш нь сайт тус бүрээр үйлчилдэг бөгөөд хуваалцдаггүй нь гүйцэтгэл болон тусгаарлалтын аль алинд нь чухал юм. Сайт тус бүрийн өгөгдлийн сангийн хязгаарлалттай хослуулснаар нэг сайтын ачаалал ихтэй эсвэл муу бичигдсэн асуулга нь бусад хөрш сайтуудынхаа өгөгдлийн санг гацаах боломжгүй юм. Та олон үе давхаргат тохиргоо хэрхэн нийлж ажилладаг талаар манай кэш функцийн хуудаснаас, мөн тусгаарлалтын хүрээн дэх түрээслэгч хоорондын хязгаарлалтын талаар дэлгэрэнгүй унших боломжтой.
Ирмэг болон түүний доорх тээвэрлэлт
Эх сурвалж дээр байрлах кэш нь сүлжээгээр мөн л дамжих ёстой. Серверийн өмнө CDN-ийн ирмэг байрладаг тул статик хөрөнгө болон кэшлэх боломжтой хуудаснуудыг зочны ойролцоох байршлаас үйлчилдэг бөгөөд ачаалал ихтэй үед ч эх сурвалж ачаалал багатай хэвээр үлдэнэ. Манай Footprint-Free хостингийн шугамын хувьд ижил ирмэг нь хэд хэдэн үйлчилгээ үзүүлэгч хооронд тархсан олон CDN-ийн сан бөгөөд энэ нь гүйцэтгэлийн зорилгоос гадна SEO footprint зорилгод үйлчилдэг; үндсэн WordPress дээр энэ нь эх сурвалжийг идэвхгүй байлгадаг хурдан, сайн ажилладаг давхарга юм.
Үүний доор үндсэн үзүүлэлтүүдийг орхигдуулсангүй. Сайтууд NVMe санах ой болон HTTP/3 дээр ажилладаг бөгөөд ингэснээр кэшээс илгээсэн өгөгдөл нь кэш байхгүй үед ч хурдан хадгалалт бүхий орчин үеийн, олон урсгалт тээвэрлэлтээр дамжин ирдэг. Эдгээр давхаргуудын аль нь ч нэмэлт хэрэгсэл биш юм: LiteSpeed, LSCache, сайт бүрийн Redis, NVMe болон HTTP/3 нь ямар нэгэн нэмэлт төлбөртэй түвшин буюу upsell биш, харин багц бүрийн үндсэн суурь юм.
Core Web Vitals-ийг үнэн хэрэгтээ юу хөдөлгөдөг вэ
Вэб хостинг нь Core Web Vitals үзүүлэлтээрээ ихэвчлэн хэт хөөсөрсөн тайлбартай байдаг тул яг тодорхой байх нь чухал юм. TTFB бол тэгшитгэлийн серверийн хариуцах хэсэг бөгөөд дээр нь байрлах кэшийн стек нь үүнийг бууруулдаг буюу HTTP/3 протоколоор edge сүлжээнээс хүргэгдсэн кэшлэгдсэн бүтэн хуудас нь TTFB-ийг аль болох хамгийн бага түвшинд хүргэдэг. TTFB нь Largest Contentful Paint үзүүлэлтийн эхний эхлэл хэсэг учраас хурдан эх үүсвэр нь дараагийн бүх үзүүлэлтүүдэд өөр ямар ч аргаар авч чадахгүй давуу талыг олгодог.
Гэхдээ LCP, CLS болон INP нь ихэвчлэн хөтөч дээр, хуудасны өөрийнх нь түвшинд шийдэгддэг: оновчгүй болгосон гол зураг, дүрслэлийг саатуулдаг CSS болон JavaScript, фонт болон зар сурталчилгаа ачаалагдах үед байрлал нь өөрчлөгдөх хуудасны бүтэц, мөн залгаасуудын улмаас үндсэн урсгалд үүсэх хүнд ачаалал юм. Серверийн ямар ч хэмжээний кэшлэлт нь 2 МБ хэмжээтэй гол зураг эсвэл олон мегабайт JavaScript агуулсан загварын асуудлыг шийдэж чадахгүй. Шударга хостинг үйлчилгээ нь серверийн гүйцэтгэлийг бараг үнэ төлбөргүй бөгөөд тогтвортой байлгах ба үүний дараа вэбсайтын фронт энд хэсгийг хөнгөн байлгах үүрэг үлддэг.
Хөдөлмөрийн энэ хуваарь бол хэрэгтэй сэтгэхүйн загвар юм. Хүсэлт хөтөч рүү хурдан хүрэх ба ачаалал ихтэй үед ч хурдаа хадгалахыг бид баталгаажуулдаг бол та өгөгдлийн хэмжээг бага, тогтвортой байлгадаг. Энэ хоёр огтлолцох цэг — кэшийг урьдчилан халаах, захын хүргэлт, динамик хуудсууд гацахгүйн тулд өгөгдлийн санг хариу үйлдэл сайтай байлгах — нь манай технологийн стек яг нарийн тааруулагдсан газар бөгөөд энэ платфор дээрх удирдлагатай WordPress нь энгийн вэб байршуулагч дээрх ижил сайттай харьцуулахад илүү хурдан байдаг шалтгаан юм.
Түгээмэл асуултууд
WP Rocket шиг кэшлэх залгаас (plugin) надад одоо ч хэрэгтэй хэвээр байна уу?
Үгүй ээ. Бүрэн хуудасны кэшлэлтийг вэб сервер дээр LiteSpeed-ийн LSCache болон урьдчилан суулгаж автоматаар шинэчлэгддэг манай өөрийн кэш залгаас (plugin) удирддаг бөгөөд энэ нь WordPress-ийг түүнтэй зөв холбож, цаана нь сайт тус бүрийн Redis объектын кэш ажилладаг. Үүний дээр хоёр дахь бүтэн хуудасны кэш залгаас давхар суулгах нь сервер түвшний кэштэй тулгарах хандлагатай байдаг тул тус болдоггүй бөгөөд үүнийг ашиглах шаардлагагүй бөгөөд зөвлөдөггүй.
Кэшлэлт минь WooCommerce сагс эсвэл нэвтэрсэн хуудасны ажиллагааг эвдэх үү?
Үгүй. Сагс, тооцоо хийх хэсэг, миний бүртгэл болон аливаа нонс эсвэл сессийн хуудсууд анхдагчаар кэшээс хасагддаг бөгөөд ESI нь кэшлэгдсэн бусад хуудсууд дээр сагсны хэсэг болон нийт дүнг амьд байдлаар хадгалдаг. Дэлгүүрийн нүүр хуудас кэшээс ачаалж байх үед худалдан авагчид үргэлж өөрсдийн сагс болон ажиллаж буй тооцооны хуудсыг хардаг.
Миний нийтлэх эсвэл засах үед кэш хэрхэн шинэчлэгддэг вэ?
Ухаалаг автомат-цэвэрлэгээ нь холбогдох WordPress дэгээ (hooks) дээр ажилладаг бөгөөд ингэснээр агуулга нийтлэх, засах, эсвэл бүтээгдэхүүн, үнэ, захиалга өөрчлөхөд бүх кэшийг биш зөвхөн нөлөөлөлд өртсөн хуудсууд болон тэгээний архивуудыг цэвэрлэж, улмаар крэйлер (crawler) тэдгээрийг дахин шинэчилдэг. Мөн та хяналтын самбараас эсвэл WordPress дотроос хүссэн үедээ цэвэрлэх боломжтой.
Зөвхөн вэб хостинг ашиглаад л төгс Core Web Vitals үзүүлэлттэй болох боломжтой юу?
Энэ нь серверын хувь болох хамгийн сайн TTFB-ийг өгч, Largest Contentful Paint (LCP)-д давуу тал олгодог. Гэвч LCP, CLS болон INP нь үндсэндээ тухайн хуудас өөрөө буюу зургийн хэмжээ, рендер хийхэд саад болох хөрөнгө, байрлалын тогтвортой байдал, үндсэн урсгал дахь JavaScript-ээс хамаарч шийдэгддэг. Манай технологийн стек серверын гүйцэтгэлийг хурдан бөгөөд тогтвортой байлгадаг бол үлдэгдэл зайг нөхөхийн тулд урд талын ачааллыг хөнгөн байлгах хэрэгтэй.
Холбоотой
14 хоног үнэгүй туршаад үзээрэй
Энийг 14 хоногийн турш ямар ч төлбөрийн картгүйгээр үнэгүй туршаад үзээрэй. Өөрийн байгаа сүлжээнээс шилжүүлж байна уу? Анхны шилжилт бидний бэлэг байх болно.
Үнэгүй эхлэх