WordPress Հոսթինգ և Փլագիններ
WordPress-ը արագ և ապահով դարձնելը. Կատարողականի և փլագինների ստուգաթերթ
WordPress-ը միշտ այնքան արագ և անվտանգ է, որքան այն, ինչ աշխատեցնում է այն։ Ահա այն գործնական ստուգաթերթը, որը մենք կիրառում ենք մեր հյուրընկալած յուրաքանչյուր WordPress կայքի համար՝ ինչը քեշավորել, ինչն ապահովել և որ պլագիններն են արժանի իրենց տեղին՝ հարթակի կողմից ավելորդ դարձածների համեմատ։
WordPress-ը լավն է այնքանով, որքանով այն աշխատեցնող միջավայրը
WordPress-ը սատարում է վեբի մեծ մասին, քանի որ այն ճկուն է, բայց այդ ճկունությունը նաև այն պատճառն է, թե ինչպես է այն դառնում դանդաղ և անապահով. լռելյայն տեղադրումը հարցնում է տվյալների բազան տասնյակ անգամներ յուրաքանչյուր էջի համար, հեռարձակում է իր տարբերակն ու ստեկը ցանկացած մեկին, ով նայում է, և հրավիրում է ձեզ կուտակել պլագիններ, մինչև կատարողականն ու հարձակման մակերեսը երկուսն էլ լուռ ու մեծանան: Դրանցից ոչ մեկը WordPress-ում թերություն չէ, որքան ենթակառուցվածքի վրա այն գործարկելու հետևանք, որը ոչինչ չի անում օգնելու համար:
Լավ նորությունն այն է, որ նույն մի քանի որոշումները շտկում են խնդիրների մեծ մասը, և դրանք բովանդակությանը չվերաբերող, այլ ստեկին առնչվող որոշումներ են: Ագրեսիվ կերպով քեշավորեք ճիշտ մակարդակում, տվյալների բազան հեռու պահեք հիմնական հոսքից, գործարկեք միայն այն մի քանի պլագինները, որոնք իսկապես արժանի են իրենց տեղին, ամեն ինչ թարմացրեք թարմացումներով և մեկուսացրեք կայքը, որպեսզի խնդիրը մնա իր սահմաններում: Այս գրառումն այդ ստուգաթերթն է՝ այն հերթականությամբ, որով մենք կիրառում ենք հարթակի յուրաքանչյուր WordPress կայքի վրա:
Քesh արեք սերվերում, այլ ոչ թե պարզապես պլագինում
WordPress-ի արագության ամենամեծ առանցքային գործոնը շատ այցելությունների դեպքում ընդհանրապես WordPress չգործարկելն է։ Ստանդարտ հարցումը գործարկում է WordPress-ը, աշխատեցնում ձեր հավելվածներն ու հարցում ուղարկում տվյալների բազային նախքան որևէ բայթ ուղարկելը. ամբողջական էջի քեշը պատրաստի էջը մատուցում է անմիջապես վեբ սերվերից հաջորդ այցելության ժամանակ՝ բաց թողնելով այդ ամբողջ գործարկումը։ Այն հարցը, թե որտեղ է գտնվում այդ քեշը, կարևոր է. քեշավորման հավելվածը գտնվում է PHP-ի ներսում, ուստի PHP-ն դեռևս սկսում է աշխատել նախքան քեշի պատասխանելը, մինչդեռ սերվերային մակարդակի քեշը պատասխանում է հարցմանն ավելի շուտ և պահում էջերն այնպիսի ձևաչափով, որը սերվերը կարող է ակնթարթորեն ուղարկել։
Յուրաքանչյուր WordPress կայք, որը մենք հոսթինգ ենք տրամադրում, աշխատում է LiteSpeed Enterprise-ով՝ սերվերային մակարդակի LSCache-ով, իսկ քեշի մեր սեփական փլագինը WordPress-ը ճիշտ միացնում է դրան հենց սկզբից՝ նախապես տեղադրված և ավտոմատ թարմացվող, այնպես որ սա ևս մեկ բան է, որը կարիք չկա կարգավորելու կամ թարմ պահելու: Ոչ LiteSpeed սերվերի վրա նույն փլագինը պարզապես չի արտանետում ամբողջական էջի header-ներ և չի խանգարում, քանի դեռ օբյեկտների քեշը շարունակում է աշխատել, այնպես որ տեղափոխված կայքը երբեք կիսատ կարգավորված չի մնում: Գործնական կանոնը ձեր սեփական ստուգաթերթիկի համար՝ մեկ ամբողջական էջի քեշ՝ սերվերի վրա, և դրա վրա չավելացնել քեշավորման երկրորդ փլագին. դրանք հակասում են միմյանց:
Օբյեկտների քեշը և տվյալների բազան
Ոչ մի հարցում չի կարող լինել ստատիկ էջ։ Մուտք գործած սեանսները, ադմինիստրատորի վահանակը, որոնումը, զամբյուղները և ցանկացված անհատականացված հատված պետք է գործարկեն PHP, և դրանց դեպքում նպատակը փոխվում է հավելվածը բաց թողնելուց մինչև տվյալների բազան բաց թողնելը: Կայքի մակարդակով օբյեկտների քեշը՝ մեր դեպքում Redis-ը, հիշողության մեջ պահում է տվյալների բազայից կատարվող կրկնվող ընթերցումների արդյունքները, որպեսզի միևնույն ընտրանքները, ժամանակավոր տվյալները (transients) և որոնումները չհարցվեն տվյալների բազայից յուրաքանչյուր այցելության ժամանակ: Արդյունքն ի հայտ է գալիս հենց այնտեղ, որտեղ ամբողջական էջի քեշն անօգնական է. ավելի արագ ադմինիստրատորի վահանակ, ավելի արագ զամբյուղներ և տվյալների բազայի վրա ծանրաբեռնվածության զգալի նվազում տրաֆիկի պայմաններում:
Վճռորոշ նշանակություն ունեցող բառն այստեղ «յուրաքանչյուր կայքի համար առանձին» հասկացությունն է: Օբյեկտների ընդհանուր քեշը նշանակում է, որ մեկ ծանրաբեռնված կամ վատ գրված կայքը կարող է ջնջել մնացած բոլորի քեշավորված տվյալները և տվյալների բազայի ռեսուրսներից զրկել իր «հարևաններին». իսկ յուրաքանչյուր կայքի համար հատկացված առանձին քեշը, տվյալների բազայի առանձին սահմանափակումների հետ մեկտեղ, կանխում է վնասի տարածումը: Ձեր ստուգաթերթում մշտական օբյեկտային քեշը (persistent object cache) համարեք պարտադիր պայման մուտք գործած օգտատերեր կամ առցանց խանութ ունեցող ցանկացած կայքի համար, և զգուշացեք այն հոսթինգներից, որտեղ այն ընդհանուր է տարբեր հաճախորդների միջև:
Այն հավելվածները, որոնք արժե գործարկել, և դրանք, որոնք հարթակը փոխարինում է
Յուրաքանչյուր հավելված, որը դուք ավելացնում եք, կոդ է, որն աշխատում է հարցումների ժամանակ, և մի դուռ, որով որևէ մեկը մի օր կարող է ներս մտնել, ուստի իրական նպատակն է ունենալ նվազագույն քանակով հավելվածներ, որոնք անում են առավելագույնը: Լավ հոսթինգը վերացնում է դրանց մի ամբողջ կատեգորիայի անհրաժեշտությունը. սերվերային մակարդակի քեշավորման, կառավարվող օբյեկտային քեշի (object cache) և պլատֆորմի պահուստային պատճենման շնորհիվ ձեզ անհրաժեշտ չեն քեշավորման հավելված, առանձին object-cache հավելված կամ պահուստային պատճենման հավելված — այդ աշխատանքներն ավելի լավ են կատարվում WordPress-ից ցածր մակարդակում, իսկ դրանք վերևում գործարկելը միայն կոնֆլիկտներ և լրացուցիչ ծանրաբեռնվածություն է ավելացնում:
Մնացել են միայն այն սակավաթիվ գործիքները, որոնք ապահովում են իրական հնարավորություններ. հավելվածներ, որոնք ձեր կայքին իրականում անհրաժեշտ են աշխատանքի համար, և՝ մեր հարթակում՝ երկու ռեպո մակարդակի հավելվածներ, որոնք մենք ստեղծում և տրամադրում ենք յուրաքանչյուր կայքի հետ: Մեր շերեփ-հիշողության (cache) հավելվածը միացնում է WordPress-ը սերվերի շերեփ-հիշողությանը և կառավարում խելացի մաքրումը, որպեսզի խմբագրումը մաքրի միայն այն էջերը, որոնք անհրաժեշտ է: Մեր footprint հավելվածը հեռացնում է այն նշանները, որոնք հաղորդում է WordPress-ի լռելյայն տեղադրումը՝ տարբերակի և գեներատորի պիտակը, հայտնաբերման վերջնակետերը, XML-RPC-ն, pingback-ները և powered-by գլխագիրը, յուրաքանչյուր տեղակայման ժամանակ, որպեսզի հավելվածի կամ թեմայի թարմացումը չկարողանա դրանք լուռ վերադարձնել: Երկուսն էլ ստեղծված են WordPress.org հավելվածների գրացուցակի ստանդարտներին համապատասխան, անվճար են և ինքնուրույն են թարմացվում:
WordPress-ը ապահով և արդիական պահելը
WordPress-ի խախտումների մեծ մասը խելացի չեն, այն հին են։ Հնացած միջուկը, թեման կամ պլագինը հայտնի, հրապարակված խոցելիությամբ, գերակշռող մեծամասնությամբ այն հիմնական միջոցն է, որով կայքերը ենթարկվում են հարձակման, ինչը թարմ մնալը դարձնում է անվտանգության ամենաբարձր արժեք ունեցող աշխատանքը, որը գոյություն ունի, և միաժամանակ՝ ամենաձանձրալին, այդ իսկ պատճառով այն բաց է թողնվում։ Կառավարվող հոսթինգը պետք է ձեզ ազատի դրանից՝ թարմացնելով WordPress-ի տակ գտնվող ստեկը և դարձնելով միջուկի ու պլագինների թարմացումները անվտանգ՝ տրամադրելով ստեյջինգ պատճեն՝ դրանք փորձարկելու համար, և արխիվային պատճեն՝ վերականգնելու համար։
Աrtարժույթից բացի, ակնկալեք, որ սահմանափակումները կկիրառվեն ձեզ համար. վնասաբեր ծրագրերի սկանավորումը լռելյայն միացված է, որպեսզի վարակը հայտնաբերվի նախքան այն այցելուի կողմից բացահայտվելը, մեկուսացում, որպեսզի վնասված մեկ կայքը չկարողանա հասնել մյուսին, DDoS պաշտպանություն եզրային կետում և TLS ամենուր՝ ավտոմատ կերպով թարմացվող վկայագրերով: Այդ ամենից ոչ մեկը չի փոխարինում հիմնական հիգիենային՝ ուժեղ հավատարմագրերին, նվազագույն արտոնություններով հասանելիությանը, այլևս չօգտագործվող հավելվածների հեռացմանը, բայց դա նշանակում է, որ ենթակառուցվածքը թույլ օղակ չէ: Ձեր ստուգաթերթում ցանկացած հոսթինգի համար հարցը պարզ է. անվտանգությունը լռելյայն է, թե՞ փաթեթ, որը դուք գնում եք:
WooCommerce և այն էջերը, որոնք երբեք չպետք է շերտապահես (cache)
Խանութն այն վայրն է, որտեղ ագրեսիվ քեշավորումն ապահովում է իր մեծագույն հաղթանակը և հասցնում ամենամեծ վնասը, եթե այն միամիտ է։ Կատալոգի, ապրանքի և կատեգորիայի էջերը ձեր ունեցած ամենաբարձր տրաֆիկ ունեցող, լավագույնս քեշավորվող էջերն են, և դրանք ամբողջական էջի քեշից սպասարկելը միակ լավագույն բանն է, որ կարող եք անել խանութի արագության համար։ Բայց զամբյուղի, վճարման և հաշվի էջերը անձնական են և երբեք չպետք է սպասարկվեն ընդհանուր քեշից. դա անելու դեպքում գնորդը կտեսնի ուրիշի զամբյուղը, ինչը միաժամանակ և՛ անսարք խանութ է, և՛ գաղտնիության խախտում։
Երկուսն էլ ունենալու եղանակը էջը քեշավորելն է և իրական ժամանակում թարմացվող հատվածների համար «անցքեր բացելը» (hole punching): Edge Side Includes-ը յուրաքանչյուր հարցման դեպքում մատուցում է զամբյուղի հատվածը, մինի-զամբյուղի ընդհանուր գումարները և հաշվի կարգավիճակը, մինչդեռ էջի մնացած մասը մատուցվում է քեշից, իսկ cart, checkout, my-account և ցանկացած nonce կամ session էջեր լռելյայն բացառվում են: Թարմությունը կարգավորվում է խելացի ավտոմատ մաքրման (auto-purge) միջոցով, որն աշխատում է ապրանքի, գնի կամ պատվերի փոփոխության դեպքում, այնպես որ հնացած գինը երբեք չի պահպանվում: Եթե օգտագործում եք WooCommerce, սա ստուգաթերթի այն մասն է, որը պետք է ճշգրիտ կատարել. արագ ցուցափեղկ քեշից, իրական ժամանակում թարմացվող զամբյուղ յուրաքանչյուր օգտատիրոջ համար և անձնական ոչ մի տվյալ երբեք չքեշավորված:
Հաճախ տրվող հարցեր
Արդյո՞ք ինձ դեռ անհրաժեշտ է քեշավորման փլագին, ինչպիսին է WP Rocket-ը:
Ոչ։ Ամբողջական էջերի քեշավորումը կառավարվում է վեբ սերվերի մակարդակով LiteSpeed-ի LSCache-ի միջոցով, մեր սեփական քեշի հավելվածը միացնում է WordPress-ը դրան և կառավարում խելացի մաքրումը, իսկ յուրաքանչյուր կայքի համար նախատեսված Redis օբյեկտների քեշը գտնվում է դրա հետևում: Երկրորդ ամբողջական էջերի քեշավորման հավելվածի ավելացումը վերևից սովորաբար հակասում է սերվերի մակարդակի քեշին, քան օգնում է, ուստի այն ոչ անհրաժեշտ է, ոչ էլ խորհուրդ է տրվում:
Ո՞ր պլագիններն է հարթակն ավելորդ դարձնում:
Քեշավորման փլագինները, օբյեկտների քեշավորման առանձին փլագինները և պահուստային պատճենման փլագիններն այստեղ ավելորդ են, քանի որ այդ աշխատանքները կատարվում են WordPress-ից ցածր մակարդակում՝ սերվերային մակարդակի քեշավորում, յուրաքանչյուր կայքի համար կառավարվող օբյեկտների քեշ և հարթակի պահուստային պատճենում: Դրանց հեռացումը նվազեցնում է կոնֆլիկտները և հարձակման ենթակա մակերեսը: Մնում է աշխատեցնել միայն այն փլագինները, որոնք իսկապես անհրաժեշտ են ձեր կայքի գործառույթների համար, ինչպես նաև մեր երկու անվճար քեշի և footprint փլագինները, որոնք մատակարարվում են նախապես տեղադրված:
Արդյոք քեշավորումը կխափանի իմ WooCommerce զամբյուղը կամ մուտք գործած օգտատերերի էջերը:
Ոչ։ Զամբյուղը, վճարման էջը, իմ հաշիվը և ցանկացած nonce կամ սեսիայի էջ լռելյայն բացառվում են քեշավորումից, իսկ Edge Side Includes-ը պահում է զամբյուղի հատվածն ու ընդհանուր գումարները ակտիվ այլ կերպ քեշավորված էջերում: Գնորդները միշտ տեսնում են իրենց սեփական զամբյուղը և աշխատող վճարման էջը, մինչդեռ խանութի վիտրինան դեռ բեռնվում է քեշից, և խելացի ավտոմատ մաքրումը հեռացնում է ազդեցության տակ գտնվող էջերը, երբ ապրանքը, գինը կամ պատվերը փոխվում է:
Ինչպե՞ս եք ապահովում WordPress-ի անվտանգությունը՝ առանց իմ կողմից այն կառավարելու:
Մենք կարգավորում ենք WordPress-ի տակ գտնվող ծրագրային միջավայրը, դարձնում հիմնական բաղադրիչների և հավելվածների թարմացումները անվտանգ՝ փորձնական տարբերակի (staging) և մեկ սեղմումով վերականգնման միջոցով, լռելյայն գործարկում վնասաբեր ծրագրերի սկանավորում և DDoS պաշտպանություն, մեկուսացնում յուրաքանչյուր կայք, որպեսզի մեկ խոցելիությունը չտարածվի, և ավտոմատ կերպով թողարկում ու թարմացնում TLS հավաստագրերը: Դա վերացնում է ենթակառուցվածքը՝ որպես թույլ օղակ, սակայն հիմնական հիգիենան, ինչպիսիք են ուժեղ հավատարմագրերը և չօգտագործվող հավելվածների հեռացումը, շարունակում է մնալ ձեր պատասխանատվությունը:
Առնչվող
Փորձեք անվճար 14 օրով
Գործարկե՛ք ձեր առաջին կայքերն անվճար 14 օրով՝ առանց քարտի։ Տեղափոխո՞ւմ եք գործող կայք կամ ցանց։ Ձեր առաջին միգրացիան մեր հաշվին է։
Սկսեք անվճար