WordPress-ի քեշավորման օպտիմալացում

Վեբկայքի դանդաղության հիմնական պատճառը սովորաբար ոչ թե մեկ պատկերն է, այլԽնդրում եք՝ երթուղավորում + սերվերային կողմի գեներացիա + ստատիկ ռեսուրսների առաքումԾածկման արդյունքում առաջացած:

• Օգտատերերը շատ հեռու են ձեր սերվերից, ինչի արդյունքում ցանցային RTT-ն բարձր է (այսը հատկապես նկատելի է մայրցամաքների միջև)
• WordPress յուրաքանչյուր հարցման համար գործարկում է PHP, հարցնում է տվյալների բազան, ցուցադրում է ձևանմուշը → TTFB (առաջին բայթի ստացման ժամանակը) աճել է
• Էջը նաև պետք է բեռնի JavaScript, CSS, տառատեսակներ և երրորդ կողմի սցրիպտներ, ինչը դանդաղեցնում է ցուցադրման և փոխազդեցության արագությունը։

Քեշավորման պլագինԱյս խնդրի լուծման բանալին կայանում է “կրկնակի հաշվարկների” ենթակա էջերի արդյունքները պահպանելու մեջ, որպեսզի սերվերը ստիպված չլինի դրանք յուրաքանչյուր անգամ նորից հաշվարկել, և համապատասխան ռազմավարություններ կիրառելով ապահովել, որ ավելի շատ օգտվողներ դիմեն քեշին, ինչի շնորհիվ զգալիորեն կրճատվի TTFB-ն։WordPress պաշտոնական փաստաթղթավորումԱյն նաև նշում է, որ W3 Total Cache-ի և WP Super Cache-ի նման պլագինները կարող են էջերը պահել որպես ստատիկ ֆայլեր և անմիջապես մատուցել օգտվողներին, այդպիսով նվազեցնելով սերվերի բեռը։

Այս էջը կարդալուց առաջ հիշեք այս երեք ոսկե կանոնները։

Միաժամանակ օգտագործեք միայն մեկ էջերի պահպանումն ապահովող պլագին։

Երբ միաժամանակ միացված են մի քանի քեշավորման պլագիններ, ամենահաճախ հանդիպող արդյունքը ոչ թե ավելի արագ կատարման արագությունն է, այլ՝

• Կեշի կանոնների հատումը, կեշերի միմյանց գերակշռելը և կեշի հիթերի ցուցանիշների անկումը
• Դինամիկ բովանդակությունը, ինչպիսիք են մուտքի կարգավիճակը, լեզուն, գնումների զամբյուղը և գները, պահվում են քեշում, ինչը հանգեցնում է “incorrect content” սխալների։
  Շատ պլագինների փաստաթղթերն ու ուղեցույցները խորհուրդ են տալիս, որ երբ օգտագործում եք կոնկրետ քեշավորման պլագին,Անջատեք մյուս քեշավորման պլագիններըհակամարտությունից խուսափելու համար

2. Առցանց առևտրի/անդամակցության/բազմալեզու կայքեր: Քեշավորումը “փոխիչ” չէ, այլ “կանոնների համակարգ”։”

WooCommerce-ի պաշտոնական կատարողականության փաստաթղթավորումԽնդրում ենք նկատի ունենալ՝ քեշավորման պլագինում համոզվեք, որ Գնումների զամբյուղ / Վճարում / Հաշիվ Համոզվեք, որ այս էջերը չեն պահպանվում քեշում, և խորհուրդ է տրվում նաև խուսափել JavaScript ֆայլերի մինիֆիկացումից (քանի որ դա հեշտությամբ կարող է առաջացնել համատեղելիության խնդիրներ):

3. “Քեշի հավելումը ≠ CDN”, սակայն քեշի հավելումը CDN-ի հիմքն է

Քեշավորման պլագինը լուծում է սկզբնային սերվերի կողմից թերահաշվարկման խնդիրը։CDN Լուծել “բովանդակությունը օգտատիրոջը ավելի մոտ է” խնդիրը։ Երկուսի միջև կա շերտավորման կապ․ նախ պետք է իջեցնել սկզբնական կայքի TTFB-ը, ապա ստատիկ ռեսուրսների տարածումը հանձնել CDN-ին․ սա է գլոբալ օգտատերերին ուղղված ամենակայուն ուղին։

Արագ ընտրություն. Վեբկայքի 4 ամենատարածված սցենարներ

Եթե չեք ուզում ամբողջ հոդվածը կարդալ, պարզապես ընտրեք ստորև ներկայացված չորս տարբերակներից մեկը՝ սխալվել չեք կարող։

1. Որոնում եմ հոգու խաղաղություն, հուսալիություն և համաշխարհային մատչելիություն → WP Rocket(Վճարված)
2. Սերվերը անշուշտ աշխատում է LiteSpeed/OpenLiteSpeed-ով։ → ԼայթՍպիդ Քեշ(Անվճար, սակայն մեծապես կախված է սերվերի հզորությունից)Պահոցավորման ֆունկցիոնալությունը պահանջվում է LiteSpeed սերվերի բաղադրիչներկարողանալ աշխատել
3. Բովանդակային կայքեր/բլոգեր/փաստաթղթերի պահոցներ փնտրում են անվճար և հուսալի լուծում → WP Super Cache(Ստատիկ HTML պահպանում)Չմուտք գործած օգտվողների մեծամասնության համար ստատիկ HTML ֆայլեր գեներացնել։
4. Ունեք տեխնիկական թիմ և պետք է մանրակրկիտ վերահսկում՝ CDN/օբյեկտի քեշ/բազմամոդուլային → W3 ընդհանուր քեշ(Ուժեղ, բայց բարդ)Հիմնական՝ համապարփակ կատարողականության շրջանակ և CDN ինտեգրում

Քեշը ճիշտ ինչ է պահում?

“Ինչու՞ են որոշ կայքեր դեռ դանդաղում, նույնիսկ cache տեղադրելուց հետո?” Մենք WordPress-ի կատարողականությունը բաժանել ենք հինգ շերտերի:

1. Դիտարկիչի քեշՀաջորդ այցերը արագացրեք (ստատիկ ռեսուրսների քեշավորման գլխագրեր, տարբերակների համարներ)
2. Էջերի պահպանումԷջի ելքը պահպանեք որպես HTML (այս էջի ուշադրության կենտրոնը)
3. Օբյեկտների քեշՏվյալների բազայի հարցումների արդյունքների պահպանում (հատկապես արժեքավոր է դինամիկ կայքերի համար)
4. PHP OPcache: Կեշավորել PHP բայթ բայթկոդ (սովորաբար կարգավորվում է սերվերի կողմից; պլագինի հիմնական առանձնահատկությունը չէ)
5. CDN/Էջի քեշ: Տեղադրեք ռեսուրսները օգտվողների մոտ գտնվող հանգույցներում

Այս հոդվածը կենտրոնացած է էջերի քեշավորման պլագինների վրա։
Բայց մենք շարունակելու ենք հիշեցնել ձեզ՝ կայքերն իսկապես արագ լինելու համար հաճախ պահանջում են 2-ի և 5-ի համադրություն։

Պլագին 1:WP Rocket(Վճարովի) — “Առանց անհանգստության” ամբողջական լուծում

WP Rocket-ը WordPress համայնքում հանրաճանաչ է ոչ թե այն պատճառով, որ այն կախարդական է, այլ այն պատճառով, որ այն երեք ամենատարածված կատարողական օպտիմալացման տեսակները փաթեթավորել է “կառավարելի փաթեթների” մեջ։

• Էջերի քեշավորում (սկզբնային սերվերի TTFB-ի նվազեցում)
• Քեշի նախաբեռնում/տաքացում (աշխարհի տարբեր վայրերից կայք մուտք գործող օգտվողների առաջին այցի փորձը բարելավելու համար)
• Հիմնական ֆրոնտենդ օպտիմալացումներ (հատկապես JS-ի հետաձգում, CSS-ի մշակում և այլն)

ՆրաՊաշտոնական փաստաթղթավորումԱյն նաև հստակ նշում է, որ նույնիսկ եթե անջատեք էջերի քեշավորումը, նախաբեռման ակտիվացումը կարող է դեռևս գործարկել կամ խթանել որոշ օպտիմալացման գործընթացներ (օրինակ՝ CSS-ի և JavaScript-ի հետ կապված օպտիմալացումներ):

1.1 WP Rocket-ը ում համար է հարմար?

WP Rocket-ը հատկապես հարմար է հետևյալ տեսակի կայքերի համար:

