[Մի՛] օգտագործեք CDN

Կայքի արագության օպտիմալացման գրեթե յուրաքանչյուր հոդված կամ գործիք ունի «օգտագործեք CDN» համեստ դրույթ: Ընդհանուր առմամբ, CDN-ն բովանդակության առաքման ցանց է կամ բովանդակության առաքման ցանց: Մենք Method Lab-ում հաճախ հանդիպում ենք հաճախորդների հարցերին այս թեմայի վերաբերյալ. նրանցից ոմանք միացնում են իրենց սեփական CDN-ը: Այս հոդվածի նպատակն է հասկանալ, թե ինչ կարող է ապահովել CDN-ն կայքի բեռնման արագության առումով, ինչ խնդիրներ կարող են առաջանալ և որ դեպքերում է CDN-ի օգտագործումը արդարացված:

Նկարում շրջագծված ուշացումները պայմանավորված են CDN-ի օգտագործմամբ:

Մի քիչ պատմություն

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

Երբ փորձում եք մեկ սերվերից բազմաթիվ հաճախորդներին զուգահեռ հեռարձակել վիդեո հոսք, սերվերի ինտերնետային ալիքը, ամենայն հավանականությամբ, կդառնա խցան: Որպես կանոն, մի քանի հազար շարանը բավական է տիպիկ սերվերի ալիքը խցանելու համար։ Իհարկե, կարող են լինել այլ ռեսուրսների սահմանափակումներ, բայց դրանք այս պահին կարևոր չեն: Կարևոր է նաև, որ սերվերի ալիքի ընդլայնումը չափազանց թանկ է (և երբեմն անհնարին), ինչպես նաև անիրագործելի: Հեռարձակումների ժամանակ ալիքի ծանրաբեռնվածությունը կլինի ցիկլային։

Անհատական ​​սերվերի ալիքը սահմանափակելու խնդիրը հիանալի լուծվում է CDN-ի կողմից։ Հաճախորդները ուղղակիորեն չեն միանում սերվերին, այլ CDN ցանցի հանգույցներին: Իդեալական իրավիճակում սերվերը ուղարկում է մեկ հոսք դեպի CDN հանգույց, այնուհետև ցանցն օգտագործում է իր սեփական ռեսուրսները՝ այս հոսքը շատ օգտվողներին հասցնելու համար։ Տնտեսական տեսանկյունից մենք վճարում ենք միայն իրականում սպառված ռեսուրսների համար (սա կարող է լինել թողունակություն կամ տրաֆիկ) և ստանում ենք մեր ծառայության գերազանց մասշտաբայնությունը: Ծանր բովանդակություն տրամադրելու համար CDN օգտագործելը լիովին արդարացված է և տրամաբանական: Թեև հարկ է նշել, որ այս տարածության ամենամեծ խաղացողները (օրինակ՝ Netflix) կառուցում են իրենց սեփական CDN-ները՝ խոշոր առևտրային CDN-ներ օգտագործելու փոխարեն (Akamai, Cloudflare, Fastly և այլն):

Քանի որ համացանցը զարգանում է, վեբ հավելվածներն իրենք ավելի բարդ և բարդ են դարձել: Առաջին պլան մղվեց բեռնման արագության խնդիրը։ Վեբ կայքի արագության սիրահարները արագ հայտնաբերեցին մի քանի հիմնական խնդիրներ, որոնց պատճառով կայքերը դանդաղ էին բեռնվում: Դրանցից մեկը ցանցի ուշացումներն էին (RTT - շրջագայության ժամանակ կամ պինգ ժամանակ): Ձգձգումները ազդում են վեբկայքի բեռնման բազմաթիվ գործընթացների վրա՝ TCP կապի ստեղծում, TLS նիստ սկսել, յուրաքանչյուր առանձին ռեսուրս (պատկեր, JS ֆայլ, HTML փաստաթուղթ և այլն) բեռնում:

