[അരുത്] ഒരു CDN ഉപയോഗിക്കരുത്

സൈറ്റ് സ്പീഡ് ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനുള്ള മിക്കവാറും എല്ലാ ലേഖനങ്ങൾക്കും ടൂളിനും "ഒരു CDN ഉപയോഗിക്കുക" എന്ന മിതമായ ക്ലോസ് ഉണ്ട്. പൊതുവേ, CDN ഒരു ഉള്ളടക്ക ഡെലിവറി നെറ്റ്‌വർക്ക് അല്ലെങ്കിൽ ഉള്ളടക്ക ഡെലിവറി നെറ്റ്‌വർക്ക് ആണ്. മെത്തേഡ് ലാബിൽ ഞങ്ങൾ ഈ വിഷയത്തിൽ ക്ലയന്റുകളിൽ നിന്ന് പലപ്പോഴും ചോദ്യങ്ങൾ നേരിടുന്നു; അവരിൽ ചിലർ അവരുടെ സ്വന്തം CDN പ്രവർത്തനക്ഷമമാക്കുന്നു. ഈ ലേഖനത്തിന്റെ ഉദ്ദേശ്യം, സൈറ്റ് ലോഡിംഗ് വേഗതയുടെ അടിസ്ഥാനത്തിൽ ഒരു CDN-ന് എന്ത് നൽകാൻ കഴിയും, എന്തൊക്കെ പ്രശ്നങ്ങൾ ഉണ്ടാകാം, ഏത് സാഹചര്യത്തിലാണ് ഒരു CDN ഉപയോഗിക്കുന്നത് ന്യായീകരിക്കപ്പെടുന്നത്.

ചിത്രത്തിൽ വട്ടമിട്ടിരിക്കുന്ന കാലതാമസം ഒരു സിഡിഎൻ ഉപയോഗിച്ചതാണ്.

ഒരു ചെറിയ ചരിത്രം

പല സാങ്കേതികവിദ്യകളെയും പോലെ, CDN-കളും ആവശ്യകതയിൽ നിന്ന് ഉയർന്നുവന്നു. ഇന്റർനെറ്റ് ഉപയോക്താക്കൾക്കിടയിൽ ഇന്റർനെറ്റ് ചാനലുകൾ വികസിപ്പിച്ചതോടെ ഓൺലൈൻ വീഡിയോ സേവനങ്ങൾ പ്രത്യക്ഷപ്പെട്ടു. സ്വാഭാവികമായും, സാധാരണ വെബ്‌സൈറ്റ് ഉള്ളടക്കവുമായി (ചിത്രങ്ങൾ, ടെക്‌സ്‌റ്റ്, CSS അല്ലെങ്കിൽ JS കോഡ്) അപേക്ഷിച്ച് വീഡിയോ ഉള്ളടക്കത്തിന് കൂടുതൽ ബാൻഡ്‌വിഡ്ത്ത് ഓർഡറുകൾ ആവശ്യമാണ്.

ഒരു സെർവറിൽ നിന്ന് നിരവധി ക്ലയന്റുകൾക്ക് സമാന്തരമായി ഒരു വീഡിയോ സ്ട്രീം പ്രക്ഷേപണം ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, സെർവറിന്റെ ഇന്റർനെറ്റ് ചാനൽ മിക്കവാറും തടസ്സമായി മാറും. ചട്ടം പോലെ, ഒരു സാധാരണ സെർവർ ചാനൽ തടസ്സപ്പെടുത്താൻ ഏതാനും ആയിരം ത്രെഡുകൾ മതിയാകും. തീർച്ചയായും, മറ്റ് വിഭവ പരിമിതികൾ ഉണ്ടാകാം, എന്നാൽ അവ ഇപ്പോൾ പ്രധാനമല്ല. സെർവർ ചാനൽ വിപുലീകരിക്കുന്നത് വളരെ ചെലവേറിയതാണ് (ചിലപ്പോൾ അസാധ്യമാണ്), കൂടാതെ അപ്രായോഗികവുമാണ്. പ്രക്ഷേപണ സമയത്ത് ചാനലിലെ ലോഡ് ചാക്രികമായിരിക്കും.

