Ինքնահոսթինգ երրորդ կողմի ռեսուրսները՝ լավը, վատը, տգեղը

Վերջին տարիներին առաջնային նախագծերի օպտիմալացման ավելի ու ավելի շատ հարթակներ առաջարկում են ինքնուրույն հոսթինգի կամ երրորդ կողմի ռեսուրսների վստահեցման հնարավորություններ: Akamai-ն թույլ է տալիս սահմանել կոնկրետ պարամետրեր ինքնուրույն ստեղծվող URL-ների համար: Cloudflare-ն ունի Edge Workers տեխնոլոգիա: Fasterzine-ը կարող է վերաշարադրել URL-ներ էջերում, որպեսզի դրանք մատնանշեն երրորդ կողմի ռեսուրսները, որոնք գտնվում են կայքի հիմնական տիրույթում:

Եթե ​​գիտեք, որ ձեր նախագծում օգտագործվող երրորդ կողմի ծառայությունները շատ հաճախ չեն փոխվում, և որ դրանք հաճախորդներին տրամադրելու գործընթացը կարող է բարելավվել, ապա հավանաբար մտածում եք նման ծառայություններ մատուցելու մասին: Այս մոտեցմամբ դուք կարող եք շատ լավ մոտեցնել այս ռեսուրսները ձեր օգտատերերին և ձեռք բերել ավելի ամբողջական վերահսկողություն հաճախորդի կողմից նրանց քեշավորման վրա: Սա, ի լրումն, թույլ է տալիս պաշտպանել օգտվողներին երրորդ կողմի ծառայության «վթարի» կամ դրա կատարողականի վատթարացման հետևանքով առաջացած խնդիրներից:

Լավ. բարելավված կատարում

Ուրիշի ռեսուրսների ինքնուրույն հոսթինգը շատ ակնհայտ կերպով բարելավում է կատարումը: Զննարկիչը կարիք չունի նորից մուտք գործել DNS, այն պետք չէ հաստատել TCP կապ և կատարել TLS ձեռքսեղմում երրորդ կողմի տիրույթում: Դուք կարող եք տեսնել, թե ինչպես է ուրիշի ռեսուրսների ինքնուրույն հոսթինգը ազդում աշխատանքի վրա՝ համեմատելով հետևյալ երկու թվերը:

Երրորդ կողմի ռեսուրսները ներբեռնվում են արտաքին աղբյուրներից (վերցված ուստի)

Երրորդ կողմի ռեսուրսները պահվում են նույն տեղում, ինչ կայքի մնացած նյութերը (վերցված ուստի)

Իրավիճակը բարելավվում է նաև նրանով, որ բրաուզերը կօգտագործի հիմնական տիրույթի հետ արդեն հաստատված HTTP/2 կապից տվյալների մուլտիպլեքսավորման և առաջնահերթության հնարավորությունը։

Եթե ​​դուք չեք հյուրընկալում երրորդ կողմի ռեսուրսները, ապա քանի որ դրանք բեռնվելու են հիմնականից տարբերվող տիրույթից, դրանք չեն կարող առաջնահերթ լինել: Սա կստիպի նրանց մրցակցել միմյանց հետ հաճախորդի թողունակության համար: Սա կարող է հանգեցնել բովանդակության բեռնման ժամանակի, որը կարևոր է էջ կառուցելու համար, որը շատ ավելի երկար է, քան այն, ինչ հնարավոր կլիներ ձեռք բերել իդեալական պայմաններում: Այստեղ խոսեք HTTP/2 առաջնահերթության մասին, որը շատ լավ բացատրում է այս ամենը:

Կարելի է ենթադրել, որ ատրիբուտների օգտագործումը արտաքին ռեսուրսների հղումներում preconnect կօգնի լուծել խնդիրը. Այնուամենայնիվ, եթե այդ հղումներից չափազանց շատ լինեն տարբեր տիրույթներ, այն իրականում կարող է ծանրաբեռնել հաղորդակցման գիծը ամենակարևոր պահին:

Եթե ​​դուք ինքներդ եք հյուրընկալում երրորդ կողմի ռեսուրսները, կարող եք վերահսկել, թե կոնկրետ ինչպես են այդ ռեսուրսները տրամադրվում հաճախորդին: Խոսքը, մասնավորապես, հետևյալի մասին է.