Խնդիրը խորացավ նրանով, որ HTTP/1.1 արձանագրությունն օգտագործելիս (մինչև SPDY, QUIC և HTTP/2-ի հայտնվելը սա միակ տարբերակն էր), բրաուզերները բացում են ոչ ավելի, քան 6 TCP կապ մեկ հոսթին։ Այս ամենը հանգեցրեց կապի դադարեցմանը և կապուղու թողունակության անարդյունավետ օգտագործմանը: Խնդիրը մասամբ լուծվեց դոմենների փոխանակման միջոցով՝ հավելյալ հոսթների ստեղծում՝ կապերի քանակի սահմանափակումը հաղթահարելու համար։

Այստեղ ի հայտ է գալիս CDN-ի երկրորդ կարողությունը՝ նվազեցնելով հետաձգումը (RTT)՝ պայմանավորված մեծ թվով կետերով և հանգույցների մոտիկությամբ օգտագործողին: Հեռավորությունն այստեղ որոշիչ դեր է խաղում՝ լույսի արագությունը սահմանափակ է (օպտիկական մանրաթելում մոտ 200 կմ/վրկ)։ Սա նշանակում է, որ յուրաքանչյուր 000 կմ ճանապարհորդություն ավելացնում է 1000 մվ ուշացում կամ 5 մվ RTT-ին: Սա փոխանցման համար պահանջվող նվազագույն ժամանակն է, քանի որ ուշացումներ կան նաև միջանկյալ սարքավորումների վրա: Քանի որ CDN-ն սովորաբար գիտի, թե ինչպես քեշավորել օբյեկտները իր սերվերների վրա, մենք կարող ենք օգուտ քաղել այդպիսի օբյեկտները CDN-ի միջոցով: Դրա համար անհրաժեշտ պայմանները. օբյեկտի առկայությունը քեշում, CDN կետի մոտիկությունը օգտատիրոջը՝ վեբ հավելվածի սերվերի (սկզբնաղբյուր) սերվերի համեմատությամբ: Կարևոր է հասկանալ, որ CDN հանգույցի աշխարհագրական հարևանությունը չի երաշխավորում ցածր ուշացում: Հաճախորդի և CDN-ի միջև երթուղին կարող է կառուցվել այնպես, որ հաճախորդը միանա այլ երկրում և, հնարավոր է, մեկ այլ մայրցամաքում գտնվող հոսթին: Այստեղ է, որ ի հայտ են գալիս հեռահաղորդակցության օպերատորների և CDN ծառայության միջև փոխհարաբերությունները (հավասարակշռում, կապեր, մասնակցություն IX-ին և այլն) և ինքնին CDN-ի երթևեկության երթուղային քաղաքականությունը: Օրինակ, Cloudflare-ը, երբ օգտագործում է երկու նախնական պլաններ (անվճար և էժան), չի երաշխավորում բովանդակության առաքումը մոտակա հյուրընկալողից. հյուրընկալողը կընտրվի նվազագույն արժեքին հասնելու համար:

Շատ առաջատար ինտերնետ ընկերություններ հանրային հետաքրքրություն են գրավում (վեբ մշակողներ և ծառայությունների սեփականատերեր) բեռնման արագության և վեբ կայքի աշխատանքի վերաբերյալ: Այս ընկերություններից են Yahoo-ն (Yslow գործիք), AOL-ը (WebPageTest) և Google-ը (Page Speed ​​​​Insights ծառայություն), որոնք մշակում են իրենց սեփական առաջարկությունները կայքերի արագացման համար (հիմնականում դրանք վերաբերում են հաճախորդների օպտիմալացմանը): Ավելի ուշ հայտնվում են վեբ կայքի արագության ստուգման նոր գործիքներ, որոնք նաև խորհուրդներ են տալիս կայքի արագության բարձրացման վերաբերյալ։ Այս ծառայություններից կամ հավելվածներից յուրաքանչյուրն ունի հետևողական առաջարկություն՝ «Օգտագործեք CDN»: Ցանցի հետաձգման կրճատումը սովորաբար նշվում է որպես CDN-ի ազդեցության բացատրություն: Ցավոք, ոչ բոլորն են պատրաստ հստակ հասկանալ, թե ինչպես է ձեռք բերվում CDN-ի արագացման էֆեկտը և ինչպես կարելի է այն չափել, ուստի առաջարկությունը վերցված է հավատքի վրա և օգտագործվում է որպես պոստուլատ: Փաստորեն, ոչ բոլոր CDN-ներն են ստեղծվում հավասար:

