ကိုယ်ပိုင် hosting ပြင်ပအဖွဲ့အစည်း အရင်းအမြစ်များ- အကောင်း၊ အဆိုး၊ အရုပ်ဆိုး

မကြာသေးမီနှစ်များအတွင်း၊ ရှေ့ဆုံးပရောဂျက်များကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် ပလပ်ဖောင်းများ ပိုများလာကာ မိမိကိုယ်ကို hosting သို့မဟုတ် proxying ပြင်ပအရင်းအမြစ်များကို အသုံးပြုရန်အတွက် အခွင့်အလမ်းများ ပေးပါသည်။ Akamai ကို သတ်မှတ်နိုင်ရမယ်။ သီးခြားဘောင်များ ကိုယ်တိုင်ဖန်တီးထားသော URL များအတွက်။ Cloudflare တွင် Edge Workers နည်းပညာရှိသည်။ Fasterzine လုပ်နိုင်ပါတယ်။ ပြန်ရေးပါ။ စာမျက်နှာများရှိ URL များသည် ဆိုက်၏ ပင်မဒိုမိန်းတွင်ရှိသော ပြင်ပအဖွဲ့အစည်းအရင်းအမြစ်များကို ညွှန်ပြနိုင်စေရန်။

သင့်ပရောဂျက်တွင်အသုံးပြုသည့် ပြင်ပကုမ္ပဏီဝန်ဆောင်မှုများသည် မကြာခဏမပြောင်းလဲကြောင်းနှင့် ၎င်းတို့အား ဖောက်သည်များထံ ပေးပို့ခြင်းလုပ်ငန်းစဉ်ကို ပိုမိုကောင်းမွန်လာစေနိုင်သည်ကို သင်သိပါက၊ ထိုကဲ့သို့သောဝန်ဆောင်မှုများကို proxy ပေးရန်အတွက် သင်စဉ်းစားနေပေမည်။ ဤချဉ်းကပ်မှုဖြင့်၊ သင်သည် ဤအရင်းအမြစ်များကို သင့်အသုံးပြုသူများထံ ပိုမိုနီးကပ်စွာ ယူဆောင်လာနိုင်ပြီး ကလိုင်းယင့်ဘက်တွင် ၎င်းတို့၏ caching ကို ပိုမိုပြည့်စုံစွာ ထိန်းချုပ်နိုင်မည်ဖြစ်သည်။ ထို့အပြင် ၎င်းသည် ပြင်ပကုမ္ပဏီဝန်ဆောင်မှုတစ်ခု၏ "ပျက်ကျခြင်း" သို့မဟုတ် ၎င်း၏စွမ်းဆောင်ရည်ကို ကျဆင်းစေသော ပြဿနာများမှ သုံးစွဲသူများကို ကာကွယ်ပေးနိုင်သည်။

ကောင်းသည်- စွမ်းဆောင်ရည် မြှင့်တင်ထားသည်။

အခြားသူတစ်ဦး၏အရင်းအမြစ်များကို ကိုယ်တိုင်လက်ခံဆောင်ရွက်ပေးခြင်းသည် စွမ်းဆောင်ရည်ကို အလွန်သိသာထင်ရှားသောနည်းလမ်းဖြင့် တိုးတက်စေသည်။ ဘရောက်ဆာသည် DNS ကို ထပ်မံဝင်ရောက်ရန် မလိုအပ်ပါ၊ ၎င်းသည် TCP ချိတ်ဆက်မှုတစ်ခုကို တည်ထောင်ရန်နှင့် ပြင်ပကုမ္ပဏီဒိုမိန်းတွင် TLS လက်ဆွဲနှုတ်ဆက်ရန် မလိုအပ်ပါ။ အောက်ပါပုံနှစ်ခုကို နှိုင်းယှဉ်ခြင်းဖြင့် အခြားသူတစ်ဦး၏အရင်းအမြစ်များကို ကိုယ်တိုင်လက်ခံဆောင်ရွက်ပေးခြင်းသည် စွမ်းဆောင်ရည်အပေါ် မည်ကဲ့သို့အကျိုးသက်ရောက်သည်ကို သင်တွေ့မြင်နိုင်ပါသည်။

