Në vitet e fundit, gjithnjë e më shumë platforma për optimizimin e projekteve front-end ofrojnë mundësi për hostim të pavarur ose për ndihmën e burimeve të jashtme. Akamai lejon përcaktimin e për URL-të e krijuara nga vetë. Cloudflare ka teknologjinë Edge Workers. Fasterzine mund të URL-të në faqet në mënyrë që ato të tregojnë burime të jashtme që ndodhen në domenin kryesor të faqes.
Nëse dihet se shërbimet e jashtme që përdorni në projektin tuaj nuk ndryshohen shpesh, dhe se procesi i dorëzimit të tyre ndaj klientëve mund të përmirësohet, atëherë sigurisht që po mendoni për ndihmën e këtyre shërbimeve. Me këtë qasje, mund të "afroni" këto burime tek përdoruesit dhe të fitoni më shumë kontroll mbi memorizimin e tyre nga ana e klientëve. Kjo, për më tepër, mbron përdoruesit nga vështirësitë të shkaktuara nga "rënia" e ndonjë shërbimi të jashtëm ose degradimi i performancës së tij.
Pozitiv: përmirësimi i performancës
Hostimi i pavarur i burimeve të huaja përmirëson performancën në mënyrë tepër të dukshme. Shfletuesi nuk duhet të kontaktojë përsëri DNS, nuk i nevojitet të vendosë një lidhje TCP dhe të kryejë një dorëzim TLS në një domen të jashtëm. Si ndikon hostimi i pavarur i burimeve të huaja në performancë mund të shihet duke krahasuar dy skica të mëposhtme.
Burimet e jashtme ngarkohen nga burime të jashtme (marrë )
Burimet e jashtme ruhen aty ku ruhen materialet e tjera të faqes (marrë )
Situata përmirësohet edhe më shumë sepse shfletuesi do të shfrytëzojë mundësitë e shumëfishtë dhe prioritizimin e të dhënave të lidhjes HTTP/2, e cila tashmë është vendosur me domenin kryesor.
Nëse nuk vendosni burime të jashtme në faqen tuaj, për shkak se ato do të ngarkohen nga një domain që ndan nga ai kryesor, nuk do të jetë e mundur t'i jepni prioritet. Kjo do të çojë në faktin se ato do të konkurrojnë me njëra-tjetrën për bandë klienti. Kjo mund të shkaktojë që koha e ngarkesës për materialet që janë kritike për formimin e faqes të jetë shumë më e gjatë se koha e arritshme në rrethana ideale. prezantimi mbi prioritizimin HTTP/2, ku gjithçka shpjegohet shumë mirë.
Mund të supozohet se përdorimi i atributit në lidhjet për burime të jashtme preconnect do të ndihmojë në zgjidhjen e problemit. Megjithatë, nëse ka shumë lidhje për domain të ndryshëm, kjo mund të ngarkojë linjën e komunikimit në momentin më kritik.
Nëse hostoni burimet e jashtme në mënyrë të pavarur – mund të kontrolloni se si këto burime i dorëzohen klientit. Kjo do të thotë se:
- Mund të sigurohet aplikimi i një algoritmi për kompresimin e të dhënave, më të përshtatshme për çdo shfletues (Brotli/gzip).
- Mund të rritet koha e memorizimit të burimeve, të cilat shpesh, madje edhe tek ofruesit më të njohur, nuk janë shumë të mëdha (për shembull, vlera për etiketën GA është vendosur në 30 minuta).
Mund të zgjatet madje edhe treguesi TTL për burimin, për shembull, deri në një vit, duke përfshirë materialet përkatëse në strategjinë tuaj të menaxhimit të memorizimit (hash-et e URL-ve, versionimi dhe kështu me radhë). Do të flasim për këtë më poshtë.
▍Mbrojtja nga ndërprerjet në funksionimin e shërbimeve të jashtme ose nga shkurtimi i tyre
Një aspekt tjetër interesant i hostimit të pavarur të burimeve të jashtme është se kjo mund të zbutë rreziqet e lidhura me ndërprerjet e shërbimeve të jashtme. Supozoni se zgjidhja juaj e jashtme për realizimin e testeve A/B është implementuar si një skritp mbështetës, i ngarkuar në seksionin e titullit të faqes. Ky skritp ngarkohet ngadalë. Nëse skritpi nuk ngarkohet dot – faqa do të mbetet bosh. Nëse ngarkimi i tij merr shumë kohë – faqa do të shfaqet me një vonesë të madhe. Ose, supozoni se në projektin përdoret një bibliotekë që ngarkohet nga një burim CDN i jashtëm. Imagjinoni se ky burim ka pësuar një defekt ose është bllokuar në ndonjë vend. Një situatë e tillë do të çojë në parregullësi në logjikën e funksionimit të faqes.
Për të mësuar se si funksionon faqja juaj nën kushtet e pamundësisë së një shërbimi të jashtëm, mund të përdorni seksionin SPOF në .
Seksioni SPOF në webpagetest.org
▍Çfarë mund të thuhet për problemet me memorizimin e materialeve në shfletues? (këshillë: kjo është një mit)
Mund të mendoni se përdorimi i CDN-ve publike automatikisht do të çojë në përmirësimin e performancës së burimeve, pasi këto shërbime kanë rrjete mjaft cilësore dhe janë të shpërndara në të gjithë botën. Por, në të vërtetë, gjithçka është pak më e komplikuar.
Le të supozojmë se kemi disa faqe të ndryshme: website1.com, website2.com, website3.com. Në të gjitha këto faqe përdoret biblioteka jQuery. Ne e lidhim atë me CDN, për shembull — googleapis.com. Mund të pritet që shfletuesi ta ngarkojë dhe ta ruajë në cache bibliotekën një herë, pastaj ta përdorë atë gjatë funksionimit të të tre faqeve. Kjo mund të zvogëlojë ngarkesën e rrjetit. Ndoshta, kjo do të ndihmojë në kursim ndonjëhere dhe do të përmirësojë performancën e burimeve. Nga një këndvështrim praktik, gjithçka duket ndryshe. Për shembull, në Safari është implementuar një mundësi e quajtur : në cache përdoren çelësa të dyfishtë, të bazuar në burimin e dokumentit dhe në burimin e burimeve të jashtme. një artikull i mirë mbi këtë temë.
Studime të vjetra dhe , si dhe një më të ri Pola Calvano, tregojnë se burimet nuk ruhen në caches e shfletuesve aq gjatë sa mund të presim: «Ekziston një hendek i rëndësishëm midis kohës së caching të burimeve të brendshme dhe atyre të jashtme të projektit. Flasim për CSS dhe për fontet në web. Konkretisht, periudha e caching për 95% të fontëve të brendshëm kalon një javë, ndërsa koha e caching për 50% të fontëve të jashtme është më pak se një javë! Kjo i jep zhvilluesve web arsye të forta për të strehuar vetë skedarët e fontëve!».
Si rezultat, nëse strehoni materialet e të tjerëve, nuk do të vëreni probleme me performancën të shkaktuara nga caching i shfletuesit.
Tani, kur kemi shqyrtuar pikat e forta të strehimit të burimeve të jashtme në mënyrë të pavarur, le të flasim për atë se si të dallojmë një implementim të mirë të këtij qasjeje nga një të keqe.
E keqe: djalli fshehet në detaje
Shkëputja e burimeve të jashtme në domenin tuaj të vetë nuk mund të bëhet automatikisht, pa u kujdesur për caching-n e duhur të këtyre burimeve.
Një nga problemet kryesore këtu është koha e caching. Për shembull, informacionet mbi versionet përfshihen në emrat e skritpëve të jashtëm më ndonjëherë kështu: jquery-3.4.1.js. Një skedar i tillë në të ardhmen nuk do të ndryshojë, si rezultat kjo nuk do të shkaktojë probleme në caching-n e tij.
Por nëse një skemë versioni nuk aplikohet për skedarët, skritpët e cache-uar, përmbajtja e të cilëve ndryshon pa ndryshuar emrin e skedarit, mund të kalben. Kjo mund të bëhet një problem serioz, pasi kjo, për shembull, nuk e lejon që në mënyrë automatike të futen rregullime sigurie në skritpët, të cilat klientët duhet t'i marrin sa më shpejt. Zhvilluesi do të ketë për të bërë përpjekje për të përditësuar këta skritpë në cache. Për më tepër, kjo mund të shkaktojë dështime në funksionimin e aplikacionit për shkak se kodi i përdorur nga klienti nga cache është ndryshe nga versioni i freskët i kodit, për të cilin merret parasysh pjesa serverike e projektit.
E vërteta është, çështjet lidhur me materialet që përditësohen shpesh (menaxherë etiketash, zgjidhje për teste A/B), caching-u i tyre në shërbimet CDN është një detyrë e dështueshme, por gjithashtu shumë më e komplikuar. Shërbime si Commanders Act, zgjidhje për menaxhimin e etiketave, përdorin web-hooks kur publikojnë versione të reja. Kjo ofron mundësinë për të organizuar një reset të cache në CDN, ose, çfarë është më e mirë, mundësinë e thirrjes së azhurnimit të hash-it ose versionit të URL-së.
▍Shpërndarja adaptuese e materialeve për klientët
Për më tepër, kur flasim për caching, duhet të marim parasysh edhe faktin se cilësimet e caching që përdoren në CDN mund të mos jenë të përshtatshme për disa burime të jashtme. Për shembull, këto burime mund të përdorin teknologjinë e snifimit të agjentit të përdoruesit (user agent sniffing, adaptive serving) për të ofruar për versione të materialeve të optimizuara posaçërisht për këto shfletues. Këto teknologji, për të zbuluar aftësitë e shfletuesit, mbështeten në shprehi të zakonshme, ose në një bazë të dhënash që përmban informacione mbi header-at HTTP User-Agent. Duke mësuar se me cilin shfletues kanë të bëjnë, ata i japin atij materialet që janë optimizuar për të.
Këtu mund të përmendim dy shërbime. E para — googlefonts.com. E dyta — polyfill.io. Shërbimi Google Fonts ofron, për një burim të caktuar, kod të ndryshëm CSS, në varësi të mundësive të shfletuesit (duke dhënë lidhje në burime woff2, duke përdorur unicode-range).
Këtu janë rezultatet e disa kërkesave ndaj Google Fonts, të realizuara nga shfletues të ndryshëm.
Rezultati i kërkesës ndaj Google Fonts, e realizuar nga Chrome
Rezultati i kërkesës ndaj Google Fonts, e realizuar nga IE10
Polyfill.io i jep vetëm polifillat që i nevojiten shfletuesit. Kjo bëhet për shkak të performancës.
Për shembull, le të shohim se çfarë do të ndodhë nëse bëjmë këtë kërkesë nga shfletues të ndryshëm:
Në përgjigje të një kërkese të tillë, e bërë nga IE10, do të vijnë 34 KB të dhënash. Ndërsa përgjigja nga Chrome do të jetë bosh.
I keqi: disa shqetësime rreth privatësisë
Ky pikë është i fundit në renditje, por jo i parëndësishëm. Bëhet fjalë se hostimi i burimeve të tjera në domenin kryesor të projektit ose në subdomenin e tij mund të rrezikojë privatësinë e përdoruesve dhe të ketë një ndikim negativ në projektin kryesor të internetit.
Nëse sistemi juaj CDN është i konfiguruar gabim, mund të përfundoni duke dërguar cookie-t e domenit tuaj në një shërbim të jashtëm. Nëse nuk organizohet një filtrimi i saktë në nivelin e CDN, atëherë cookie-t e seancës tuaja, të cilat normalisht nuk mund të shfrytëzohen në JavaScript (me atributin httponly), mund të dërgohen në një host të jashtëm.
Kjo mund të ndodhë me gjurmues të tillë si Eulerian ose Criteo. Gjurmuesit e jashtëm mund të kenë vendosur një identifikues unik në cookie. Ata, nëse ishin pjesë e materialeve të webfaqeve, mund të lexonin identifikuesin sipas dëshirës gjatë punës së përdoruesit me burime të ndryshme në internet.
Sot, shumica e shfletuesve përfshijnë mbrojtje kundër këtij lloj sjelljeje të gjurmuesve. Si rezultat, tani gjurmuesit përdorin teknologjinë , duke u maskuar si skriptet e ndryshme të projekteve. Pikërisht, gjurmuesit i ofrojnë pronarëve të faqeve të internetit që të shtojnë në cilësimet e tyre CNAME për një domen, adresa e të cilit zakonisht duket si një grup rastësish të karaktereve.
Edhe pse nuk rekomandohet që cookie-t e një web-faqeje të jenë të aksesueshme për të gjitha subdomenet (p.sh. *.website.com), shumë webfaqe e bëjnë këtë. Në këtë rast, këto cookie automatikisht dërgohen te një gjurmues i jashtëm të maskuar. Si rezultat, as që mund të flasim për privatësi.
Për më tepër, e njëjta gjë ndodh edhe me headristat HTTP , të cilat dërgohen vetëm në domenin kryesor, pasi ato mund të përdoren për të krijuar të përdoruesit. Sigurohuni që shërbimi juaj CDN të filtrojë saktësisht këto headra.
Përfundimet
Nëse planifikoni të implementoni një hostim të pavarur të burimeve të jashtme së shpejti — lejoni që t'ju jap disa këshilla:
- Hostoni bibliotekat tuaja më të rëndësishme të JS, fontet dhe skedarët CSS. Kjo do të ulë rrezikun e rënies së faqes ose të reduktimit të performancës si rezultat i paprekshmërisë së një burimi thelbësor për funksionimin e faqes, për shkak të një shërbimi të jashtëm.
- Para se të ruani burime të jashtme në CDN, sigurohuni që emërtimi i skedarëve të përdorë një sistem versionimi, ose që të mund të menaxhoni ciklin e jetës së këtyre burimeve, duke pastruar me dorë ose automatikisht cache-n e CDN kur publikoni një version të ri të skriptit.
- Kujdesuni shumë për cilësimet e CDN, serverëve proxy, cache. Kjo do t'ju lejojë të shmangni dërgimin e cookie-ve të projektit tuaj ose headra
Client-Hintsnë shërbime të jashtme.
Të nderuar lexues! A po vendosni në serverat tuaj materiale të tjerë që janë jashtëzakonisht të rëndësishme për funksionimin e projekteve tuaja?
Burimi: habr.com
