I de seneste år har flere platforme til optimering af frontend-projekter tilbudt muligheder for selvhosting eller proxy til tredjepartsressourcer. Akamai giver mulighed for at angive til selvoprettede URL'er. Cloudflare har teknologien Edge Workers. Fasterzine kan URL'er på siderne, så de peger på tredjepartsressourcer, der findes på hoveddomænet for hjemmesiden.
Hvis det er kendt, at de tredjepartstjenester, der bruges i dit projekt, ikke ændrer sig for ofte, og at processen for deres levering til kunderne kan forbedres, er du helt sikkert begyndt at overveje proxying af sådanne tjenester. Med denne tilgang kan du i høj grad "nærme" disse ressourcer til brugerne og få bedre kontrol over deres caching på klientsiden. Dette beskytter også brugerne mod problemer forårsaget af "nedbrud" af tredjepartstjenesten eller forringelse af dens ydeevne.
Godt: forbedring af ydeevne
Selvhosting af andres ressourcer forbedrer ydeevnen på en ret åbenlys måde. Browseren behøver ikke at kontakte DNS igen, den skal ikke etablere en TCP-forbindelse og udføre en TLS-håndtryk på en tredjepartsdomæne. Den måde, hvorpå selvhosting af andres ressourcer påvirker ydeevnen, kan ses ved at sammenligne de to følgende billeder.
Tredjepartsressourcer indlæses fra eksterne kilder (taget )
Tredjepartsressourcer gemmes der, hvor de øvrige materialer på hjemmesiden også findes (taget )
Situationen forbedres yderligere af, at browseren vil udnytte mulighederne for multiplexing og prioritering af data i HTTP/2-forbindelsen, der allerede er etableret med hoveddomænet.
Hvis man ikke hoster tredjepartsressourcer, så da de vil blive indlæst fra et domæne, der er forskelligt fra hoveddomænet, kan de ikke prioriteres. Dette vil føre til, at de konkurrerer med hinanden om båndbredden for klienten. Dette kan resultere i, at indlæsningstiden for materialer, der er kritiske for at danne siden, bliver meget længere end den tid, der kan opnås under ideelle omstændigheder. en præsentation om HTTP/2-prioritering, hvor alt dette meget godt forklares.
Det kan antages, at brugen af attributterne i links til eksterne ressourcer preconnect vil hjælpe med at løse problemet. Men hvis der er for mange links til forskellige domæner, kan det faktisk overbelaste forbindelsen på det mest kritiske tidspunkt.
Hvis man hoster tredjepartsressourcer selv, kan man kontrollere, hvordan disse ressourcer leveres til klienten. Det handler om følgende:
- Man kan sikre, at der anvendes den bedst egnede datakompressionsalgoritme for hver browser (Brotli/gzip).
- Man kan øge cachetiden for ressourcer, som normalt, selv hos de mest kendte udbydere, ikke er særlig lang (for eksempel fastsættes den relevante værdi for GA-tag til 30 minutter).
Man kan endda forlænge TTL-værdien for ressourcen, for eksempel til et år, ved at inkludere de relevante materialer i sin cache-styringsstrategi (URL-hash, versionering osv.). Det vil vi tale om nedenfor.
▍Beskyttelse mod driftsforstyrrelser ved tredjepartsservices eller deres nedlukning
Et andet interessant aspekt ved at hoste tredjepartsressourcer selv er, at det giver mulighed for at mindske risiciene i forbindelse med driftsforstyrrelser ved tredjepartsservices. Antag, at den tredjepartsløsning, du bruger til A/B-testning, er implementeret som et blokkerende script, der indlæses i hovedsektionen af siden. Dette script indlæses langsomt. Hvis det relevante script ikke kan indlæses, vil siden være tom. Hvis indlæsningen tager meget lang tid, vil siden dukke op med stor forsinkelse. Eller antag, at der bruges et bibliotek, der indlæses fra en ekstern CDN-ressource. Forestil dig, at denne ressource oplever nedbrud eller er blevet blokeret i et land. En sådan situation vil forstyrre webstedets funktionalitet.
For at finde ud af, hvordan dit websted fungerer under betingelser med utilgængelighed af en ekstern service, kan du bruge SPOF-sektionen på .
SPOF-sektionen på webpagetest.org
▍Hvordan står det til med problemer med cache af materiale i browsere? (tips: det er en myte)
Man kan tro, at brugen af offentlige CDN automatisk vil føre til bedre ydeevne af ressourcerne, da disse tjenester har ret gode netværk og er fordelt over hele verden. Men i virkeligheden er alt lidt mere komplekst.
Lad os antage, at vi har flere forskellige websteder: website1.com, website2.com, website3.com. På alle disse websteder bruges jQuery-biblioteket. Vi tilslutter det ved hjælp af CDN, for eksempel — googleapis.com. Man kunne forvente, at browseren én gang vil indlæse og cache biblioteket og derefter bruge det, når den arbejder med de tre websteder. Dette kunne reducere belastningen på nettet. Måske ville det spare nogle ressourcer op og hjælpe med at forbedre ydeevnen. Men set fra et praktisk synspunkt ser alt anderledes ud. For eksempel, i Safari er der implementeret en funktion kaldet : i cachen bruges dobbelte nøgler, baseret på dokumentets kilde og på kilden til den tredjepartsressource. en god artikel om emnet.
Gamle undersøgelser og , samt nyere Paul Calvano, viser, at ressourcer ikke opbevares i browsercache så længe, som vi kunne forvente: «Der er en betydelig forskel mellem cachingtiden for egne og tredjepartsressourcer i et projekt. Det drejer sig om CSS og web-fonts. Specifikt, cacheperioden for 95% af egne skrifttyper overstiger en uge, mens cacheperioden for 50% af tredjeparts skrifttyper er mindre end en uge! Dette giver webudviklere god grund til selv at hoste skrifttypefiler!».
Som et resultat, hvis du hoster andres indhold, vil du ikke bemærke problemer med ydeevnen forårsaget af browsercaching.
Nu, hvor vi har set på styrkerne ved selv hosting af tredjepartsressourcer, lad os tale om, hvordan man kan skelne mellem en god implementering af denne tilgang og en dårlig.
Dårlig: djævlen ligger i detaljerne
At flytte tredjepartsressourcer til sit eget domæne kan ikke gøres automatisk uden at sikre korrekt caching af disse ressourcer.
Et af de vigtigste problemer her er cachingtiden. For eksempel inkluderer versionsoplysninger i navne på tredjeparts scripts cirka sådan her: jquery-3.4.1.js. Denne fil vil ikke ændre sig i fremtiden, hvilket ikke vil forårsage nogen problemer med dens caching.
Men hvis en form for versionering ikke anvendes, kan cachede scripts, hvis indhold ændres, mens filnavnet forbliver det samme, blive forældede. Dette kan blive et alvorligt problem, da det for eksempel ikke gør det muligt automatisk at implementere sikkerhedsopdateringer i scripts, som kunderne hurtigt skal have. Udvikleren vil skulle gøre en indsats for at opdatere sådanne scripts i cachen. Derudover kan det føre til fejl i applikationen, da koden, der anvendes på klienten fra cachen, adskiller sig fra den opdaterede version af koden, som serverdelen af projektet er baseret på.
Sandt nok, når det kommer til materialer, der opdateres ofte (tags management, A/B-test løsninger), er caching i CDN en opgave, der er løsbar, men også meget mere kompleks. Tjenester som Commanders Act, tags management løsninger, bruger webhooks ved publicering af nye versioner. Dette giver mulighed for at organisere cache opdateringer på CDN, eller endnu bedre, at udløse opdateringen af hash eller version URL.
▍Adaptiv levering af materialer til kunder
Derudover, når vi taler om caching, skal vi også tage højde for, at cacheindstillingerne, der anvendes på CDN, måske ikke passer til visse tredjeparts ressourcer. For eksempel kan sådanne ressourcer bruge teknologi til sniffing af brugeragent (user agent sniffing, adaptive serving) for at levere specifikke versioner af materialer, der er optimeret specielt til disse browsere. Disse teknologier, for at finde ud af browserens kapabiliteter, er afhængige af regulære udtryk eller en database, der indeholder oplysninger om HTTP-overskriften. User-Agent. Når de er klar over, hvilken browser de har at gøre med, leverer de materialer, der er tilpasset den.
Her kan vi huske to tjenester. Den første er googlefonts.com. Den anden er polyfill.io. Tjenesten Google Fonts leverer, til et givent ressourcer, forskellig CSS-kode, der afhænger af browserens kapabiliteter (giver links til woff2-ressourcer, bruger unicode-range).
Her er resultaterne af et par forespørgsler til Google Fonts, udført fra forskellige browsere.
Resultatet af anmodningen til Google Fonts udført fra Chrome
Resultatet af anmodningen til Google Fonts udført fra IE10
Polyfill.io leverer kun de polyfills, som browseren har brug for. Dette gøres for at forbedre ydeevnen.
Lad os se på, hvad der sker, hvis vi foretager den følgende anmodning fra forskellige browsere:
I svar på en sådan anmodning udført fra IE10 vil der komme 34 KB data. Mens svaret, udført fra Chrome, vil være tomt.
Ont: nogle overvejelser omkring privatliv
Dette punkt er det sidste i rækkefølgen, men ikke i vigtighed. Det handler om, at selvhosting af tredjeparts ressourcer på hoveddomænet for projektet eller dets underdomæne kan true brugernes privatliv og have negative konsekvenser for det primære webprojekt.
Hvis dit CDN-system ikke er korrekt konfigureret, kan alt ende med, at du sender cookies fra dit domæne til en tredjepartstjeneste. Hvis der ikke er implementeret korrekt filtrering på CDN-niveau, kan dine session cookies, som normalt ikke kan bruges i JavaScript (med attributten httponly), blive sendt til en ekstern vært.
Netop dette kan ske med trackere som Eulerian eller Criteo. Tredjeparts trackere kunne indstille en unik identifikator i cookies. De kunne, hvis de var en del af materialet på webstederne, læse identifikatoren efter eget valg, mens brugeren interagerede med forskellige webressourcer.
I dag inkluderer de fleste browsere beskyttelse mod denne type trackeradfærd. Som et resultat bruger trackere nu teknologien , hvor de camouflerer sig som egne scripts fra forskellige projekter. Det vil sige, at trackere tilbyder webstedsejere at tilføje CNAME til deres indstillinger for et domæne, der normalt ser ud som en tilfældig samling af tegn.
Selvom det ikke anbefales at gøre cookies fra webstedet tilgængelige for alle underdomæner (for eksempel - *.website.com), gøres det på mange websteder. I så fald sendes sådanne cookies automatisk til en camoufleret tredjeparts tracker. Som resultat er der ikke længere tale om nogen form for privatliv.
Derudover sker der det samme med HTTP-overskrifterne , som kun sendes til hoveddomænet, da de kan bruges til at oprette brugeren. Vær opmærksom på, at den CDN-tjeneste, du bruger, korrekt filtrerer sådanne overskrifter.
Resumé
Hvis du planlægger snart at implementere selvhostede tredjepartsressourcer, lad mig give dig et par råd:
- Host dine vigtigste JS-biblioteker, skrifttyper og CSS-filer. Dette reducerer risikoen for, at dit website går ned eller mister ydeevne, hvis en ressource, der er afgørende for websitets drift, bliver utilgængelig på grund af en tredjepartsservice.
- Før du cacher tredjepartsressourcer på CDN, skal du sikre, at der anvendes et versionssystem i filnavnene, eller at du kan styre livscyklussen for disse ressourcer ved manuelt eller automatisk at tømme CDN-cachen, når en ny version af scriptet offentliggøres.
- Vær meget opmærksom på indstillingerne for CDN, proxyservere og cache. Dette vil hjælpe dig med at undgå at sende cookies fra dit projekt eller headers
Client-Hintstil tredjepartsservices.
Kære læsere! Hoster du på dine servere tredjepartsindhold, som er ekstremt vigtigt for driften af dine projekter?
Kilde: habr.com