• Դուք կարող եք ապահովել, որ օգտագործվում է տվյալների սեղմման ալգորիթմը, որը լավագույնս համապատասխանում է յուրաքանչյուր դիտարկիչին (Brotli/gzip):
• Դուք կարող եք մեծացնել քեշավորման ժամանակը ռեսուրսների համար, որոնք սովորաբար առանձնապես երկար չեն, նույնիսկ ամենահայտնի պրովայդերների դեպքում (օրինակ, GA պիտակի համար համապատասխան արժեքը սահմանված է 30 րոպե):

Դուք նույնիսկ կարող եք երկարացնել TTL-ը ռեսուրսի համար, ասենք, մեկ տարի՝ ներառելով համապատասխան բովանդակություն ձեր քեշավորման կառավարման ռազմավարության մեջ (URL հեշեր, տարբերակների մշակում և այլն): Այս մասին կխոսենք ստորև:

▍Պաշտպանություն երրորդ կողմի ծառայությունների աշխատանքի ընդհատումներից կամ դրանց անջատումից

Ինքնահոսթինգի երրորդ կողմի ռեսուրսների մեկ այլ հետաքրքիր կողմն այն է, որ այն թույլ է տալիս մեղմել երրորդ կողմի ծառայությունների խափանումների հետ կապված ռիսկերը: Ենթադրենք, որ երրորդ կողմի A/B թեստավորման լուծումը, որն օգտագործում եք, իրականացվում է որպես արգելափակող սկրիպտ, որը բեռնվում է էջի գլխի բաժնում: Այս սցենարը դանդաղ է բեռնվում: Եթե ​​համապատասխան սկրիպտը չհաջողվի բեռնել, էջը դատարկ կլինի: Եթե ​​բեռնումը շատ երկար տևի, էջը կհայտնվի երկար ուշացումով։ Կամ, ենթադրենք, որ նախագիծն օգտագործում է երրորդ կողմի CDN ռեսուրսից ներբեռնված գրադարան: Պատկերացնենք, որ այս ռեսուրսը որոշակի երկրում ձախողվել է կամ արգելափակվել։ Նման իրավիճակը կբերի կայքի տրամաբանության խախտման։

Պարզելու համար, թե ինչպես է աշխատում ձեր կայքը, երբ որոշ արտաքին ծառայություններ անհասանելի են, կարող եք օգտագործել SPOF բաժինը webpagetest.org.

SPOF բաժինը webpagetest.org-ում

▍Ի՞նչ կասեք բրաուզերներում նյութերի քեշավորման հետ կապված խնդիրների մասին: (ակնարկ. դա առասպել է)

Դուք կարող եք մտածել, որ հանրային CDN-ների օգտագործումը ավտոմատ կերպով կհանգեցնի ռեսուրսների ավելի լավ աշխատանքի, քանի որ այս ծառայություններն ունեն բավականին բարձրորակ ցանցեր և տարածվում են ամբողջ աշխարհում: Բայց իրականում ամեն ինչ մի փոքր ավելի բարդ է:

Ենթադրենք, մենք ունենք մի քանի տարբեր կայքեր՝ website1.com, website2.com, website3.com: Այս բոլոր կայքերն օգտագործում են jQuery գրադարանը: Մենք այն միացնում ենք նրանց՝ օգտագործելով CDN, օրինակ՝ googleapis.com: Դուք կարող եք ակնկալել, որ զննարկիչը մեկ անգամ ներբեռնելու և պահելու է գրադարանը, այնուհետև այն կօգտագործի բոլոր երեք կայքերում: Սա կարող է նվազեցնել ցանցի բեռը: Միգուցե դա ձեզ թույլ կտա ինչ-որ տեղ գումար խնայել և օգնել բարելավել ռեսուրսի աշխատանքը: Գործնական տեսանկյունից ամեն ինչ այլ կերպ է թվում։ Օրինակ, Safari-ն ունի մի ֆունկցիա, որը կոչվում է Խելացի հետևելու կանխարգելումՔեշը օգտագործում է երկակի բանալիներ՝ հիմնված փաստաթղթի աղբյուրի և երրորդ կողմի ռեսուրսի աղբյուրի վրա: Այստեղ լավ հոդված այս թեմայով:

հին ուսումնասիրություններ Անտաշ անասուն նողկալի արարած и facebook, ինչպես նաև ավելի վերջերս հետազոտություն Պոլ Կալվանոն ցույց է տալիս, որ ռեսուրսները չեն պահվում բրաուզերի քեշերում այնքան ժամանակ, որքան մենք կարող ենք ակնկալել. Խոսքը CSS-ի և վեբ տառատեսակների մասին է։ Մասնավորապես, բնիկ տառատեսակների 95%-ի քեշի կյանքը մեկ շաբաթից ավելի է, մինչդեռ երրորդ կողմի տառատեսակների 50%-ի քեշի կյանքը մեկ շաբաթից պակաս է: Սա վեբ ծրագրավորողներին համոզիչ պատճառ է տալիս իրենք իրենց տառատեսակի ֆայլերը հյուրընկալելու համար»:

