Хостинг и перформансе
Како чинимо WordPress брзим: LiteSpeed Enterprise, LSCache и Redis по сајту
Најбржи WordPress захтев је онај који се никада не изврши — ево како наш стек одговара на већину посета из кеша пре него што се PHP или MySQL уопште покрену, и шта то значи за Core Web Vitals.
Најбржи захтев је онај који се никада не покрене
Стандардни WordPress захтев је скуп. Веб-сервер препушта посао PHP-у, PHP покреће WordPress, извршава прикључке, шаље упите бази MySQL неколико десетина пута, склапа HTML и тек тада шаље бајтове назад. На посећеном сајту читав тај процес се одвија за сваког посетиоца, и управо ту одлази готово целокупно ваше време до првог бајта.
Наш одговор је да осигурамо да се, за већину посета, ништа од тога уопште не догоди. На свим сајтовима које хостујемо — преко 100.000 PBN сајтова плус стандардни управљани WordPress — велика већина прегледа страница на корисничком делу сервира се као унапред изрендерована цела страница директно из кеша, без покретања PHP-а или приступа бази података. Остатак ове објаве посвећен је томе како се уклапају слојеви који то омогућавају и где сваки од њих оправдава своје место.
Важно је поставити ствари тако да ово нису кешеви који се међусобно такмиче и између којих бирате. Кеш целе странице, кеш објеката и CDN edge прихватају различите класе захтева, а права вредност лежи у томе како преносе рад један другоме.
LiteSpeed Enterprise + LSCache: слој кеширања целих страница
Сваки сајт ради на LiteSpeed Enterprise систему са LSCache кеширањем на нивоу сервера. Када се одговор корисничког дела може кеширати, веб-сервер га означава LiteSpeed заглављима за контролу кеша и ознакама, а LiteSpeed при следећој посети директно испоручује комплетну страницу — без покретања PHP процеса и без слања MySQL упита. То представља највећу појединачну предност за WordPress TTFB, јер у потпуности уклања покретање апликације са критичне путање.
Пошто се LSCache налази унутар веб-сервера, а не у PHP додатку, он почиње да ради раније у животном циклусу захтева и чува странице у облику који сервер може тренутно да испразни. Пузач кеша (cache crawler) одржава популарне странице спремним, тако да први посетилац након чишћења кеша није онај који плаћа цену поновног генерисања странице. Резултат је знатно нижи и доследнији TTFB у односу на кеш заснован искључиво на додатку надограђеном на генерички стек, где се кеш и даље налази иза PHP-а.
Наш сопствени кеш прикључак на нивоу званичног спремишта долази унапред инсталиран и са аутоматским ажурирањем на сваком сајту, правилно повезујући WordPress са LSCache решењем одмах по покретању. На изворном серверу који није LiteSpeed, он једноставно не шаље заглавља за кеширање целе странице и уклања се са пута, док кеш објеката и правила за изузимање настављају да раде свој посао — тако да мигрирани сајт никада не остаје у нефункционалном, полуконфигурисаном стању.
Останите брзи без сервирања застарелог садржаја: ESI и паметно аутоматско чишћење кеша
Агресивно кеширање целе странице има два класична начина отказивања: приказивање странице другог корисника пријављеном кориснику и приказивање странице која је требало да се промени било коме. Оба проблема се решавају на нивоу кеширања, а не мањим кеширањем.
ESI (Edge Side Includes) нам омогућава да кеширамо страницу док истовремено правимо изузетке за делове који морају остати динамички. На WooCommerce продавници, странице каталога, производа и категорија се испоручују из кеша целе странице за најбржи могући TTFB, док ESI учитава делове корпе, збирне износе мини-корпе и статус налога по сваком захтеву. Корпа, плаћање, мој налог, као и све странице са nonce или сесијским подацима, подразумевано су изузети. Купци увек виде своју сопствену корпу и функционално плаћање; сви остали и даље добијају излог продавнице из кеша.
Ажурност се одржава паметним аутоматским чишћењем. Куке за чишћење се аутоматски покрећу када се промене садржај, производи, цене или поруџбине, па се релевантне кеширане странице освежавају одмах, а не на основу тајмера, а кеш можете очистити и на захтев са контролне табле или директно из WordPress-а. Чишћење на основу ознака значи да уређивање једне објаве брише ту објаву и њене архиве — а не целу кеш меморију — тако да једна измена не доводи до поновног покретања кеша за цео сајт.
Redis кеш објеката по сајту: за оно што не може бити цела страница
Није сваки захтев статична пуна страница. Пријављене сесије, WordPress администрација, WooCommerce корпе, претрага и динамички фрагменти које ESI оставља активним морају да покрећу PHP. За њих се циљ помера са „прескочи апликацију“ на „прескочи базу података“.
Сваки сајт добија сопствени наменски Redis кеш објеката. WordPress кешира резултате поновљених читања из базе података — опције, транзијенте, претраге објава и термина, WooCommerce податке о производима и сесијама — у меморији, тако да се исти упит не извршава над MySQL-ом при свакој посети. Ефекат је највидљивији управо тамо где кеширање целе странице не може да помогне: брже контролне табле, брже корпе и далеко мање оптерећење базе података под саобраћајем.
Кеш објеката се додељује по сајту, а не заједнички, што је важно и за перформансе и за изолацију. У комбинацији са ограничењем базе података по сајту, тешки или лоше написани упити једног сајта не могу ускратити ресурсе базе података његовим суседима. Можете прочитати више о томе како се цела вишеслојна конфигурација уклапа на нашој страници са функцијама кеширања, као и о границама између закупаца у оквиру изолације.
Ивица и транспорт испод ње
Кеш који се налази на изворном серверу и даље мора да путује кроз мрежу. Испред сервера налази се CDN чвориште (edge), па се статички ресурси и кеширане странице испоручују са тачке присуства у близини посетиоца, а изворни сервер остаје растерећен чак и под оптерећењем. За нашу линију хостинга без дигиталног отиска исто чвориште представља вишеструку CDN мрежу распоређену преко неколико провајдера, што поред перформанси остварује и циљ уклањања дигиталног отиска; на стандардном WordPress систему то је једноставно брз, добро конфигурисан слој који одржава изворне сервере у стању мировања.
Испод површине, основе нису занемарене. Сајтови раде на NVMe складишту уз HTTP/3, па бајтови које кеш шаље стижу путем савременог, мултиплексираног преноса уз брзо складиште иза сваког промашаја кеша. Ниједан од ових слојева није додатак: LiteSpeed, LSCache, Redis за сваки сајт, NVMe и HTTP/3 представљају основу на сваком тарифном пакету, а не ниво за додатну продају.
Шта заиста покреће Core Web Vitals
Вреди бити прецизан, јер се хостинг често прецењује када су у питању Core Web Vitals. TTFB је део једначине за који је одговоран сервер, а стеринг кеширања изнад њега је оно што га смањује — кеширана цела страница испоручена преко HTTP/3 протокола са ивице мреже (edge) је приближно најнижи TTFB који се може постићи. Пошто TTFB представља почетну тачку за Largest Contentful Paint, брз изворни сервер даје свим наредним метрикама предност коју иначе не би могле да имају.
Али о LCP, CLS и INP метрикама углавном одлучује сам прегледач, односно сама страница: неоптимизована главна слика (hero image), CSS и JavaScript који блокирају рендеровање, померање изгледа док се фонтови и огласи учитавају, као и оптерећење главне нити (main-thread) од стране додатака. Никаква количина кеширања на серверу не може поправити главну слику од 2 MB или тему која учитава мегабајте JavaScript кода. Поштен хостинг чини допринос сервера практично занемарљивим и доследним, а на самом сајту је да фронтенд одржи лаганим.
Та подела рада представља користан ментални модел. Ми гарантујемо да захтев брзо стиже до прегледача и да остаје брз под саобраћајем; Ви одржавате садржај малим и стабилним. Тачка у којој се то двоје спаја — загревање кеша, испорука на мрежној ивици и одржавање одзива базе података како динамичке странице не би кочиле — управо је оно за шта је наш систем оптимизован, и управо то чини управљани WordPress на овој платформи бржим од истог сајта на генеричком хостингу.
Често постављана питања
Да ли ми је и даље потребан прикључак за кеширање као што је WP Rocket?
Не. Кеширање целе странице на веб-серверу обавља LiteSpeed-ов LSCache, а наш сопствени прикључак за кеширање — унапред инсталиран и аутоматски ажуриран — исправно повезује WordPress са њим, уз Redis кеш објеката за сваки сајт у позадини. Додавање другог прикључка за кеширање целе странице обично долази у сукоб са кешом на нивоу сервера уместо да помаже, тако да није потребно нити се препоручује.
Хоће ли кеширање покварити моју WooCommerce корпу или странице за пријављене кориснике?
Не. Странице корпе, плаћања, корисничког налога (my-account), као и све странице са nonce вредностима или сесијама, подразумевано су искључене из кеша, док ESI одржава сегмент корпе и укупне износе ажурним на страницама које се иначе кеширају. Купци увек виде своју корпу и функционално плаћање, док се излог продавнице и даље учитава из кеша.
Како кеш остаје ажуран када објавим или уредим садржај?
Паметно аутоматско чишћење се покреће на одговарајућим WordPress кукама, па објављивање, уређивање садржаја или промена производа, цене или поруџбине брише само погођене странице и њихове архиве — не и целу кеш меморију — а пописивач их поново загрева. Такође можете извршити чишћење на захтев са контролне табле или директно из WordPress-а.
Може ли само хостинг да ми обезбеди савршене Core Web Vitals?
Ово вам пружа најбољи могући TTFB, што представља удео сервера и почетну предност за Largest Contentful Paint. Међутим, на LCP, CLS и INP у великој мери утиче сама страница — величине слика, ресурси који блокирају рендеровање, стабилност прелома и JavaScript на главној нити. Наш стек чини допринос сервера брзим и уједначеним; одржавање front-end садржаја лаганим је оно што премошћује преостали јаз.
Повезано
Испробајте бесплатно 14 дана
Покрените своје прве сајтове бесплатно на 14 дана — без картице. Премештате постојећу мрежу? Ваша прва миграција је о нашем трошку.
Започните бесплатно