Хостинг және өнімділік
WordPress-ті қалай жылдамдатамыз: LiteSpeed Enterprise, LSCache және әр сайтқа арналған Redis
Ең жылдам WordPress сұранысы — мүлде орындалмайтын сұраныс: мұнда біздің стек PHP немесе MySQL іске қосылғанға дейін көптеген кірулерге кэштен қалай жауап беретіні және бұл Core Web Vitals үшін нені білдіретіні көрсетілген.
Ең жылдам сұраныс — ешқашан орындалмайтын сұраныс
Қалыпты WordPress сұранысы өте көп ресурс талап етеді. Веб-сервер сұранысты PHP-ге тапсырады, PHP WordPress-ті жүктейді, плагиндерді іске қосады, MySQL-ге бірнеше ондаған рет сұрау жібереді, HTML жинайды және содан кейін ғана байттарды кері жібереді. Жүктемесі көп сайтта бұл бүкіл процесс әрбір келуші үшін қайталанады және сіздің алғашқы байтты алу уақытыңыздың (TTFB) барлығы дерлік осы кезеңде кетеді.
Біздің шешіміміз — кірулердің көпшілігінде осының ешқайсысы мүлдем орын алмауын қамтамасыз ету. Біз хостинг қызметін ұсынатын сайттар бойынша — 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 немесе сессия беттері әдепкі бойынша қосылмайды. Сатып алушылар әрқашан өз себетін және жұмыс істеп тұрған төлем бетін көреді; ал витринаны барлығы бұрынғысынша кэштен алады.
Жаңа күйде сақтау ақылды автоматты тазалау арқылы орындалады. Мазмұн, өнімдер, бағалар немесе тапсырыстар өзгерген кезде тазалау ілмектері автоматты түрде іске қосылады, сондықтан кэштелген қажетті беттер таймер бойынша емес, бірден жаңартылады, сондай-ақ басқару тақтасынан немесе WordPress ішінен сұраныс бойынша тазалауды орындай аласыз. Тегтерге негізделген тазалау бір жазбаны өңдеу барлық кэшті емес, тек сол жазба мен оның архивтерін тазартатынын білдіреді, сондықтан жалғыз өңдеу бүкіл сайтты нөлден қайта жүктелуге («суық іске қосуға») мәжбүрлемейді.
Әр сайтқа арналған Redis нысандық кэші: толық бет бола алмайтын деректер үшін
Әрбір сұраныс статикалық толық бет бола алмайды. Жүйеге кірген сеанстар, WordPress әкімшісі, WooCommerce себеттері, іздеу және ESI белсенді қалдыратын динамикалық үзінділердің барлығы PHP-ді іске қосуы керек. Олар үшін мақсат «қолданбаны өткізіп жіберуден» «деректер базасын өткізіп жіберуге» ауысады.
Әрбір сайт өзінің жеке Redis нысандық кэшіне ие болады. WordPress дерекқордан қайталанатын оқу нәтижелерін — опцияларды, транзиенттерді, жазбалар мен терминдерді іздеуді, WooCommerce өнімдері мен сессия деректерін — жадта кэштейді, сондықтан бірдей сұрау әрбір кіру кезінде MySQL жүйесіне қайта жіберілмейді. Бұл әсер толық беттік кэш көмектесе алмайтын жерлерде ерекше байқалады: басқару тақталары жылдамырақ жұмыс істейді, себеттер жедел жаңартылады және трафик кезінде дерекқорға түсетін жүктеме айтарлықтай төмендейді.
Нысан кэші ортақ емес, әр сайтқа жеке беріледі, бұл өнімділік үшін де, оқшаулау үшін де өте маңызды. Әр сайтқа арналған дерекқор сұраныстарын шектеу жүйесімен біріктірілгендіктен, бір сайттың ауыр немесе дұрыс жазылмаған сұраныстары көрші сайттар үшін дерекқор ресурстарын тауыса алмайды. Сіз бүкіл көпдеңгейлі жүйенің қалай өзара әрекеттесетіні туралы кэштеу мүмкіндіктері бетінен және оқшаулау кезіндегі клиенттер арасындағы шекаралар туралы толығырақ оқи аласыз.
Шет және оның астындағы көлік
Бастапқы серверде сақталатын кэш бәрібір желі арқылы өтуі керек. Сервердің алдында CDN шеті (edge) орналасқан, сондықтан статикалық ресурстар мен кэштелетін беттер пайдаланушыға жақын орналасқан қатысу нүктесінен көрсетіледі, ал бастапқы сервер тіпті жүктеме кезінде де тыныш күйде қалады. Біздің із қалдырмайтын (footprint-free) хостинг желіміз үшін дәл осы шет бірнеше провайдерлер арасында бөлінген 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 жүктейтін тақырыпты түзей алмайды. Адал хостинг сервердің әсерін іс жүзінде біркелкі әрі байқалмайтын етеді, ал одан кейін фронтендтің жеңіл болуын қамтамасыз ету сайттың өз жауапкершілігінде болады.
Бұл еңбек бөлінісі — пайдалы менталдық модель. Біз сұраныстың браузерге жылдам жетуіне және жоғары трафик кезінде де жылдам қалуына кепілдік береміз; ал сіз деректер көлемінің (payload) шағын әрі тұрақты болуын қамтамасыз етесіз. Екі жақтың түйісетін тұсы — кэшті жылыту (cache warm-up), edge арқылы жеткізу және динамикалық беттер бөгелмес үшін дерекқордың жауап беру жылдамдығын сақтау — дәл біздің стегіміз бапталған сала болып табылады және осы платформадағы басқарылатын 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-ке байланысты анықталады. Біздің стек сервердің жұмысын жылдам әрі тұрақты етеді; ал қалған айырмашылықты жою үшін фронтенд көлемін шағын ұстау қажет.
Байланысты
14 күн бойы тегін қолданып көріңіз
Алғашқы сайттарыңызды 14 күн бойы тегін іске қосыңыз — карта қажет емес. Қолданыстағы желіні көшіресіз бе? Көшіру тегін және шектеусіз жүзеге асырылады.
Тегін бастау