ပြင်ပအရင်းအမြစ်များကို ပြင်ပအရင်းအမြစ်များမှ ဒေါင်းလုဒ်လုပ်သည် (ထံမှရယူသည်။ ဒီမှာ)

Third-party ရင်းမြစ်များကို အခြား site ပစ္စည်းများကဲ့သို့ တစ်နေရာတည်းတွင် သိမ်းဆည်းထားပါသည် (ထံမှ ယူသည်။ ဒီမှာ)

browser သည် multiplex လုပ်နိုင်စွမ်းနှင့် main domain ဖြင့်တည်ဆောက်ထားပြီးဖြစ်သော HTTP/2 ချိတ်ဆက်မှုမှ ဒေတာများကို ဦးစားပေးလုပ်ဆောင်မည်ဟူသောအချက်ကြောင့်လည်း အခြေအနေတိုးတက်လာပါသည်။

အကယ်၍ သင်သည် ပြင်ပအဖွဲ့အစည်း ရင်းမြစ်များကို လက်ခံဆောင်ရွက်ခြင်းမပြုပါက၊ ၎င်းတို့ကို ပင်မတစ်ခုနှင့် မတူသော ဒိုမိန်းတစ်ခုမှ တင်ဆောင်မည်ဖြစ်သောကြောင့် ၎င်းတို့ကို ဦးစားပေး၍ မရပါ။ ဒါက client ရဲ့ bandwidth အတွက် အချင်းချင်း ပြိုင်ဆိုင်စေပါလိမ့်မယ်။ ၎င်းသည် စံပြအခြေအနေများတွင် ရရှိနိုင်သည့် စာမျက်နှာထက် များစွာပိုရှည်သော စာမျက်နှာတစ်ခုကို တည်ဆောက်ရန် အရေးကြီးသည့် အကြောင်းအရာအတွက် တင်သည့်အချိန်ကို ဖြစ်ပေါ်စေနိုင်သည်။ ဒီမှာ ဤအရာအားလုံးကို ကောင်းမွန်စွာရှင်းပြသည့် HTTP/2 ဦးစားပေးခြင်းအကြောင်း ဆွေးနွေးပါ။

ပြင်ပအရင်းအမြစ်များနှင့်ချိတ်ဆက်မှုများတွင် attribute များကိုအသုံးပြုခြင်းဟုယူဆနိုင်သည်။ preconnect ပြဿနာကို ဖြေရှင်းရာမှာ ကူညီပေးပါလိမ့်မယ်။ သို့သော်၊ မတူညီသောဒိုမိန်းများသို့ ဤလင့်ခ်များ များလွန်းပါက၊ ၎င်းသည် အမှန်တကယ် အရေးကြီးဆုံးအခိုက်အတန့်တွင် ဆက်သွယ်ရေးလိုင်းကို ကျော်လွန်သွားနိုင်သည်။

အကယ်၍ သင်သည် ပြင်ပအဖွဲ့အစည်း အရင်းအမြစ်များကို သင်ကိုယ်တိုင် လက်ခံဆောင်ရွက်ပေးပါက၊ ဤအရင်းအမြစ်များကို သုံးစွဲသူအား မည်ကဲ့သို့ အတိအကျ ပေးအပ်သည်ကို သင်ထိန်းချုပ်နိုင်သည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် အောက်ပါအကြောင်းများကို ပြောနေပါသည်။

• ဘရောက်ဆာတစ်ခုစီတိုင်းနှင့် အသင့်တော်ဆုံး ဒေတာချုံ့မှု အယ်လဂိုရီသမ်ကို အသုံးပြုကြောင်း သေချာစေနိုင်ပါသည်။ (Brotli/gzip)
• လူသိအများဆုံး ပံ့ပိုးပေးသူများနှင့်ပင် ပုံမှန်အားဖြင့် ရှည်လျားခြင်းမရှိသော အရင်းအမြစ်များအတွက် သိုလှောင်မှုအချိန်ကို တိုးမြှင့်နိုင်သည် (ဥပမာ၊ GA တက်ဂ်အတွက် ဆက်စပ်တန်ဖိုးကို မိနစ် 30 သတ်မှတ်ထားသည်)။

