Pastaraisiais metais vis daugiau platformų, skirtų optimizuoti priekinius projektus, siūlo savarankiško prieglobos arba tarpinio serverio trečiųjų šalių išteklių galimybes. Akamai leidžia nustatyti savarankiškai sugeneruotiems URL. „Cloudflare“ turi „Edge Workers“ technologiją. Fasterzine gali URL puslapiuose, kad jie nukreiptų į trečiųjų šalių išteklius, esančius pagrindiniame svetainės domene.
Jei žinote, kad jūsų projekte naudojamos trečiųjų šalių paslaugos keičiasi ne itin dažnai, o jų pristatymo klientams procesas galėtų būti patobulintas, tuomet tikriausiai galvojate apie tokių paslaugų perdavimą tarpiniu serveriu. Taikydami šį metodą galite labai gerai priartinti šiuos išteklius prie savo vartotojų ir geriau valdyti jų talpyklą kliento pusėje. Be to, tai leidžia apsaugoti vartotojus nuo bėdų, kylančių dėl trečiosios šalies paslaugos „gedimo“ arba jos veikimo pablogėjimo.
Gerai: geresnis našumas
Savarankiškas kažkieno išteklių priegloba labai akivaizdžiai pagerina našumą. Naršyklėms nereikia vėl prisijungti prie DNS, jai nereikia užmegzti TCP ryšio ir atlikti TLS rankos paspaudimą trečiosios šalies domene. Palyginę du toliau pateiktus skaičius, galite pamatyti, kaip kito asmens išteklių priegloba veikia našumą.
Trečiųjų šalių ištekliai atsisiunčiami iš išorinių šaltinių (paimti iš )
Trečiųjų šalių ištekliai saugomi toje pačioje vietoje kaip ir likusi svetainės medžiaga (paimta iš )
Situaciją pagerina ir tai, kad naršyklė naudos galimybę multipleksuoti ir teikti pirmenybę duomenims iš HTTP/2 ryšio, kuris jau yra užmegztas su pagrindiniu domenu.
Jei neturite trečiųjų šalių išteklių, jie bus įkelti iš kito domeno nei pagrindinis, todėl jiems negali būti teikiama pirmenybė. Dėl to jie konkuruos tarpusavyje dėl kliento pralaidumo. Dėl to turinio, būtino kuriant puslapį, įkėlimo laikas gali būti daug ilgesnis, nei būtų galima pasiekti idealiomis aplinkybėmis. kalbėti apie HTTP/2 prioritetų nustatymą, kuris visa tai labai gerai paaiškina.
Galima daryti prielaidą, kad atributų naudojimas nuorodose į išorinius išteklius preconnect padės išspręsti problemą. Tačiau jei šių nuorodų į skirtingus domenus yra per daug, tai iš tikrųjų gali perkrauti ryšio liniją pačiu svarbiausiu momentu.
Jei patys priglobiate trečiosios šalies išteklius, galite valdyti, kaip tiksliai šie ištekliai bus suteikti klientui. Būtent, mes kalbame apie šiuos dalykus:
- Galite užtikrinti, kad būtų naudojamas geriausiai kiekvienai naršyklei tinkantis duomenų glaudinimo algoritmas (Brotli/gzip).
- Galite padidinti išteklių saugojimo talpykloje laiką, kuris paprastai nėra ypač ilgas, net ir naudojant žinomiausius teikėjus (pavyzdžiui, atitinkama GA žymos vertė nustatyta į 30 minučių).
Jūs netgi galite pratęsti išteklių TTL iki, tarkime, metams, įtraukdami atitinkamą turinį į talpyklos valdymo strategiją (URL maišos, versijų kūrimo ir kt.). Apie tai kalbėsime žemiau.
▍Apsauga nuo trečiųjų šalių paslaugų veikimo sutrikimų arba jų išjungimo
Kitas įdomus savarankiško trečiųjų šalių išteklių prieglobos aspektas yra tai, kad tai leidžia sumažinti riziką, susijusią su trečiųjų šalių paslaugų nutrūkimu. Tarkime, kad jūsų naudojamas trečiosios šalies A/B testavimo sprendimas yra įdiegtas kaip blokuojantis scenarijus, įkeliamas puslapio antraštėje. Šis scenarijus įkeliamas lėtai. Jei nepavyksta įkelti atitinkamo scenarijaus, puslapis bus tuščias. Jei įkėlimas užtrunka labai ilgai, puslapis pasirodys su dideliu vėlavimu. Arba, tarkime, projekte naudojama biblioteka, atsisiųsta iš trečiosios šalies CDN šaltinio. Įsivaizduokime, kad šis šaltinis patyrė gedimą arba buvo užblokuotas tam tikroje šalyje. Tokia situacija sukels svetainės logikos pažeidimą.
Norėdami sužinoti, kaip jūsų svetainė veikia, kai kuri nors išorinė paslauga nepasiekiama, galite naudoti SPOF skyrių .
Webpagetest.org SPOF skyrius
▍O kaip dėl problemų, susijusių su medžiagos talpyklomis naršyklėse? (užuomina: tai mitas)
Galbūt manote, kad viešųjų CDN naudojimas automatiškai pagerintų išteklių našumą, nes šios paslaugos turi gana aukštos kokybės tinklus ir yra platinamos visame pasaulyje. Bet iš tikrųjų viskas yra šiek tiek sudėtingiau.
Tarkime, kad turime kelias skirtingas svetaines: website1.com, website2.com, website3.com. Visos šios svetainės naudoja jQuery biblioteką. Sujungiame jį su jais naudodami CDN, pavyzdžiui – googleapis.com. Galite tikėtis, kad naršyklė vieną kartą atsisiųs ir įkels talpyklą biblioteką, o tada naudos ją visose trijose svetainėse. Tai gali sumažinti tinklo apkrovą. Galbūt tai leis kur nors sutaupyti pinigų ir pagerinti išteklių našumą. Praktiniu požiūriu viskas atrodo kitaip. Pavyzdžiui, „Safari“ turi funkciją, vadinamą : talpykloje naudojami du raktai, pagrįsti dokumento šaltiniu ir trečiosios šalies šaltiniu. geras straipsnis šia tema.
senos studijos и , taip pat naujesni Paul Calvano, parodykite, kad ištekliai naršyklės talpyklose saugomi ne tiek ilgai, kiek galėtume tikėtis: „Yra rimtas atotrūkis tarp paties projekto ir trečiųjų šalių išteklių talpyklos laiko. Mes kalbame apie CSS ir žiniatinklio šriftus. Būtent, 95% vietinių šriftų talpyklos tarnavimo laikas yra ilgesnis nei savaitė, o 50% trečiųjų šalių šriftų talpyklos veikimo laikas yra trumpesnis nei savaitė! Tai suteikia žiniatinklio kūrėjams įtikinamą priežastį patiems talpinti šriftų failus!
Todėl, jei priglobiate kitų žmonių turinį, nepastebėsite jokių našumo problemų, kurias sukelia naršyklės talpyklos kaupimas.
Dabar, kai apžvelgėme trečiosios šalies savarankiško prieglobos pranašumus, pakalbėkime apie tai, kaip atskirti gerą šio metodo įgyvendinimą nuo blogo.
Blogasis: velnias slypi detalėse
Trečiųjų šalių išteklių perkėlimas į savo domeną negali būti atliekamas automatiškai, neužtikrinant, kad tokie ištekliai būtų tinkamai saugomi talpykloje.
Viena iš pagrindinių problemų čia yra talpyklos laikas. Pavyzdžiui, versijos informacija įtraukta į trečiųjų šalių scenarijų pavadinimus, tokius kaip: jquery-3.4.1.js. Ateityje toks failas nepasikeis ir dėl to nekils problemų dėl talpyklos.
Bet jei kuri nors versijų kūrimo schema nenaudojama dirbant su failais, talpykloje saugomi scenarijai, kurių turinys keičiasi, o failo pavadinimas išlieka nepakitęs, gali pasenti. Tai gali būti rimta problema, nes, pavyzdžiui, neleidžiama pridėti automatinių saugos pataisų į scenarijus, kuriuos klientai turi gauti kuo greičiau. Kūrėjas turės pasistengti atnaujinti tokius scenarijus talpykloje. Be to, tai gali sukelti programų gedimus dėl to, kad kliente naudojamas kodas iš talpyklos skiriasi nuo naujausios kodo versijos, kuriai skirta projekto serverio dalis.
Tiesa, jei kalbėtume apie dažnai atnaujinamas medžiagas (žymų tvarkykles, A/B testavimo sprendimus), tai jų talpinimas naudojant CDN įrankius yra užduotis, kurią galima išspręsti, tačiau ji yra daug sudėtingesnė. Tokios paslaugos kaip „Commanders Act“, žymų valdymo sprendimas, skelbia žiniatinklio kabliukus, kai skelbia naujas versijas. Tai suteikia galimybę priverstinai išvalyti CDN talpyklą arba, dar geriau, priverstinai atnaujinti maišą arba URL.
▍Adaptyvus medžiagų pristatymas klientams
Be to, kai kalbame apie talpyklą, turime atsižvelgti į tai, kad CDN naudojami talpyklos nustatymai gali būti netinkami kai kuriems trečiųjų šalių ištekliams. Pavyzdžiui, tokie ištekliai gali naudoti naudotojo agento uostymo (adaptyviojo aptarnavimo) technologiją, kad aptarnautų konkrečias naršykles su turinio versijomis, optimizuotomis specialiai toms naršyklėms. Šios technologijos remiasi reguliariosiomis išraiškomis arba HTTP antraštės informacijos duomenų baze, kad išsiaiškintų naršyklės galimybes. User-Agent. Sužinoję, su kuria naršykle naudojasi, jie pateikia jai skirtą medžiagą.
Čia galite prisiminti dvi paslaugas. Pirmasis yra googlefonts.com. Antrasis yra polyfill.io. „Google Fonts“ paslauga tam tikram ištekliui suteikia įvairų CSS kodą, priklausomai nuo naršyklės galimybių (suteikia nuorodas į woff2 išteklius naudojant unicode-range).
Štai kelių „Google Fonts“ užklausų, atliktų naudojant skirtingas naršykles, rezultatai.
„Google“ šriftų užklausos rezultatas iš „Chrome“.
„Google Fonts“ užklausos, vykdytos iš IE10, rezultatas
Polyfill.io suteikia naršyklei tik jai reikalingus polifilius. Tai daroma dėl našumo priežasčių.
Pavyzdžiui, pažiūrėkime, kas atsitiks, jei paleisite šią užklausą iš skirtingų naršyklių:
Atsakant į tokį prašymą, vykdomą iš IE10, bus gauta 34 KB duomenų. Ir atsakymas į jį, vykdomas iš „Chrome“, bus tuščias.
Piktas: kai kurie privatumo aspektai
Šis punktas yra paskutinis, bet ne mažiau svarbus. Esmė ta, kad savarankiškas trečiųjų šalių išteklių priegloba pagrindiniame projekto domene arba jo padomenyje gali kelti pavojų vartotojų privatumui ir neigiamai paveikti pagrindinį žiniatinklio projektą.
Jei jūsų CDN sistema netinkamai sukonfigūruota, galite nusiųsti savo domeno slapukus trečiosios šalies paslaugai. Jei tinkamas filtravimas nėra organizuotas CDN lygiu, jūsų seanso slapukai, kurie paprastai negali būti naudojami JavaScript (su httponly), gali būti išsiųstas užsienio šeimininkui.
Būtent taip gali nutikti naudojant tokius stebėjimo įrenginius kaip Eulerian ar Criteo. Trečiųjų šalių stebėjimo priemonės slapuke galėjo nustatyti unikalų identifikatorių. Jei jie buvo svetainės medžiagos dalis, jie galėtų savo nuožiūra skaityti identifikatorių, kol vartotojas dirbs su skirtingais žiniatinklio ištekliais.
Šiomis dienomis dauguma naršyklių turi apsaugą nuo tokio tipo stebėjimo priemonių. Dėl to sekimo įrenginiai dabar naudoja technologijas , apsimetę savo pačių scenarijais įvairiems projektams. Būtent sekimo priemonės siūlo svetainių savininkams pridėti CNAME prie savo nustatymų tam tikram domenui, kurio adresas dažniausiai atrodo kaip atsitiktinis simbolių rinkinys.
Nors nerekomenduojama svetainių slapukų padaryti prieinamus visiems padomeniams (pvz., *.svetainė.com), daugelis svetainių tai daro. Tokiu atveju tokie slapukai automatiškai siunčiami į paslėptą trečiosios šalies sekimo priemonę. Dėl to mes nebegalime kalbėti apie jokį privatumą.
Be to, tas pats atsitinka su HTTP antraštėmis , kurie siunčiami tik į pagrindinį domeną, nes juos galima naudoti kuriant Vartotojas. Įsitikinkite, kad jūsų naudojama CDN paslauga tinkamai filtruoja šias antraštes.
rezultatai
Jei netrukus planuojate įdiegti savarankišką trečiųjų šalių išteklių prieglobą, leiskite man duoti jums keletą patarimų:
- Priglobkite svarbiausias JS bibliotekas, šriftus ir CSS failus. Tai sumažins svetainės gedimo arba našumo pablogėjimo riziką dėl to, kad svetainei gyvybiškai svarbūs ištekliai nepasiekiami dėl trečiosios šalies paslaugos kaltės.
- Prieš įkeldami trečiųjų šalių išteklius į CDN talpyklą, įsitikinkite, kad suteikiant jų failams pavadinimus naudojama tam tikra versijų nustatymo sistema arba kad galite valdyti šių išteklių gyvavimo ciklą rankiniu būdu arba automatiškai iš naujo nustatydami CDN talpyklą, kai skelbiate naują scenarijus.
- Būkite labai atsargūs dėl CDN, tarpinio serverio ir talpyklos parametrų. Tai leis jums neleisti, kad jūsų projektui ar antraštėms būtų siunčiami slapukai
Client-Hintstrečiųjų šalių paslaugos.
Mieli skaitytojai! Ar savo serveriuose talpinate kitų žmonių medžiagą, kuri yra nepaprastai svarbi jūsų projektų veikimui?
Šaltinis: www.habr.com