Հոսթինգ և արտադրողականություն
Ինչպես ենք արագացնում 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. ամբողջական էջի շերտը
Յուրաքանչյուր կայք աշխատում է LiteSpeed Enterprise-ի վրա՝ սերվերի մակարդակի LSCache-ով: Երբ ֆրոնտենդի պատասխանը ենթակա է քեշավորման, վեբ սերվերը այն դրոշմում է LiteSpeed cache-control և թեգերի վերնագրերով, իսկ LiteSpeed-ը հաջորդ հարցման դեպքում ամբողջական էջը մատուցում է անմիջապես՝ առանց PHP գործընթաց գործարկելու, առանց MySQL հարցում կատարելու: Սա WordPress TTFB-ի վրա ազդող ամենամեծ առանձին լծակն է, քանի որ այն կրիտիկական ուղուց ամբողջությամբ հեռացնում է հավելվածի բեռնումը:
Քանի որ LSCache-ը գործում է անմիջապես վեբ սերվերի ներսում, այլ ոչ թե PHP փլագինում, այն սկսում է աշխատել հարցման կենսացիկլի ավելի վաղ փուլում և էջերը պահում է այնպիսի ձևաչափով, որը սերվերը կարող է ակնթարթորեն մաքրել: Քեշի կրոլերը պահպանում է հանրաճանաչ էջերի ակտիվությունը («տաք» վիճակը), որպեսզի քեշի մաքրումից հետո առաջին այցելուն ստիպված չլինի սպասել էջի վերագեներացմանը: Արդյունքը զգալիորեն ավելի ցածր և կայուն TTFB-ն է՝ համեմատած ընդհանուր ստեկին ավելացված միայն փլագինային քեշի հետ, որտեղ քեշը դեռ գտնվում է PHP-ի հետևում:
Մեր սեփական ռեպո-մակարդակի քեշավորման փլագինը գալիս է նախապես տեղադրված և ավտոմատ թարմացվող յուրաքանչյուր կայքում՝ WordPress-ը ի սկզբանե ճիշտ կապելով LSCache-ի հետ։ Ոչ LiteSpeed սկզբնաղբյուրի վրա այն պարզապես չի թողարկում ամբողջական էջի վերնագրեր և չի խոչընդոտում աշխատանքին, մինչդեռ օբյեկտների քեշը և բացառման կանոնները շարունակում են կատարել իրենց աշխատանքը, հետևաբար տեղափոխված կայքը երբեք չի մնում կիսատ կարգավորված կամ խաթարված վիճակում։
Արագության պահպանում առանց հնացած բովանդակություն մատուցելու. ESI և խելացի ավտոմատ մաքրում
Էջերի ամբողջական ագրեսիվ քեշավորումն ունի խափանման երկու դասական եղանակ՝ մուտք գործած օգտատիրոջը ուրիշի էջը ցուցադրելը և որևէ մեկին այնպիսի էջ ցուցադրելը, որը պետք է փոխված լիներ: Երկուսն էլ լուծվում են քեշավորման մակարդակում, ոչ թե ավելի քիչ քեշավորելու միջոցով:
ESI-ն (Edge Side Includes) թույլ է տալիս մեզ պահել էջը քեշում՝ միաժամանակ բացառություններ անելով այն մասերի համար, որոնք պետք է մնան դինամիկ: WooCommerce խանութում կատալոգի, ապրանքների և կատեգորիաների էջերը մատուցվում են որպես ամբողջական էջի քեշ՝ հնարավոր ամենաարագ TTFB-ի համար, մինչդեռ ESI-ն յուրաքանչյուր հարցման դեպքում մշակում է զամբյուղի հատվածը, մինի-զամբյուղի ընդհանուր գումարը և հաշվի կարգավիճակը: Զամբյուղի, վճարման, իմ հաշվի և ցանկացած nonce-ի կամ սեսիայի էջեր լռելյայն բացառված են: Գնորդները միշտ տեսնում են իրենց սեփական զամբյուղը և գործող վճարման համակարգը. յուրաքանչյուր ոք շարունակում է ստանալ խանութի ցուցափեղկը քեշից:
Թարմությունը կարգավորվում է խելացի ավտոմատ մաքրման (auto-purge) միջոցով: Մաքրման կարթերը (purge hooks) գործարկվում են ավտոմատ կերպով, երբ փոխվում են բովանդակությունը, ապրանքները, գները կամ պատվերները, ուստի համապատասխան քեշավորված էջերը թարմացվում են անմիջապես, այլ ոչ թե ըստ ժամանակացույցի, ինչպես նաև Դուք կարող եք կատարել մաքրում ըստ պահանջի՝ կառավարման վահանակից կամ WordPress-ի ներսից: Թեգերի վրա հիմնված մաքրումը նշանակում է, որ մեկ գրառման խմբագրումը մաքրում է միայն այդ գրառումը և դրա արխիվները, ոչ թե ամբողջ քեշը, ուստի մեկ խմբագրումը չի առաջացնում ամբողջ կայքի «սառը մեկնարկ» (cold-start):
Redis օբյեկտների քեշ յուրաքանչյուր կայքի համար․ այն ամենի համար, ինչը չի կարող լինել ամբողջական էջ
Ոչ բոլոր հարցումները կարող են լինել ստատիկ ամբողջական էջ: Մուտք գործած սեսիաները, WordPress-ի ադմինիստրատորը, WooCommerce-ի զամբյուղները, որոնումը և դինամիկ հատվածները, որոնք ESI-ն թողնում է ակտիվ, բոլորը պետք է գործարկեն PHP: Դրանց համար նպատակը փոխվում է «բաց թողնել հավելվածը»-ից դեպի «բաց թողնել տվյալների բազան»:
Յուրաքանչյուր կայք ստանում է իր հատուկ Redis օբյեկտների քեշը: WordPress-ը հիշողության մեջ քեշավորում է տվյալների բազայի կրկնվող ընթերցումների արդյունքները՝ կարգավորումները, ժամանակավոր տվյալները (transients), գրառումների և տերմինների որոնումները, WooCommerce-ի ապրանքների և սեսիաների տվյալները, որպեսզի նույն հարցումը չկատարվի MySQL-ի վրա յուրաքանչյուր այցելության ժամանակ: Արդյունքն առավել նկատելի է հենց այնտեղ, որտեղ էջի ամբողջական քեշը չի կարող օգնել՝ ավելի արագ կառավարման վահանակներ, ավելի արագ զամբյուղներ և տվյալների բազայի զգալիորեն ավելի ցածր ծանրաբեռնվածություն տրաֆիկի դեպքում:
Օբյեկտների քեշը նախատեսված է յուրաքանչյուր կայքի համար առանձին և համատեղ չի օգտագործվում, ինչը կարևոր է թե՛ արտադրողականության, թե՛ մեկուսացման համար: Յուրաքանչյուր կայքի համար տվյալների բազայի սահմանափակման հետ համատեղ՝ մեկ կայքի ծանր կամ վատ գրված հարցումները չեն կարող զրկել հարևաններին տվյալների բազայի ռեսուրսներից: Կարող եք ավելին կարդալ այն մասին, թե ինչպես է գործում ամբողջ բազմաշերտ համակարգը մեր քեշավորման գործառույթների էջում, ինչպես նաև վարձակալների միջև սահմանների մասին՝ մեկուսացման բաժնում:
Եզրը և դրա տակ գտնվող տրանսպորտը
Հիմնական սերվերում պահվող քեշը դեռևս պետք է անցնի ցանցով: Սերվերի առջև տեղակայված է CDN եզրը (edge), ուստի ստատիկ ռեսուրսները և քեշավորվող էջերը մատուցվում են այցելուին մոտ գտնվող ներկայության կետից, իսկ հիմնական սերվերը մնում է հանգիստ նույնիսկ ծանրաբեռնվածության պայմաններում: Մեր առանց թվային հետքի (footprint-free) հոսթինգի գծի համար նույն այդ եզրը multi-CDN միավորում է՝ բաշխված մի քանի մատակարարների միջև, ինչը ծառայում է ինչպես թվային հետքը թաքցնելու, այնպես էլ արտադրողականության նպատակին. սովորական WordPress-ում այն պարզապես արագ և արդյունավետ շերտ է, որը հիմնական սերվերները պահում է պարապուրդի մեջ:
Հիմքում ընկած բաղադրիչների վրա ոչինչ չի խնայվել։ Կայքերն աշխատում են NVMe պահոցի վրա HTTP/3-ով, ուստի քեշի ուղարկած բայթերը տեղ են հասնում ժամանակակից, մուլտիպլեքսային փոխադրման միջոցով, իսկ քեշի ցանկացած բացթողման (cache miss) հետևում կանգնած է արագ պահոցը։ Այս շերտերից ոչ մեկը վճարովի հավելում չէ․ 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 է առաքում: Ազնիվ հոսթինգը սերվերի ներդրումը դարձնում է գործնականում անվճար և կայուն, որից հետո կայքի պատասխանատվությունն է պահպանել ֆրոնտենդի թեթևությունը:
Աշխատանքի այդ բաժանումն օգտակար մտային մոդել է: Մենք երաշխավորում ենք, որ հարցումը բրաուզերին հասնում է արագ և մնում է արագ նույնիսկ մեծ երթևեկության պայմաններում. դուք ապահովում եք, որ տվյալների ծավալը լինի փոքր և կայուն: Այնտեղ, որտեղ այս երկուսը հանդիպում են՝ քեշի տաքացում (cache warm-up), եզրային առաքում (edge delivery) և տվյալների բազայի արձագանքման արագության պահպանում, որպեսզի դինամիկ էջերը չհապաղեն, հենց այն կետն է, որտեղ մեր ստեկը կարգավորված է, և դա է այն, ինչ կառավարվող WordPress-ն այս հարթակում դարձնում է ավելի արագ, քան նույն կայքը սովորական հոսթինգում:
Հաճախ տրվող հարցեր
Արդյո՞ք ինձ դեռ պետք է քեշավորման փլագին, ինչպիսին է WP Rocket-ը:
Ոչ։ Ամբողջական էջի քեշավորումը վեբ սերվերում իրականացվում է LiteSpeed-ի LSCache-ի կողմից, իսկ մեր սեփական քեշ փլագինը, որը նախապես տեղադրված է և ավտոմատ թարմացվող, ճիշտ կերպով կապում է WordPress-ը դրա հետ՝ յուրաքանչյուր կայքի համար ֆոնային ռեժիմում ունենալով Redis օբյեկտների քեշ։ Դրա վրա ամբողջական էջի քեշավորման երկրորդ փլագին ավելացնելը սովորաբար օգնելու փոխարեն հակասում է սերվերի մակարդակի քեշին, ուստի դա անհրաժեշտ չէ և խորհուրդ չի տրվում։
Արդյո՞ք քեշավորումը կխաթարի իմ WooCommerce զամբյուղի կամ մուտք գործած էջերի աշխատանքը:
Ոչ: Զամբյուղը, վճարման էջը, my-account-ը և ցանկացած nonce կամ սեսիայի էջեր լռելյայն բացառված են քեշից, իսկ ESI-ն ապահովում է զամբյուղի հատվածի և ընդհանուր գումարների թարմացումը մյուս քեշավորված էջերում: Գնորդները միշտ տեսնում են իրենց զամբյուղը և աշխատող վճարման էջը, մինչ խանութի ցուցափեղկը դեռ բեռնվում է քեշից:
Ինչպե՞ս է քեշը մնում թարմ, երբ ես հրապարակում կամ խմբագրում եմ:
Խելացի ավտոմատ մաքրումը գործարկվում է համապատասխան WordPress hook-երի վրա, ուստի բովանդակության հրապարակումը, խմբագրումը կամ ապրանքի, գնի կամ պատվերի փոփոխությունը մաքրում է միայն ազդակիր էջերը և դրանց արխիվները, ոչ թե ամբողջ քեշը, իսկ կրոլերը կրկին տաքացնում է դրանք: Դուք կարող եք նաև մաքրում կատարել ըստ պահանջի՝ կառավարման վահանակից կամ WordPress-ի ներսից:
Կարո՞ղ է միայն հոսթինգն ինձ ապահովել կատարյալ Core Web Vitals:
Սա ձեզ տալիս է հնարավոր լավագույն TTFB-ն, որը սերվերի մասնաբաժինն է և մեկնարկային առավելություն Largest Contentful Paint-ի համար։ Սակայն LCP-ն, CLS-ը և INP-ն հիմնականում որոշվում են հենց էջի կողմից՝ պատկերների չափսերը, ռենդերինգը արգելափակող ռեսուրսները, դասավորության կայունությունը և հիմնական հոսքի JavaScript-ը։ Մեր սթեքը սերվերի ներդրումը դարձնում է արագ և կայուն․ front-end-ի ծավալը թեթև պահելն այն է, ինչ վերացնում է մնացած տարբերությունը։
Հարակից
Փորձեք այն անվճար 14 օր
Գործարկեք ձեր առաջին կայքերն անվճար 14 օրով — առանց քարտի։ Տեղափոխո՞ւմ եք գոյություն ունեցող ցանցը։ Տեղափոխումներն անվճար են և անսահմանափակ։
Սկսեք անվճար