သင်၏ caching စီမံခန့်ခွဲမှုဗျူဟာ (URL hashes၊ versioning, etc.) တွင် သက်ဆိုင်ရာ အကြောင်းအရာများကို ထည့်သွင်းခြင်းဖြင့် TTL ကို သက်တမ်းတိုးနိုင်သည်။ ဒီအကြောင်းကို အောက်မှာ ပြောပြပါမယ်။

▍ ပြင်ပကုမ္ပဏီ ဝန်ဆောင်မှုများ သို့မဟုတ် ၎င်းတို့၏ လုပ်ငန်းလည်ပတ်မှုတွင် အနှောင့်အယှက်များကို အကာအကွယ်ပေးခြင်း

ကိုယ်တိုင် hosting Third-party ရင်းမြစ်များ၏ နောက်ထပ် စိတ်ဝင်စားဖွယ် ရှုထောင့်မှာ ပြင်ပကုမ္ပဏီ ဝန်ဆောင်မှုများ ပြတ်တောက်မှုနှင့် ဆက်စပ်နေသော အန္တရာယ်များကို လျော့ပါးသက်သာစေရန် ခွင့်ပြုပေးခြင်းဖြစ်သည်။ သင်အသုံးပြုနေသော Third-party A/B စမ်းသပ်ခြင်းဖြေရှင်းချက်ကို စာမျက်နှာ၏ ခေါင်းပိုင်းအပိုင်းတွင် တင်သည့် ပိတ်ဆို့ခြင်း script တစ်ခုအဖြစ် ယူဆကြပါစို့။ ဤဇာတ်ညွှန်းသည် နှေးကွေးစွာ တက်လာပါသည်။ သက်ဆိုင်ရာ script ကို တင်ရန် ပျက်ကွက်ပါက စာမျက်နှာသည် ဗလာဖြစ်နေပါမည်။ တင်ရန် အချိန်အတော်ကြာပါက စာမျက်နှာသည် အချိန်ကြာကြာ နှောင့်နှေးနေမည် ဖြစ်သည်။ သို့မဟုတ်၊ ပရောဂျက်သည် ပြင်ပအဖွဲ့အစည်း CDN ​​အရင်းအမြစ်မှ ဒေါင်းလုဒ်လုပ်ထားသော စာကြည့်တိုက်ကို အသုံးပြုသည်ဆိုပါစို့။ ဤအရင်းအမြစ်သည် ချို့ယွင်းမှုတစ်ခု သို့မဟုတ် နိုင်ငံတစ်ခုတွင် ပိတ်ဆို့ခံထားရကြောင်း စိတ်ကူးကြည့်ကြပါစို့။ ထိုသို့သောအခြေအနေသည် site ၏ယုတ္တိကိုချိုးဖောက်မှုဖြစ်ပေါ်စေလိမ့်မည်။

အချို့သော ပြင်ပဝန်ဆောင်မှုများ မရရှိနိုင်သောအခါ သင့်ဆိုက် မည်သို့အလုပ်လုပ်သည်ကို သိရှိရန်၊ သင်သည် SPOF ကဏ္ဍကို အသုံးပြုနိုင်သည်။ webpagetest.org.

webpagetest.org ရှိ SPOF ကဏ္ဍ

▍ဘရောက်ဆာများတွင် ပစ္စည်းများ သိမ်းဆည်းခြင်းဆိုင်ရာ ပြဿနာများ ကရော ဘယ်လိုလဲ။ (အရိပ်အမြွက် - ဒါဟာ ဒဏ္ဍာရီတစ်ခု)

အများသူငှာ CDN များကို အသုံးပြုခြင်းဖြင့် ဤဝန်ဆောင်မှုများသည် အရည်အသွေးမြင့်မားသောကွန်ရက်များရှိပြီး ကမ္ဘာတစ်ဝှမ်းတွင် ဖြန့်ဝေပေးသောကြောင့် ပိုမိုကောင်းမွန်သော အရင်းအမြစ်စွမ်းဆောင်ရည်ကို အလိုအလျောက်ဦးတည်လာမည်ဟု သင်ထင်ကောင်းထင်နိုင်ပါသည်။ ဒါပေမယ့် အရာအားလုံးက တကယ်တော့ နည်းနည်းပိုရှုပ်ထွေးပါတယ်။