Օգտագործելով CDN այսօր

CDN-ների օգտագործման օգտակարությունը գնահատելու համար դրանք պետք է դասակարգվեն: Ի՞նչ կարելի է գտնել այժմ գործնականում (փակագծերում բերված օրինակները, իհարկե, սպառիչ չեն).

1. Անվճար CDN՝ JS գրադարաններ բաշխելու համար (MaxCDN, Google. Yandex):
2. Հաճախորդի օպտիմալացման ծառայությունների CDN (օրինակ՝ Google Fonts տառատեսակների համար, Cloudinary, Cloudimage պատկերների համար):
3. CDN ստատիկ և ռեսուրսների օպտիմալացման համար CMS-ում (հասանելի է Bitrix-ում, WordPress-ում և այլն):
4. Ընդհանուր նշանակության CDN (StackPath, CDNVideo, NGENIX, Megafon):
5. CDN վեբ կայքի արագացման համար (Cloudflare, Imperva, Airi):

Այս տեսակների հիմնական տարբերությունն այն է, թե երթևեկության որքան մասն է անցնում CDN-ով: 1-3 տեսակները բովանդակության միայն մի մասի առաքումն են՝ մեկ հարցումից մինչև մի քանի տասնյակ (սովորաբար նկարներ): 4-րդ և 5-րդ տեսակները երթևեկի ամբողջական պրոքսինգ են CDN-ի միջոցով:

Գործնականում դա նշանակում է միացումների քանակը, որոնք օգտագործվում են կայքը բեռնելու համար: HTTP/2-ով մենք օգտագործում ենք մեկ TCP կապ հոսթին ցանկացած քանակի հարցումներ մշակելու համար: Եթե ​​ռեսուրսները բաժանենք հիմնական հոսթի (ծագման) և CDN-ի, ապա անհրաժեշտ է հարցումները բաշխել մի քանի տիրույթներում և ստեղծել մի քանի TCP կապ։ Ամենավատ դեպքն է՝ DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT: Այս բանաձևը հաշվի չի առնում բջջային ցանցերում սարքի ռադիոալիքի ակտիվացման ուշացումները (եթե այն ակտիվ չէր) և բջջային աշտարակի հետաձգումները:

Ահա թե ինչ տեսք ունի կայքի բեռնման ջրվեժի վրա (CDN-ին միանալու ուշացումները ընդգծված են RTT 150 ms-ով).

Եթե ​​CDN-ն ընդգրկում է կայքի ողջ տրաֆիկը (բացառությամբ երրորդ կողմի ծառայությունների), ապա մենք կարող ենք օգտագործել մեկ TCP կապ՝ խնայելով լրացուցիչ հոսթերին միանալու ձգձգումները: Իհարկե, դա վերաբերում է HTTP/2 կապերին:

Հետագա տարբերությունները որոշվում են որոշակի CDN-ի ֆունկցիոնալությամբ. առաջին տիպի համար այն պարզապես ստատիկ ֆայլ է հոսթինգում, հինգերորդում այն ​​փոփոխում է կայքի բովանդակության մի քանի տեսակներ՝ օպտիմալացման նպատակով:

CDN հնարավորություններ վեբ կայքի արագացման համար

Եկեք նկարագրենք CDN-ի հնարավորությունների ողջ շրջանակը կայքերի արագացման համար՝ առանց հաշվի առնելու CDN-ի առանձին տեսակների ֆունկցիոնալությունը, այնուհետև տեսնենք, թե ինչ է իրականացվում դրանցից յուրաքանչյուրում:

1. Տեքստային ռեսուրսների սեղմում

Ամենատարրական և հասկանալի հատկանիշը, սակայն հաճախ վատ է իրականացվում: Բոլոր CDN-ները հայտարարում են սեղմման առկայությունը որպես իրենց արագացման հատկանիշ: Բայց եթե ավելի մանրամասն նայեք, թերությունները պարզ են դառնում.