ഒരു വ്യക്തിഗത സെർവറിന്റെ ചാനൽ പരിമിതപ്പെടുത്തുന്നതിനുള്ള പ്രശ്നം CDN മുഖേന പരിഹരിച്ചിരിക്കുന്നു. ക്ലയന്റുകൾ നേരിട്ട് സെർവറിലേക്ക് കണക്റ്റുചെയ്യുന്നില്ല, മറിച്ച് CDN നെറ്റ്‌വർക്കിലെ നോഡുകളിലേക്കാണ്. അനുയോജ്യമായ സാഹചര്യത്തിൽ, സിഡിഎൻ നോഡിലേക്ക് സെർവർ ഒരു സ്ട്രീം അയയ്ക്കുന്നു, തുടർന്ന് ഈ സ്ട്രീം നിരവധി ഉപയോക്താക്കൾക്ക് കൈമാറാൻ നെറ്റ്‌വർക്ക് സ്വന്തം ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു. സാമ്പത്തിക വീക്ഷണകോണിൽ നിന്ന്, യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന വിഭവങ്ങൾക്ക് മാത്രമേ ഞങ്ങൾ പണം നൽകൂ (ഇത് ബാൻഡ്‌വിഡ്ത്ത് അല്ലെങ്കിൽ ട്രാഫിക് ആകാം) കൂടാതെ ഞങ്ങളുടെ സേവനത്തിന്റെ മികച്ച സ്കേലബിളിറ്റി നേടുകയും ചെയ്യുന്നു. കനത്ത ഉള്ളടക്കം നൽകുന്നതിന് ഒരു CDN ഉപയോഗിക്കുന്നത് പൂർണ്ണമായും ന്യായവും യുക്തിസഹവുമാണ്. വലിയ വാണിജ്യ CDN-കൾ (Akamai, Cloudflare, Fastly, മുതലായവ) ഉപയോഗിക്കുന്നതിന് പകരം ഈ സ്ഥലത്തെ ഏറ്റവും വലിയ കളിക്കാർ (ഉദാ: Netflix) സ്വന്തം CDN-കൾ നിർമ്മിക്കുന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

വെബ് വികസിച്ചതനുസരിച്ച്, വെബ് ആപ്ലിക്കേഷനുകൾ തന്നെ കൂടുതൽ സങ്കീർണ്ണവും സങ്കീർണ്ണവുമാണ്. ലോഡിംഗ് വേഗതയുടെ പ്രശ്നം മുന്നിലെത്തി. വെബ്‌സൈറ്റുകൾ സാവധാനത്തിൽ ലോഡുചെയ്യുന്നതിന് കാരണമായ നിരവധി പ്രധാന പ്രശ്‌നങ്ങൾ വെബ്‌സൈറ്റ് സ്പീഡ് പ്രേമികൾ പെട്ടെന്ന് തിരിച്ചറിഞ്ഞു. അതിലൊന്നാണ് നെറ്റ്‌വർക്ക് കാലതാമസം (ആർടിടി - റൗണ്ട് ട്രിപ്പ് സമയം അല്ലെങ്കിൽ പിംഗ് സമയം). വെബ്‌സൈറ്റ് ലോഡിംഗിലെ പല പ്രക്രിയകളെയും കാലതാമസം ബാധിക്കുന്നു: ഒരു TCP കണക്ഷൻ സ്ഥാപിക്കൽ, ഒരു TLS സെഷൻ ആരംഭിക്കൽ, ഓരോ വ്യക്തിഗത ഉറവിടവും ലോഡുചെയ്യുന്നു (ചിത്രം, JS ഫയൽ, HTML പ്രമാണം മുതലായവ)