ကျွန်ုပ်တို့တွင် မတူညီသောဆိုက်များစွာရှိသည်- website1.com၊ website2.com၊ website3.com ဆိုကြပါစို့။ ဤဆိုက်များအားလုံးသည် jQuery စာကြည့်တိုက်ကို အသုံးပြုသည်။ ဥပမာ - googleapis.com ကို အသုံးပြု၍ CDN ကို အသုံးပြု၍ ၎င်းတို့နှင့် ချိတ်ဆက်ပါသည်။ ဘရောက်ဆာသည် ဒစ်ဂျစ်တိုက်ကို တစ်ကြိမ်ဒေါင်းလုဒ်လုပ်ပြီး ကက်ရှ်လုပ်ရန် မျှော်လင့်နိုင်ပြီး ဆိုက်သုံးခုလုံးတွင် ၎င်းကို အသုံးပြုနိုင်သည်။ ၎င်းသည် ကွန်ရက်ပေါ်ရှိ ဝန်ကို လျှော့ချနိုင်သည်။ ဤအရာက သင့်အား တစ်နေရာရာတွင် ငွေစုနိုင်စေပြီး အရင်းအမြစ်စွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးနိုင်မည်ဖြစ်သည်။ လက်တွေ့ရှုထောင့်ကနေကြည့်ရင် အရာအားလုံးက ကွဲပြားပါတယ်။ ဥပမာအားဖြင့်၊ Safari ဟုခေါ်သောအင်္ဂါရပ်တစ်ခုရှိသည်။ အသိဉာဏ်ခြေရာခံကာကွယ်တားဆီးရေး: ကက်ရှ်သည် စာရွက်စာတမ်း၏ အရင်းအမြစ်နှင့် ပြင်ပအဖွဲ့အစည်း အရင်းအမြစ်၏ အရင်းအမြစ်အပေါ် အခြေခံ၍ သော့နှစ်ခုကို အသုံးပြုသည်။ ဒီမှာ ဤအကြောင်းအရာအတွက် ဆောင်းပါးကောင်း။

လေ့လာမှုဟောင်းများ Yahoo က и Facebook ကအပြင် ပိုမကြာသေး လေ့လာ Paul Calvano ၊ ကျွန်ုပ်တို့ မျှော်လင့်ထားသမျှ ကာလပတ်လုံး ဘရောက်ဆာ ကက်ရှ်များတွင် အရင်းအမြစ်များကို သိမ်းဆည်းထားမည်မဟုတ်ကြောင်း ပြသသည်- “ပရောဂျက်တစ်ခု၏ ကိုယ်ပိုင်နှင့် ပြင်ပကုမ္ပဏီ အရင်းအမြစ်များကို သိမ်းဆည်းချိန်ကြားတွင် ကြီးမားသော ကွာဟချက်ရှိသည်။ CSS နှင့် ဝဘ်ဖောင့်များအကြောင်း ပြောနေပါသည်။ ဆိုလိုသည်မှာ၊ မူရင်းဖောင့်များ၏ 95% သည် တစ်ပတ်ထက်ပိုသော ကက်ရှ်သက်တမ်းရှိပြီး ပြင်ပဖောင့်များ၏ 50% သည် တစ်ပတ်ထက်နည်းသော ကက်ရှ်သက်တမ်းရှိသည်။ ၎င်းသည် ဝဘ်ဆော့ဖ်ဝဲရေးသားသူများကို ဖောင့်ဖိုင်များကိုယ်တိုင် လက်ခံကျင်းပရန် ခိုင်လုံသောအကြောင်းပြချက်တစ်ခုပေးသည်။”

ရလဒ်အနေဖြင့် သင်သည် အခြားသူများ၏ အကြောင်းအရာကို လက်ခံဆောင်ရွက်ပေးပါက၊ ဘရောက်ဆာ ကက်ရှ်လုပ်ခြင်းကြောင့် ဖြစ်ပေါ်လာသည့် စွမ်းဆောင်ရည်ပြဿနာများကို သင်သတိမထားမိတော့ပါ။

