Sa mga nakalipas na taon, parami nang parami ang mga platform para sa pag-optimize ng mga front-end na proyekto ay nag-aalok ng mga pagkakataon para sa self-hosting o pag-proxy ng mga mapagkukunan ng third-party. Pinapayagan ka ng Akamai na magtakda para sa mga sariling binuong URL. May teknolohiyang Edge Workers ang Cloudflare. Pwede ang Fasterzine Mga URL sa mga pahina upang tumuro ang mga ito sa mga mapagkukunan ng third-party na matatagpuan sa pangunahing domain ng site.
Kung alam mo na ang mga serbisyo ng third-party na ginagamit sa iyong proyekto ay hindi masyadong madalas na nagbabago, at na ang proseso ng paghahatid ng mga ito sa mga kliyente ay maaaring mapabuti, malamang na iniisip mo ang tungkol sa pag-proxy ng mga naturang serbisyo. Sa diskarteng ito, maaari mong mailapit ang mga mapagkukunang ito sa iyong mga user at makakuha ng mas kumpletong kontrol sa kanilang pag-cache sa panig ng kliyente. Ito, bilang karagdagan, ay nagbibigay-daan sa iyong protektahan ang mga user mula sa mga problemang dulot ng "pag-crash" ng isang third-party na serbisyo o pagkasira ng pagganap nito.
Mabuti: Pinahusay na pagganap
Ang pag-host sa sarili ng mga mapagkukunan ng ibang tao ay nagpapabuti sa pagganap sa isang napakalinaw na paraan. Hindi kailangang i-access muli ng browser ang DNS, hindi nito kailangang magtatag ng koneksyon sa TCP at magsagawa ng TLS handshake sa isang third-party na domain. Makikita mo kung paano nakakaapekto sa pagganap ang pag-host sa sarili ng mga mapagkukunan ng ibang tao sa pamamagitan ng paghahambing sa sumusunod na dalawang figure.
Ang mga mapagkukunan ng third party ay dina-download mula sa mga panlabas na mapagkukunan (kinuha mula sa )
Ang mga mapagkukunan ng third-party ay naka-imbak sa parehong lugar tulad ng iba pang mga materyal ng site (kinuha mula sa )
Ang sitwasyon ay napabuti din sa pamamagitan ng katotohanan na ang browser ay gagamit ng kakayahang mag-multipleks at mag-prioritize ng data mula sa HTTP/2 na koneksyon na naitatag na sa pangunahing domain.
Kung hindi ka nagho-host ng mga mapagkukunan ng third-party, kung gayon dahil ilo-load ang mga ito mula sa isang domain na iba sa pangunahing isa, hindi sila maaaring bigyang-priyoridad. Magdudulot ito sa kanila na makipagkumpitensya sa isa't isa para sa bandwidth ng kliyente. Ito ay maaaring magresulta sa mga oras ng paglo-load para sa nilalamang kritikal sa pagbuo ng isang pahina na mas mahaba kaysa sa kung ano ang maaaring makamit sa ilalim ng mainam na mga pangyayari. makipag-usap sa HTTP/2 prioritization na nagpapaliwanag ng lahat ng ito nang napakahusay.
Maaaring ipagpalagay na ang paggamit ng mga katangian sa mga link sa mga panlabas na mapagkukunan preconnect ay makakatulong sa paglutas ng problema. Gayunpaman, kung napakarami sa mga link na ito sa iba't ibang mga domain, maaari talaga itong mag-overload sa linya ng komunikasyon sa pinakamahalagang sandali.
Kung ikaw mismo ang nagho-host ng mga mapagkukunan ng third-party, makokontrol mo kung paano eksaktong ibinibigay ang mga mapagkukunang ito sa kliyente. Ibig sabihin, pinag-uusapan natin ang mga sumusunod:
- Maaari mong tiyakin na ang data compression algorithm na pinakaangkop sa bawat browser ay ginagamit (Brotli/gzip).
- Maaari mong taasan ang oras ng pag-cache para sa mga mapagkukunan na karaniwang hindi partikular na mahaba, kahit na sa mga pinakakilalang provider (halimbawa, ang katumbas na halaga para sa tag ng GA ay nakatakda sa 30 minuto).
Maaari mo ring i-extend ang TTL para sa isang mapagkukunan sa, halimbawa, sa isang taon sa pamamagitan ng pagsasama ng may-katuturang nilalaman sa iyong diskarte sa pamamahala ng pag-cache (URL hashes, bersyon, atbp.). Pag-uusapan natin ito sa ibaba.
βProteksyon laban sa mga pagkaantala sa pagpapatakbo ng mga serbisyo ng third-party o ang kanilang pagsasara
Ang isa pang kawili-wiling aspeto ng self-hosting na mga mapagkukunan ng third-party ay nagbibigay-daan ito sa iyong pagaanin ang mga panganib na nauugnay sa mga pagkawala ng mga serbisyo ng third-party. Ipagpalagay natin na ang third-party na A/B testing solution na ginagamit mo ay ipinatupad bilang blocking script na naglo-load sa head section ng page. Mabagal na naglo-load ang script na ito. Kung hindi ma-load ang kaukulang script, magiging walang laman ang page. Kung aabutin ng napakatagal na oras upang mag-load, lalabas ang page na may mahabang pagkaantala. O, ipagpalagay na ang proyekto ay gumagamit ng isang library na na-download mula sa isang third-party na mapagkukunan ng CDN. Isipin natin na ang mapagkukunang ito ay nakaranas ng pagkabigo o na-block sa isang partikular na bansa. Ang ganitong sitwasyon ay hahantong sa isang paglabag sa lohika ng site.
Upang malaman kung paano gumagana ang iyong site kapag hindi available ang ilang panlabas na serbisyo, maaari mong gamitin ang seksyong SPOF sa .
Seksyon ng SPOF sa webpagetest.org
βKumusta naman ang mga problema sa pag-cache ng mga materyales sa mga browser? (pahiwatig: ito ay isang alamat)
Maaari mong isipin na ang paggamit ng mga pampublikong CDN ay awtomatikong hahantong sa mas mahusay na pagganap ng mapagkukunan, dahil ang mga serbisyong ito ay may medyo mataas na kalidad na mga network at ipinamamahagi sa buong mundo. Ngunit ang lahat ay talagang medyo mas kumplikado.
Sabihin nating mayroon kaming iba't ibang mga site: website1.com, website2.com, website3.com. Ang lahat ng mga site na ito ay gumagamit ng jQuery library. Ikinonekta namin ito sa kanila gamit ang isang CDN, halimbawa - googleapis.com. Maaari mong asahan na i-download at i-cache ng browser ang library nang isang beses, at pagkatapos ay gamitin ito sa lahat ng tatlong site. Maaari nitong bawasan ang pagkarga sa network. Marahil ito ay magbibigay-daan sa iyo upang makatipid ng pera sa isang lugar at makatulong na mapabuti ang pagganap ng mapagkukunan. Mula sa isang praktikal na pananaw, ang lahat ay mukhang iba. Halimbawa, may feature na tinatawag ang Safari : Gumagamit ang cache ng dalawahang susi batay sa pinagmulan ng dokumento at sa pinagmulan ng mapagkukunan ng third-party. magandang artikulo sa paksang ito.
lumang pag-aaral ΠΈ , pati na rin ang mas kamakailan Paul Calvano, ay nagpapakita na ang mga mapagkukunan ay hindi naka-imbak sa mga cache ng browser hangga't maaari nating asahan: βMay malubhang agwat sa pagitan ng oras ng pag-cache ng sarili at third-party na mapagkukunan ng proyekto. Pinag-uusapan natin ang tungkol sa CSS at mga web font. Ibig sabihin, 95% ng mga native na font ay may cache life na higit sa isang linggo, habang 50% ng mga third-party na font ay may cache life na mas mababa sa isang linggo! Nagbibigay ito sa mga web developer ng isang nakakahimok na dahilan upang mag-host ng mga file ng font mismo!"
Bilang resulta, kung nagho-host ka ng nilalaman ng ibang tao, hindi mo mapapansin ang anumang mga isyu sa pagganap na dulot ng pag-cache ng browser.
Ngayong nasaklaw na natin ang mga kalakasan ng third-party na self-hosting, pag-usapan natin kung paano sabihin ang isang mahusay na pagpapatupad ng diskarteng ito mula sa isang masamang.
Ang Masama: Ang diyablo ay nasa mga detalye
Ang paglipat ng mga mapagkukunan ng third-party sa iyong sariling domain ay hindi maaaring gawin nang awtomatiko nang hindi tinitiyak na ang mga naturang mapagkukunan ay maayos na naka-cache.
Ang isa sa mga pangunahing problema dito ay ang oras ng pag-cache. Halimbawa, ang impormasyon ng bersyon ay kasama sa mga third-party na pangalan ng script tulad nito: jquery-3.4.1.js. Ang nasabing file ay hindi magbabago sa hinaharap, at bilang isang resulta hindi ito magiging sanhi ng anumang mga problema sa pag-cache nito.
Ngunit kung ang ilang scheme ng bersyon ay hindi ginagamit kapag nagtatrabaho sa mga file, ang mga naka-cache na script, na nagbabago ang mga nilalaman habang ang pangalan ng file ay nananatiling hindi nagbabago, ay maaaring maging luma na. Maaari itong maging isang seryosong problema, dahil ito, halimbawa, ay hindi nagpapahintulot ng mga awtomatikong patch ng seguridad na maidagdag sa mga script na kailangang matanggap ng mga kliyente sa lalong madaling panahon. Kailangang magsikap ang developer na i-update ang mga naturang script sa cache. Bilang karagdagan, maaari itong maging sanhi ng mga pagkabigo ng application dahil sa katotohanan na ang code na ginamit sa kliyente mula sa cache ay naiiba sa pinakabagong bersyon ng code kung saan ang bahagi ng server ng proyekto ay idinisenyo.
Totoo, kung pinag-uusapan natin ang tungkol sa mga materyales na madalas na ina-update (mga tag manager, mga solusyon para sa pagsubok ng A/B), kung gayon ang pag-cache sa mga ito gamit ang mga tool sa CDN ay isang gawain na maaaring malutas, ngunit mas kumplikado. Ang mga serbisyo tulad ng Commanders Act, isang solusyon sa pamamahala ng tag, ay gumagamit ng mga webhook kapag nagpa-publish ng mga bagong bersyon. Nagbibigay ito sa iyo ng kakayahang pilitin ang isang cache flush sa CDN, o, mas mabuti pa, ang kakayahang pilitin ang isang hash o pag-update ng URL.
βAdaptive na paghahatid ng mga materyales sa mga kliyente
Bilang karagdagan, kapag pinag-uusapan natin ang tungkol sa pag-cache, kailangan nating isaalang-alang ang katotohanan na ang mga setting ng caching na ginamit sa CDN ay maaaring hindi angkop para sa ilang mga mapagkukunan ng third-party. Halimbawa, maaaring gumamit ang mga naturang mapagkukunan ng teknolohiya ng user agent sniffing (adaptive serving) upang maghatid ng mga partikular na browser na may mga bersyon ng content na partikular na na-optimize para sa mga browser na iyon. Ang mga teknolohiyang ito ay umaasa sa mga regular na expression, o isang database ng impormasyon sa header ng HTTP, upang malaman ang mga kakayahan ng browser. User-Agent. Kapag alam na nila kung aling browser ang kanilang kinakaharap, binibigyan nila ito ng mga materyales na idinisenyo para dito.
Dito mo maaalala ang dalawang serbisyo. Ang una ay googlefonts.com. Ang pangalawa ay polyfill.io. Nagbibigay ang serbisyo ng Google Fonts, para sa isang tiyak na mapagkukunan, ng iba't ibang CSS code, depende sa mga kakayahan ng browser (nagbibigay ng mga link sa mga mapagkukunan ng woff2 gamit ang unicode-range).
Narito ang mga resulta ng ilang query sa Google Fonts na ginawa mula sa iba't ibang browser.
Resulta ng query sa Google Fonts mula sa Chrome
Resulta ng query sa Google Fonts na naisakatuparan mula sa IE10
Ang Polyfill.io ay nagbibigay lamang sa browser ng mga polyfill na kailangan nito. Ginagawa ito para sa mga kadahilanan ng pagganap.
Halimbawa, tingnan natin kung ano ang mangyayari kung patakbuhin mo ang sumusunod na kahilingan mula sa iba't ibang browser:
Bilang tugon sa naturang kahilingan na isinagawa mula sa IE10, 34 KB ng data ang matatanggap. At ang sagot dito, na isinagawa mula sa Chrome, ay magiging walang laman.
Galit: Ilang pagsasaalang-alang sa privacy
Ang puntong ito ay huli sa pagkakasunud-sunod, ngunit hindi bababa sa mahalaga. Ang punto ay ang self-hosting ng mga mapagkukunan ng third-party sa pangunahing domain ng proyekto o sa subdomain nito ay maaaring malagay sa panganib ang privacy ng mga user at negatibong makaapekto sa pangunahing proyekto sa web.
Kung hindi na-configure nang tama ang iyong CDN system, maaari mong ipadala ang cookies ng iyong domain sa isang third-party na serbisyo. Kung ang wastong pag-filter ay hindi nakaayos sa antas ng CDN, ang iyong session cookies, na karaniwang hindi magagamit sa JavaScript (na may httponly), ay maaaring ipadala sa isang dayuhang host.
Ito mismo ang maaaring mangyari sa mga tagasubaybay tulad ng Eulerian o Criteo. Maaaring nagtakda ang mga third-party na tracker ng natatanging identifier sa cookie. Kung bahagi sila ng mga materyal ng site, maaari nilang basahin ang identifier sa kanilang paghuhusga habang nagtatrabaho ang user sa iba't ibang mapagkukunan ng web.
Sa mga araw na ito, karamihan sa mga browser ay may kasamang proteksyon laban sa ganitong uri ng pag-uugali ng tagasubaybay. Bilang resulta, gumagamit na ngayon ng teknolohiya ang mga tagasubaybay , na nagpapanggap bilang kanilang sariling mga script para sa iba't ibang mga proyekto. Ibig sabihin, nag-aalok ang mga tracker sa mga may-ari ng site na magdagdag ng CNAME sa kanilang mga setting para sa isang partikular na domain, ang address na karaniwang mukhang random na hanay ng mga character.
Bagama't hindi inirerekomenda na gawing available ang cookies ng website sa lahat ng subdomain (halimbawa - *.website.com), maraming site ang gumagawa nito. Sa kasong ito, ang naturang cookies ay awtomatikong ipinapadala sa isang disguised third-party tracker. Bilang resulta, hindi na namin mapag-usapan ang anumang privacy.
Gayundin, ang parehong bagay ay nangyayari sa mga header ng HTTP , na ipinadala lamang sa pangunahing domain, dahil magagamit ang mga ito upang lumikha gumagamit. Tiyaking sinasala ng serbisyo ng CDN na iyong ginagamit ang mga header na ito nang tama.
Mga resulta ng
Kung pinaplano mong ipatupad ang self-hosting ng mga mapagkukunan ng third-party sa lalong madaling panahon, hayaan mo akong bigyan ka ng ilang payo:
- I-host ang iyong pinakamahalagang JS library, font at CSS file. Babawasan nito ang panganib ng pagkabigo ng site o pagkasira ng pagganap dahil sa isang mapagkukunang mahalaga sa site na hindi magagamit dahil sa kasalanan ng isang third-party na serbisyo.
- Bago mo i-cache ang mga mapagkukunan ng third-party sa isang CDN, tiyaking ginagamit ang ilang uri ng versioning system kapag pinangalanan ang kanilang mga file, o maaari mong pamahalaan ang lifecycle ng mga mapagkukunang ito sa pamamagitan ng manu-mano o awtomatikong pag-reset ng CDN cache kapag nag-publish ng bagong bersyon ng ang script.
- Maging maingat sa iyong CDN, proxy server, at mga setting ng cache. Ito ay magbibigay-daan sa iyong pigilan ang iyong proyekto o mga header mula sa pagpapadala ng cookies
Client-Hintsmga serbisyo ng ikatlong partido.
Minamahal na mambabasa! Nagho-host ka ba ng mga materyales ng ibang tao sa iyong mga server na lubhang mahalaga para sa pagpapatakbo ng iyong mga proyekto?
Pinagmulan: www.habr.com