• Դինամիկ սեղմման համար ցածր աստիճաններ կարող են օգտագործվել - 5-6 (օրինակ, gzip-ի համար առավելագույնը 9 է);
• ստատիկ սեղմումը (ֆայլերը քեշում) չի օգտագործում լրացուցիչ հնարավորություններ (օրինակ՝ zopfi կամ brotli 11 աստիճանով)
• Բրոտլիի արդյունավետ սեղմման համար աջակցություն չկա (խնայելով մոտ 20%՝ համեմատած gzip-ի հետ):

Եթե ​​դուք օգտագործում եք CDN, արժե ստուգել այս մի քանի կետերը. վերցրեք CDN-ից ստացված ֆայլը, ձայնագրեք դրա սեղմված չափը և սեղմեք այն ձեռքով համեմատության համար (օրինակ, brotli-ի աջակցությամբ կարող եք օգտագործել որոշ առցանց ծառայություն: vsszhat.rf).

2. Հաճախորդի քեշավորման վերնագրերի կարգավորում

Նաև արագացման պարզ հատկություն. ավելացրեք վերնագրեր հաճախորդի կողմից բովանդակության քեշավորման համար (զննարկիչ): Ամենաարդիական վերնագիրը քեշի կառավարումն է, հնացածը՝ ժամկետանց: Բացի այդ, Etag-ը կարող է օգտագործվել: Հիմնական բանը այն է, որ քեշի վերահսկման առավելագույն տարիքը բավականաչափ մեծ է (մեկ ամսից և ավելի): Եթե պատրաստ եք հնարավորինս կոշտ քեշավորել ռեսուրսը, կարող եք ավելացնել անփոփոխ տարբերակը:

CDN-ները կարող են նվազեցնել առավելագույն տարիքային արժեքը՝ ստիպելով օգտվողին ավելի հաճախ վերաբեռնել ստատիկ բովանդակությունը: Անհասկանալի է, թե դա ինչի հետ է կապված՝ ցանցում երթևեկությունն ավելացնելու ցանկության կամ այն ​​կայքերի հետ համատեղելիությունը, որոնք չգիտեն, թե ինչպես վերականգնել քեշը: Օրինակ, Cloudflare վերնագրի քեշի կանխադրված ժամանակը 1 ժամ է, ինչը շատ ցածր է անփոփոխ ստատիկ տվյալների համար:

3. Պատկերի օպտիմալացում

Քանի որ CDN-ն ստանձնում է պատկերների քեշավորման և սպասարկման գործառույթները, տրամաբանական կլինի դրանք օպտիմալացնել CDN-ի կողմից և մատուցել օգտատերերին այս ձևով: Եկեք անմիջապես վերապահենք, որ այս հատկությունը հասանելի է միայն CDN տիպերի 2, 3 և 5-ի համար:

Դուք կարող եք օպտիմիզացնել պատկերները տարբեր ձևերով՝ օգտագործելով առաջադեմ սեղմման ձևաչափեր (օրինակ՝ WebP), ավելի արդյունավետ կոդավորիչներ (MozJPEG) կամ պարզապես մաքրելով ավելորդ մետատվյալները:

Ընդհանրապես նման օպտիմալացումների երկու տեսակ կա՝ որակի կորստով և առանց որակի կորստի։ CDN-ները սովորաբար ձգտում են օգտագործել առանց կորուստների օպտիմիզացում՝ պատկերի որակի փոփոխության վերաբերյալ հաճախորդների հնարավոր բողոքներից խուսափելու համար: Նման պայմաններում շահույթը նվազագույն կլինի։ Իրականում, հաճախ JPEG որակի մակարդակը շատ ավելի բարձր է, քան անհրաժեշտ է, և դուք կարող եք ապահով կերպով վերասեղմել ավելի ցածր որակի մակարդակով՝ առանց խախտելու օգտվողի փորձը: Մյուս կողմից, դժվար է որակի և կարգավորումների մակարդակը համընդհանուր որոշել բոլոր հնարավոր վեբ հավելվածների համար, ուստի CDN-ներն օգտագործում են ավելի պահպանողական կարգավորումներ՝ համեմատած նրանց հետ, որոնք կարող են կիրառվել՝ հաշվի առնելով համատեքստը (պատկերների նպատակը, վեբ հավելվածի տեսակը: և այլն)