ယခုကျွန်ုပ်တို့သည် Third-party self-hosting ၏အားသာချက်များကိုဖုံးအုပ်ထားပြီး၊ ဤချဉ်းကပ်မှု၏ကောင်းမွန်သောအကောင်အထည်ဖော်မှုကိုမည်သို့ပြောပြရမည်ကိုပြောကြပါစို့။

မကောင်းမှု- မာရ်နတ်သည် အသေးစိတ်အချက်များထဲတွင် ရှိနေသည်။

ပြင်ပအဖွဲ့အစည်း အရင်းအမြစ်များကို သင့်ကိုယ်ပိုင်ဒိုမိန်းသို့ ရွှေ့ခြင်းသည် ထိုအရင်းအမြစ်များကို မှန်ကန်စွာ ကက်ရှ်ထားကြောင်း သေချာစေခြင်းမရှိဘဲ အလိုအလျောက် လုပ်ဆောင်၍မရပါ။

ဤနေရာတွင် အဓိကပြဿနာတစ်ခုမှာ သိမ်းဆည်းချိန်ဖြစ်သည်။ ဥပမာ၊ ဗားရှင်းအချက်အလက်ကို ဤကဲ့သို့သော ပြင်ပကုမ္ပဏီ ဇာတ်ညွှန်းအမည်များတွင် ထည့်သွင်းထားသည်- jquery-3.4.1.js. ထိုသို့သောဖိုင်သည် အနာဂတ်တွင် ပြောင်းလဲမည်မဟုတ်ပါ၊ ရလဒ်အနေဖြင့် ၎င်းသည် ၎င်း၏ ကက်ရှ်လုပ်ခြင်းတွင် မည်သည့်ပြဿနာမျှဖြစ်စေမည်မဟုတ်ပါ။

သို့သော် အချို့သော ဗားရှင်းပုံစံ အစီအစဉ်ကို ဖိုင်များ၊ ကက်ရှ် script များနှင့် အလုပ်လုပ်ရာတွင် အသုံးမပြုပါက၊ ဖိုင်အမည် မပြောင်းလဲသော်လည်း ပြောင်းလဲသည့် အကြောင်းအရာများသည် ခေတ်နောက်ကျသွားနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ ဖောက်သည်များ တတ်နိုင်သမျှ မြန်မြန်ရရှိရန် လိုအပ်သော script များအတွင်း အလိုအလျောက် လုံခြုံရေး ဖာထေးမှုများကို ထည့်သွင်းခွင့်မပြုသောကြောင့် ၎င်းသည် လေးလေးနက်နက် ပြဿနာတစ်ခု ဖြစ်နိုင်သည်။ ဆော့ဖ်ဝဲရေးသားသူသည် ကက်ရှ်တွင် ထိုကဲ့သို့သော script များကို အပ်ဒိတ်လုပ်ရန် ကြိုးပမ်းရလိမ့်မည်။ ထို့အပြင်၊ ၎င်းသည် cache မှ client တွင်အသုံးပြုသည့်ကုဒ်သည် ပရောဂျက်၏ဆာဗာအစိတ်အပိုင်းကိုဒီဇိုင်းထုတ်သည့်နောက်ဆုံးဗားရှင်းနှင့်ကွဲပြားသည့်အချက်ကြောင့်၊ ၎င်းသည် အက်ပလီကေးရှင်းပျက်ကွက်မှုကိုဖြစ်စေနိုင်သည်။

မှန်ပါသည်၊ မကြာခဏ အပ်ဒိတ်လုပ်ထားသော ပစ္စည်းများအကြောင်း (တက်ဂ်မန်နေဂျာများ၊ A/B စမ်းသပ်ခြင်းအတွက် ဖြေရှင်းချက်)၊ CDN ကိရိယာများကို အသုံးပြု၍ ၎င်းတို့အား သိမ်းဆည်းခြင်းသည် ဖြေရှင်းနိုင်သော အလုပ်ဖြစ်သော်လည်း ပို၍ရှုပ်ထွေးပါသည်။ တဂ်စီမံခန့်ခွဲမှုဖြေရှင်းချက်ဖြစ်သည့် Commanders Act ကဲ့သို့သော ဝန်ဆောင်မှုများသည် ဗားရှင်းအသစ်များကို ထုတ်ဝေသည့်အခါ ဝဘ်ချိတ်များကို အသုံးပြုပါ။ ၎င်းသည် သင့်အား CDN ​​တွင် ကက်ရှ်တစ်ခုအား တွန်းထုတ်နိုင်စွမ်း သို့မဟုတ် hash သို့မဟုတ် URL အပ်ဒိတ်ကို တွန်းအားပေးနိုင်စွမ်းကို ပေးစွမ်းနိုင်သည်။

