Katika miaka ya hivi majuzi, majukwaa mengi zaidi ya kuboresha miradi ya mbele hutoa fursa za kujipangisha mwenyewe au kutoa seva mbadala kwa rasilimali za watu wengine. Akamai hukuruhusu kuweka kwa URL zinazojitengeneza. Cloudflare ina teknolojia ya Edge Workers. Fasterzine inaweza URL kwenye kurasa ili zielekeze kwenye rasilimali za wahusika wengine ziko kwenye kikoa kikuu cha tovuti.
Iwapo unajua kuwa huduma za wahusika wengine zinazotumiwa katika mradi wako hazibadiliki mara nyingi sana, na kwamba mchakato wa kuziwasilisha kwa wateja unaweza kuboreshwa, basi huenda unafikiria kuhusu kutoa huduma kama wakala. Kwa mbinu hii, unaweza kuleta rasilimali hizi karibu na watumiaji wako na kupata udhibiti kamili zaidi wa uakibishaji wao kwenye upande wa mteja. Hii, kwa kuongeza, inakuwezesha kulinda watumiaji kutokana na shida zinazosababishwa na "kuanguka" kwa huduma ya tatu au uharibifu wa utendaji wake.
Nzuri: Utendaji ulioboreshwa
Kukaribisha rasilimali za mtu mwingine huboresha utendakazi kwa njia dhahiri sana. Kivinjari hakihitaji kufikia DNS tena, haihitaji kuanzisha muunganisho wa TCP na kufanya kupeana mkono kwa TLS kwenye kikoa cha watu wengine. Unaweza kuona jinsi kukaribisha rasilimali za mtu mwingine kunavyoathiri utendaji kwa kulinganisha takwimu mbili zifuatazo.
Rasilimali za wahusika wengine hupakuliwa kutoka kwa vyanzo vya nje (zimechukuliwa kutoka )
Rasilimali za watu wengine huhifadhiwa katika sehemu sawa na nyenzo zingine za tovuti (zilizochukuliwa kutoka )
Hali pia inaboreshwa na ukweli kwamba kivinjari kitatumia uwezo wa kuzidisha na kuweka kipaumbele data kutoka kwa unganisho la HTTP/2 ambalo tayari limeanzishwa na kikoa kikuu.
Ikiwa huna mwenyeji wa rasilimali za tatu, basi kwa kuwa zitapakiwa kutoka kwa kikoa tofauti na kuu, haziwezi kupewa kipaumbele. Hii itawafanya kushindana wao kwa wao kwa kipimo data cha mteja. Hii inaweza kusababisha nyakati za upakiaji wa yaliyomo muhimu katika kuunda ukurasa ambao ni mrefu zaidi kuliko ule ambao unaweza kufikiwa chini ya hali bora. zungumza juu ya kipaumbele cha HTTP/2 ambacho kinaelezea haya yote vizuri.
Inaweza kuzingatiwa kuwa matumizi ya sifa katika viungo vya rasilimali za nje preconnect itasaidia katika kutatua tatizo. Hata hivyo, ikiwa kuna viungo vingi sana vya vikoa tofauti, vinaweza kupakia laini ya mawasiliano kwa wakati muhimu zaidi.
Ikiwa unakaribisha rasilimali za watu wengine mwenyewe, unaweza kudhibiti jinsi rasilimali hizi zinatolewa kwa mteja. Yaani, tunazungumza juu ya yafuatayo:
- Unaweza kuhakikisha kuwa kanuni ya ukandamizaji wa data ambayo inafaa kila kivinjari inatumiwa (Brotli/gzip).
- Unaweza kuongeza muda wa kuweka akiba kwa rasilimali ambazo kwa kawaida si ndefu sana, hata kwa watoa huduma wanaojulikana zaidi (kwa mfano, thamani inayolingana ya lebo ya GA imewekwa kuwa dakika 30).
Unaweza hata kupanua TTL kwa nyenzo, tuseme, mwaka kwa kujumuisha maudhui muhimu katika mkakati wako wa usimamizi wa akiba (heshi za URL, uchapishaji, n.k.). Tutazungumza juu ya hii hapa chini.
βUlinzi dhidi ya kukatizwa kwa huduma za watu wengine au kuzimwa kwao
Kipengele kingine cha kuvutia cha upangishaji wa rasilimali za wahusika wengine ni kwamba hukuruhusu kupunguza hatari zinazohusiana na kukatika kwa huduma za wahusika wengine. Wacha tuchukue kuwa suluhisho la majaribio la A/B la mtu wa tatu unalotumia linatekelezwa kama hati ya kuzuia ambayo hupakia kwenye sehemu ya kichwa cha ukurasa. Hati hii hupakia polepole. Ikiwa hati inayolingana itashindwa kupakia, ukurasa utakuwa tupu. Ikiwa inachukua muda mrefu sana kupakia, ukurasa utaonekana kwa kuchelewa kwa muda mrefu. Au, tuseme mradi unatumia maktaba iliyopakuliwa kutoka kwa rasilimali ya CDN ya wahusika wengine. Hebu fikiria kwamba rasilimali hii ilipata kushindwa au ilizuiwa katika nchi fulani. Hali hiyo itasababisha ukiukaji wa mantiki ya tovuti.
Ili kujua jinsi tovuti yako inavyofanya kazi wakati baadhi ya huduma za nje hazipatikani, unaweza kutumia sehemu ya SPOF .
Sehemu ya SPOF kwenye webpagetest.org
βJe kuhusu matatizo ya uhifadhi wa nyenzo katika vivinjari? (dokezo: ni hadithi)
Unaweza kufikiria kuwa kutumia CDN za umma kunaweza kusababisha utendakazi bora wa rasilimali kiotomatiki, kwa kuwa huduma hizi zina mitandao ya ubora wa juu na inasambazwa kote ulimwenguni. Lakini kila kitu ni kweli kidogo ngumu zaidi.
Wacha tuseme tuna tovuti kadhaa tofauti: website1.com, website2.com, website3.com. Tovuti hizi zote hutumia maktaba ya jQuery. Tunawaunganisha kwa kutumia CDN, kwa mfano - googleapis.com. Unaweza kutarajia kivinjari kupakua na kuweka akiba maktaba mara moja, na kisha kuitumia katika tovuti zote tatu. Hii inaweza kupunguza mzigo kwenye mtandao. Labda hii itawawezesha kuokoa pesa mahali fulani na kusaidia kuboresha utendaji wa rasilimali. Kutoka kwa mtazamo wa vitendo, kila kitu kinaonekana tofauti. Kwa mfano, Safari ina kipengele kinachoitwa : Akiba hutumia vitufe viwili kulingana na chanzo cha hati na chanzo cha rasilimali ya wahusika wengine. makala nzuri juu ya mada hii.
masomo ya zamani ΠΈ , pamoja na hivi karibuni zaidi Paul Calvano, onyesha kwamba rasilimali hazihifadhiwi katika akiba za kivinjari kwa muda mrefu tunavyoweza kutarajia: βKuna pengo kubwa kati ya muda wa uhifadhi wa rasilimali za mradi na za watu wengine. Tunazungumza juu ya CSS na fonti za wavuti. Yaani, 95% ya fonti asili zina maisha ya akiba ya zaidi ya wiki moja, wakati 50% ya fonti za watu wengine huhifadhi akiba ya chini ya wiki moja! Hii inawapa watengenezaji wa wavuti sababu ya kulazimisha kuandaa faili za fonti wenyewe!
Kwa hivyo, ikiwa unapangisha maudhui ya watu wengine, hutaona matatizo yoyote ya utendaji yanayosababishwa na uhifadhi wa kivinjari.
Sasa kwa kuwa tumeshughulikia uwezo wa mwenyeji wa mtu wa tatu, hebu tuzungumze juu ya jinsi ya kutofautisha utekelezaji mzuri wa mbinu hii kutoka kwa mbaya.
Mbaya: Ibilisi yuko katika maelezo
Kuhamisha rasilimali za wahusika wengine kwenye kikoa chako mwenyewe hakuwezi kufanywa kiotomatiki bila kuhakikisha kuwa rasilimali kama hizo zimeakibishwa ipasavyo.
Moja ya shida kuu hapa ni wakati wa kuhifadhi. Kwa mfano, maelezo ya toleo yanajumuishwa katika majina ya hati ya watu wengine kama hii: jquery-3.4.1.js. Faili kama hiyo haitabadilika katika siku zijazo, na kwa sababu hiyo hii haitasababisha matatizo yoyote na caching yake.
Lakini ikiwa mpango fulani wa toleo haujatumiwa wakati wa kufanya kazi na faili, hati zilizohifadhiwa, yaliyomo ambayo hubadilika wakati jina la faili halijabadilika, inaweza kuwa ya zamani. Hili linaweza kuwa tatizo kubwa, kwani, kwa mfano, hairuhusu viraka vya usalama otomatiki kuongezwa kwenye hati ambazo wateja wanahitaji kupokea haraka iwezekanavyo. Msanidi atalazimika kufanya bidii kusasisha hati kama hizo kwenye kashe. Kwa kuongeza, hii inaweza kusababisha kushindwa kwa programu kutokana na ukweli kwamba msimbo unaotumiwa kwa mteja kutoka kwa cache hutofautiana na toleo la hivi karibuni la msimbo ambao sehemu ya seva ya mradi imeundwa.
Kweli, ikiwa tunazungumzia kuhusu vifaa vinavyosasishwa mara kwa mara (wasimamizi wa vitambulisho, ufumbuzi wa kupima A / B), kisha kuwaweka kwa kutumia zana za CDN ni kazi ambayo inaweza kutatuliwa, lakini ni ngumu zaidi. Huduma kama vile Sheria ya Makamanda, suluhisho la usimamizi wa lebo, tumia viboreshaji vya wavuti wakati wa kuchapisha matoleo mapya. Hii inakupa uwezo wa kulazimisha uwekaji akiba kwenye CDN, au, bora zaidi, uwezo wa kulazimisha hashi au sasisho la URL.
β Uwasilishaji unaobadilika wa nyenzo kwa wateja
Kwa kuongeza, tunapozungumzia caching, tunahitaji kuzingatia ukweli kwamba mipangilio ya caching iliyotumiwa kwenye CDN inaweza kuwa haifai kwa baadhi ya rasilimali za tatu. Kwa mfano, nyenzo kama hizo zinaweza kutumia teknolojia ya kunusa wakala wa mtumiaji (huduma inayobadilika) kutumikia vivinjari mahususi vilivyo na matoleo ya maudhui yaliyoboreshwa mahususi kwa vivinjari hivyo. Teknolojia hizi zinategemea usemi wa kawaida, au hifadhidata ya maelezo ya kichwa cha HTTP, ili kubaini uwezo wa kivinjari. User-Agent. Mara tu wanapojua ni kivinjari gani wanashughulikia, wanakipa nyenzo iliyoundwa kwa ajili yake.
Hapa unaweza kukumbuka huduma mbili. Ya kwanza ni googlefonts.com. Ya pili ni polyfill.io. Huduma ya Fonti za Google hutoa, kwa rasilimali fulani, msimbo mbalimbali wa CSS, kulingana na uwezo wa kivinjari (kutoa viungo kwa rasilimali za woff2 kwa kutumia unicode-range).
Haya hapa ni matokeo ya hoja kadhaa za Fonti za Google kutoka kwa vivinjari tofauti.
Matokeo ya swali la Fonti za Google kutoka Chrome
Matokeo ya hoja ya Fonti za Google iliyotekelezwa kutoka IE10
Polyfill.io hupa kivinjari aina nyingi tu zinazohitaji. Hii inafanywa kwa sababu za utendaji.
Kwa mfano, hebu tuangalie kile kinachotokea ikiwa utaendesha ombi lifuatalo kutoka kwa vivinjari tofauti:
Kwa kujibu ombi kama hilo lililotekelezwa kutoka kwa IE10, 34 KB ya data itapokelewa. Na jibu kwake, kutekelezwa kutoka Chrome, itakuwa tupu.
Hasira: Mazingatio fulani ya faragha
Hatua hii ni ya mwisho kwa utaratibu, lakini sio muhimu sana. Jambo ni kwamba upangishaji wa kibinafsi wa rasilimali za wahusika wengine kwenye kikoa kikuu cha mradi au kwenye kikoa chake kidogo kunaweza kuhatarisha faragha ya watumiaji na kuathiri vibaya mradi mkuu wa wavuti.
Ikiwa mfumo wako wa CDN haujasanidiwa ipasavyo, unaweza kuishia kutuma vidakuzi vya kikoa chako kwa huduma ya watu wengine. Ikiwa uchujaji unaofaa haujapangwa katika kiwango cha CDN, basi vidakuzi vya kikao chako, ambavyo katika hali ya kawaida haviwezi kutumika katika JavaScript (pamoja na httponly), inaweza kutumwa kwa mwenyeji wa kigeni.
Hiki ndicho hasa kinaweza kutokea kwa wafuatiliaji kama Eulerian au Criteo. Vifuatiliaji vya watu wengine vinaweza kuwa vimeweka kitambulisho cha kipekee kwenye kidakuzi. Ikiwa zilikuwa sehemu ya nyenzo za tovuti, wangeweza kusoma kitambulisho kwa hiari yao wakati mtumiaji alikuwa akifanya kazi na rasilimali tofauti za wavuti.
Siku hizi, vivinjari vingi vinajumuisha ulinzi dhidi ya aina hii ya tabia ya kifuatiliaji. Kwa hiyo, wafuatiliaji sasa wanatumia teknolojia , wakijifanya kuwa hati zao za miradi mbalimbali. Yaani, wafuatiliaji huwapa wamiliki wa tovuti kuongeza CNAME kwenye mipangilio yao ya kikoa fulani, anwani ambayo kwa kawaida huonekana kama seti nasibu ya herufi.
Ingawa haipendekezwi kufanya vidakuzi vya tovuti vipatikane kwa vikoa vidogo vyote (kwa mfano - *.website.com), tovuti nyingi hufanya hivi. Katika kesi hii, vidakuzi kama hivyo hutumwa kiotomatiki kwa kifuatiliaji cha wahusika wengine. Kwa hivyo, hatuwezi tena kuzungumza juu ya faragha yoyote.
Pia, jambo hilo hilo hufanyika na vichwa vya HTTP , ambazo hutumwa tu kwa kikoa kikuu, kwa vile zinaweza kutumika kuunda mtumiaji. Hakikisha kuwa huduma ya CDN unayotumia inachuja vichwa hivi kwa usahihi.
Matokeo ya
Ikiwa unapanga kutekeleza upangishaji binafsi wa rasilimali za watu wengine hivi karibuni, wacha nikupe ushauri:
- Pangisha maktaba zako muhimu zaidi za JS, fonti na faili za CSS. Hii itapunguza hatari ya tovuti kushindwa au uharibifu wa utendakazi kutokana na rasilimali muhimu kwa tovuti kutopatikana kwa sababu ya hitilafu ya huduma ya wahusika wengine.
- Kabla ya kuweka akiba ya rasilimali za wahusika wengine kwenye CDN, hakikisha kuwa aina fulani ya mfumo wa uchapishaji unatumiwa wakati wa kutaja faili zao, au unaweza kudhibiti mzunguko wa maisha wa rasilimali hizi kwa kuweka upya akiba ya CDN wewe mwenyewe au kiotomatiki wakati wa kuchapisha toleo jipya la hati.
- Kuwa mwangalifu sana kuhusu CDN yako, seva mbadala, na mipangilio ya akiba. Hii itakuruhusu kuzuia mradi au vichwa vyako kutuma vidakuzi
Client-Hintshuduma za mtu wa tatu.
Ndugu wasomaji! Je, unakaribisha nyenzo za watu wengine kwenye seva zako ambazo ni muhimu sana kwa uendeshaji wa miradi yako?
Chanzo: mapenzi.com