Azken urteotan, frontend proiektuak optimizatzeko gero eta plataforma gehiagok eskaintzen dituzte hirugarrenen baliabideak autoostatatzeko edo proxy egiteko aukerak. Akamai-k ezartzeko aukera ematen dizu Norberak sortutako URLetarako. Cloudflare-k Edge Workers teknologia du. Fasterzine daiteke Orrialdeetako URLak, gunearen domeinu nagusian kokatutako hirugarrenen baliabideetara seinalatzeko.
Badakizu zure proiektuan erabiltzen diren hirugarrenen zerbitzuak ez direla askotan aldatzen eta bezeroei emateko prozesua hobetu daitekeela, ziurrenik zerbitzu horiek proxy egitea pentsatzen ari zara. Ikuspegi honekin, baliabide hauek zure erabiltzaileengana hurbil ditzakezu eta bezeroaren aldean haien cachearen gaineko kontrol osoa lortu. Honek, gainera, erabiltzaileak hirugarrenen zerbitzu baten "crash" edo bere errendimenduaren hondatzeak eragindako arazoetatik babesteko aukera ematen du.
Ona: errendimendua hobetu da
Beste norbaiten baliabideak auto-ostatatzeak errendimendua hobetzen du oso modu agerian. Arakatzaileak ez du DNS berriro sartu behar, ez du TCP konexiorik ezarri beharrik eta TLS esku-ematea hirugarrenen domeinu batean. Beste norbaiten baliabideak auto-ostatatzeak errendimenduan nola eragiten duen ikus dezakezu hurrengo bi zifrak alderatuz.
Hirugarrenen baliabideak kanpoko iturrietatik deskargatzen dira (tik hartuta )
Hirugarrenen baliabideak guneko gainontzeko materialen leku berean gordetzen dira (tik hartuak). )
Egoera ere hobetzen da arakatzaileak domeinu nagusiarekin dagoeneko ezarrita dagoen HTTP/2 konexioko datuak multiplexatzeko eta lehenesteko gaitasuna erabiliko duelako.
Hirugarrenen baliabideak ez badituzu ostatatzen, nagusitik desberdina den domeinu batetik kargatuko direnez, ezin zaie lehentasuna eman. Horrek bezeroaren banda zabalerako elkarren artean lehiatuko ditu. Horren ondorioz, egoera idealetan lor daitekeena baino askoz luzeagoa den orrialde bat eraikitzeko funtsezko edukia kargatzeko denborak sor ditzake. hau guztia oso ondo azaltzen duen HTTP/2 lehentasunari buruz hitz egin.
Kanpoko baliabideetarako esteketan atributuak erabiltzea dela pentsa daiteke preconnect arazoa konpontzen lagunduko du. Hala ere, domeinu ezberdinetarako esteka horietako gehiegi baldin badaude, komunikazio-lerroa gainkargatu dezake momentu erabakigarrienean.
Hirugarrenen baliabideak zuk zeuk ostatatzen badituzu, baliabide horiek bezeroari nola ematen zaizkion kontrola dezakezu. Hain zuzen, honako hauetaz ari gara:
- Arakatzaile bakoitzari hobekien egokitzen zaion datuak konprimitzeko algoritmoa erabiltzen dela ziurtatu dezakezu (Brotli/gzip).
- Normalean bereziki luzeak ez diren baliabideen cache-denbora handitu dezakezu, baita hornitzaile ezagunenekin ere (adibidez, GA etiketari dagokion balioa 30 minutukoa da).
Baliabide baten TTL-a ere luza dezakezu urtebetera, esate baterako, zure cachearen kudeaketa estrategian eduki garrantzitsua sartuz (URL hashak, bertsioak, etab.). Honetaz hitz egingo dugu jarraian.
βHirugarrenen zerbitzuen funtzionamenduan eteten edo horiek itzaltzearen aurkako babesa
Auto-ostatatutako hirugarrenen baliabideen beste alderdi interesgarri bat hirugarrenen zerbitzuen etenekin lotutako arriskuak arintzeko aukera ematen duela da. Demagun erabiltzen ari zaren hirugarrenen A/B probaren irtenbidea orriaren buruaren atalean kargatzen den blokeo-script gisa inplementatuta dagoela. Script hau poliki kargatzen da. Dagokion script-ak kargatzen huts egiten badu, orria hutsik egongo da. Kargatzeko oso denbora luzea behar bada, orria atzerapen luze batekin agertuko da. Edo, demagun proiektuak hirugarrenen CDN baliabide batetik deskargatutako liburutegi bat erabiltzen duela. Imajina dezagun baliabide honek porrot bat izan duela edo blokeatu egin dela herrialde jakin batean. Egoera horrek gunearen logikaren urraketa ekarriko du.
Kanpoko zerbitzuren bat erabilgarri ez dagoenean zure guneak nola funtzionatzen duen jakiteko, SPOF atala erabil dezakezu .
SPOF atala webpagetest.org webgunean
βZer gertatzen da arakatzaileetan materialen cachean dauden arazoekin? (Iradokizuna: mito bat da)
Pentsa dezakezu CDN publikoak erabiltzeak baliabideen errendimendu hobea ekarriko lukeela automatikoki, zerbitzu hauek nahiko kalitate handiko sareak dituztelako eta mundu osoan banatuta baitaude. Baina, egia esan, dena apur bat konplikatuagoa da.
Demagun hainbat gune ezberdin ditugula: webgunea1.com, webgunea2.com, webgunea3.com. Gune hauek guztiek jQuery liburutegia erabiltzen dute. Haiekin konektatzen dugu CDN bat erabiliz, adibidez - googleapis.com. Arakatzaileak liburutegia behin deskargatu eta cachean gordeko duela espero dezakezu, eta gero hiru guneetan erabiltzea. Horrek sareko karga murriztu dezake. Beharbada, horrek dirua aurrezteko aukera emango dizu nonbait eta baliabideen errendimendua hobetzen lagunduko dizu. Ikuspegi praktikotik denak itxura ezberdina du. Adibidez, Safari izeneko funtzio bat du : Cacheak gako bikoitzak erabiltzen ditu dokumentuaren iturriaren eta hirugarrenen baliabidearen iturriaren arabera. gai honi buruzko artikulu ona.
ikasketa zaharrak ΠΈ , baita berriagoak ere Paul Calvanok, erakutsi du baliabideak ez direla arakatzaileen cacheetan gordetzen espero genezakeen adina denboraz: βDesfase larria dago proiektu baten eta hirugarrenen baliabideen cache-denboraren artean. CSS eta web letra-tipoei buruz ari gara. Hain zuzen, jatorrizko letra-tipoen % 95ek astebete baino gehiagoko cache-bizitza dute, eta hirugarrenen % 50ek, berriz, astebete baino gutxiagoko cache-bizitza dute! Horrek web-garatzaileei arrazoi ezinbestekoa ematen die letra-tipo-fitxategiak beraiek ostatatzeko!
Ondorioz, besteen edukia ostatatzen baduzu, ez duzu arakatzailearen cachean eragindako errendimendu-arazorik nabarituko.
Hirugarrenen auto-ostalaritzaren indarguneak estali ditugula, hitz egin dezagun ikuspegi honen ezarpen on bat txar batetik nola bereizten.
Txarra: deabrua xehetasunetan dago
Hirugarrenen baliabideak zure domeinura eraman ezin dira automatikoki egin baliabide horiek behar bezala cachean daudela ziurtatu gabe.
Hemen arazo nagusietako bat cachean gordetzeko denbora da. Adibidez, bertsioaren informazioa hirugarrenen script-izenetan sartzen da honela: jquery-3.4.1.js. Fitxategi hori ez da aldatuko etorkizunean, eta, ondorioz, horrek ez du arazorik sortuko bere cachean.
Baina fitxategiekin lan egitean bertsio-eskemaren bat erabiltzen ez bada, cachean gordetako script-ak, fitxategiaren izena aldatzen ez den bitartean haien edukia aldatzen da, zaharkituta geratu daitezke. Arazo larria izan daiteke, adibidez, bezeroek ahalik eta azkarren jaso behar dituzten scriptetan segurtasun-adabaki automatizatuak gehitzea ahalbidetzen duelako. Garatzaileak ahalegina egin beharko du cachean horrelako scriptak eguneratzeko. Horrez gain, honek aplikazio-hutsegiteak eragin ditzake, bezeroan erabiltzen den kodea cachetik desberdina delako proiektuaren zerbitzariaren zatia diseinatu den kodearen azken bertsioaren aldean.
Egia da, maiz eguneratzen diren materialei buruz hitz egiten badugu (etiketa-kudeatzaileak, A/B testetarako irtenbideak), CDN tresnak erabiliz cachean gordetzea konpondu daitekeen zeregina da, baina askoz konplexuagoa da. Commanders Act bezalako zerbitzuek, etiketak kudeatzeko irtenbideak, webhook-ak erabiltzen dituzte bertsio berriak argitaratzerakoan. Honek CDNn cachea hustea behartzeko aukera ematen dizu, edo, hobeto esanda, hash edo URL eguneratzea behartzeko aukera ematen dizu.
βBezeroei materialak egokitzeko entrega
Gainera, cacheari buruz hitz egiten dugunean, kontuan hartu behar dugu CDNn erabiltzen diren cache-ezarpenak agian ez direla egokiak hirugarrenen baliabide batzuetarako. Esaterako, baliabide horiek erabiltzaile-agenteen sniffing (zerbitzu moldagarria) teknologia erabil dezakete arakatzaile zehatzak hornitzeko, arakatzaile horietarako berariaz optimizatutako edukien bertsioekin. Teknologia hauek esamolde erregularretan edo HTTP goiburuko informazio datu-base batean oinarritzen dira arakatzailearen gaitasunak ezagutzeko. User-Agent. Zein nabigatzailerekin ari diren jakitean, horretarako diseinatutako materialak ematen dizkiote.
Hemen bi zerbitzu gogoratu ditzakezu. Lehenengoa googlefonts.com da. Bigarrena polyfill.io da. Google Fonts zerbitzuak baliabide jakin baterako hainbat CSS kode eskaintzen ditu, arakatzailearen gaitasunen arabera (woff2 baliabideetarako estekak emanez. unicode-range).
Hona hemen arakatzaile ezberdinetatik egindako Google Fonts-en pare baten emaitzak.
Chrome-ren Google Fonts kontsultaren emaitza
IE10etik exekutatutako Google Fonts kontsultaren emaitza
Polyfill.io-k arakatzaileari behar dituen polyfills bakarrik ematen dizkio. Hau errendimendu arrazoiengatik egiten da.
Adibidez, ikus dezagun zer gertatzen den arakatzaile ezberdinetatik honako eskaera hau exekutatzen baduzu:
IE10-tik exekutatutako eskaera horri erantzunez, 34 KB datuak jasoko dira. Eta horren erantzuna, Chrome-tik exekutatuta, hutsik egongo da.
Haserre: pribatutasun kontu batzuk
Puntu hau azkena da, baina ez da garrantzitsuena. Kontua da proiektuaren domeinu nagusian edo bere azpidomeinuan hirugarrenen baliabideen auto-ostatatzeak erabiltzaileen pribatutasuna arriskuan jar dezakeela eta web proiektu nagusiari negatiboki eragin diezaiokeela.
Zure CDN sistema behar bezala konfiguratuta ez badago, baliteke zure domeinuko cookieak hirugarrenen zerbitzu batera bidaltzea. CDN mailan iragazketa egokia antolatzen ez bada, zure saioko cookieak, normalean JavaScript-en erabili ezin direnak httponly), atzerriko ostalari bati bidal daiteke.
Horixe da Eulerian edo Criteo bezalako jarraitzaileekin gerta daitekeena. Baliteke hirugarrenen jarraitzaileak identifikatzaile esklusibo bat ezarri izana cookiean. Gunearen materialen parte balira, identifikatzailea irakur zezaketen erabiltzaileak web baliabide ezberdinekin lan egiten zuen bitartean.
Egun, arakatzaile gehienek jarraitzaile-portaera horren aurkako babesa dute. Ondorioz, jarraitzaileak teknologia erabiltzen dute orain , hainbat proiekturen gidoi propio gisa mozorrotuz. Hain zuzen, jarraitzaileei webguneen jabeei CNAME bat gehitzeko aukera eskaintzen diete domeinu jakin bateko ezarpenetan, zeinaren helbideak normalean ausazko karaktere multzo baten itxura du.
Webguneetako cookieak azpidomeinu guztien eskura jartzea (adibidez - *.website.com) gomendatzen ez den arren, gune askok hori egiten dute. Kasu honetan, cookie horiek automatikoki bidaltzen dira mozorrotutako hirugarrenen jarraitzaile batera. Ondorioz, ezin dugu gehiago inongo pribatutasunaz hitz egin.
Gainera, gauza bera gertatzen da HTTP goiburuekin , domeinu nagusira soilik bidaltzen direnak, sortzeko erabil baitaitezke erabiltzailea. Ziurtatu erabiltzen duzun CDN zerbitzuak goiburu hauek behar bezala iragazten dituela.
Emaitzak
Hirugarrenen baliabideen auto-ostalaritza laster ezartzeko asmoa baduzu, gomendio batzuk emango dizkizut:
- Osta ezazu zure JS liburutegi garrantzitsuenak, letra-tipoak eta CSS fitxategiak. Honek gunearen hutsegite edo errendimendua hondatzeko arriskua murriztuko du, gunerako ezinbestekoa den baliabide bat erabilgarri ez dagoelako hirugarrenen zerbitzu baten errua dela eta.
- Hirugarrenen baliabideak CDN batean gorde aurretik, ziurtatu nolabaiteko bertsio-sistema erabiltzen dela haien fitxategiak izendatzerakoan, edo baliabide horien bizi-zikloa kudeatu dezakezula CDNren cachea eskuz edo automatikoki berrezarriz bertsio berri bat argitaratzean. gidoia.
- Kontuz ibili zure CDN, proxy zerbitzari eta cache ezarpenekin. Horri esker, zure proiektua edo goiburuak cookieak bidaltzea eragotziko duzu
Client-Hintshirugarrenen zerbitzuak.
Irakurle maitea! Zure proiektuen funtzionamendurako oso garrantzitsuak diren beste batzuen materialak hartzen dituzu zure zerbitzarietan?
Iturria: www.habr.com