▍ ဖောက်သည်များထံ ပစ္စည်းများ အလိုက်သင့် ပေးပို့ခြင်း။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ကက်ရှ်အကြောင်းပြောသောအခါ၊ CDN တွင်အသုံးပြုသည့် ကက်ရှ်ဆက်တင်များသည် ပြင်ပအဖွဲ့အစည်း အရင်းအမြစ်အချို့အတွက် မသင့်လျော်နိုင်ဟူသောအချက်ကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ ဥပမာအားဖြင့်၊ ထိုအရင်းအမြစ်များသည် အဆိုပါဘရောက်ဆာများအတွက် အထူးသင့်လျော်သောအကြောင်းအရာဗားရှင်းများဖြင့် သီးခြားဘရောက်ဆာများကို ဝန်ဆောင်မှုပေးရန်အတွက် အသုံးပြုသူအေးဂျင့် sniffing (အလိုက်သင့် ဆောင်ရွက်ပေးသည်) နည်းပညာကို အသုံးပြုနိုင်ပါသည်။ ဤနည်းပညာများသည် ပုံမှန်ဖော်ပြချက်များ သို့မဟုတ် HTTP ခေါင်းစီးအချက်အလက်၏ ဒေတာဘေ့စ်တစ်ခုအပေါ်တွင် မူတည်ပြီး ဘရောက်ဆာစွမ်းဆောင်နိုင်မှုကို ရှာဖွေဖော်ထုတ်နိုင်သည်။ User-Agent. ဘယ်ဘရောက်ဆာနဲ့ ချိတ်ဆက်နေတယ်ဆိုတာကို သူတို့သိပြီးတာနဲ့ သူတို့အတွက် ဒီဇိုင်းထုတ်ထားတဲ့ ပစ္စည်းတွေကို ပေးတယ်။

ဤနေရာတွင် ဝန်ဆောင်မှုနှစ်ခုကို မှတ်သားနိုင်ပါသည်။ ပထမတစ်ခုက googlefonts.com ဖြစ်ပါတယ်။ ဒုတိယတစ်ခုကတော့ polyfill.io ဖြစ်ပါတယ်။ Google Fonts ဝန်ဆောင်မှုသည် browser ၏စွမ်းဆောင်နိုင်မှုများပေါ်မူတည်၍ အမျိုးမျိုးသော CSS ကုဒ်အတွက် ပံ့ပိုးပေးသည် (အသုံးပြု၍ woff2 အရင်းအမြစ်များသို့ လင့်ခ်များပေးခြင်း၊ unicode-range).

ဤသည်မှာ မတူညီသောဘရောက်ဆာများမှ ပြုလုပ်ထားသော Google Fonts queries နှစ်ခု၏ ရလဒ်များဖြစ်သည်။

Chrome မှ Google Fonts မေးမြန်းမှုရလဒ်

IE10 မှ လုပ်ဆောင်ခဲ့သော Google Fonts query ၏ ရလဒ်

Polyfill.io သည် ဘရောက်ဆာအား လိုအပ်သော polyfills များကိုသာ ပေးသည်။ ၎င်းသည် စွမ်းဆောင်ရည် အကြောင်းပြချက်များဖြင့် လုပ်ဆောင်သည်။

ဥပမာအားဖြင့်၊ သင်သည် မတူညီသောဘရောက်ဆာများမှ အောက်ပါတောင်းဆိုချက်ကို လုပ်ဆောင်ပါက ဘာဖြစ်မည်ကို လေ့လာကြည့်ကြပါစို့။ https://polyfill.io/v3/polyfill.js?features=default