Արդյունքում, եթե դուք հյուրընկալում եք այլ մարդկանց բովանդակությունը, դուք չեք նկատի բրաուզերի քեշավորման հետևանքով առաջացած կատարողականի որևէ խնդիր:

Այժմ, երբ մենք լուսաբանեցինք երրորդ կողմի ինքնահոսթինգի ուժեղ կողմերը, եկեք խոսենք այն մասին, թե ինչպես կարելի է տարբերակել այս մոտեցման լավ իրականացումը վատից:

Վատը՝ սատանան մանրուքների մեջ է

Երրորդ կողմի ռեսուրսները ձեր սեփական տիրույթ տեղափոխելը չի ​​կարող ավտոմատ կերպով իրականացվել՝ առանց ապահովելու, որ այդպիսի ռեսուրսները պատշաճ կերպով պահված են:

Այստեղ հիմնական խնդիրներից մեկը քեշավորման ժամանակն է: Օրինակ, տարբերակի մասին տեղեկատվությունը ներառված է երրորդ կողմի սկրիպտների անուններում, ինչպիսիք են. jquery-3.4.1.js. Նման ֆայլը ապագայում չի փոխվի, և արդյունքում դա որևէ խնդիր չի առաջացնի դրա քեշավորման հետ կապված:

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

Ճիշտ է, եթե խոսենք հաճախակի թարմացվող նյութերի մասին (tag managers, A/B թեստավորման լուծումներ), ապա CDN գործիքների միջոցով դրանց քեշավորումը լուծելի խնդիր է, բայց շատ ավելի բարդ։ Ծառայությունները, ինչպիսիք են Commanders Act-ը, պիտակների կառավարման լուծումը, օգտագործում են վեբ-կեռիկներ նոր տարբերակները հրապարակելիս: Սա ձեզ հնարավորություն է տալիս ստիպել քեշը լցվել CDN-ի վրա, կամ, ավելի լավ, հեշ կամ URL-ի թարմացում պարտադրելու հնարավորություն:

▍Նյութերի հարմարվողական առաքում հաճախորդներին

Բացի այդ, երբ մենք խոսում ենք քեշավորման մասին, մենք պետք է հաշվի առնենք այն փաստը, որ CDN-ում օգտագործվող քեշավորման կարգավորումները կարող են հարմար չլինել երրորդ կողմի որոշ ռեսուրսների համար: Օրինակ՝ նման ռեսուրսները կարող են օգտագործել օգտատերերի հոտառության (հարմարվողական սպասարկում) տեխնոլոգիա՝ հատուկ բրաուզերներին սպասարկելու համար բովանդակության տարբերակները, որոնք օպտիմիզացված են հատուկ այդ բրաուզերների համար: Այս տեխնոլոգիաները հիմնվում են կանոնավոր արտահայտությունների կամ HTTP վերնագրի տեղեկատվության տվյալների բազայի վրա՝ բրաուզերի հնարավորությունները պարզելու համար: User-Agent. Երբ նրանք իմանան, թե որ բրաուզերի հետ գործ ունեն, նրան տալիս են դրա համար նախատեսված նյութեր։

Այստեղ դուք կարող եք հիշել երկու ծառայություն. Առաջինը googlefonts.com-ն է։ Երկրորդը polyfill.io-ն է։ Google Fonts ծառայությունը որոշակի ռեսուրսի համար տրամադրում է տարբեր CSS կոդ՝ կախված բրաուզերի հնարավորություններից (հղումներ տալով woff2 ռեսուրսներին՝ օգտագործելով unicode-range).

Ահա Google Fonts-ի մի քանի հարցումների արդյունքները, որոնք արվել են տարբեր բրաուզերներից:

Google Fonts-ի հարցման արդյունքը Chrome-ից

IE10-ից կատարված Google Fonts հարցման արդյունքը

Polyfill.io-ն զննարկիչին տալիս է միայն իրեն անհրաժեշտ պոլիֆիլները: Սա արվում է կատարողականի նկատառումներով:

Օրինակ, եկեք տեսնենք, թե ինչ է տեղի ունենում, եթե գործարկեք հետևյալ հարցումը տարբեր բրաուզերներից. https://polyfill.io/v3/polyfill.js?features=default

