Վեբկայքի քեշավորման օպտիմալացում

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

• Օգտատերերը չափազանց հեռու են ձեր սերվերից, ինչի արդյունքում ցանցային 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: Կեշավորել 1TB–184TB բայթկոդ (սովորաբար կարգավորվում է սերվերի կողմից; պլագինի հիմնական ուշադրության առարկա չէ)
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/սեսիա/նոնսից։
• Երբ քեշը այս էջերը դիտարկում է որպես “ստատիկ էջեր”, հետևանքները կարող են տատանվել կոճակների չաշխատելուց մինչև, ամենավատ դեպքերում, գների, պաշարների մակարդակների կամ հաշվի տվյալների անհամապատասխանությունների։
• Վատն այն է, որ ձեր թեստերը կարող են մեկ տարածաշրջանում հաջողությամբ անցնել, սակայն մեկ այլ տարածաշրջանում խնդիրների հանդիպել՝ CDN/cache հարվածների տարբերությունների պատճառով։

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 ֆայլերը անմիջապես մատուցվում են վեբ սերվերի կողմից, այդպիսով շրջանցելով թանկարժեք 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) աջակցություն։ Այն նաև ներառում է User-Agent-ով և Referrer-ով խմբավորված շարժական քեշավորում, AMP-ի աջակցություն և հակադարձ պրոքսի (Nginx/Varnish) ինտեգրում։

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

Իդեալական է՝

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

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

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

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

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

• Էջի քեշը կարող է պահպանվել հիշողության մեջ, սկավառակի վրա կամ 1 ՏԲ կամ 219 ՏԲ տարողությամբ։
• Տվյալների բազայի օբյեկտների քեշավորում, օբյեկտների քեշավորում՝ կարելի է օգտագործել 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. Ֆրոնթենդի օպտիմալացման (JS/CSS) վերագրումը առաջացրել է ֆունկցիոնալ խնդիրներ

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

2. Առաքման նախապատրաստական ռեգրեսիոն թեստավորման ստուգաթերթիկ

• Արդյո՞ք մուտք գործելու/ելքից դուրս գալու ֆունկցիան աշխատում է ճիշտ։
• Արդյո՞ք ձևաթղթերի ներկայացումները (կապի ձևաթղթեր, բաժանորդագրություններ, մուտք և գրանցում) աշխատում են ճիշտ։
• Էլեկտրոնային առևտրի գործընթացը՝ Ավելացնել զամբյուղին → Վաուչեր → Առաքման վճարներ/հարկեր → Վճարում → Պատվերի էջ
• Լեզվի փոխարկման ֆունկցիան կայուն է՞ (փոխարկումից հետո բովանդակության, URL-ների, hreflang-ի և արժույթի առումով)
• Արդյո՞ք շարժական մենյուն, pop-up պատուհանները, էջի գլորումը և հապաղող բեռնումը աշխատում են ճիշտ։
• Ստուգեք՝ արդյոք հետևման սկրիպտները (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-ը ստանդարտ կարգավորումներով չի քեշավորում հիմնական էջերը, ինչպիսիք են զամբյուղի, վճարման և հաշվի էջերը։
• Էլեկտրոնային առևտրում նորաստեղծ կայքերի համար “դադարների կանխարգելումը” ավելի կարևոր է, քան “առավելագույն կատարողականությունը”։

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 և տառատեսակներ) դեռևս բեռնվում են սկզբնական սերվերից մայրցամաքների միջով։
• Երրորդ կողմի սցրիպտները (գովազդներ, զրույց, վերլուծություն) դանդաղեցնում են էջի ցուցադրման և փոխազդեցության արագությունը։
• Նկարը չափազանց մեծ է, ինչի հետևանքով ներբեռման արագությունը դանդաղ է (cache-ումը չի կարող լուծել մեծ ֆայլի չափի խնդիրը “առաջնային ներբեռման” ընթացքում)

Մոտեցում:

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

Կարդացեք:

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

---

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

Ախտանիշներ:

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

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

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

Մոտեցում:

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