• Կորպորատիվ կայքեր, բրենդային կայքեր, բովանդակային մարքեթինգային կայքեր, վայրէջքի էջեր (բազմաթիվ երկրներից և տարածաշրջաններից եկող երթևեկություն)
• Ես նախընտրում եմ արագ գործարկում՝ կայունությունը որպես գերակա առաջնահերթություն, քան հույս դնել անվճար պլագինների խառնաշփոթի վրա։
• Մենք չունենք նվիրված օպերացիաների կամ կատարողականության ինժեներ, սակայն ունենք պահանջներ օգտվողի փորձի և SEO-ի վերաբերյալ։
• Ուու-կոմերս Այն կարելի է օգտագործել, սակայն ավելի մեծ զգուշությամբ (ինչպես այս բաժնում հետագայում կքննարկվի)Կանոններ և ռիսկեր）

1.2. Վեբկայքերի զննման սցենարներում դրա հիմնական արժեքը (ոչ միայն “կեշի անջատիչ”)

A. Քեշի նախաբեռնում. լուծում է “առաջին այցերի ժամանակ բաշխված վեբ-թրաֆիկի պատճառով առաջացող անկայունության” խնդիրը”

Երբ կայքի օգտատերերը բաշխված են տարբեր վայրերում, դուք կհանդիպեք շատ տարածված դանդաղության տեսակին։
Երբ օգտվողը որոշակի տարածաշրջանում առաջին անգամ բացում է էջը, և այդ էջի քեշը ավարտվել է կամ երբեք նախապես չի բեռնվել → այդ օգտվողը կրում է PHP/DB ամբողջական ռենդերացման ծախսը։
Նախաբեռման մեխանիզմԱյդ բառերի նշանակությունը հետևյալն է՝Նախապես վճարեք “սկզբնական կառուցման” արժեքը։, այդպիսով նվազեցնելով առաջին անգամ այցելողների փորձարկման առարկա դառնալու հավանականությունը։

• Նախաբեռնում չկա։ Առաջին եկածը առաջին սպասարկվում է։
• Նախաբեռնում: Համակարգը ֆոնային ռեժիմում կենտրոնացված կերպով գեներացնում է քեշ տվյալներ, ինչը ապահովում է ավելի կայուն փորձ առաջին անգամ այցելողների համար։

B. JavaScript-ի գործարկման հետաձգումը: սա այն հատկությունն է, որը օգտվողի փորձին առաջարկում է ամենաակնառու բարելավումը, սակայն այն նաև կրում է ամենամեծ ռիսկը։

WP Rocket-ը պաշտոնապես վերաբերում է “JavaScript-ի գործարկման հետաձգում”Նկարագրվում է որպես JavaScript-ի ամենաուժեղ օպտիմալացումը՝ այն հետաձգում է սցրիպտի գործարկումը մինչև օգտվողը փոխազդի էջի հետ (մկնիկը տեղափոխելով, էկրանին հպվելով, էջը գլորելով, ստեղն սեղմելով և այլն), որպեսզի էջը նախապես ցուցադրվի։

Սա կարևոր է վեբկայքի կատարողականության համար, քանի որ սցրիպտների բեռնումն ու գործարկման արգելափակումը ավելի հեշտությամբ կարող են ուժեղանալ միջմայրցամաքային ցանցերում։

• Ռեսուրսների ներբեռնումները մի փոքր դանդաղ են → Գլխավոր թրեդը ավելի հավանական է, որ ծանրաբեռնված լինի սցրիպտներով
• Երրորդ կողմի սցրիպտները (օրինակ՝ վերլուծական, գովազդային և զրույցի պլագիններ) ավելի մեծ հավանականությամբ կարող են վատթարացնել INP-ն և փոխազդեցության ուշացումը։

Այնուամենայնիվ, սա կարող է նաև որոշ խնդիրներ առաջացնել:

• JavaScript-ի ուշացումները հավանական է ազդեն՝ մենյուների, կարուսելների, պոպ-ափերի, ձևաթղթերի վավերացման, վճարումների և հետևման կոդի ներդրման վրա։
• Այդ պատճառով այն լավ է հարմար “քայլ առ քայլ + սև ցուցակից բացառման” ռազմավարության համար։

C. Մյուս պլագինների/թեմների հետ համատեղելիություն: Առանց խնդիրների չի նշանակում “զրոյական հակասություններ”

WP Rocket-ը հատուկ թվարկել է “Անհամատեղելի պլագիններ/թեմա”list», քանի որ սա կարող է ազդել WP Rocket-ի քեշավորման և օպտիմալացման մեխանիզմների վրա, ինչպիսիք են ելքի բուֆերավորումը։

• Եթե ձեր կայքում տեղադրված են բազմաթիվ պլագիններ և ռեսուրսատար թեմա, “performans optimizatsia”-ն դիտարկեք որպես փոքրածավալ ներդրման նախագիծ՝ յուրաքանչյուր փոփոխությունից հետո (ֆորմեր, մուտք, վճարում, լեզվի փոփոխություն և այլն) իրականացնելով ռեգրեսիոն թեստավորում։

1.3 WooCommerce-ի և դինամիկ կայքերի վերաբերյալ հատուկ նշումներ

Պաշտոնական WooCommerce փաստաթղթավորման մեջ քեշավորման պլագին կազմաձևելիս ընդգծված հիմնական կետը հետևյալն է՝

• Գնումների զամբյուղ / Վճարում / Հաշիվ Չպահպանել քեշում
• և առաջարկում էԽուսափեք JavaScript ֆայլերի փոքրացումից

Ինչու՞

• Գնումների զամբյուղի, վճարման և հաշվի էջերը մեծապես կախված են cookie-ներից, նստաշրջաններից և nonce-ներից։
• Երբ քեշը այս էջերը դիտարկում է որպես “ստատիկ էջեր”, հետևանքները կարող են տատանվել կոճակների չաշխատելուց մինչև, ամենավատ դեպքերում, գների, պաշարների կամ հաշվի տվյալների անհամապատասխանություններ։
• Ամենավախենալին այն է, որ մի տարածաշրջանում թեստը կարող է նորմալ անցնել, իսկ մյուսում խնդիրներ առաջանան CDN-ի կամ քեշի հիթերի տարբերությունների պատճառով

1.4 Քեշի պլագինների քաղաքականությունների առաջարկներ

Մակարդակ 1. Հիմնական անվտանգության միջոցառումներ (ինչ-որ բան, որը գրեթե բոլոր կայքերը պետք է կիրառեն)

• Էջերի քեշավորումը միացնել
• ԲացՔեշի նախաբեռնում(Առաջին այցելուների համար կայունության բարելավում)
• Բրաուզերի քեշի խելամիտ ռազմավարություն（կարելի է իրականացնել WP Rocket/սերվեր/CDN ցանկացած շերտում）

2-րդ մակարդակ՝ միջին եկամտաբերություն, միջին ռիսկ (համապատասխանում է բովանդակային կայքերի մեծամասնությանը)

• Նկարների ծույլ բեռնում / iframe (Նկարների օպտիմալացման ավելի խորը ուսումնասիրություն)
• Կառավարեք CSS ֆայլի չափը (օրինակ՝ չօգտագործված CSS-ը հեռացնելով)

3-րդ մակարդակ՝ բարձր եկամտաբերություն, բայց բարձր ռիսկ (պետք է ներառի բեքթեստավորման ստուգաթերթիկ)