HTTP/1.1 പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുമ്പോൾ (SPDY, QUIC, HTTP/2 എന്നിവയുടെ വരവിന് മുമ്പ് ഇത് ഒരേയൊരു ഓപ്‌ഷനായിരുന്നു), ബ്രൗസറുകൾ ഒരു ഹോസ്റ്റിലേക്ക് 6-ൽ കൂടുതൽ TCP കണക്ഷനുകൾ തുറക്കാത്തതാണ് പ്രശ്നം കൂടുതൽ വഷളാക്കിയത്. ഇതെല്ലാം കണക്ഷൻ പ്രവർത്തനരഹിതമാക്കുന്നതിനും ചാനൽ ബാൻഡ്‌വിഡ്‌ത്തിന്റെ കാര്യക്ഷമമല്ലാത്ത ഉപയോഗത്തിനും കാരണമായി. ഡൊമെയ്ൻ ഷാർഡിംഗ് വഴി പ്രശ്നം ഭാഗികമായി പരിഹരിച്ചു - കണക്ഷനുകളുടെ എണ്ണത്തിന്റെ പരിധി മറികടക്കാൻ അധിക ഹോസ്റ്റുകളുടെ സൃഷ്ടി.

ഇവിടെയാണ് CDN-ന്റെ രണ്ടാമത്തെ കഴിവ് ദൃശ്യമാകുന്നത് - ധാരാളം പോയിന്റുകളും ഉപയോക്താവിനുള്ള നോഡുകളുടെ സാമീപ്യവും കാരണം ലേറ്റൻസി (RTT) കുറയ്ക്കുന്നു. ദൂരം ഇവിടെ ഒരു നിർണായക പങ്ക് വഹിക്കുന്നു: പ്രകാശത്തിന്റെ വേഗത പരിമിതമാണ് (ഒപ്റ്റിക്കൽ ഫൈബറിൽ ഏകദേശം 200 കി.മീ/സെക്കൻഡ്). ഇതിനർത്ഥം, ഓരോ 000 കി.മീ യാത്രയും RTT ലേക്ക് 1000 ms കാലതാമസം അല്ലെങ്കിൽ 5 ms ചേർക്കുന്നു എന്നാണ്. ഇന്റർമീഡിയറ്റ് ഉപകരണങ്ങളിൽ കാലതാമസം ഉള്ളതിനാൽ ഇത് സംപ്രേഷണത്തിന് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ സമയമാണ്. ഒരു CDN-ന് സാധാരണയായി അതിന്റെ സെർവറുകളിൽ ഒബ്‌ജക്റ്റുകൾ കാഷെ ചെയ്യാൻ അറിയാവുന്നതിനാൽ, ഒരു CDN വഴി അത്തരം ഒബ്‌ജക്റ്റുകൾ ലോഡ് ചെയ്യുന്നതിൽ നിന്ന് നമുക്ക് പ്രയോജനം നേടാം. ഇതിന് ആവശ്യമായ വ്യവസ്ഥകൾ: കാഷെയിലെ ഒബ്‌ജക്‌റ്റിന്റെ സാന്നിധ്യം, വെബ് ആപ്ലിക്കേഷൻ സെർവറുമായി (ഒറിജിൻ സെർവർ) താരതമ്യപ്പെടുത്തുമ്പോൾ സിഡിഎൻ പോയിന്റിന്റെ സാമീപ്യം ഉപയോക്താവിന്. ഒരു CDN നോഡിന്റെ ഭൂമിശാസ്ത്രപരമായ സാമീപ്യം കുറഞ്ഞ ലേറ്റൻസി ഉറപ്പ് നൽകുന്നില്ലെന്ന് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്. ക്ലയന്റിനും CDN-നും ഇടയിലുള്ള റൂട്ടിംഗ്, മറ്റൊരു രാജ്യത്തും ഒരുപക്ഷേ മറ്റൊരു ഭൂഖണ്ഡത്തിലും ഒരു ഹോസ്റ്റുമായി ക്ലയന്റ് കണക്റ്റുചെയ്യുന്ന വിധത്തിൽ നിർമ്മിക്കാൻ കഴിയും. ഇവിടെയാണ് ടെലികോം ഓപ്പറേറ്റർമാരും സിഡിഎൻ സേവനവും (പിയറിംഗ്, കണക്ഷനുകൾ, ഐഎക്‌സിലെ പങ്കാളിത്തം മുതലായവ) തമ്മിലുള്ള ബന്ധവും സിഡിഎന്റെ തന്നെ ട്രാഫിക് റൂട്ടിംഗ് നയവും പ്രവർത്തിക്കുന്നത്. ഉദാഹരണത്തിന്, Cloudflare, രണ്ട് പ്രാരംഭ പ്ലാനുകൾ (സൗജന്യവും വിലകുറഞ്ഞതും) ഉപയോഗിക്കുമ്പോൾ, അടുത്തുള്ള ഹോസ്റ്റിൽ നിന്ന് ഉള്ളടക്കം ഡെലിവറി ചെയ്യുമെന്ന് ഉറപ്പുനൽകുന്നില്ല - ഏറ്റവും കുറഞ്ഞ ചെലവ് നേടാൻ ഹോസ്റ്റിനെ തിരഞ്ഞെടുക്കും.

