Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat

Vitet e fundit, gjithnjë e më shumë platforma për optimizimin e projekteve të përparme ofrojnë mundësi për vetë-strehim ose proksim të burimeve të palëve të treta. Akamai ju lejon të vendosni parametra specifikë për URL-të e krijuara vetë. Cloudflare ka teknologjinë Edge Workers. Fasterzine mund rishkruaj URL-të në faqe në mënyrë që ato të tregojnë burimet e palëve të treta të vendosura në domenin kryesor të faqes.

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat

Nëse e dini se shërbimet e palëve të treta të përdorura në projektin tuaj nuk ndryshojnë shumë shpesh dhe se procesi i dorëzimit të tyre te klientët mund të përmirësohet, atëherë me siguri po mendoni për proksimin e shërbimeve të tilla. Me këtë qasje, ju mund t'i afroni shumë mirë këto burime me përdoruesit tuaj dhe të fitoni kontroll më të plotë mbi ruajtjen e tyre në memorie në anën e klientit. Kjo, përveç kësaj, ju lejon të mbroni përdoruesit nga problemet e shkaktuara nga "përplasja" e një shërbimi të palës së tretë ose degradimi i performancës së tij.

Mirë: Performanca e përmirësuar

Vetë-strehimi i burimeve të dikujt tjetër përmirëson performancën në një mënyrë shumë të dukshme. Shfletuesi nuk ka nevojë të hyjë përsëri në DNS, nuk ka nevojë të krijojë një lidhje TCP dhe të kryejë një shtrëngim duarsh TLS në një domen të palës së tretë. Ju mund të shihni sesi vetë-strehimi i burimeve të dikujt tjetër ndikon në performancën duke krahasuar dy figurat e mëposhtme.

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat
Burimet e palëve të treta shkarkohen nga burime të jashtme (marrë nga prandaj)

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat
Burimet e palëve të treta ruhen në të njëjtin vend si pjesa tjetër e materialeve të sitit (marrë nga prandaj)

Situata përmirësohet edhe nga fakti se shfletuesi do të përdorë mundësinë e shumëfishimit dhe prioritizimit të të dhënave nga lidhja HTTP/2 që tashmë është krijuar me domenin kryesor.

Nëse nuk pret burime të palëve të treta, atëherë meqenëse ato do të ngarkohen nga një domen i ndryshëm nga ai kryesor, nuk mund të kenë përparësi. Kjo do të bëjë që ata të konkurrojnë me njëri-tjetrin për gjerësinë e brezit të klientit. Kjo mund të rezultojë në kohë ngarkimi për përmbajtje kritike për ndërtimin e një faqeje që është shumë më e gjatë se ajo që do të ishte e arritshme në rrethana ideale. Këtu flasim për prioritizimin e HTTP/2 që i shpjegon shumë mirë të gjitha këto.

Mund të supozohet se përdorimi i atributeve në lidhjet me burimet e jashtme preconnect do të ndihmojë në zgjidhjen e problemit. Megjithatë, nëse ka shumë nga këto lidhje me domene të ndryshme, në të vërtetë mund të mbingarkojë linjën e komunikimit në momentin më vendimtar.

Nëse pret vetë burime të palëve të treta, mund të kontrollosh se si saktësisht këto burime i jepen klientit. Përkatësisht, ne po flasim për sa vijon:

  • Mund të siguroheni që të përdoret algoritmi i kompresimit të të dhënave që i përshtatet më mirë çdo shfletuesi (Brotli/gzip).
  • Mund të rrisni kohën e memorizimit për burimet që zakonisht nuk janë veçanërisht të gjata, madje edhe me ofruesit më të njohur (për shembull, vlera përkatëse për etiketën GA është vendosur në 30 minuta).

Ju madje mund ta zgjasni TTL-në për një burim, të themi, një vit duke përfshirë përmbajtjen përkatëse në strategjinë tuaj të menaxhimit të memorizimit (hashe URL, versioni, etj.). Ne do të flasim për këtë më poshtë.

