Հոսթինգ և կատարողականություն
Ինչպես ենք մենք 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 և tag վերնագրերով, և LiteSpeed-ը մատուցում է ամբողջական էջը անմիջապես հաջորդ հարցման ժամանակ՝ առանց PHP պրոցեսի գործարկման կամ MySQL հարցման ուղարկման: Դա WordPress TTFB-ի վրա ազդող ամենամեծ գործոնն է, քանի որ այն հեռացնում է հավելվածի ամբողջական բեռնումը հիմնական աշխատանքային հոսքից:
Քանի որ LSCache-ն աշխատում է վեբ սերվերի ներսում, այլ ոչ թե PHP հավելվածում, այն սկսում է գործել հարցման կյանքի ցիկլի ավելի վաղ փուլում և պահպանում է էջերն այնպիսի ձևաչափով, որը սերվերը կարող է ակնթարթորեն բեռնաթափել: Քեշի որոնող բոտը (crawler) ապահովում է հայտնի էջերի մշտական ակտիվությունը, այնպես որ քեշի մաքրումից հետո առաջին այցելուն չէ, որ ստիպված է լինում սպասել էջի վերաստեղծմանը: Արդյունքում TTFB-ն զգալիորեն ցածր է և ավելի կայուն՝ համեմատած ընդհանուր տեխնոլոգիական ստեկի վրա տեղադրված միայն հավելվածային քեշի հետ, որտեղ քեշը դեռևս գտնվում է PHP-ի հետևում:
Մեր սեփական հավաքածուի մակարդակի քեշի փլագինը տեղադրված և ավտոմատ թարմացվող է գալիս յուրաքանչյուր կայքում՝ WordPress-ը միանգամից ճիշտ միացնելով LSCache-ին։ Ոչ LiteSpeed հիմքում այն պարզապես չի ուղարկում ամբողջական էջի վերնագրեր և չի խառնվում, մինչդեռ օբյեկտների քեշը և բացառման կանոններն շարունակում են իրենց աշխատանքը, այնպես որ տեղափոխված կայքը երբեք չի մնում կոտրված, կիսակարգավորված վիճակում։
Արագ մնալ առանց հնացածը մատուցելու. ESI և խելացի ավտոմատ մաքրում
Ամբողջ էջի ագրեսիվ քեշավորումն ունի երկու դասական ձախողման ռեժիմ՝ համակարգ մուտք գործած օգտատիրոջը մեկ այլ անձի էջը ցույց տալը և ցանկացված անձի այնպիսի էջ տրամադրելը, որը պետք է որ փոխված լիներ: Երկուսն էլ լուծվում են քեշավորման շերտում, այլ ոչ թե ավելի քիչ քեշավորելու միջոցով:
ESI-ն (Edge Side Includes) թույլ է տալիս քեշավորել էջը՝ միաժամանակ բացվածքներ թողնելով այն մասերի համար, որոնք պետք է մնան ակտիվ: WooCommerce խանութում կատալոգի, ապրանքի և կատեգորիայի էջերը մատուցվում են որպես ամբողջական էջի քեշ՝ հնարավորինս արագ TTFB-ի համար, մինչդեռ ESI-ն ըստ հարցման մշակում է զամբյուղի հատվածը, մինի զամբյուղի ընդհանուր գումարը և հաշվի կարգավիճակը: Զամբյուղը, վճարման էջը, իմ հաշիվը և ցանկացած nonce կամ սեսիայի էջ լռելյայն բացառված են: Գնորդները միշտ տեսնում են իրենց սեփական զամբյուղը և գործող վճարման էջը, մինչդեռ մյուս բոլորը խանութի վիտրինան ստանում են քեշից:
Թարմությունը կառավարվում է խելացի ավտոմատ մաքրման միջոցով: Մաքրման հուշումներն աշխատում են ինքնաբերաբար, երբ բովանդակությունը, ապրանքները, գները կամ պատվերները փոխվում են, այնպես որ համապատասխան քեշավորված էջերը թարմանում են անմիջապես, այլ ոչ թե ժամանակաչափով, և դուք կարող եք նաև մաքրել ըստ պահանջի վահանակից կամ ներսից WordPress: Պիտակների վրա հիմնված մաքրումը նշանակում է, że մեկ գրառման խմբագրումը մաքրում է այդ գրառումը և դրա արխիվները, այլ ոչ թե ամբողջ քեշը, այնպես որ մեկ խմբագրումը չի սառեցնում ամբողջ կայքը:
Յուրաքանչյուր կայքի համար Redis օբյեկտների շտեմարան՝ այն ամենի համար, ինչը չի կարող ամբողջական էջ լինել
Ոչ մի հարցում չի կարող լինել ստատիկ ամբողջական էջ: Մուտք գործած սեանսները, WordPress ադմինիստրատորը, WooCommerce զամբյուղները, որոնումը և այն դինամիկ հատվածները, որոնք թողնում է ESI-ն, բոլորն էլ պետք է գործարկեն PHP: Դրանց համար նպատակը փոխվում է «բաց թողնել հավելվածը»-ից դեպի «բաց թողնել տվյալների բազան»։
Յուրաքանչյուր կայք ստանում է սեփական նվիրված Redis օբյեկտների քեշ: WordPress-ը հիշողության մեջ քեշավորում է կրկնվող տվյալների բազայի հարցումների արդյունքները՝ ընտրանքներ, ժամանակավոր տվյալներ, գրառումների և տերմինների որոնումներ, WooCommerce-ի ապրանքների և նստաշրջանի տվյալներ, որպեսզի նույն հարցումը չկատարվի MySQL-ի դեմ յուրաքանչյուր այցելության ժամանակ: Արդյունքն ամենաակնառու է հենց այնտեղ, որտեղ ամբողջական էջի քեշը չի կարող օգնել. ավելի արագ վահանակներ, ավելի արագ զամբյուղներ և տվյալների բազայի զգալիորեն ցածր բեռնվածություն տրաֆիկի պայմաններում:
Օբյեկտների քեշը նախատեսված է յուրաքանչյուր կայքի համար առանձին և ընդհանուր չէ, ինչը կարևոր է ինչպես արդյունավետության, այնպես էլ մեկուսացման տեսանկյունից: Յուրաքանչյուր կայքի համար տվյալների բազայի սահմանափակման (throttling) հետ համատեղ՝ մեկ կայքի ծանր կամ սխալ գրված հարցումները չեն կարող սպառել տվյալների բազայի ռեսուրսները հարևան կայքերի համար: Դուք կարող եք կարդալ ավելին այն մասին, թե ինչպես է բազմաշերտ այս ամբողջ համակարգն աշխատում մեր քեշավորման հնարավորությունների էջում, ինչպես նաև վարձակալների միջև սահմանների մասին՝ մեկուսացման բաժնում:
Եզրը և դրա տակ գտնվող տրանսպորտը
Ծագման սերվերում գտնվող քեշը միևնույն է՝ ստիպված է անցնել ցանցով: Սերվերի առջևում տեղադրված է CDN-ի եզրային հանգույցը, ուստի ստատիկ ռեսուրսները և քեշավորվող էջերը մատուցվում են այցելուին մոտ գտնվող ներկայության կետից, և ծագման սերվերը մնում է անխռով նույնիսկ ծանրաբեռնվածության պայմաններում: Մեր Footprint-Free հոսթինգի գծի համար նույն եզրային հանգույցը մի քանի մատակարարների միջև տարածված բազմա-CDN հավաքածու է, որն իրականացնում է ինչպես որոնողական հետքի (footprint) նպատակը, այնպես էլ կատարողականության. ստանդարտ WordPress-ի դեպքում այն պարզապես արագ, լավ աշխատող շերտ է, որը ծագման սերվերներն անգործ է պահում:
Տակից հիմունքները խնայված չեն: Կայքերը աշխատում են NVMe կրիչների վրա HTTP/3-ով, այնպես որ այն բայթերը, որոնք քեշն իրականում ուղարկում է, տեղ են հասնում ժամանակակից, մուլտիպլեքսային տրանսպորտով՝ ցանկացած քեշի բացթողման հետևում գտնվող արագ կրիչով: Այս շերտերից ոչ մեկը հավելում չէ. LiteSpeed-ը, LSCache-ը, յուրաքանչյուր կայքի համար նախատեսված Redis-ը, NVMe-ն և HTTP/3-ը հիմնական չափանիշ են յուրաքանչյուր պլանում, այլ ոչ թե հավելավճարային մակարդակ:
Իrine իրականում ազդում Core Web Vitals-ի վրա
Արժե լինել ճշգրիտ, քանի որ հոսթինգը հաճախ չափազանցված է ներկայացվում Core Web Vitals-ի մասով: TTFB-ն հավասարման այն մասն է, որի համար պատասխանատու է սերվերը, իսկ քեշավորման стек-ը դրանից վերև այն է, ինչ նվազեցնում է այն. edge-ից HTTP/3-ով մատուցվող քեշավորված ամբողջական էջը TTFB-ի հնարավոր ամենացածր ցուցանիշն է: Քանի որ TTFB-ն Largest Contentful Paint-ի առաջատար եզրն է, արագ ծագման սերվերը (origin) յուրաքանչյուր հաջորդական մետրիկայի տալիս է այնպիսի առավելություն, որն այլ կերպ հնարավոր չէ ստանալ:
Սակայն LCP-ն, CLS-ը և INP-ն հիմնականում որոշվում են դիտարկիչում՝ հենց էջի կողմից. չօպտիմալացված գլխավոր պատկերը, ռենդերավորումը արգելափակող CSS-ը և JavaScript-ը, տառատեսակների ու գովազդների բեռնման ժամանակ փոփոխվող դասավորությունը և փլագինների պատճառով հիմնական հոսքի (main-thread) ծանր աշխատանքը: Սերվերային քեշավորման ոչ մի ծավալ չի ուղղի 2 ՄԲ-անոց գլխավոր պատկերը կամ թեման, որը փոխանցում է մեգաբայթերով JavaScript: Ազնիվ հոսթինգը սերվերի ներդրումը դարձնում է արդյունավետորեն անվճար և կայուն, իսկ այնուհետև կայքից է կախված user-facing հատվածը (front end) թեթև պահելը:
Այդ աշխատանքի բաժանումը օգտակար մտավոր մոդել է։ Մենք երաշխավորում ենք, որ հարցումը արագ հասնի բրաուզերին և արագ մնա տրաֆիկի պայմաններում. դուք պահպանում եք փոխանցվող տվյալների ծավալը փոքր և կայուն: Այնտեղ, gdzie հանդիպում են այդ երկուսը՝ քեշի տաքացում, եզրային առաքում և տվյալների բազայի պատասխանատու պահպանում, որպեսզի դինամիկ էջերը չկանգնեն, հենց այն տեղն է, որտեղ մեր ստեկը լարված է, և հենց դա է, որ WordPress-ի կառավարվող հոսթինգն այս հարթակում ավելի արագ է դարձնում, քան նույն կայքը ընդհանուր հոսթինգում:
Հաճախ տրվող հարցեր
Արդյո՞ք ինձ դեռ անհրաժեշտ է քեշավորման փլագին, ինչպիսին է WP Rocket-ը:
Ոչ։ Ամբողջ էջի քեշավորումը կառավարվում է վեբ սերվերի մակարդակով LiteSpeed-ի LSCache-ի և մեր սեփական քեշի հավելվածի միջոցով (նախապես տեղադրված և ավտոմատ թարմացվող), որը ճիշտ է միացնում WordPress-ը դրան՝ յուրաքանչյուր կայքի համար նախատեսված Redis օբյեկտային քեշով: Երկրորդ ամբողջ էջի քեշավորման հավելվածը վերևից ավելացնելը սովորաբար հակասում է սերվերի մակարդակի քեշին, քան օգնում, ուստի այն անհրաժեշտ չ է և խորհուրդ չի տրվում։
Արդյոք քեշավորումը կխափանի իմ WooCommerce զամբյուղը կամ մուտք գործած օգտատերերի էջերը:
Ոչ։ Զամբյուղը, վճարումը, my-account և ցանկացած nonce կամ սեսիայի էջ լռելյայն բացառվում են քեշից, իսկ ESI-ն պահում է զամբյուղի ֆրագմենտը և գումարները ակտիվ այլ կերպ քեշավորված էջերում: Գնորդները միշտ տեսնում են իրենց սեփական զամբյուղը և աշխատող վճարման էջը, մինչ խանութի վիտրինան դեռ բեռնվում է քեշից:
Ինչպ՞ս է քեշը թարմ մնում, երբ հրապարակում կամ խմբագրում եմ:
Խելացի ավտոմատ մաքրումը գործարկվում է համապատասխան WordPress հուկերով, ուստի բովանդակության հրապարակումը, խմբագրումը կամ ապրանքի, գնի կամ պատվերի փոփոխությունը մաքրում է միայն տուժած էջերը և դրանց արխիվները, այլ ոչ թե ամբողջ քեշը, և սողունը (crawler) կրկին տաքացնում է դրանք: Կարող եք նաև մաքրել ըստ պահանջի վահանակից կամ WordPress-ի ներսից:
Կարո՞ղ է արդյոք միայն հոսթինգն ինձ ապահովել կատարյալ Core Web Vitals:
Այն ապահովում է հնարավորինս լավագույն TTFB, որը սերվերի բաժինն է և առավելություն՝ Largest Contentful Paint-ի համար: Սակայն LCP-ն, CLS-ը և INP-ն մեծ մասամբ որոշվում են հենց էջի կողմից՝ պատկերների չափեր, վերծանումը խոչընդոտող ռեսուրսներ, էջի կառուցվածքի կայունություն և հիմնական հոսքի (main-thread) JavaScript: Մեր տեխնոլոգիական հենքը սերվերի աշխատանքը դարձնում է արագ և կայուն. առջևի վերջնակետի (front-end) ծանրաբեռնվածությունը փոքր պահելն այն է, ինչը լրացնում է մնացած բացը:
Առնչվող
Փորձեք անվճար 14 օրով
Գործարկե՛ք ձեր առաջին կայքերն անվճար 14 օրվա ընթացքում՝ առանց քարտի: Տեղափոխո՞ւմ եք գոյություն ունեցող ցանց: Ձեր առաջին միգրացիան մեր հաշվին է:
Սկսեք անվճար