പല പ്രമുഖ ഇന്റർനെറ്റ് കമ്പനികളും ലോഡിംഗ് വേഗതയും വെബ്‌സൈറ്റ് പ്രകടനവും എന്ന വിഷയത്തിലേക്ക് പൊതു താൽപ്പര്യം (വെബ് ഡെവലപ്പർമാരും സേവന ഉടമകളും) ആകർഷിക്കുന്നു. ഈ കമ്പനികളിൽ Yahoo (Yslow ടൂൾ), AOL (WebPageTest), Google (പേജ് സ്പീഡ് ഇൻസൈറ്റ്സ് സേവനം) എന്നിവ ഉൾപ്പെടുന്നു, അവ സൈറ്റുകൾ വേഗത്തിലാക്കാൻ അവരുടേതായ ശുപാർശകൾ വികസിപ്പിക്കുന്നു (പ്രാഥമികമായി അവ ക്ലയന്റ് ഒപ്റ്റിമൈസേഷനുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു). പിന്നീട്, പുതിയ വെബ്‌സൈറ്റ് സ്പീഡ് ടെസ്റ്റിംഗ് ടൂളുകൾ പ്രത്യക്ഷപ്പെടുന്നു, ഇത് വെബ്‌സൈറ്റ് വേഗത വർദ്ധിപ്പിക്കുന്നതിനുള്ള നുറുങ്ങുകളും നൽകുന്നു. ഈ സേവനങ്ങളിലോ പ്ലഗിന്നുകളിലോ ഓരോന്നിനും സ്ഥിരമായ ഒരു നിർദ്ദേശമുണ്ട്: "ഒരു CDN ഉപയോഗിക്കുക." നെറ്റ്‌വർക്ക് ലേറ്റൻസിയിലെ കുറവ് സാധാരണയായി CDN-ന്റെ ഫലത്തിന്റെ വിശദീകരണമായി ഉദ്ധരിക്കപ്പെടുന്നു. നിർഭാഗ്യവശാൽ, CDN-ന്റെ ആക്സിലറേഷൻ പ്രഭാവം എങ്ങനെ കൈവരിക്കാമെന്നും അത് എങ്ങനെ അളക്കാമെന്നും കൃത്യമായി മനസ്സിലാക്കാൻ എല്ലാവരും തയ്യാറല്ല, അതിനാൽ ശുപാർശ വിശ്വാസത്തിൽ എടുക്കുകയും ഒരു പോസ്റ്റുലേറ്റായി ഉപയോഗിക്കുകയും ചെയ്യുന്നു. വാസ്തവത്തിൽ, എല്ലാ CDN-കളും തുല്യമായി സൃഷ്ടിച്ചിട്ടില്ല.

CDN ഇന്ന് ഉപയോഗിക്കുന്നു

CDN-കൾ ഉപയോഗിക്കുന്നതിന്റെ പ്രയോജനം വിലയിരുത്തുന്നതിന്, അവയെ തരംതിരിക്കേണ്ടതുണ്ട്. പ്രായോഗികമായി ഇപ്പോൾ എന്താണ് കണ്ടെത്താൻ കഴിയുക (ബ്രാക്കറ്റുകളിലെ ഉദാഹരണങ്ങൾ തീർച്ചയായും സമഗ്രമല്ല):