4. TLS կապի օպտիմիզացում

Երթևեկության մեծ մասն այսօր անցնում է TLS կապերով, ինչը նշանակում է, որ մենք լրացուցիչ ժամանակ ենք ծախսում TLS բանակցությունների վրա: Վերջերս այս գործընթացը արագացնելու համար նոր տեխնոլոգիաներ են մշակվել: Օրինակ, սա EC ծածկագրություն է, TLS 1.3, նիստերի քեշը և տոմսերը, ապարատային կոդավորման արագացումը (AES-NI) և այլն: TLS-ի ճիշտ կարգավորումը կարող է նվազեցնել կապի ժամանակը մինչև 0-1 RTT (չհաշված DNS և TCP):

Ժամանակակից ծրագրային ապահովման դեպքում դժվար չէ ինքնուրույն իրականացնել նման պրակտիկա:

Ոչ բոլոր CDN-ներն են իրականացնում TLS-ի լավագույն փորձը, դուք կարող եք դա ստուգել՝ չափելով TLS կապի ժամանակը (օրինակ՝ Webpagetest-ում): Իդեալական է նոր կապի համար՝ 1RTT, 2RTT՝ միջին մակարդակ, 3RTT և ավելի՝ վատ:

Հարկ է նաև նշել, որ նույնիսկ CDN մակարդակով TLS օգտագործելիս, մեր վեբ հավելվածով սերվերը նույնպես պետք է մշակի TLS, բայց CDN-ի կողմից, քանի որ սերվերի և CDN-ի միջև տրաֆիկը անցնում է հանրային ցանցով։ Ամենավատ դեպքում մենք կստանանք TLS կապի կրկնակի ուշացումներ (առաջինը CDN հոսթին, երկրորդը նրա և մեր սերվերի միջև):

Որոշ հավելվածների համար արժե ուշադրություն դարձնել անվտանգության խնդիրներին. տրաֆիկը սովորաբար վերծանվում է CDN հանգույցների վրա, և սա պոտենցիալ հնարավորություն է երթևեկության գաղտնալսման համար: Առանց երթևեկության բացահայտման աշխատելու տարբերակը սովորաբար առաջարկվում է լավագույն սակագնային պլաններում՝ հավելավճարով:

5. Նվազեցնել կապի ուշացումները

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

Գործնականում տարբեր ցանցերի առաջնահերթությունները կարող են լինել կոնկրետ տարածաշրջաններում: Օրինակ, ռուսական CDN-ները Ռուսաստանում ավելի շատ ներկայության կետեր կունենան: Ամերիկյաններն առաջին հերթին ցանցը կզարգացնեն ԱՄՆ-ում։ Օրինակ, ամենամեծ CDN Cloudflare-ից մեկը Ռուսաստանում ընդամենը 2 միավոր ունի՝ Մոսկվայում և Սանկտ Պետերբուրգում: Այսինքն, մենք կարող ենք խնայել առավելագույնը մոտ 10 մվ ուշացում՝ համեմատած Մոսկվայում ուղղակի տեղաբաշխման հետ:

Արևմտյան CDN-ների մեծ մասն ընդհանրապես միավորներ չունի Ռուսաստանում: Միանալով նրանց՝ դուք կարող եք միայն մեծացնել ուշացումները ձեր ռուս լսարանի համար։

6. Բովանդակության օպտիմիզացում (նվազագույնիֆիկացում, կառուցվածքային փոփոխություններ)