▍Mbrojtje nga ndërprerjet në funksionimin e shërbimeve të palëve të treta ose mbyllja e tyre

Një aspekt tjetër interesant i burimeve të palëve të treta vetë-strehues është se ju lejon të zbutni rreziqet që lidhen me ndërprerjet e shërbimeve të palëve të treta. Le të supozojmë se zgjidhja e testimit të palëve të treta A/B që po përdorni është zbatuar si një skript bllokues që ngarkohet në pjesën kryesore të faqes. Ky skenar ngarkohet ngadalë. Nëse skripti përkatës dështon të ngarkohet, faqja do të jetë bosh. Nëse kërkon shumë kohë për t'u ngarkuar, faqja do të shfaqet me një vonesë të gjatë. Ose, supozoni se projekti përdor një bibliotekë të shkarkuar nga një burim CDN i palës së tretë. Le të imagjinojmë që ky burim ka pësuar një dështim ose është bllokuar në një vend të caktuar. Një situatë e tillë do të çojë në një shkelje të logjikës së faqes.

Për të zbuluar se si funksionon faqja juaj kur një shërbim i jashtëm nuk është i disponueshëm, mund të përdorni seksionin SPOF faqe në internet.org.

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat
Seksioni SPOF në webpagetest.org

▍Po në lidhje me problemet me ruajtjen në memorie të materialeve në shfletues? (udhëzim: është një mit)

Ju mund të mendoni se përdorimi i CDN-ve publike do të çonte automatikisht në performancë më të mirë të burimeve, pasi këto shërbime kanë rrjete mjaft të cilësisë së lartë dhe shpërndahen në mbarë botën. Por në fakt gjithçka është pak më e ndërlikuar.

Le të themi se kemi disa sajte të ndryshme: website1.com, website2.com, website3.com. Të gjitha këto sajte përdorin bibliotekën jQuery. Ne e lidhim atë me ta duke përdorur një CDN, për shembull - googleapis.com. Mund të presësh që shfletuesi të shkarkojë dhe të ruajë memorien e bibliotekës një herë, dhe më pas ta përdorë atë në të tre faqet. Kjo mund të zvogëlojë ngarkesën në rrjet. Ndoshta kjo do t'ju lejojë të kurseni para diku dhe të ndihmoni në përmirësimin e performancës së burimeve. Nga pikëpamja praktike, gjithçka duket ndryshe. Për shembull, Safari ka një veçori të quajtur Parandalimi Inteligjent i Ndjekjes: Cache përdor çelësa të dyfishtë bazuar në burimin e dokumentit dhe burimin e burimit të palës së tretë. Këtu artikull i mirë për këtë temë.

studime të vjetra Yahoo и Facebook, si dhe më të fundit studim Paul Calvano, tregojnë se burimet nuk ruhen në cache të shfletuesit për aq kohë sa mund të presim: “Ka një hendek serioz midis kohës së ruajtjes së memorieve të burimeve të një projekti dhe burimeve të palëve të treta. Ne po flasim për CSS dhe fontet në internet. Gjegjësisht, 95% e shkronjave vendase kanë jetëgjatësi cache më shumë se një javë, ndërsa 50% e shkronjave të palëve të treta kanë një jetë të cache më pak se një javë! Kjo u jep zhvilluesve të uebit një arsye bindëse për të pritur vetë skedarët e shkronjave!”

Si rezultat, nëse pret përmbajtjen e njerëzve të tjerë, nuk do të vëreni ndonjë problem të performancës të shkaktuar nga memoria e shfletuesit.

Tani që kemi mbuluar pikat e forta të vetë-pritjes nga palët e treta, le të flasim se si të dallojmë një zbatim të mirë të kësaj qasjeje nga një i keq.

E keqja: Djalli është në detaje