• Հետաձգել JavaScript-ի գործարկումը (նախապատվություն տալ ռենդերինգին, սակայն սա կարող է ազդել փոխազդեցության վրա)
• JS/CSS-ի մինիֆիկացում/միավորում: առանձնակի զգուշություն ցուցաբերեք էլեկտրոնային առևտրի, անդամակցության և բազմալեզու կայքերի դեպքում (WooCommerce-ն նաև զգուշացրել է JavaScript-ի մինիֆիկացման հետ կապված ռիսկերի մասին։）

1.5 Գնագոյացում և լիցենզավորում

• WP Rocket-ը գործում է վճարովի լիցենզավորման մոդելով, և լիցենզաների տարբերակները տարբեր են կայքերի քանակից կախված։

Պլագին 2:LiteSpeed Cache (LSCWP)“Անվճար բարձրակարգ” առաջարկը վավեր է միայն այն դեպքում, եթե սերվերը իսկապես աշխատում է LiteSpeed-ով։

LiteSpeed Cache-ի վերաբերյալ տարածված սխալ պատկերացումն այն է, որ այն ընդամենը WordPress պլագին է, որը տեղադրվելուց հետո ցանկացած հոստինգային հարթակում նույնքան արդյունավետ կաշխատի, որքան WP Rocket-ը։ Սակայն իրականում դա այդպես չէ։

LiteSpeed պաշտոնական փաստաթղթավորումՀստակեցնելու համար՝ LSCWP-ի քեշավորման ֆունկցիոնալությունը պահանջում է LiteSpeed Server, քանի որ այն պետք է հաղորդակցվի LiteSpeed Web Server-ի ներկառուցված էջերի քեշավորման (LSCache) հնարավորության հետ; պլագինն պատասխանատու է սերվերին տեղեկացնելու, թե որ էջերը կարելի է քեշավորել, որքան ժամանակով, և պիտակների միջոցով մաքրում (purge) նախաձեռնելու համար։

LiteSpeed Cache-ի հիմնական առավելությունը կայանում է “Սերվերային էջերի պահպանում (LSCache)”Եթե չլինեին LiteSpeed/OpenLiteSpeed սերվերները, այս կարևոր առավելությունը գոյություն չէր ունենա։

2.1 ԼայթՍպիդ ՔեշԴա ում համար է հարմար?

Համապատասխանում է՝

• Ձեր հոստինգի կառավարման վահանակում հստակ նշված է ԼայթՍպիդ / ՕփենԼայթՍպիդ(Օրինակ՝ շատ cPanel սերվերներ ցուցադրում են սա)
• Դուք ցանկանում եք, որ անվճար պլանը ապահովի գերազանց TTFB և բազմահոսքային կատարողականություն։“
• Պատրաստ ե՞ս ընդունել, որ, չնայած այն շատ հզոր է, այն նաև ներառում է բազմաթիվ հասկացություններ (TTL, Tag, Purge, ESI, Crawler…)?

Չի այնքան հարմար

• Դուք վստահ չեք, թե հոստը որ վեբ սերվերն է օգտագործում, կամ հաստատել եք, որ դա Nginx-ն է կամ Apache-ն (բացառությամբ այն դեպքի, երբ ցանկանում եք օգտագործել միայն դրա ֆրոնթ-ենդ օպտիմալացման որոշ հնարավորություններ, որի դեպքում դրա ծախսարդյունավետությունն ու բարդությունը կարող են չարժենալ)
• Դուք ունեք բարդ էլեկտրոնային առևտրի/անդամակցության/բազմալեզու կայք, բայց չունեք թեստավորման գործընթաց (LSCWP-ն հզոր է, սակայն ավելի հակված է “սխալ բովանդակություն պահպանելուն”):

2.2 Նրա քեշավորման մեխանիզմը՝ ինչու այն ավելի շուտ նման է “սերվերի հնարավորությունների մի մասի”

Դուք կարող եք մեկ “տեխնիկական բացատրությամբ” ամփոփել, թե ինչպես է աշխատում LiteSpeed Cache-ը։

• WP Rocket / WP Super Cache Այս միջոցառումները հիմնականում ներառում են քեշավորում և օպտիմալացում WordPress/PHP կողմում։
• LSCWP Սա “WordPress կառավարման վահանակի + LiteSpeed սերվերի ներկառուցված LSCache”-ի համադրություն է։ Պլագինը պատասխանատու է կանոններ սահմանելու և ազդանշանները մաքրելու համար, իսկ իսկական բարձր արագությամբ էջերի քեշավորումը տեղի է ունենումՍերվերի շերտ。

Սա ուղղակիորեն ազդում է օգտվողի փորձի վրա. սերվերային կողմի քեշավորումը ընդհանուր առմամբ ավելի թեթև, արագ և ավելի լավ է միաժամանակյա հարցումները մշակելու ունակությամբ (հատկապես երթևեկության հանկարծակի աճի կամ որոնողական համակարգի ռոբոտների հաճախակի այցելությունների ժամանակ).

2.3 LSCWP-ի “ճիշտ” օգտագործման ձևը կայքի օգտվողի սցենարի մեջ”

Մենք “ճիշտ մոտեցումը” բաժանել ենք չորս մակարդակների:

Շերտ 1: էջերի քեշավորման ռազմավարություն (որոշում է՝ արդյոք TTFB-ն իսկապես կարող է կրճատվել)

• Սահմանեք, թե որ էջերը կարելի է պահել քեշում (հիմնականում հանրային բովանդակության էջեր)
• Սահմանեք, թե որ էջերը երբեք չպետք է պահպանվեն քեշում (մուտք, հաշիվ, գնումների զամբյուղ, վճարում և էջեր, որոնք լեզվի/արժույթի փոխարկման համար կախված են cookie-ներից)
• Տեղադրեք cache-ի համար ողջամիտ TTL (քանի որ բովանդակությունը ավելի հաճախ թարմացվում է, TTL-ը պետք է լինի կարճ; հակառակ դեպքում՝ երկար)
• Ստեղծեք մաքրման քաղաքականություն՝ բովանդակությունը թարմացնելուց հետո մաքրեք համապատասխան պիտակները (ոչ թե ամբողջ կայքի մասով ընդհանուր մաքրում կատարելով)

Եթե այս շերտը ճիշտ իրականացվի, կայքի համար ամենաանմիջական օգուտը կլինի TTFB-ն նվազել է, և առաջին էկրանի բեռնումը ավելի կայուն է։。

Շերտ 2: նախաբեռնում/վերլուծում (որոշում է՝ արդյոք “ցածր երթևեկություն ունեցող էջերի” առաջին այցելությունը դանդաղ է)

Վեբկայքեր այցելելիս “ոչ համաչափ օգտվողի փորձառության” հաճախակի պատճառը “տաք և սառը քեշի անհամապատասխանություններից” է։

• Հանրաճանաչ էջերը անընդհատ այցելվում են, ուստի քեշը մնում է արդիական։
• Փոքր այցելություններ ունեցող էջերը երկար ժամանակ անտեսվել են, ուստի առաջին անգամ այցելողների համար դրանք շատ դանդաղ են բեռնվում։

Նախաբեռնումը ոչ միայն տորթի վրա շաքարապատումն է, այլև վեբկայքում օգտվողների համար միատեսակ փորձ ապահովելու բանալին։

Ցուցակ 3: Դինամիկ բովանդակության (էլեկտրոնային առևտուր/անդամակցություն/բազմալեզու) անվտանգության լուծումներ

LSCWP-ի ուժը կայանում է նրանում, որ այն ձեզ տրամադրում է “առաջադեմ գործիքների” լայն շրջանակ, ինչպիսիք են՝

• Մուտք գործած օգտվողների, մեկնաբանողների և այլնի համար տարբերակված քեշավորման ռազմավարություններ։
• Edge-Side Inclusion (ESI)-ի հիմնական գաղափարը կայանում է էջը բաժանել «cacheable common body» և «non-cacheable dynamic fragments» մասերի, դրանք առանձին մշակել և ապա եզրային հանգույցում կրկին միավորել։

Շերտ 4: Առցանց ծառայություններ և ընտրովի բարելավումներ

Շատ կայքավարներ LSCWP-ում կշփվեն QUIC.cloud-ի առցանց ծառայությունների հետ (օրինակ՝ էջի օպտիմալացման ծառայություններ):QUIC.cloud փաստաթղթավորումԱյն հստակ նշում է, որ LSCWP-ին տրամադրում է էջի օպտիմալացման ծառայություններ, ներառյալ Critical CSS (CCSS), Unique CSS (UCSS) և Viewport-optimised Images (VPI):

• Այս ծառայությունները ընտրովի ենԴուք կարող եք օգտագործել միայն սերվերի կողմի պահպանումը առանց առցանց օպտիմալացման միացման։
• Մի անգամ առցանց ծառայությունները ակտիվացվեն, ձեր կայքի ռեսուրսների և էջերի մշակման հոսքը կփոխվի (այս տեղեկությունը կարևոր է բիզնեսների և գաղտնիության նկատմամբ զգայուն հաճախորդների համար)

2.4 LSCWP-ում ընդհանուր թերությունները

1. Սերվերը չի աշխատում LiteSpeed-ով, սակայն այն LSCWP-ին վերաբերվում է որպես լիարժեք ֆունկցիոնալ քեշավորման պլագին։
   Արդյունք: Քեշավորումը չաշխատեց ինչպես սպասվում էր և նաև բարձրացրեց կազմաձևման բարդությունը։ Լուծում: Առաջին հերթին ստուգեք հոստի ստեկը; եթե այն չի ԼայթՍպիդ... դիտարկեք WP Rocket-ը կամ WP Super Cache-ը։
2. Ֆրոնտենդի չափազանց շատ օպտիմալացումների միացումը առաջացրել է ֆունկցիոնալ խնդիրներ։
   Էջի օպտիմալացումը (CSS/JS) հաճախ ավելի հեշտ է առաջացնում համատեղելիության խնդիրներ, քան կեշավորումը ինքնին։ Խորհուրդ՝ նախ համոզվեք, որ էջի կեշավորումը աշխատում է անխափան, ապա օպտիմալացումները միացրեք հերթով՝ միաժամանակ կազմելով ռեգրեսիոն թեստերի ստուգաթերթիկ (ֆորմեր, մենյուներ, վճարում, հետևում, լեզվի փոփոխություն և այլն)։
3. Դինամիկ էջերի համար բացառման/շարդավորման ռազմավարությունների բացակայություն
   Հաճախ հանդիպող խնդիրներ՝ գնումների զամբյուղների, վճարման էջերի և հաշվի էջերի քեշավորում; կամ լեզուների կամ արժույթների սխալ փոխարկում։ Էլեկտրոնային առևտրի կայքերը պետք է սա դիտարկեն որպես նախաներդրման ստուգում (ինչպես WooCommerce-ն է ընդգծում)։Մի պահպանեք քեշում կարևոր էջերը）。

Պլագին 3:WP Super Cache(Անվճար) — բովանդակային կայքերի դասական “ցածր ռիսկ, բարձր եկամտաբերություն” ռազմավարությունը

WP Super Cache Ինչու՞ այն այդքան երկար ժամանակ շարունակում է մնալ հանրաճանաչ։ Որովհետև այն խնդիրները լուծում է շատ պարզ, “սերվերի համար հարմար” ձևով։
Դինամիկ WordPress էջերը փոխարկել ստատիկ HTML ֆայլերի, այնուհետև այս HTML ֆայլերը անմիջապես մատուցվում են Web սերվերի կողմից՝ այդպիսով շրջանցելով թանկարժեք PHP մշակումը։

Պլագինի էջում նշվում է նաև, որ ստատիկ HTML-ը մատուցվում է չհավաստագրված օգտվողների մեծամասնությանը, և տրվում է շատ հստակ բացատրություն՝ “99% այցելուներին կտրամադրվեն ստատիկ HTML ֆայլեր”; մեկ պահպանված ֆայլ կարելի է մատուցել հազարավոր անգամներ։

3.1 WP Super Cache-ը ում համար է հարմար?

Շատ խորհուրդ է տրվում։

• Բլոգներ, բովանդակային կայքեր, փաստաթղթավորման կայքեր, կորպորատիվ կայքեր, վայրէջքի էջեր
• Այցելուները հիմնականում այն օգտվողներն են, որոնք չեն մուտք գործել։
• Դուք ուզում եք՝ անվճար, կայուն և ցածր սպասարկման ծախսեր

Օգտագործել զգուշությամբ / Պահանջում է ավելի ամուր ռազմավարություն:

• Շատ դինամիկ կայքեր՝ մեծ քանակությամբ անհատականացված բովանդակությամբ և օգտվողի կարգավիճակին համապատասխան փոփոխվող էջերով։
• Մեծ էլեկտրոնային առևտրի հարթակներ: Սա ընդունելի է, սակայն համոզվեք, որ հիմնական էջերը չեն պահպանվում քեշում և որ դա ինտեգրված է ձեր թեստավորման գործընթացում։

3.2 Նրա երեք քեշավորման մեթոդները:

WP Super Cache հավելվածի նկարագրությունը թվարկում է երեք քեշավորման մեթոդներ՝ ըստ արագության հերթականության, և բացատրում է դրանց միջև տարբերությունները:

• mod_rewrite (Մասնագետ)Ամենաարագ մեթոդը, որը ամբողջությամբ շրջանցում է PHP-ը, սակայն պահանջում է .htaccess ֆայլի փոփոխություն; եթե այն սխալ կազմաձևվի, կայքի անհասանելի դառնալու ռիսկը մեծանում է։
• Պարզ (խորհուրդ տրվող մեթոդ)PHP-ը ստատիկ ֆայլերի համար ապահովում է “սուպեր քեշ”, առաջարկելով mod_rewrite-ի հետ համեմատելի արագություններ, սակայն ավելի պարզ կազմաձևով։
• WP-Cache քեշավորումԱվելի ճկուն, հարմար է հայտնի օգտվողների, պարամետրերով URL-ների, ֆիդերի և այլնի համար, սակայն դանդաղ է։

Խորհուրդ տրվող տարբերակներ:

• Սկսնակներ/կայունություն փնտրողներ՝ օգտագործեք առաջարկվող (պարզ) մեթոդը։
• Եթե դուք շատ լավ ծանոթ եք սերվերի կանոններին և պատրաստ եք կրել դրանց վերագրման ռիսկը, ապա դիտարկեք Փորձագիտական ռեժիմը։
• Ձեզ անհրաժեշտ է ավելի ճկուն կառավարում “ծանոթ օգտվողների/պարամետրերի” նկատմամբ՝ հասկանալով WP-Cache-ի դերը

3.3 WP Super Cache-ի ուժեղ և թույլ կողմերը

Առավելություններ:

1. Իդեալական է CDN-ի հետ օգտագործման համար
   Քանի որ այն էապես ենթադրում է “ստատիկ HTML-ի գեներացում”, դա բնականաբար համընկնում է CDN/edge caching մոտեցման հետ։
2. Առաջնաղբյուր սերվեր CPU-ի և տվյալների բազայի բեռի բարելավումը շատ նկատելի է։
   Երբ կայքի այցելուների հոսքը բաշխված է աշխարհի տարբեր մասերում, որոնողական համակարգերի և սոցիալական ցանցերի ռոբոտները նույնպես կարող են գործել տարբեր երկրներից։ Ստատիկացումը շատ արդյունավետ է “կրկնակի ռենդերավորման” դեմ պայքարում։

Թույլ կողմեր:

1. Սա “բոլորը մեկում” կատարողականության օպտիմալացման փաթեթ չէ։”
   Նրա հիմնական ուժը գտնվում է էջերի քեշավորման մեջ; WP Rocket-ի պես այն չի առաջարկում CSS-ի և JavaScript-ի խորքային օպտիմալացումների համապարփակ փաթեթ։ Հնարավոր է, որ անհրաժեշտ լինի իրականացնել լրացուցիչ օպտիմալացումներ “Image Optimisation” և “Front-end Optimisation” էջերի միջոցով (կամ օգտագործել այլ պլագիններ կամ թեմայի մակարդակի օպտիմալացումներ)։
2. Մենք պետք է ավելի մեծ զգուշավորություն ցուցաբերենք “դինամիկ անհատականացման” նկատմամբ։
   Օրինակ՝ տարածաշրջանի հիման վրա ցուցադրել տարբեր բովանդակություն կամ օգտվողի կարգավիճակի հիման վրա ցուցադրել տարբեր գներ, լեզուներ կամ առաջարկություններ։ Այսպիսի դեպքերում դուք պետք է սահմանեք բացառությունների կանոններ կամ կիրառեք ավելի հարմար բաժանված քեշավորման լուծում։

3.4 WooCommerce համատեղելիություն՝ ինչու՞ այն ավելի “անվտանգ” է”

Պաշտոնական WooCommerce փաստաթղթավորումըՊետք է նշել, որ WooCommerce-ը բնիկ համատեղելի է WP Super Cache-ի հետ, և WooCommerce-ը ուղարկում է ազդանշան WP Super Cache-ին՝ ապահովելու համար, որ «Զամբյուղ», «Վճարում» և «Իմ հաշիվ» էջերը ստանդարտ կարգով չպահպանվեն քեշում։

• Նույնիսկ եթե դուք սկսնակ եք, WP Super Cache-ի և WooCommerce-ի համադրությունը նվազեցնում է “կարևոր էջերի քեշավորման” թերության մեջ ընկնելու հավանականությունը։
• Այնուամենայնիվ, մենք դեռևս խորհուրդ ենք տալիս գործարկումից առաջ անցկացնել ռեգրեսիոն թեստավորում (ներառյալ վճարումները, վաուչերները, առաքման վճարները, հարկային դրույքաչափերը, բազմակի արժույթները և այլն)։

Պլագին 4:W3 Total Cache (W3TC)— Ամենաամբողջական “գործունակության շրջանակ”, իդեալական ինժեներական թիմերի համար

W3 ընդհանուր քեշ WordPress.org-ում այն դիրքավորված է ոչ թե որպես “մեկ քեշավորման պլագին”, այլ ավելի շուտ որպես “կայքի կատարողականության օպտիմալացման շրջանակ”. այն շեշտը դնում է SEO-ի, Core Web Vitals-ի և ընդհանուր օգտվողի փորձի բարելավման վրա՝ CDN ինտեգրման և լավագույն փորձերի միջոցով։

Պլագինի նկարագրությունը թվարկում է լայն հնարավորությունների շրջանակ՝ էջ/ էջերի/պոստերի քեշավորում, CSS/JS քեշավորում, ֆիդերի քեշավորում, որոնման արդյունքների քեշավորում, տվյալների բազայի օբյեկտների քեշավորում, օբյեկտների քեշավորում, ֆրագմենտների քեշավորում և տարբեր քեշավորման մեթոդների (օրինակ՝ Redis, Memcached և APC) աջակցություն։ Այն նաև ներառում է շարժական քեշավորում՝ օգտվողի գործակալ (UA) և հղողի (referrer) հիմքով խմբավորված, AMP աջակցություն և հակադարձ պրոքսի (Nginx/Varnish) ինտեգրում։

4.1 W3 Total Cache-ը ում համար է հարմար?

Իդեալական է՝

• Դուք ունեք մշակման և շահագործման հմտություններ և պատրաստ եք իրականացնել քայլ առ քայլ տեղադրում, բեռի թեստավորում և ռեգրեսիոն թեստավորում։“
• Ձեր կայքը բարդ է՝ այն ունի բազմալեզու աջակցություն, թեմատիկ փոխարկում, բջջային սարքերի համար հատուկ օպտիմալացում և բարդ բովանդակային կառուցվածք։
• Դուք ոչ միայն ցանկանում եք կիրառել էջերի քեշավորում, այլև ցանկանում եք համակարգում ներառել օբյեկտների և ֆրագմենտների քեշավորում (հատկապես դինամիկ կայքերի համար)

Չի համապատասխանում՝

• Դուք ուզում եք, որ այն արագ լինի անմիջապես տուփից հանելիս և չեք ուզում հասկանալ քեշի շերտավորումը։
• Դուք չունեք թեստավորման գործընթաց, սակայն ցանկանում եք միաժամանակ միացնել բարձր ռիսկային ֆունկցիաներ, ինչպիսիք են կոմպրեսիան և ուշացված սցենարները։

4.2 Ինչու է այն բնութագրվում որպես “հզոր, բայց բարդ”։ Վեբկայքերը առաջնահերթություն են տալիս “կառավարելիությանը”։”

W3TC-ի արժեքը ոչ թե նրանում է, որ “այն անխուսափելիորեն ավելի արագ է մյուսներից”, այլ նրանում, որ այն ձեզ տրամադրում է բավարար կառավարման տարբերակներ՝ ձեր կատարողականության ռազմավարությունը ինժեներական շրջանակի վերածելու համար։

• Էջի քեշ՝ կարող է գտնվել հիշողությունում, սկավառակում կամ CDN-ում
• Տվյալների բազայի օբյեկտների քեշավորում, օբյեկտների քեշավորում՝ կարելի է օգտագործել Redis, Memcached և այլն։
• Ֆրագմենտների քեշավորում՝ հատկապես օգտակար է “կիսադինամիկ էջերի” համար։
• Բջջային աջակցություն՝ պահոցային էջերը առանձին պահել ըստ հղողի կամ օգտվողի գործակալության խմբի
• CDN կառավարում: Մեդիա գրադարանների, թեմաների ֆայլերի և այլնի թափանցիկ կառավարում։ CDN կառավարում

Այս հնարավորությունները հատկապես արժեքավոր են կայքերի համար, քանի որ համաշխարհային տրաֆիկը հաճախ հանդիպում է:

• Նույն էջի տարբերակներ տարբեր սարքերում, տարածաշրջաններում և լեզուներով
• Որոշ բովանդակություն կարելի է պահել քեշում, մինչդեռ մյուս բովանդակությունը պետք է թարմացվի իրական ժամանակում (օրինակ՝ գներ, պաշարի մակարդակներ, օգտվողի կարգավիճակ)

4.3 W3TC-ի “Խորհուրդ տրվող ակտիվացման կարգը”

Խորհուրդ տրվող հերթականություն:

1. Առայժմ միայն էջերի քեշավորումը միացրեք։
   Հաստատեք՝ արդյոք TTFB-ն նվազել է, արդյոք բովանդակությունը համահունչ է, և արդյոք մուտքի վիճակը, բազմալեզու ֆունկցիոնալությունը և հիմնական էլեկտրոնային առևտրի աշխատանքային հոսքերը ճիշտ են գործում։
2. Վերակտիվացրեք զննարկչի քեշը
   Նպատակ՝ էջերի վերաբեռնումների և ստատիկ ռեսուրսների բեռման արագացումը և մայրցամաքների միջև ավելորդ ներբեռումների կրճատումը։
3. Վերաիրականացնել օբյեկտների քեշը / տվյալների բազայի օբյեկտների քեշը
   Հարմար է դինամիկ կայքերի համար (WooCommerce, անդամակցության համակարգեր, բարդ հարցումներ)։
   Կիրառելի չէ. Մաքուր բովանդակության կայքերը կարող են ապահովել սահմանափակ եկամուտ և նույնիսկ մեծացնել ռեսուրսների սպառումը։
4. Վերջապես զբաղվել կոմպրեսիայով, սցրիպտերի հետաձգմամբ և ֆրոնտենդի օպտիմալացմամբ։
   Քանի որ սա այն շերտն է, որը առավել հակված է ֆունկցիոնալ խնդիրների, պետք է կազմել ռեգրեսիոն թեստավորման ստուգաթերթիկ (ներառյալ վճարումները, ձևերը, հետևումը, pop-up պատուհանները, մենյուները, լեզվի փոփոխությունը և այլն):

WooCommerce հիշեցում՝ “cache plugin configuration”-ի վերաբերյալՄի պահպանեք քեշում կարևոր էջերը, և խորհուրդ է տրվում խուսափել JavaScript ֆայլերի մինիֆիկացումից։

Չորս պլագինների համեմատության մատրիցա

Խնդրում ենք նկատի ունենալ՝ սա չի վերաբերում “ով է ավելի ուժեղ”, այլ “ով է ձեր իրավիճակին ավելի հարմար”։

չափ	WP Rocket	ԼայթՍպիդ Քեշ	WP Super Cache	W3 ընդհանուր քեշ
Հիմնական դիրքավորում	Բոլորը մեկում լուծում (կեշավորում + օպտիմալացում)	Սերվերի մակարդակի քեշավորում (LSCache-ի օգտագործմամբ)	Ստատիկ HTML-ի քեշավորում	Աշխատանքային շրջանակ (բազմաշերտ քեշավորում + CDN)
Հյուրընկալչի կախվածություն	Նվազագույն (համընդհանուր)	Բարձր (պահանջում է LiteSpeed/OpenLiteSpeed՝ միջուկային քեշավորումը օգտագործելու համար)	Նվազագույն (համընդհանուր)	Միջին (համընդհանուր, սակայն ավելի կախված է միջավայրի/կոնֆիգուրացիայի հնարավորություններից)
Սովորելու ծախսերը	ցածրից միջին	中	低	高
Բովանդակային կայքի առաջարկման միավոր	շատ բարձր	Շատ բարձր (եթե բավարարվեն պայմանները)	շատ բարձր	Միջինից բարձր (կախված է թիմից)
Էլեկտրոնային առևտրի/անդամակցության կայք	Կարելի է օգտագործել, սակայն զգուշություն ցուցաբերեք (WooCommerce-ի հիմնական էջերը չեն պահվում քեշում)	Հասանելի է, սակայն պահանջում է կանոններ/շարդավորման ռազմավարություններ։	Հասանելի է, և WooCommerce-ը նշում է, որ այն բնիկ համատեղելի է և ստանդարտ կարգավորմամբ չի պահպանում հիմնական էջերը քեշում։	Հասանելի է; հարմար է ինժեներական կիրառությունների համար
Բյուջե	Վճարել	Առանց վճարի	Առանց վճարի	Անվճար + վճարովի տարբերակներ

“Cache Incidents” և կանխարգելման ստուգաթերթիկ

1. Քեշավորման պատճառով “սխալ բովանդակության” երեք հիմնական պատճառները

A. “Պետականությամբ” էջերը դիտարկել որպես “առանց պետականության ստատիկ էջեր”

Օրինակ՝ հաշվի էջը, գնումների զամբյուղը և վճարման էջը պահվում են քեշում։ WooCommerce Իշխանությունները բազմիցս ընդգծել են Գնումների զամբյուղի, վճարման և հաշվի էջերը չպետք է պահպանվեն քեշում։

B. Շատ լեզուների, արժույթների և տարածաշրջանային տարբերակների համար քեշավորումը ճիշտ չի տարբերակվում։

Եթե ձեր կայքը cookie-ների, հարցման պարամետրերի կամ աշխարհագրական դիրքի հիման վրա ցուցադրում է տարբեր բովանդակություն, ձեր քեշավորման ռազմավարությունը պետք է հաշվի առնի “տարբերակային չափերը”: Հակառակ դեպքում A տարածաշրջանի օգտվողի համար ստեղծված քեշը կարող է օգտագործվել B տարածաշրջանի օգտվողի կողմից։

C. Front-end օպտիմալացման (JS/CSS) վերակազմումը առաջացրել է ֆունկցիոնալ խնդիրներ

Մասնավորապես՝ JavaScript-ի մինիֆիկացում, փաթեթավորում և ծույլ բեռնում։ WooCommerce-ը նույնիսկ խորհուրդ է տալիսԽուսափեք JavaScript ֆայլերի փոքրացումից。

2. Նախնական տեղադրման ռեգրեսիոն թեստավորման ստուգաթերթիկ

• Արդյո՞ք մուտք գործելու/ելքից դուրս գալու ֆունկցիան աշխատում է ճիշտ։
• Արդյո՞ք ձևաթղթերի ներկայացումները (կապի ձևաթղթեր, բաժանորդագրություններ, մուտք և գրանցում) աշխատում են ճիշտ։
• Էլեկտրոնային առևտրի գործընթացը՝ Ավելացնել զամբյուղին → Վաուչեր → Առաքման վճարներ/հարկեր → Վճարում → Պատվերի էջ
• Արդյո՞ք լեզվի փոփոխման ֆունկցիան կայուն է (փոփոխումից հետո բովանդակության, URL-ների, hreflang պիտակների և արժույթի առումով)։
• Արդյո՞ք շարժական մենյուն, պոպ-ափերը, սքրոլինգը և ծույլ բեռնումը աշխատում են ճիշտ։
• Ստուգեք՝ արդյոք հետևման սկրիպտները (GA, Meta Pixel, փոխարկման իրադարձություններ) դեռևս գործարկվում են։

Հաճախակի տրվող հարցեր

Q1: Ինչու է կայքը դեռ դանդաղ աշխատում օտար երկրներից մուտք գործելիս, չնայած որ ես տեղադրել եմ քեշավորման պլագին?

Ամենատարածված պատճառը այն է, որ դուք միայն լուծել եք “առաջնային սերվերում կրկնակի ցուցադրման” խնդիրը, սակայն չեք լուծել “մայրցամաքային ցանցային ուշացման” խնդիրը։
Քեշավորման պլագինները թույլ են տալիս սերվերին ավելի արագ մատուցել բովանդակությունը (նվազեցնելով TTFB-ն), սակայն ստատիկ ռեսուրսները (նկարներ, CSS, JS, տառատեսակներ) և գլոբալ կապերի RTT-ն դեռ պետք է լինեն CDN Տարածքը լրացնելու համար։
👉 Ուստի ճիշտ մոտեցումն այսպիսին է:Նախ, համոզվեք, որ սկզբնային սերվերի քեշավորումը ճիշտ է աշխատում,CDN-ում վերբեռնել համաշխարհային տարածման համար。

Q2: Ինչու՞ բովանդակությունը չի թարմացվում, երբ ես այն պահել եմ քեշում։

Սա այն պատճառով է, որ դուք դիտում եք “հին քեշը”։ Լուծում:

• Ստեղծեք քեշի մաքրման քաղաքականություն՝ թարմացնելուց հետո մաքրեք համապատասխան գրառման կամ էջի քեշը (ոչ թե ամբողջ կայքի քեշը)։
• Նախապես տաքացում կամ սողալով մաքրում պահանջող լուծումների համար՝ մաքրումից հետո պետք է կրկին կատարել նախնական տաքացում, հակառակ դեպքում առաջին այցը դանդաղ կանցնի։
• CDN-ի վերաբերյալ անհրաժեշտ է հաշվի առնել, որ CDN եզրը կարող է նաև պահել հին ռեսուրսները։

Q3: Կարո՞ղ եմ միաժամանակ տեղադրել WP Rocket-ը և WP Super Cache-ը։

Սա չի խորհուրդ տրվում։ Ամենակայուն աշխատանքի համար լավագույնն է միաժամանակ օգտագործել միայն մեկ էջերի քեշավորման պլագին։ Դուք կարող եք “մեկը քեշավորման, մեկը օպտիմալացման համար” գաղափարը ընկալել որպես “աշխատանքի բաժանում”, սակայն գործնականում դրանք հաճախ խանգարում են էջերի քեշավորմանը կամ ռեսուրսների վերաշարադրմանը, ինչը բարձր հավանականությամբ հանգեցնում է հակամարտությունների։ Լավ է ընտրել “առաջնային քեշավորման պլագին” և լրացուցիչ պահանջները լուծելու համար օգտագործել ավելի մասնագիտացված, միանձնյա գործիքներ։

Q4: Արդյո՞ք էլեկտրոնային առևտրի կայքերում քեշավորումը ռիսկային է։

Դա վտանգավոր չէ; վտանգավորը “օրենքների բացակայությունն” է։WooCommerce առաջարկություններԽնդրում ենք նկատի ունենալ՝ գնումների զամբյուղի, վճարման և հաշվի էջերը չպետք է պահպանվեն քեշում, և պետք է խուսափել JavaScript-ի կոմպրեսիայից։
Բացի այդ, WooCommerce-ը նաև նշում է, որ այն համատեղելի է WP Super Cache-ի հետ բնիկ համատեղելիությունև ըստ կանխորոշման խուսափում է հիմնական էջերի քեշավորումից։
Այսպիսով, թեև էլեկտրոնային առևտրի կայքերը անշուշտ կարելի է քեշավորել, եթե դա դիտարկեք որպես “ուղիղ փոփոխություն”, այն պետք է փորձարկվի։

Q5: Պետք է ընտրեմ LiteSpeed Cache-ը՞ թե WP Rocket-ը՞

• Հաստատե՞լ եք, որ սերվերը աշխատում է LiteSpeed/OpenLiteSpeed-ով։Առաջնահերթություն տալ LiteSpeed Cache-ին (անվճար և հզոր, որի հիմնական ուժեղ կողմերը բխում են սերվերային կարգի LSCache-ից)
• Դուք անորոշ եք սերվերի կազմաձևի հարցում / չեք ուզում խնդիրներ ունենալ / ցանկանում եք խնդիրներից զերծ, ամբողջական լուծումWP Rocket-ը ավելի կայուն է։
• Դուք ղեկավարում եք բովանդակային կայք և ուշադիր եք բյուջեի նկատմամբ։WP Super Cache-ը ավելի կայուն և թեթև է։

Քեշավորման պլագին CDN-ի հետ համատեղ

Քեշավորման պլագինը լուծում է “սկզբնաղբյուր սերվերից բովանդակության ոչ բավարար մատուցման” և “TTFB-ի բարձրացման” խնդիրները; CDN-ն ապահովում է, որ «ստատիկ ռեսուրսները աշխարհով մեկ ավելի մոտ լինեն օգտվողներին»: միայն դրանց համատեղ կիրառման դեպքում դրանք առաջարկում են գլոբալ մուտքի ամենատարածված օպտիմալ լուծումը։

• Բովանդակային կայքերում տարածված համադրություններ:էջի քեշ + CDN ստատիկ բաշխում
• Դինամիկ կայքերի համար սովորական համադրություններ:Էջերի քեշավորում (ստրիկտորեն վերահսկվող և բացառված) + օբյեկտների քեշավորում (ըստ պահանջի) + CDN ստատիկ բաշխում

👉 Կարդացեք:CDN արագացում (գլոբալ հանգույցներ և քեշավորման քաղաքականություն)

Խորհուրդ տրվող վեբկայքի քեշավորման կարգավորումներ

1. Բովանդակային կայքեր / Բլոգներ / Դকুমենտային կայքեր

Նպատակ: Նվազեցրեք TTFB-ն, ապահովեք ավելի հարթ առաջին էկրանի փորձ, թեթևացրեք սերվերի բեռը և օգտագործեք CDN գլոբալ բաշխման համար։

1.1 Առավել անհոգ բիզնես փաթեթ

• WP Rocket (էջերի պահպանում + նախաբեռնում + ֆրոնտենդ օպտիմալացում)
  • CDN (կներկայացվի CDN էջում)

Կիրառելի է՝

• Դուք ուզում եք այնպիսի բան, որը պահանջում է նվազագույն կարգավորում, ապահովում է արագ արդյունքներ և ունի ցածր ռիսկ։“
• Թեմաներն ու պլագինները չափազանց շատ են, և ես ուզում եմ նվազագույնի հասցնել համատեղելիության խնդիրները։

Նշելու կետեր:

• Ֆրոնտենդի օպտիմալացումը (հատկապես JavaScript-ի հետաձգումը) իրականացվում է փուլ առ փուլ՝ ֆունկցիոնալ խնդիրներ (օրինակ՝ մենյուներ, ձևեր և հետևում) կանխելու համար։
• Կայքերը, որոնք հաճախակի վերափոխվում են կամ պարբերաբար հրապարակում են բովանդակություն, պետք է կիրառեն “մաքրման և տաքացման” ռազմավարություն; հակառակ դեպքում ցածր այցելություններ ունեցող էջերի առաջին այցելությունները դանդաղ կլինեն։

1.2 Դասական համադրություն, որը միաժամանակ անվճար և հուսալի է

• WP Super Cache (ստատիկ HTML պահպանում)Դինամիկ էջերից ստատիկ HTML գեներացնել, հիմնականում ոչ մուտք գործած օգտվողներին մատուցելու համար։
  • CDN

Կիրառելի է՝

• Բյուջեին հետևող, սակայն կայունություն փնտրող
• Այցելուները հազվադեպ են մուտք գործում
• Կառավարելի բովանդակության թարմացման ժամանակացույց

Նշելու կետեր:

• Սա “առաջին հերթին էջի քեշի” մոտեցում է; մի ակնկալեք, որ այն որպես կողմնակի արդյունք կլուծի բոլոր բարդ CSS-ի և JavaScript-ի խնդիրները։

---

2. Կորպորատիվ կայքեր / Բրենդային կայքեր / Վայրէջքի էջեր

Նպատակ: Արագությունը կարևոր է, սակայն ավելի կարևոր է չթողնել, որ օպտիմալացումը խանգարի փոխարկման ընթացքին։

2.1 Պինդ և կառավարելի (խորհուրդ է տրվում համաշխարհային արշավների/վերափոխման վայրէջքի էջերի համար)

• WP Rocket
• + (ընտրովի) թեթև քաշով պատկերների օպտիմալացում (դուք ունեք “Պատկերների օպտիմալացում” էջ)
  • CDN

Ինչու այն հարմար է փոխարկման կայքի համար:

• Փոխարկման հարթակները առավել խոցելի են օպտիմալացման արդյունքում ձևերի, պոպ-ափերի և հետևման սցրիպտների խափանման նկատմամբ։“
• WP Rocket-ը որդեգրում է ավելի “ինտեգրված” մոտեցում՝ թույլ տալով ձեզ մեկ համակարգում առանձին-առանձին ակտիվացնել ֆունկցիաները և իրականացնել ռեգրեսիոն թեստավորում։

Կորպորատիվ կայք գործարկելու սկզբունքներ:

• Շահագործման օպտիմալացումը համարվում է “տեղակայման փոփոխություն” և պետք է ուղեկցվի ռեգրեսիոն թեստավորման ստուգաթերթիկով։
• JavaScript-ի հետաձգման, փաթեթավորման կամ մինիֆիկացման հետ կապված ցանկացած կարգավորում պետք է նախապես փորձարկվի նախարտադրական միջավայրում՝ նախքան դրանց ներդրումը։

---

3. WooCommerce էլեկտրոնային առևտրի կայք (պատվերների կառավարում + դինամիկ էջերի անվտանգություն)

Նպատակ: Կարևոր է ապահովել, որ գնումների զամբյուղի, վճարման և հաշվի էջերը լինեն ամբողջությամբ ճշգրիտ, միևնույն ժամանակ պահպանելով արագությունը։

WooCommerce-ի պաշտոնական դիրքորոշումը քեշավորման պլագինների վերաբերյալ շատ հստակ է։Մի պահպանեք զամբյուղի, վճարման և հաշվի էջերըՆաև խորհուրդ է տրվում խուսափել JavaScript ֆայլերի մինիֆիկացումից՝ համատեղելիության խնդիրները նվազագույնի հասցնելու համար։

3.1 Ավելի “սկսնակների համար հարմար” անվճար անվտանգության ուղի

• WP Super Cache + WooCommerce
  • CDN

Ինչու է այն նշված որպես “սկսնակների համար ավելի անվտանգ տարբերակ”։

• WooCommerce-ը նշում է, որ այն բնիկ համատեղելի է WP Super Cache-ի հետ, և նշում է, որ WP Super Cache-ը ստանդարտ կարգավորումներով չի պահպանում (cache) կարևոր էջերը, ինչպիսիք են զամբյուղի, վճարման և հաշվի էջերը։
• Էլեկտրոնային առևտրում նորաստեղծ կայքերի համար “դադարների կանխարգելումը” ավելի կարևոր է, քան “առավելագույն կատարողականությունը”։

3.2 Եթե օգտագործում եք LiteSpeed հոստինգ (անվճար, բայց շատ հզոր)

• LiteSpeed Cache (պահանջում է LiteSpeed/OpenLiteSpeed հոստինգային միջավայր՝ սերվերի հիմնական քեշավորման հնարավորություններից լիովին օգտվելու համար)
• + (Ընտրովի) օբյեկտների քեշավորում (Redis/Memcached՝ կախված սերվերի հզորությունից և կայքի չափից)
  • CDN

Կիրառելի է՝

• Հոստերի ստեկը հստակ սահմանված է, և դուք պատրաստ եք կարգավորել քեշավորման կանոններն ու բացառման ռազմավարությունները։
• Պատվերների և ապրանքների մեծ ծավալով ելքային սերվերը պետք է կարողանա հաղթահարել ավելի մեծ բեռ։

3.3 Ինժեներական թիմեր / Բարդ էլեկտրոնային առևտրի հարթակներ (բազմաթիվ կառավարելի մոդուլներով)

• W3 Total Cache (արտադրողականության շրջանակ, բազմաթիվ քեշավորման շերտեր և CDN ինտեգրում)
  • Օբյեկտների քեշավորում (ըստ պահանջի)
  • CDN

Կիրառելի է՝

• Եթե ունեք DevOps թիմ, կարող եք համակարգը տեղադրել փուլային մոտեցմամբ՝ մոդուլ առ մոդուլ ներդրում, բեռի թեստավորում և ռեգրեսիոն թեստավորում։
• Պահանջում է ֆրագմենտային քեշավորում կամ ավելի բարդ տարբերակային ռազմավարություններ (օրինակ՝ սարքի, տարածաշրջանի կամ լեզվի ըստ մանրամասն քեշավորում)

---

4. Անդամակցության կայքեր/համայնքներ/օնլայն դասընթացներ (պահանջում են հաճախակի մուտք և առաջարկում են բարձր աստիճանի անհատականացում)

Նպատակ: Համոզվեք, որ հանրային բովանդակությունը արագ բեռնվում է, միևնույն ժամանակ ապահովելով, որ մուտք գործած օգտատերերի բովանդակությունը մնում է առանձին։

4.1 Անհոգ, սակայն պահանջում է խիստ բացառման ռազմավարություն

• WP Rocket
• + (ընտրովի) օբյեկտների քեշավորում (եթե կան բազմաթիվ դինամիկ հարցումներ)
  • CDN

Հիմնական կետեր:

• Դուք պետք է բացառեք հետևյալ էջերը քեշավորումից, քանի որ դրանք օգտվողից կախված են փոփոխվում՝ “Իմ հաշիվ”, «Պատվերներ», «Ուսուցման ընթացք», «Հաղորդագրություններ», «Գնումների զամբյուղ» և այլն։
• Այսպիսի կայքերը առավել հակված են խնդիրների, ինչպիսիք են “այլ օգտվողների բովանդակությունը դիտելը” կամ «թույլտվական սխալները»; ռիսկերը պետք է հստակ բացատրվեն էջում։

4.2 LiteSpeed հոստինգ + առաջադեմ քաղաքականություններ

• LiteSpeed Cache (սերվերային քեշավորում + ավելի առաջադեմ քաղաքականության գործիքներ)
• + (պահանջարկով) օբյեկտների քեշավորում
  • CDN

Հիմնական կետեր:

• Անդամակցության կայքերը հաճախ պահանջում են “պահպանվող բովանդակություն + ոչ պահպանվող հատված” մոտեցում։
• Նախաբեռման և մաքրման ռազմավարությունները պետք է ավելի կատարելագործվեն, հակառակ դեպքում օգտվողները թարմացումից հետո էլ հաճախ կշարունակեն տեսնել հին բովանդակությունը։

Վեբկայքի քեշ՝ “Խնդիրների խուսափման դեպքային ուսումնասիրություններ”

Դեպք 1. Տեղադրվեց քեշավորման պլագին, սակայն արագության մեջ գրեթե ոչ մի փոփոխություն չկար։

Ախտանիշներ:

• Տեղական տարածքում կամ շրջանում արագության թեստերը ընդունելի են, սակայն օվկիանոսից այն կողմ (մայրցամաքների միջև) արագությունները մնում են դանդաղ։
• TTFB-ն բարելավվել է, սակայն ընդհանուր բեռման ժամանակը զգալիորեն չի կրճատվել։

Ընդհանուր պատճառներ:

• Դուք միայն իրականացրել եք սկզբնական սերվերի քեշավորումը (TTFB), սակայն ստատիկ ռեսուրսները (նկարներ, JavaScript, CSS և տառատեսակներ) դեռևս բեռնվում են մայրցամաքների միջով գտնվող սկզբնական սերվերից։
• Երրորդ կողմի սցրիպտները (գովազդներ, զրույց, վերլուծություն) դանդաղեցնում են էջի ցուցադրման և փոխազդեցության արագությունը։
• Նկարը չափազանց մեծ է, ինչի պատճառով ներբեռնումը դանդաղ է (կեշավորումը չի լուծում մեծ ֆայլի չափի խնդիրը սկզբնական ներբեռման ժամանակ)

Մոտեցում:

• Քեշավորման պլագինը հիմնականում պատասխանատու է սերվերի բեռի նվազեցման և հիթերի ցուցանիշների բարելավման համար։“
• Ստատիկ ռեսուրսներ CDN-ի միջոցով
• Նկարի օպտիմալացում
• Երրորդ կողմի սցրիպտներ ուշացման/բաժանման ռազմավարությունների համար

Կարդացեք:

• CDN Արագացում՝ գլոբալ հանգույցներ և քեշավորման ռազմավարություն
• Նկարի օպտիմալացում՝ ֆորմատավորում/կոմպրեսիա/lazy loading

---

Դեպք 2: Քեշավորումը միացնելուց հետո էջը փոփոխվել է, սակայն ֆրոնտենդը չի թարմացել։

Ախտանիշներ:

• Պարունակությունը/դասավորությունը թարմացվել է ադմին պանելում, սակայն ֆրոնտենդը դեռ ցուցադրում է հին տարբերակը։
• Կամ գուցե միայն որոշ շրջաններ են թարմացվել, մինչդեռ մյուսները մնացել են անփոփոխ (ինչը բավականին տարածված է համաշխարհային կայքում)

Ընդհանուր պատճառներ:

• Էջերի քեշը չի մաքրվել, կամ մաքրման գործողության շրջանակը սխալ է։
• Նախնական տաքացումը/փորփրումը չի կատարվել; քեշի մաքրումը այն դարձրել է «սառը», ինչի հետևանքով առաջին բեռնումը դանդաղ է, մինչդեռ դու սխալմամբ կարծում ես, որ թարմացում չի եղել
• Եթե դուք միացրել եք CDN եզրային քեշը, ապա եզրը կարող է նաև պահպանել հին ռեսուրսները։

Մոտեցում:

• Սահմանել “հրապարակումից/վերանայումից հետո մաքրման քաղաքականություն”. մաքրել համապատասխան էջերը՝ ամբողջ կայքը խիստ մաքրելու փոխարեն։
• Մշակեք նախաբեռման ռազմավարություն հիմնական էջերի (մայր էջ, հիմնական վայրէջքի էջեր) համար՝ “cleaning up”-ի պատճառով դրանց դանդաղումը կանխելու համար։”
• Անհրաժեշտության դեպքում կատարել եզրերի մաքրում CDN շերտում։

---

Դեպք 3. Լեզուների կամ արժույթների միջև անցումից հետո բովանդակության ցուցադրման խնդիրներ

Ախտանիշներ:

• Էջը լեզուներ փոխելուց հետո դեռ ցուցադրում է նախորդ լեզուն։
• Մյուս կողմից, որոշ տարածաշրջանների օգտատերերը կարող են տեսնել սխալ արժույթ կամ ոչ ճիշտ բովանդակություն։

Ընդհանուր պատճառներ:

• Քեշը չի տարբերակում “տարբերակային չափերը” (cookie-ներ / պարամետրեր / լեզվական նախածանցներ / ենթադոմեյններ)
• Քեշի հիթի արդյունքում օգտվողին, ով օգտագործում է B լեզուն, մատուցվեց A լեզվով էջ։

Մոտեցում:

• Սահմանեք ձեր բազմալեզու ռազմավարությունը՝ թղթապանակ / ենթադոմեն / պարամետր / cookie
• Կիրառեք “փոփոխական քաղաքականություն” քեշավորման կանոններին կամ բացառեք հիմնական էջերը։
• Որոշ կայքեր պահանջում են ավելի առաջադեմ “շարդացված քեշավորման” մոտեցում (W3TC-ն ավելի հարմար է ինժեներական վերահսկողության համար)

---

Դեպք 4: էլեկտրոնային առևտրի կայքում քեշավորումն ակտիվացնելուց հետո գնումների զամբյուղի և վճարման գործընթացի խնդիրներ

Ախտանիշներ:

• Գնումների զամբյուղի քանակը սխալ է, գինը սխալ է, և վճարման կոճակը չի աշխատում։
• Մուտք գործելուց հետո տեսնել ինձ չպատկանող բովանդակություն (լուրջ)

Ընդհանուր պատճառներ:

• Գլխավոր էջերը, ինչպիսիք են Զամբյուղը, Վճարումը և Իմ հաշիվը, պահվում են քեշում։
• JS-ի մինիֆիկացումն ու կոնկատենացիան առաջացնում են վճարման և դինամիկ բաղադրիչների անհամատեղելիություն։

Մոտեցում:

• WooCommerce-ը պաշտոնապես նշում է, որ գնումների զամբյուղի, վճարման և հաշվի էջերը չպետք է պահպանվեն քեշում և խորհուրդ է տալիս խուսափել JavaScript ֆայլերի կոմպրեսիայից։
• Նախ ճիշտ աշխատեցրեք “էջերի պահպանումը + բացառումը”, ապա մտածեք ֆրոնտ-ենդ օպտիմալացման մասին։
• Եթե օգտագործում եք WP Super Cache, WooCommerce-ը նշում է, որ այն բնիկ համատեղելի է և, որպես կանոն, բացառում է հիմնական էջերը քեշավորումից։

---

Դեպք 5: Մենյուները, ձևերը և պոպ-ափերը դադարում են աշխատել “Defer JS/Combine Scripts”-ը ակտիվացնելուց հետո

Ախտանիշներ:

• Նավիգացիոն մենյուն չի բացվում
• Ֆորմի վավերացումը ձախողվել է կամ ֆորմը չի կարող ուղարկվել։
• Pop-up/carousel-ի խնդիրներ
• Վիճակագրություն/փոխարկման իրադարձություններ չեն գործարկվում (հրատարակիչների համար ամենամեծ գլխացավանքը)

Ընդհանուր պատճառներ:

• JavaScript-ի փոփոխությունների հետաձգումը սցենարի գործարկման ժամանակ՝ սցենարը չի գործարկվում մինչև օգտվողը նրա հետ փոխազդի, մինչդեռ որոշ բաղադրիչներ հենվում են այն հանգամանքի վրա, որ դրանք նախնականացվեն անմիջապես էջի բեռնման պահին։“
• Միաձուլումը կամ սեղմումը կարող է փոխել սցրիպտների հերթականությունը կամ խախտել կախվածությունները։

WP Rocket-ը պաշտոնապես նկարագրում է “JS-ի գործարկման հետաձգումը” որպես իր ամենաուժեղ JS օպտիմալացումներից մեկը. սցրիպտները հետաձգվում են մինչև օգտվողի փոխազդեցությունը, որպեսզի էջը նախ կարողանա ցուցադրվել. սա հզոր հնարավորություն է, սակայն այն նաև ավելի մեծ ռիսկ է պարունակում համատեղելիության խնդիրների առումով.

Մոտեցում:

• Փուլ առ փուլ ներդնել՝ նախ կեշը, ապա պատկերները, հետո CSS-ը և վերջապես JavaScript-ը։
• Բացառել հիմնական սցրիպտները (վճարումներ, ձևաթղթեր, մենյուներ, հետևում)
• Յուրաքանչյուր փոփոխության համար պետք է կազմել ռեգրեսիոն թեստավորման ստուգաթերթիկ։

---

Պատշաճ 6: Ես միայն տեղադրել եմ LiteSpeed Cache-ը, բայց կարծես թե այն շատ բան չի անում։

Ախտանիշներ:

• Ես միացրել եմ LiteSpeed Cache-ը, բայց TTFB-ն շատ չի բարելավվել։
• Հարվածների ցուցանիշը նույնպես առանձնապես բարձր չէ։

Ընդհանուր պատճառներ:

• Ձեր սերվերը չի աշխատում LiteSpeed կամ OpenLiteSpeed-ով, ուստի դուք չեք կարող օգտվել LSCache-ի հիմնական հնարավորություններից։
• Կամ գուցե դուք միացրել եք բազմաթիվ օպտիմալացումներ, սակայն “էջերի քեշի քաղաքականությունը/նախապես տաքացումը/բացառումները” դեռ չեն կարգավորվել։

Մոտեցում:

• Առաջին հերթին ստուգեք վեբ սերվերի ստեկը՝ արդյոք դա LiteSpeed է, թե OpenLiteSpeed։ (Սա նախապայման է։)
• Նորից կենտրոնացրեք ջանքերը էջերի պահպանման ռազմավարությունների, նախաբեռման, խնդիրների լուծման և օպտիմալացման վրա։“
• Եթե դուք չեք օգտագործում LiteSpeed հոստինգը, դիտարկեք WP Rocket-ը կամ WP Super Cache-ը։