1. JS ലൈബ്രറികൾ വിതരണം ചെയ്യുന്നതിനുള്ള സൗജന്യ CDN (MaxCDN, Google. Yandex).
2. ക്ലയന്റ് ഒപ്റ്റിമൈസേഷനായുള്ള സേവനങ്ങളുടെ CDN (ഉദാഹരണത്തിന്, ഫോണ്ടുകൾക്കുള്ള Google ഫോണ്ടുകൾ, ക്ലൗഡറി, ഇമേജുകൾക്കുള്ള ക്ലൗഡ് ഇമേജ്).
3. CMS-ൽ സ്റ്റാറ്റിക്, റിസോഴ്സ് ഒപ്റ്റിമൈസേഷനുള്ള CDN (ബിട്രിക്സ്, വേർഡ്പ്രസ്സ് എന്നിവയിലും മറ്റുള്ളവയിലും ലഭ്യമാണ്).
4. പൊതു ആവശ്യത്തിനുള്ള CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. വെബ്‌സൈറ്റ് ആക്സിലറേഷനായുള്ള CDN (Cloudflare, Imperva, Airi).

ഈ തരങ്ങൾ തമ്മിലുള്ള പ്രധാന വ്യത്യാസം സിഡിഎൻ വഴി എത്രത്തോളം ട്രാഫിക് പോകുന്നു എന്നതാണ്. 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 ആണ്);
• സ്റ്റാറ്റിക് കംപ്രഷൻ (കാഷെയിലെ ഫയലുകൾ) അധിക സവിശേഷതകൾ ഉപയോഗിക്കുന്നില്ല (ഉദാഹരണത്തിന്, ഡിഗ്രി 11 ഉള്ള സോഫി അല്ലെങ്കിൽ ബ്രോട്ട്ലി)
• കാര്യക്ഷമമായ ബ്രോട്ട്ലി കംപ്രഷന് പിന്തുണയില്ല (ജിസിപ്പുമായി താരതമ്യം ചെയ്യുമ്പോൾ ഏകദേശം 20% ലാഭിക്കുന്നു).

നിങ്ങൾ ഒരു CDN ഉപയോഗിക്കുകയാണെങ്കിൽ, ഈ കുറച്ച് പോയിന്റുകൾ പരിശോധിക്കുന്നത് മൂല്യവത്താണ്: CDN-ൽ നിന്ന് ലഭിച്ച ഫയൽ എടുക്കുക, അതിന്റെ കംപ്രസ് ചെയ്ത വലുപ്പം രേഖപ്പെടുത്തുക, താരതമ്യത്തിനായി സ്വമേധയാ കംപ്രസ് ചെയ്യുക (ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് brotli പിന്തുണയുള്ള ചില ഓൺലൈൻ സേവനം ഉപയോഗിക്കാം. vsszhat.rf).

2. ക്ലയന്റ് കാഷിംഗ് ഹെഡറുകൾ ക്രമീകരിക്കുന്നു

ഒരു ലളിതമായ സ്പീഡ് അപ്പ് ഫീച്ചറും: ക്ലയന്റ് (ബ്രൗസർ) വഴി ഉള്ളടക്കം കാഷെ ചെയ്യുന്നതിനായി തലക്കെട്ടുകൾ ചേർക്കുക. ഏറ്റവും നിലവിലുള്ള തലക്കെട്ട് കാഷെ-നിയന്ത്രണമാണ്, കാലഹരണപ്പെട്ടത് കാലഹരണപ്പെടുന്നു. കൂടാതെ, Etag ഉപയോഗിക്കാവുന്നതാണ്. പ്രധാന കാര്യം, കാഷെ-നിയന്ത്രണത്തിന്റെ പരമാവധി പ്രായം മതിയായതാണ് (ഒരു മാസമോ അതിൽ കൂടുതലോ) ഉറവിടം കഴിയുന്നത്ര കഠിനമായി കാഷെ ചെയ്യാൻ നിങ്ങൾ തയ്യാറാണെങ്കിൽ, നിങ്ങൾക്ക് മാറ്റമില്ലാത്ത ഓപ്ഷൻ ചേർക്കാം.