Ի պատասխան IE10-ից կատարված նման հարցման, կստացվի 34 ԿԲ տվյալ: Եվ դրա պատասխանը՝ կատարված Chrome-ից, դատարկ կլինի։

Զայրացած. Գաղտնիության որոշ նկատառումներ

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

Եթե ​​ձեր CDN համակարգը ճիշտ կազմաձևված չէ, դուք կարող եք ի վերջո ուղարկել ձեր տիրույթի թխուկները երրորդ կողմի ծառայությանը: Եթե ​​պատշաճ զտումը կազմակերպված չէ CDN մակարդակում, ապա ձեր նստաշրջանի թխուկները, որոնք սովորաբար չեն կարող օգտագործվել JavaScript-ում (այսուհետ՝ httponly), կարող է ուղարկվել օտարերկրյա հյուրընկալողին:

Սա հենց այն է, ինչ կարող է պատահել Eulerian-ի կամ Criteo-ի նման թրեքերի հետ: Երրորդ կողմի հետագծերը կարող են եզակի նույնացուցիչ սահմանել թխուկի մեջ: Եթե ​​դրանք կայքի նյութերի մաս էին, նրանք կարող էին կարդալ նույնացուցիչն իրենց հայեցողությամբ, մինչ օգտատերը աշխատում էր տարբեր վեբ ռեսուրսների հետ:

Այս օրերին բրաուզերների մեծամասնությունը ներառում է պաշտպանություն այս տեսակի հետագծային վարքագծի դեմ: Արդյունքում, թրեքերներն այժմ օգտագործում են տեխնոլոգիա CNAME քողարկում, դիմակավորվելով որպես իրենց սեփական սցենարներ տարբեր նախագծերի համար: Մասնավորապես, թրեյքերները կայքի սեփականատերերին առաջարկում են CNAME ավելացնել իրենց կարգավորումներում որոշակի տիրույթի համար, որի հասցեն սովորաբար նման է նիշերի պատահական շարքին:

Թեև խորհուրդ չի տրվում կայքի թխուկները հասանելի դարձնել բոլոր ենթադոմեյններին (օրինակ՝ *.website.com), շատ կայքեր դա անում են։ Այս դեպքում, նման թխուկները ավտոմատ կերպով ուղարկվում են քողարկված երրորդ կողմի հետքեր: Արդյունքում, մենք այլևս չենք կարող խոսել որևէ գաղտնիության մասին:

Նույնը տեղի է ունենում նաև HTTP վերնագրերի դեպքում Հաճախորդ-Հուշումներ, որոնք ուղարկվում են միայն հիմնական տիրույթ, քանի որ դրանք կարող են օգտագործվել ստեղծելու համար թվային մատնահետք օգտագործող. Համոզվեք, որ ձեր օգտագործած CDN ծառայությունը ճիշտ է զտում այս վերնագրերը:

Արդյունքները

Եթե ​​նախատեսում եք շուտով իրականացնել երրորդ կողմի ռեսուրսների ինքնուրույն հոսթինգ, թույլ տվեք ձեզ մի քանի խորհուրդ տալ.

• Տեղադրեք ձեր ամենակարևոր JS գրադարանները, տառատեսակները և CSS ֆայլերը: Սա կնվազեցնի կայքի ձախողման կամ կատարողականի վատթարացման վտանգը՝ կայքի համար կենսական նշանակություն ունեցող ռեսուրսի անհասանելի լինելու պատճառով՝ երրորդ կողմի ծառայության մեղքով:
• Նախքան CDN-ի վրա երրորդ կողմի ռեսուրսները քեշավորելը, համոզվեք, որ դրանց ֆայլերը անվանելիս օգտագործվում է ինչ-որ տարբերակավորման համակարգ, կամ որ կարող եք կառավարել այդ ռեսուրսների կյանքի ցիկլը՝ ձեռքով կամ ավտոմատ կերպով վերականգնելով CDN քեշը, երբ հրապարակեք նոր տարբերակը: սցենարը։
• Շատ զգույշ եղեք ձեր CDN-ի, պրոքսի սերվերի և քեշի կարգավորումների վերաբերյալ: Սա թույլ կտա կանխել ձեր նախագծի կամ վերնագրերի քուքիների ուղարկումը Client-Hints երրորդ կողմի ծառայություններ:

Հարգելի ընթերցողներ: Ձեր սերվերների վրա հյուրընկալո՞ւմ եք այլ մարդկանց նյութերը, որոնք չափազանց կարևոր են ձեր նախագծերի շահագործման համար:

Source: www.habr.com