Ամենաբարդ և տեխնոլոգիապես առաջադեմ կետը: Առաքման ընթացքում բովանդակության փոփոխությունը կարող է շատ ռիսկային լինել: Նույնիսկ եթե մենք վերցնենք փոքրացումը. սկզբնաղբյուրի կրճատումը (ավելորդ տարածությունների, անկարևոր կառուցվածքների և այլնի պատճառով) կարող է ազդել դրա կատարման վրա: Եթե ​​խոսենք ավելի լուրջ փոփոխությունների մասին՝ JS կոդը HTML-ի վերջ տեղափոխելու, ֆայլերի միաձուլման և այլնի մասին, ապա կայքի ֆունկցիոնալությունը խաթարելու ռիսկն էլ ավելի մեծ է։

Հետևաբար, միայն որոշ տիպի 5 CDN-ներ են դա անում: Իհարկե, հնարավոր չի լինի ավտոմատացնել բոլոր փոփոխությունները, որոնք անհրաժեշտ են արագացնելու համար. անհրաժեշտ է ձեռքով վերլուծություն և օպտիմալացում: Օրինակ, չօգտագործված կամ կրկնօրինակ կոդի հեռացումը ձեռքով աշխատանք է:

Որպես կանոն, բոլոր նման օպտիմալացումները վերահսկվում են կարգավորումներով, իսկ ամենավտանգավորները լռելյայն անջատված են:

Աջակցություն արագացման հնարավորություններին ըստ CDN տեսակի

Այսպիսով, եկեք տեսնենք, թե ինչ պոտենցիալ արագացման հնարավորություններ են տալիս CDN-ների տարբեր տեսակները:

Հարմարության համար մենք կրկնում ենք դասակարգումը.

1. Անվճար CDN՝ JS գրադարաններ բաշխելու համար (MaxCDN, Google. Yandex):
2. Հաճախորդի օպտիմալացման ծառայությունների CDN (օրինակ՝ Google Fonts տառատեսակների համար, Cloudinary, Cloudimage պատկերների համար):
3. CDN ստատիկ և ռեսուրսների օպտիմալացման համար CMS-ում (հասանելի է Bitrix-ում, WordPress-ում և այլն):
4. Ընդհանուր նշանակության CDN (StackPath, CDNVideo, NGENIX, Megafon):
5. CDN վեբ կայքի արագացման համար (Cloudflare, Imperva, Airi):

Հիմա եկեք համեմատենք CDN-ի առանձնահատկություններն ու տեսակները.

Հնարավորություն
1 տեսակ
2 տեսակ
3 տեսակ
4 տեսակ
5 տեսակ

Տեքստի սեղմում
+–
-
+–
+–
+

Քեշի վերնագրեր
+
+
+
+
+

Նկարներ
-
+–
+–
-
+

TLS
-
-
-
+–
+

Ուշացումներ
-
-
-
+
+

Պարունակություն
-
-
-
-
+

Այս աղյուսակում «+»-ն օգտագործվում է ամբողջական աջակցություն ցույց տալու համար, «–»-ը աջակցություն չէ, իսկ «+–»-ը մասնակի աջակցություն է: Իհարկե, իրականում կարող են լինել այս աղյուսակից շեղումներ (օրինակ, որոշ ընդհանուր նշանակության CDN-ն կիրականացնի նկարների օպտիմալացման հնարավորություններ), բայց ընդհանուր գաղափարի համար դա օգտակար է։

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

Հուսանք, այս հոդվածը կարդալուց հետո դուք ավելի հստակ պատկեր կունենաք «օգտագործեք CDN» առաջարկության վերաբերյալ՝ ձեր կայքերն արագացնելու համար:

Ինչպես ցանկացած բիզնեսում, դուք չեք կարող հավատալ որևէ ծառայության մարքեթինգային խոստումներին: Էֆեկտը պետք է չափվի և փորձարկվի իրական պայմաններում: Եթե ​​դուք արդեն օգտագործում եք CDN, ստուգեք այն արդյունավետության համար՝ օգտագործելով հոդվածում նկարագրված չափանիշները:

Հնարավոր է, որ այս պահին CDN-ի օգտագործումը դանդաղեցնում է ձեր կայքի բեռնման ժամանակը:

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

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

Source: www.habr.com