CDN-കൾക്ക് പരമാവധി പ്രായ മൂല്യം കുറയ്ക്കാൻ കഴിയും, ഇത് സ്ഥിരമായ ഉള്ളടക്കം കൂടുതൽ തവണ റീലോഡ് ചെയ്യാൻ ഉപയോക്താവിനെ പ്രേരിപ്പിക്കുന്നു. ഇത് എന്തിനുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്നത് വ്യക്തമല്ല: നെറ്റ്‌വർക്കിൽ ട്രാഫിക് വർദ്ധിപ്പിക്കാനുള്ള ആഗ്രഹം അല്ലെങ്കിൽ കാഷെ എങ്ങനെ പുനഃസജ്ജമാക്കണമെന്ന് അറിയാത്ത സൈറ്റുകളുമായി അനുയോജ്യത വർദ്ധിപ്പിക്കുക. ഉദാഹരണത്തിന്, സ്ഥിരസ്ഥിതി ക്ലൗഡ്ഫ്ലെയർ ഹെഡർ കാഷെ സമയം 1 മണിക്കൂറാണ്, ഇത് മാറ്റാനാവാത്ത സ്റ്റാറ്റിക് ഡാറ്റയ്ക്ക് വളരെ കുറവാണ്.

3. ഇമേജ് ഒപ്റ്റിമൈസേഷൻ

ഇമേജുകൾ കാഷെ ചെയ്യുന്നതിനും നൽകുന്നതിനുമുള്ള പ്രവർത്തനങ്ങൾ CDN ഏറ്റെടുക്കുന്നതിനാൽ, അവയെ CDN വശത്ത് ഒപ്റ്റിമൈസ് ചെയ്യുകയും ഈ ഫോമിൽ ഉപയോക്താക്കൾക്ക് നൽകുകയും ചെയ്യുന്നത് യുക്തിസഹമായിരിക്കും. CDN തരങ്ങൾ 2, 3, 5 എന്നിവയിൽ മാത്രമേ ഈ ഫീച്ചർ ലഭ്യമാകൂ എന്ന് ഉടൻ തന്നെ റിസർവേഷൻ ചെയ്യാം.