IE10 မှ လုပ်ဆောင်သော တောင်းဆိုချက်ကို တုံ့ပြန်သည့်အနေဖြင့် ဒေတာ 34 KB ကို လက်ခံရရှိမည်ဖြစ်သည်။ Chrome မှလုပ်ဆောင်သော အဖြေသည် ဗလာဖြစ်လိမ့်မည်။

စိတ်ဆိုးခြင်း- ကိုယ်ရေးကိုယ်တာအချက်အချို့

ဤအချက်သည် အစီအစဥ်နောက်ဆုံးဖြစ်သည်၊ သို့သော် အရေးအကြီးဆုံးမဟုတ်ပေ။ အဓိကအချက်မှာ ပရောဂျက်၏ ပင်မဒိုမိန်းတွင် ပြင်ပမှရင်းမြစ်များကို ကိုယ်တိုင် hosting ပြုလုပ်ခြင်းသည် သုံးစွဲသူများ၏ privacy ကို ထိခိုက်စေနိုင်ပြီး ပင်မဝဘ်ပရောဂျက်ကို ထိခိုက်စေနိုင်သည်။

သင်၏ CDN စနစ်အား မှန်ကန်စွာ မသတ်မှတ်ပါက၊ သင်သည် သင်၏ ဒိုမိန်း၏ ကွက်ကီးများကို ပြင်ပအဖွဲ့အစည်း ဝန်ဆောင်မှုတစ်ခုသို့ ပေးပို့ခြင်းအား အဆုံးသတ်နိုင်ပါသည်။ CDN အဆင့်တွင် သင့်လျော်သော စစ်ထုတ်ခြင်းကို မစီစဉ်ထားပါက၊ ပုံမှန်အားဖြင့် JavaScript တွင် အသုံးမပြုနိုင်သော သင်၏ session cookies များ (ထို့အတူ၊ httponly) နိုင်ငံခြားအိမ်ရှင်ထံ ပေးပို့နိုင်ပါသည်။

ဤသည်မှာ Eulerian သို့မဟုတ် Criteo ကဲ့သို့ ခြေရာခံသူများနှင့် ဖြစ်ပွားနိုင်သည် ။ Third-party ခြေရာခံကိရိယာများသည် cookie တွင်ထူးခြားသောအမှတ်အသားတစ်ခုကိုသတ်မှတ်ထားနိုင်သည်။ အကယ်၍ ၎င်းတို့သည် ဝဘ်ဆိုက်ပစ္စည်းများ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်ခဲ့ပါက၊ အသုံးပြုသူသည် မတူညီသော ဝဘ်အရင်းအမြစ်များနှင့် အလုပ်လုပ်နေချိန်တွင် ၎င်းတို့၏ ဆုံးဖြတ်ချက်များကို ဖတ်ရှုနိုင်သည်။

ယနေ့ခေတ်တွင် ဘရောက်ဆာအများစုသည် ဤခြေရာခံခြင်းအပြုအမူအမျိုးအစားကို အကာအကွယ်ပေးပါသည်။ ရလဒ်အနေဖြင့် ယခုအခါ ခြေရာခံကိရိယာများသည် နည်းပညာကို အသုံးပြုလာကြသည်။ CNAME အင်္ကျီဝတ်ခြင်း။ပရောဂျက်အမျိုးမျိုးအတွက် ၎င်းတို့၏ကိုယ်ပိုင် ဇာတ်ညွှန်းများအဖြစ် ဟန်ဆောင်ထားသည်။ ဆိုလိုသည်မှာ၊ ခြေရာခံသူများသည် အချို့သောဒိုမိန်းတစ်ခုအတွက် ၎င်းတို့၏ဆက်တင်များတွင် CNAME ကိုထည့်ရန် ဆိုက်ပိုင်ရှင်များကို ကမ်းလှမ်းသည်၊ ၎င်းလိပ်စာသည် များသောအားဖြင့် ကျပန်းဇာတ်ကောင်အစုတစ်ခုနှင့်တူသည်။

