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
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.
Burimet e palëve të treta shkarkohen nga burime të jashtme (marrë nga
Burimet e palëve të treta ruhen në të njëjtin vend si pjesa tjetër e materialeve të sitit (marrë nga
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.
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
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
studime të vjetra
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.
Rezultati i pyetjes së shkronjave të Google nga Chrome
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:
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ë
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
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?
Burimi: www.habr.com