De siste årene har flere og flere plattformer for å optimalisere front-end-prosjekter tilby muligheter for selvhosting eller proxying av tredjepartsressurser. Akamai lar deg stille inn for egengenererte URL-er. Cloudflare har Edge Workers-teknologi. Fasterzine kan URL-er på sider slik at de peker til tredjepartsressurser som ligger på hoveddomenet til nettstedet.
Hvis du vet at tredjepartstjenestene som brukes i prosjektet ditt ikke endres veldig ofte, og at prosessen med å levere dem til klienter kan forbedres, så tenker du sannsynligvis på å bruke proxy for slike tjenester. Med denne tilnærmingen kan du godt bringe disse ressursene nærmere brukerne dine og få mer fullstendig kontroll over hurtigbufferen deres på klientsiden. Dette lar deg i tillegg beskytte brukere mot problemer forårsaket av "krasj" av en tredjepartstjeneste eller forringelse av ytelsen.
Bra: Forbedret ytelse
Å være vertskap for andres ressurser forbedrer ytelsen på en veldig åpenbar måte. Nettleseren trenger ikke å få tilgang til DNS igjen, den trenger ikke opprette en TCP-tilkobling og utføre et TLS-håndtrykk på et tredjepartsdomene. Du kan se hvordan det å være vertskap for andres ressurser påvirker ytelsen ved å sammenligne følgende to figurer.
Tredjepartsressurser lastes ned fra eksterne kilder (hentet fra )
Tredjepartsressurser lagres på samme sted som resten av nettstedets materiell (hentet fra )
Situasjonen forbedres også ved at nettleseren vil bruke muligheten til å multiplekse og prioritere data fra HTTP/2-forbindelsen som allerede er etablert med hoveddomenet.
Hvis du ikke er vert for tredjepartsressurser, kan de ikke prioriteres, siden de lastes fra et annet domene enn det viktigste. Dette vil få dem til å konkurrere med hverandre om klientens båndbredde. Dette kan resultere i lastetider for innhold som er avgjørende for å bygge en side som er mye lengre enn det som ville vært oppnåelig under ideelle omstendigheter. snakk om HTTP/2-prioritering som forklarer alt dette veldig godt.
Det kan antas at bruk av attributter i lenker til eksterne ressurser preconnect vil hjelpe til med å løse problemet. Men hvis det er for mange av disse koblingene til forskjellige domener, kan det faktisk overbelaste kommunikasjonslinjen på det mest avgjørende øyeblikket.
Hvis du er vert for tredjepartsressurser selv, kan du kontrollere nøyaktig hvordan disse ressursene gis til klienten. Vi snakker nemlig om følgende:
- Du kan sikre at datakomprimeringsalgoritmen som passer best for hver nettleser brukes (Brotli/gzip).
- Du kan øke hurtigbufringstiden for ressurser som vanligvis ikke er spesielt lange, selv hos de mest kjente leverandørene (for eksempel er den tilsvarende verdien for GA-taggen satt til 30 minutter).
Du kan til og med utvide TTL-en for en ressurs til for eksempel et år ved å inkorporere relevant innhold i strategien for caching-administrasjon (URL-hasher, versjonering osv.). Vi skal snakke om dette nedenfor.
▍Beskyttelse mot avbrudd i driften av tredjepartstjenester eller avstengning av dem
Et annet interessant aspekt ved selvhostende tredjepartsressurser er at det lar deg redusere risikoen forbundet med utfall av tredjepartstjenester. La oss anta at tredjeparts A/B-testløsningen du bruker er implementert som et blokkeringsskript som lastes inn i head-delen av siden. Dette skriptet laster sakte. Hvis det korresponderende skriptet ikke kan lastes, vil siden være tom. Hvis det tar veldig lang tid å laste, vil siden vises med en lang forsinkelse. Eller anta at prosjektet bruker et bibliotek lastet ned fra en tredjeparts CDN-ressurs. La oss forestille oss at denne ressursen opplevde en feil eller ble blokkert i et bestemt land. En slik situasjon vil føre til et brudd på logikken til nettstedet.
For å finne ut hvordan nettstedet ditt fungerer når en ekstern tjeneste er utilgjengelig, kan du bruke SPOF-delen på .
SPOF-delen på webpagetest.org
▍Hva med problemer med bufring av materialer i nettlesere? (hint: det er en myte)
Du tror kanskje at bruk av offentlige CDN-er automatisk vil føre til bedre ressursytelse, siden disse tjenestene har nettverk av ganske høy kvalitet og distribueres over hele verden. Men alt er faktisk litt mer komplisert.
La oss si at vi har flere forskjellige nettsteder: website1.com, website2.com, website3.com. Alle disse nettstedene bruker jQuery-biblioteket. Vi kobler den til dem ved å bruke et CDN, for eksempel - googleapis.com. Du kan forvente at nettleseren laster ned og cacher biblioteket én gang, og deretter bruker det på alle tre nettstedene. Dette kan redusere belastningen på nettverket. Kanskje dette vil tillate deg å spare penger et sted og bidra til å forbedre ressursytelsen. Fra et praktisk synspunkt ser alt annerledes ut. For eksempel har Safari en funksjon som heter : Bufferen bruker to nøkler basert på kilden til dokumentet og kilden til tredjepartsressursen. god artikkel om dette emnet.
gamle studier и , samt nyere Paul Calvano, viser at ressurser ikke lagres i nettleserbuffere så lenge som vi kunne forvente: «Det er et alvorlig gap mellom bufringstiden til et prosjekts egne og tredjepartsressurser. Vi snakker om CSS og webfonter. Nemlig 95 % av native fonter har en cache-levetid på mer enn en uke, mens 50 % av tredjeparts fonter har en cache-levetid på mindre enn en uke! Dette gir webutviklere en overbevisende grunn til å være vert for fontfiler selv!»
Som et resultat, hvis du er vert for andres innhold, vil du ikke merke noen ytelsesproblemer forårsaket av nettleserbufring.
Nå som vi har dekket styrkene til tredjeparts selvhosting, la oss snakke om hvordan man kan skille en god implementering av denne tilnærmingen fra en dårlig.
The Bad: Djevelen er i detaljene
Flytting av tredjepartsressurser til ditt eget domene kan ikke gjøres automatisk uten å sikre at slike ressurser er riktig bufret.
Et av hovedproblemene her er caching-tid. For eksempel er versjonsinformasjon inkludert i tredjeparts skriptnavn som dette: jquery-3.4.1.js. En slik fil vil ikke endre seg i fremtiden, og som et resultat vil dette ikke forårsake noen problemer med cachen.
Men hvis noen versjonsordninger ikke brukes når du arbeider med filer, kan hurtigbufrede skript, hvis innhold endres mens filnavnet forblir uendret, bli utdatert. Dette kan være et alvorlig problem, siden det for eksempel ikke tillater at automatiserte sikkerhetsoppdateringer legges til skript som klienter trenger å motta så raskt som mulig. Utvikleren må gjøre en innsats for å oppdatere slike skript i cachen. I tillegg kan dette føre til applikasjonsfeil på grunn av at koden som brukes på klienten fra cachen skiller seg fra den nyeste versjonen av koden som serverdelen av prosjektet er designet for.
Riktignok, hvis vi snakker om materialer som oppdateres ofte (tag-managere, løsninger for A/B-testing), så er bufring av dem ved hjelp av CDN-verktøy en oppgave som kan løses, men er mye mer kompleks. Tjenester som Commanders Act, en tagadministrasjonsløsning, bruker webhooks når de publiserer nye versjoner. Dette gir deg muligheten til å tvinge en hurtigbufferflush på CDN, eller enda bedre, muligheten til å tvinge en hash- eller URL-oppdatering.
▍Tilpasset levering av materialer til kunder
I tillegg, når vi snakker om caching, må vi ta i betraktning det faktum at caching-innstillingene som brukes på CDN ikke er egnet for enkelte tredjepartsressurser. Slike ressurser kan for eksempel bruke teknologi for brukeragentsniffing (adaptiv visning) for å betjene spesifikke nettlesere med versjoner av innhold som er optimalisert spesielt for disse nettleserne. Disse teknologiene er avhengige av regulære uttrykk, eller en database med HTTP-hodeinformasjon, for å finne ut nettleserfunksjoner. User-Agent. Når de vet hvilken nettleser de har å gjøre med, gir de den materialer designet for det.
Her kan du huske to gudstjenester. Den første er googlefonts.com. Den andre er polyfill.io. Google Fonts-tjenesten gir, for en bestemt ressurs, forskjellig CSS-kode, avhengig av nettleserens muligheter (gir lenker til woff2-ressurser ved å bruke unicode-range).
Her er resultatene av et par Google Fonts-spørringer laget fra forskjellige nettlesere.
Google Fonts-spørringsresultat fra Chrome
Resultat av Google Fonts-søk utført fra IE10
Polyfill.io gir nettleseren bare polyfillene den trenger. Dette gjøres av ytelseshensyn.
La oss for eksempel ta en titt på hva som skjer hvis du kjører følgende forespørsel fra forskjellige nettlesere:
Som svar på en slik forespørsel utført fra IE10, vil 34 KB med data bli mottatt. Og svaret på det, utført fra Chrome, vil være tomt.
Sint: Noen personvernhensyn
Dette punktet er sist i rekkefølge, men ikke minst viktig. Poenget er at selvhosting av tredjepartsressurser på hoveddomenet til prosjektet eller på dets underdomene kan sette personvernet til brukere i fare og påvirke hovednettprosjektet negativt.
Hvis CDN-systemet ditt ikke er riktig konfigurert, kan du ende opp med å sende domenets informasjonskapsler til en tredjepartstjeneste. Hvis riktig filtrering ikke er organisert på CDN-nivå, vil øktens informasjonskapsler, som normalt ikke kan brukes i JavaScript (med httponly), kan sendes til en utenlandsk vert.
Dette er nøyaktig hva som kan skje med sporere som Eulerian eller Criteo. Tredjepartssporere kan ha satt en unik identifikator i informasjonskapselen. Hvis de var en del av nettstedets materialer, kunne de lese identifikatoren etter eget skjønn mens brukeren jobbet med forskjellige nettressurser.
I disse dager inkluderer de fleste nettlesere beskyttelse mot denne typen sporingsadferd. Som et resultat bruker trackere nå teknologi , maskert som sine egne manus for ulike prosjekter. Sporere tilbyr nemlig nettstedseiere å legge til en CNAME i innstillingene for et bestemt domene, hvis adresse vanligvis ser ut som et tilfeldig sett med tegn.
Selv om det ikke anbefales å gjøre nettsideinformasjonskapsler tilgjengelig for alle underdomener (for eksempel - *.website.com), gjør mange nettsteder dette. I dette tilfellet sendes slike informasjonskapsler automatisk til en forkledd tredjeparts tracker. Som et resultat kan vi ikke lenger snakke om noe personvern.
Det samme skjer også med HTTP-hoder , som bare sendes til hoveddomenet, siden de kan brukes til å lage bruker. Sørg for at CDN-tjenesten du bruker filtrerer disse overskriftene riktig.
Resultater av
Hvis du planlegger å implementere selvhosting av tredjepartsressurser snart, la meg gi deg noen tips:
- Vert dine viktigste JS-biblioteker, fonter og CSS-filer. Dette vil redusere risikoen for nettstedsvikt eller ytelsesforringelse på grunn av at en ressurs som er viktig for nettstedet er utilgjengelig på grunn av feilen til en tredjepartstjeneste.
- Før du hurtigbufrer tredjepartsressurser på et CDN, må du forsikre deg om at et slags versjonssystem brukes når du navngir filene deres, eller at du kan administrere livssyklusen til disse ressursene ved å manuelt eller automatisk tilbakestille CDN-hurtigbufferen når du publiserer en ny versjon av manuset.
- Vær veldig forsiktig med CDN, proxy-server og cache-innstillinger. Dette vil tillate deg å forhindre at prosjektet eller overskriftene dine sendes informasjonskapsler
Client-Hintstredjepartstjenester.
Kjære lesere! Hoster du andres materialer på serverne dine som er ekstremt viktige for driften av prosjektene dine?
Kilde: www.habr.com