Zhvendosja e burimeve të palëve të treta në domenin tuaj nuk mund të bëhet automatikisht pa u siguruar që këto burime të ruhen siç duhet.

Një nga problemet kryesore këtu është koha e memorizimit. Për shembull, informacioni i versionit përfshihet në emrat e skripteve të palëve të treta si ky: jquery-3.4.1.js. Një skedar i tillë nuk do të ndryshojë në të ardhmen, dhe si rezultat kjo nuk do të shkaktojë ndonjë problem me ruajtjen e tij në memorie.

Por nëse një skemë versionimi nuk përdoret kur punoni me skedarë, skriptet e memorizuara, përmbajtja e të cilave ndryshon ndërsa emri i skedarit mbetet i pandryshuar, mund të bëhen të vjetëruara. Ky mund të jetë një problem serioz, pasi, për shembull, nuk lejon shtimin e arnimeve të automatizuara të sigurisë në skriptet që klientët duhet të marrin sa më shpejt që të jetë e mundur. Zhvilluesi do të duhet të bëjë një përpjekje për të përditësuar skriptet e tilla në cache. Për më tepër, kjo mund të shkaktojë dështime të aplikacionit për shkak të faktit se kodi i përdorur në klient nga cache ndryshon nga versioni më i fundit i kodit për të cilin është krijuar pjesa e serverit të projektit.

Vërtetë, nëse flasim për materiale që përditësohen shpesh (menaxherët e etiketave, zgjidhjet për testimin A/B), atëherë ruajtja e tyre në memorie duke përdorur mjetet CDN është një detyrë që mund të zgjidhet, por është shumë më komplekse. Shërbime si Commanders Act, një zgjidhje për menaxhimin e etiketave, përdorin grepa në internet kur publikojnë versione të reja. Kjo ju jep mundësinë për të detyruar një flush të cache-it në CDN, ose, akoma më mirë, aftësinë për të detyruar një përditësim hash ose URL.

▍Dorëzimi përshtatës i materialeve tek klientët

Përveç kësaj, kur flasim për caching, duhet të kemi parasysh faktin se cilësimet e caching-ut të përdorura në CDN mund të mos jenë të përshtatshme për disa burime të palëve të treta. Për shembull, burime të tilla mund të përdorin teknologjinë e nuhatjes së agjentit të përdoruesit (shërbimi adaptiv) për të shërbyer shfletues të veçantë me versione të përmbajtjes të optimizuara posaçërisht për ata shfletues. Këto teknologji mbështeten në shprehjet e rregullta, ose një bazë të dhënash të informacionit të kokës HTTP, për të kuptuar aftësitë e shfletuesit. User-Agent. Pasi ata e dinë se me cilin shfletues kanë të bëjnë, ata i japin materiale të dizajnuara për të.

Këtu mund të mbani mend dy shërbime. E para është googlefonts.com. E dyta është polyfill.io. Shërbimi Google Fonts ofron, për një burim të caktuar, kode të ndryshme CSS, në varësi të aftësive të shfletuesit (duke dhënë lidhje me burimet woff2 duke përdorur unicode-range).

Këtu janë rezultatet e disa pyetjeve të Google Fonts të bëra nga shfletues të ndryshëm.

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat
Rezultati i pyetjes së shkronjave të Google nga Chrome

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat
Rezultati i pyetjes së shkronjave të Google të ekzekutuar nga IE10

Polyfill.io i jep shfletuesit vetëm polifillet që i nevojiten. Kjo është bërë për arsye të performancës.

Për shembull, le të hedhim një vështrim se çfarë ndodh nëse ekzekutoni kërkesën e mëposhtme nga shfletues të ndryshëm: https://polyfill.io/v3/polyfill.js?features=default

Në përgjigje të një kërkese të tillë të ekzekutuar nga IE10, do të merren 34 KB të dhëna. Dhe përgjigja për të, e ekzekutuar nga Chrome, do të jetë bosh.