നിങ്ങൾക്ക് വിവിധ രീതികളിൽ ഇമേജുകൾ ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയും: വിപുലമായ കംപ്രഷൻ ഫോർമാറ്റുകൾ (വെബ്പി പോലുള്ളവ), കൂടുതൽ കാര്യക്ഷമമായ എൻകോഡറുകൾ (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 എന്നിവയും അതിലധികവും - മോശം.

സി‌ഡി‌എൻ തലത്തിൽ ടി‌എൽ‌എസ് ഉപയോഗിക്കുമ്പോൾ പോലും, ഞങ്ങളുടെ വെബ് ആപ്ലിക്കേഷനുള്ള സെർ‌വറും ടി‌എൽ‌എസ് പ്രോസസ്സ് ചെയ്യണം, പക്ഷേ സി‌ഡി‌എൻ വശത്ത് നിന്ന്, സെർ‌വറും സി‌ഡി‌എനും തമ്മിലുള്ള ട്രാഫിക് പൊതു നെറ്റ്‌വർക്കിലൂടെ കടന്നുപോകുന്നതിനാൽ. ഏറ്റവും മോശം സാഹചര്യത്തിൽ, ഞങ്ങൾക്ക് ഇരട്ട TLS കണക്ഷൻ കാലതാമസം ലഭിക്കും (ആദ്യത്തേത് CDN ഹോസ്റ്റിലേക്ക്, രണ്ടാമത്തേത് അതിനും ഞങ്ങളുടെ സെർവറിനുമിടയിൽ).

ചില ആപ്ലിക്കേഷനുകൾക്കായി, സുരക്ഷാ പ്രശ്നങ്ങളിൽ ശ്രദ്ധിക്കുന്നത് മൂല്യവത്താണ്: ട്രാഫിക് സാധാരണയായി CDN നോഡുകളിൽ ഡീക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു, ഇത് ട്രാഫിക് തടസ്സപ്പെടുത്താനുള്ള സാധ്യതയുള്ള അവസരമാണ്. ട്രാഫിക് വെളിപ്പെടുത്താതെ ജോലി ചെയ്യുന്നതിനുള്ള ഓപ്ഷൻ സാധാരണയായി ഒരു അധിക ഫീസായി ടോപ്പ് താരിഫ് പ്ലാനുകളിൽ വാഗ്ദാനം ചെയ്യുന്നു.

5. കണക്ഷൻ കാലതാമസം കുറയ്ക്കുക

എല്ലാവരും സംസാരിക്കുന്ന CDN-ന്റെ പ്രധാന നേട്ടം: CDN ഹോസ്റ്റും ഉപയോക്താവും തമ്മിലുള്ള കുറഞ്ഞ ലേറ്റൻസി (കുറവ് ദൂരം). ഉപയോക്താക്കളുടെ (നഗരങ്ങൾ, ട്രാഫിക് എക്സ്ചേഞ്ച് പോയിന്റുകൾ മുതലായവ) കേന്ദ്രീകരിച്ചിരിക്കുന്ന സ്ഥലങ്ങളിൽ ഹോസ്റ്റുകൾ സ്ഥിതി ചെയ്യുന്ന ഭൂമിശാസ്ത്രപരമായി വിതരണം ചെയ്ത നെറ്റ്‌വർക്ക് ആർക്കിടെക്ചർ സൃഷ്ടിക്കുന്നതിലൂടെ നേടിയെടുക്കുന്നു.

പ്രായോഗികമായി, വ്യത്യസ്‌ത നെറ്റ്‌വർക്കുകൾക്കുള്ള മുൻഗണനകൾ പ്രത്യേക പ്രദേശങ്ങളിലായിരിക്കാം. ഉദാഹരണത്തിന്, റഷ്യൻ CDN-കൾക്ക് റഷ്യയിൽ കൂടുതൽ സാന്നിധ്യമുണ്ടാകും. അമേരിക്കക്കാരാണ് ആദ്യം യുഎസ്എയിൽ നെറ്റ്‌വർക്ക് വികസിപ്പിക്കുക. ഉദാഹരണത്തിന്, ഏറ്റവും വലിയ CDN Cloudflare ന് റഷ്യയിൽ 2 പോയിന്റുകൾ മാത്രമേയുള്ളൂ - മോസ്കോയും സെന്റ് പീറ്റേഴ്സ്ബർഗും. അതായത്, മോസ്കോയിലെ നേരിട്ടുള്ള പ്ലെയ്‌സ്‌മെന്റുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ നമുക്ക് പരമാവധി 10 എംഎസ് ലേറ്റൻസി ലാഭിക്കാം.

മിക്ക പാശ്ചാത്യ CDN-കൾക്കും റഷ്യയിൽ പോയിന്റുകളൊന്നുമില്ല. അവരുമായി കണക്റ്റുചെയ്യുന്നതിലൂടെ, നിങ്ങളുടെ റഷ്യൻ പ്രേക്ഷകർക്കുള്ള കാലതാമസം വർദ്ധിപ്പിക്കാൻ മാത്രമേ നിങ്ങൾക്ക് കഴിയൂ.

6. ഉള്ളടക്ക ഒപ്റ്റിമൈസേഷൻ (മിനിഫിക്കേഷൻ, ഘടനാപരമായ മാറ്റങ്ങൾ)

ഏറ്റവും സങ്കീർണ്ണവും സാങ്കേതികമായി പുരോഗമിച്ചതുമായ പോയിന്റ്. ഡെലിവറി സമയത്ത് ഉള്ളടക്കം മാറ്റുന്നത് വളരെ അപകടകരമാണ്. നമ്മൾ മിനിഫിക്കേഷൻ എടുത്താലും: സോഴ്സ് കോഡ് കുറയ്ക്കുന്നത് (അധിക ഇടങ്ങൾ, അപ്രധാനമായ ഘടനകൾ മുതലായവ കാരണം) അതിന്റെ പ്രകടനത്തെ ബാധിക്കും. നമ്മൾ കൂടുതൽ ഗുരുതരമായ മാറ്റങ്ങളെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ - JS കോഡ് HTML-ന്റെ അവസാനത്തിലേക്ക് നീക്കുക, ഫയലുകൾ ലയിപ്പിക്കുക മുതലായവ - സൈറ്റിന്റെ പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്തുന്നതിനുള്ള സാധ്യത ഇതിലും കൂടുതലാണ്.

അതിനാൽ, ചില ടൈപ്പ് 5 CDN-കൾ മാത്രമാണ് ഇത് ചെയ്യുന്നത്. തീർച്ചയായും, കാര്യങ്ങൾ വേഗത്തിലാക്കാൻ ആവശ്യമായ എല്ലാ മാറ്റങ്ങളും ഓട്ടോമേറ്റ് ചെയ്യാൻ സാധ്യമല്ല - മാനുവൽ വിശകലനവും ഒപ്റ്റിമൈസേഷനും ആവശ്യമാണ്. ഉദാഹരണത്തിന്, ഉപയോഗിക്കാത്ത അല്ലെങ്കിൽ ഡ്യൂപ്ലിക്കേറ്റ് കോഡ് നീക്കംചെയ്യുന്നത് ഒരു മാനുവൽ ടാസ്ക്കാണ്.

ചട്ടം പോലെ, അത്തരം എല്ലാ ഒപ്റ്റിമൈസേഷനുകളും ക്രമീകരണങ്ങളാൽ നിയന്ത്രിക്കപ്പെടുന്നു, ഏറ്റവും അപകടകരമായവ സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനരഹിതമാക്കുന്നു.

CDN തരം ത്വരിതപ്പെടുത്തൽ കഴിവുകൾക്കുള്ള പിന്തുണ

അതിനാൽ വിവിധ തരത്തിലുള്ള CDN-കൾ നൽകുന്ന ത്വരിതപ്പെടുത്തൽ സാധ്യതകൾ എന്തൊക്കെയെന്ന് നോക്കാം.

സൗകര്യാർത്ഥം, ഞങ്ങൾ വർഗ്ഗീകരണം ആവർത്തിക്കുന്നു.

1. JS ലൈബ്രറികൾ വിതരണം ചെയ്യുന്നതിനുള്ള സൗജന്യ CDN (MaxCDN, Google. Yandex).
2. ക്ലയന്റ് ഒപ്റ്റിമൈസേഷനായുള്ള സേവനങ്ങളുടെ CDN (ഉദാഹരണത്തിന്, ഫോണ്ടുകൾക്കുള്ള Google ഫോണ്ടുകൾ, ക്ലൗഡറി, ഇമേജുകൾക്കുള്ള ക്ലൗഡ് ഇമേജ്).
3. CMS-ൽ സ്റ്റാറ്റിക്, റിസോഴ്സ് ഒപ്റ്റിമൈസേഷനുള്ള CDN (ബിട്രിക്സ്, വേർഡ്പ്രസ്സ് എന്നിവയിലും മറ്റുള്ളവയിലും ലഭ്യമാണ്).
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-ന് പിന്നിൽ നിലനിൽക്കുന്നു: സെർവർ ഭാഗത്തിന്റെ ഒപ്റ്റിമൈസേഷൻ, ക്ലയന്റ് ഭാഗത്തെ വിപുലമായ മാറ്റങ്ങൾ (ഉപയോഗിക്കാത്ത കോഡ് നീക്കംചെയ്യൽ, റെൻഡറിംഗ് പ്രക്രിയ ഒപ്റ്റിമൈസ് ചെയ്യുക, ഉള്ളടക്കം, ഫോണ്ടുകൾ, അഡാപ്റ്റബിലിറ്റി മുതലായവയിൽ പ്രവർത്തിക്കുന്നു. )

അവലംബം: www.habr.com