ဝဘ်ဆိုဒ်ကွတ်ကီးများကို ဒိုမိန်းခွဲများ (ဥပမာ - *.website.com) တွင် အသုံးပြုရန် မအကြံပြုသော်လည်း၊ ဤကိစ္စတွင်၊ ထိုကဲ့သို့သော ကွတ်ကီးများကို ရုပ်ဖျက်ထားသော ပြင်ပမှ ခြေရာခံကိရိယာထံ အလိုအလျောက် ပေးပို့ပါသည်။ ရလဒ်အနေဖြင့် ကျွန်ုပ်တို့သည် မည်သည့်ကိုယ်ရေးကိုယ်တာအကြောင်းမျှ မပြောနိုင်တော့ပါ။

ထို့အပြင် HTTP ခေါင်းစီးများနှင့်လည်း အလားတူဖြစ်တတ်ပါသည်။ ဖောက်သည်- အရိပ်အမြွက်ဖန်တီးရန်အတွက် အသုံးပြု၍ရသောကြောင့် ပင်မဒိုမိန်းသို့သာ ပေးပို့သည်။ ဒစ်ဂျစ်တယ်လက်ဗွေ အသုံးပြုသူကို။ သင်အသုံးပြုနေသည့် CDN ဝန်ဆောင်မှုသည် ဤခေါင်းစီးများကို မှန်ကန်စွာ စစ်ထုတ်ကြောင်း သေချာပါစေ။

ရလဒ်များကို

အကယ်၍ သင်သည် Third-party အရင်းအမြစ်များကို မကြာမီတွင် ကိုယ်တိုင်လက်ခံကျင်းပရန် စီစဉ်နေပါက၊ ကျွန်ုပ်အား အကြံဉာဏ်အချို့ ပေးပါရစေ။

• သင်၏အရေးကြီးဆုံး JS စာကြည့်တိုက်များ၊ ဖောင့်များနှင့် CSS ဖိုင်များကို လက်ခံဆောင်ရွက်ပေးပါ။ ၎င်းသည် ပြင်ပကုမ္ပဏီဝန်ဆောင်မှု၏အမှားကြောင့် ဝဘ်ဆိုက်အတွက် အရေးပါသောအရင်းအမြစ်တစ်ခုဖြစ်သည့် အရင်းအမြစ်တစ်ခုကြောင့် ဝဘ်ဆိုက်ပျက်ကွက်ခြင်း သို့မဟုတ် စွမ်းဆောင်ရည်ကျဆင်းခြင်းအန္တရာယ်ကို လျှော့ချပေးမည်ဖြစ်သည်။
• CDN တွင် ပြင်ပအဖွဲ့အစည်း အရင်းအမြစ်များကို သင် ကက်ရှ်မလုပ်မီ ၎င်းတို့၏ ဖိုင်များကို အမည်ပေးရာတွင် ဗားရှင်းတစ်မျိုးမျိုးကို အသုံးပြုထားကြောင်း သေချာစေပါ သို့မဟုတ် ဗားရှင်းအသစ်ကို ထုတ်ဝေသည့်အခါတွင် CDN ကက်ရှ်ကို ကိုယ်တိုင် သို့မဟုတ် အလိုအလျောက် ပြန်လည်သတ်မှတ်ခြင်းဖြင့် ဤအရင်းအမြစ်များ၏ ဘဝသံသရာကို စီမံခန့်ခွဲနိုင်ကြောင်း သေချာပါစေ။ ဇာတ်ညွှန်း။
• သင်၏ CDN၊ ပရောက်စီဆာဗာနှင့် ကက်ရှ်ဆက်တင်များအကြောင်း အလွန်သတိထားပါ။ ၎င်းသည် သင့်ပရောဂျက် သို့မဟုတ် ခေါင်းစီးများကို ကွတ်ကီးများ ပေးပို့ခြင်းမှ တားဆီးနိုင်မည်ဖြစ်သည်။ Client-Hints ပြင်ပဝန်ဆောင်မှုများ။

ချစ်ခင်ရပါသောစာဖတ်သူများ! သင့်ပရောဂျက်များ၏လည်ပတ်မှုအတွက် အလွန်အရေးကြီးသော အခြားသူများ၏ပစ္စည်းများကို သင့်ဆာဗာများတွင် လက်ခံဆောင်ရွက်ပေးပါသလား။

source: www.habr.com