I zemëruar: Disa konsiderata të privatësisë

Kjo pikë është e fundit në radhë, por jo më pak e rëndësishme. Çështja është se vetë-strehimi i burimeve të palëve të treta në domenin kryesor të projektit ose në nëndomain e tij mund të rrezikojë privatësinë e përdoruesve dhe të ndikojë negativisht në projektin kryesor të uebit.

Nëse sistemi juaj CDN nuk është konfiguruar saktë, mund të përfundoni duke dërguar kukit e domenit tuaj te një shërbim i palës së tretë. Nëse filtrimi i duhur nuk organizohet në nivelin CDN, atëherë skedarët e sesionit tuaj, të cilat normalisht nuk mund të përdoren në JavaScript (me httponly), mund t'i dërgohet një hosti të huaj.

Kjo është pikërisht ajo që mund të ndodhë me gjurmuesit si Eulerian ose Criteo. Gjurmuesit e palëve të treta mund të kenë vendosur një identifikues unik në kuki. Nëse do të ishin pjesë e materialeve të faqes, ata mund të lexonin identifikuesin sipas gjykimit të tyre ndërsa përdoruesi ishte duke punuar me burime të ndryshme ueb.

Këto ditë, shumica e shfletuesve përfshijnë mbrojtje kundër këtij lloji të sjelljes së gjurmuesit. Si rezultat, gjurmuesit tani përdorin teknologjinë Veshje CNAME, duke u maskuar si skenarë të tyre për projekte të ndryshme. Gjegjësisht, gjurmuesit u ofrojnë pronarëve të faqeve të shtojnë një CNAME në cilësimet e tyre për një domen të caktuar, adresa e të cilit zakonisht duket si një grup i rastësishëm karakteresh.

Megjithëse nuk rekomandohet të vihen në dispozicion skedarët e faqeve të internetit për të gjitha nënfushat (për shembull - *.website.com), shumë sajte e bëjnë këtë. Në këtë rast, cookie të tilla dërgohen automatikisht te një gjurmues i maskuar i palëve të treta. Si rezultat, nuk mund të flasim më për ndonjë privatësi.

Gjithashtu, e njëjta gjë ndodh me titujt HTTP Klienti-Udhëzime, të cilat dërgohen vetëm në domenin kryesor, pasi ato mund të përdoren për të krijuar gjurmë gishtash dixhitale përdorues. Sigurohuni që shërbimi CDN që përdorni i filtron saktë këto tituj.

Rezultatet e

Nëse po planifikoni të zbatoni së shpejti vetë-strehimin e burimeve të palëve të treta, më lejoni t'ju jap disa këshilla:

  • Prisni bibliotekat tuaja më të rëndësishme JS, fontet dhe skedarët CSS. Kjo do të zvogëlojë rrezikun e dështimit të faqes ose degradimit të performancës për shkak të mungesës së disponueshmërisë së një burimi jetik për sitin për shkak të fajit të një shërbimi të palës së tretë.
  • Përpara se të ruani burimet e palëve të treta në një CDN, sigurohuni që të përdoret një lloj sistemi versioni kur emërtoni skedarët e tyre ose që mund të menaxhoni ciklin e jetës së këtyre burimeve duke rivendosur manualisht ose automatikisht memorien e CDN-së kur publikoni një version të ri të skenarin.
  • Jini shumë të kujdesshëm në lidhje me cilësimet tuaja CDN, serverin proxy dhe cache. Kjo do t'ju lejojë të parandaloni që projekti ose titujt tuaj të dërgohen cookie Client-Hints shërbimet e palëve të treta.

Të nderuar lexues! A pret materialet e njerëzve të tjerë në serverët tuaj që janë jashtëzakonisht të rëndësishëm për funksionimin e projekteve tuaja?

Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat
Vetë-strehimi i burimeve të palëve të treta: të mirat, të këqijat, të shëmtuarat

Burimi: www.habr.com

Shto një koment