I de senere år har flere og flere platforme til optimering af front-end-projekter tilbudt muligheder for selvhosting eller proxy af tredjepartsressourcer. Akamai giver dig mulighed for at indstille til selvgenererede URL'er. Cloudflare har Edge Workers-teknologi. Fasterzine kan URL'er på sider, så de peger på tredjepartsressourcer placeret på webstedets hoveddomæne.
Hvis du ved, at de tredjepartstjenester, der bruges i dit projekt, ikke ændrer sig særlig ofte, og at processen med at levere dem til kunderne kunne forbedres, så overvejer du sandsynligvis at give sådanne tjenester proxy. Med denne tilgang kan du meget vel bringe disse ressourcer tættere på dine brugere og få mere fuldstændig kontrol over deres caching på klientsiden. Dette giver dig desuden mulighed for at beskytte brugere mod problemer forårsaget af "nedbrud" af en tredjepartstjeneste eller forringelse af dens ydeevne.
Godt: Forbedret ydeevne
Selvvært for andres ressourcer forbedrer ydeevnen på en meget indlysende måde. Browseren behøver ikke at få adgang til DNS igen, den behøver ikke oprette en TCP-forbindelse og udføre et TLS-håndtryk på et tredjepartsdomæne. Du kan se, hvordan selvvært andres ressourcer påvirker ydeevnen ved at sammenligne følgende to figurer.
Tredjepartsressourcer downloades fra eksterne kilder (hentet fra )
Tredjepartsressourcer gemmes på samme sted som resten af webstedets materialer (taget fra )
Situationen forbedres også af, at browseren vil bruge muligheden for at multiplekse og prioritere data fra den HTTP/2-forbindelse, der allerede er etableret med hoveddomænet.
Hvis du ikke er vært for tredjepartsressourcer, kan de ikke prioriteres, da de vil blive indlæst fra et andet domæne end det primære. Dette vil få dem til at konkurrere med hinanden om kundens båndbredde. Dette kan resultere i indlæsningstider for indhold, der er afgørende for opbygningen af en side, som er meget længere end hvad der ville være muligt under ideelle omstændigheder. snak om HTTP/2-prioritering, der forklarer alt dette meget godt.
Det kan antages, at brugen af attributter i links til eksterne ressourcer preconnect vil hjælpe med at løse problemet. Men hvis der er for mange af disse links til forskellige domæner, kan det faktisk overbelaste kommunikationslinjen på det mest afgørende tidspunkt.
Hvis du selv hoster tredjepartsressourcer, kan du kontrollere, hvordan disse ressourcer præcist gives til klienten. Vi taler nemlig om følgende:
- Du kan sikre dig, at den datakomprimeringsalgoritme, der passer bedst til hver browser, bruges (Brotli/gzip).
- Du kan øge cachetiden for ressourcer, der normalt ikke er specielt lange, selv hos de mest kendte udbydere (f.eks. er den tilsvarende værdi for GA-tagget sat til 30 minutter).
Du kan endda forlænge TTL for en ressource til f.eks. et år ved at inkorporere relevant indhold i din cachehåndteringsstrategi (URL-hashes, versionering osv.). Vi vil tale om dette nedenfor.
▍Beskyttelse mod afbrydelser i driften af tredjepartstjenester eller deres nedlukning
Et andet interessant aspekt ved selvhostende tredjepartsressourcer er, at det giver dig mulighed for at mindske risiciene forbundet med udfald af tredjepartstjenester. Lad os antage, at den tredjeparts A/B-testløsning, du bruger, er implementeret som et blokeringsscript, der indlæses i hovedafsnittet på siden. Dette script indlæses langsomt. Hvis det tilsvarende script ikke indlæses, vil siden være tom. Hvis det tager meget lang tid at indlæse, vises siden med en lang forsinkelse. Eller antag, at projektet bruger et bibliotek indlæst fra en tredjeparts CDN-ressource. Lad os forestille os, at denne ressource oplevede en fiasko eller blev blokeret i et bestemt land. En sådan situation vil føre til en krænkelse af webstedets logik.
For at finde ud af, hvordan dit websted fungerer, når en ekstern tjeneste ikke er tilgængelig, kan du bruge SPOF-sektionen på .
SPOF-sektionen på webpagetest.org
▍Hvad med problemer med caching af materialer i browsere? (tip: det er en myte)
Du tror måske, at brug af offentlige CDN'er automatisk vil føre til bedre ressourceydelse, da disse tjenester har netværk af ret høj kvalitet og distribueres over hele verden. Men alt er faktisk lidt mere kompliceret.
Lad os sige, at vi har flere forskellige websteder: website1.com, website2.com, website3.com. Alle disse websteder bruger jQuery-biblioteket. Vi forbinder det til dem ved hjælp af et CDN, for eksempel - googleapis.com. Du kan forvente, at browseren downloader og cacher biblioteket én gang og derefter bruger det på tværs af alle tre websteder. Dette kan reducere belastningen på netværket. Måske vil dette give dig mulighed for at spare penge et sted og hjælpe med at forbedre ressourceydelsen. Fra et praktisk synspunkt ser alt anderledes ud. For eksempel har Safari en funktion kaldet : Cachen bruger to nøgler baseret på kilden til dokumentet og kilden til tredjepartsressourcen. god artikel om dette emne.
gamle undersøgelser и , såvel som nyere Paul Calvano, viser, at ressourcer ikke gemmes i browser-caches så længe, som vi kunne forvente: "Der er en alvorlig kløft mellem cachetiden for et projekts egne og tredjepartsressourcer. Vi taler om CSS og webskrifttyper. Nemlig 95 % af native skrifttyper har en cachelevetid på mere end en uge, mens 50 % af tredjeparts skrifttyper har en cachelevetid på mindre end en uge! Dette giver webudviklere en overbevisende grund til selv at være vært for skrifttypefiler!"
Som et resultat, hvis du hoster andres indhold, vil du ikke bemærke nogen ydeevneproblemer forårsaget af browser-cache.
Nu hvor vi har dækket styrkerne ved tredjeparts-selvhosting, lad os tale om, hvordan man skelner en god implementering af denne tilgang fra en dårlig.
The Bad: Djævelen er i detaljerne
At flytte tredjepartsressourcer til dit eget domæne kan ikke gøres automatisk uden at sikre, at sådanne ressourcer er korrekt cachelagret.
Et af hovedproblemerne her er cachetid. For eksempel er versionsoplysninger inkluderet i tredjeparts scriptnavne som dette: jquery-3.4.1.js. En sådan fil vil ikke ændre sig i fremtiden, og som følge heraf vil dette ikke forårsage nogen problemer med dens caching.
Men hvis en versionsordning ikke bruges, når du arbejder med filer, kan cachelagrede scripts, hvis indhold ændres, mens filnavnet forbliver uændret, blive forældede. Dette kan være et alvorligt problem, da det for eksempel ikke tillader, at automatiserede sikkerhedsrettelser føjes til scripts, som klienter skal modtage så hurtigt som muligt. Udvikleren bliver nødt til at gøre en indsats for at opdatere sådanne scripts i cachen. Derudover kan dette forårsage applikationsfejl på grund af, at koden, der bruges på klienten fra cachen, adskiller sig fra den seneste version af koden, som serverdelen af projektet er designet til.
Sandt nok, hvis vi taler om materialer, der opdateres ofte (tag-managere, løsninger til A/B-test), så er cachelagring af dem ved hjælp af CDN-værktøjer en opgave, der kan løses, men er meget mere kompleks. Tjenester som Commanders Act, en tag-administrationsløsning, bruger webhooks, når de udgiver nye versioner. Dette giver dig mulighed for at tvinge en cache-flush på CDN, eller endnu bedre, muligheden for at tvinge en hash- eller URL-opdatering.
▍Tilpasset levering af materialer til kunder
Derudover, når vi taler om caching, skal vi tage højde for, at de cachingindstillinger, der bruges på CDN'et, muligvis ikke er egnede til nogle tredjepartsressourcer. Sådanne ressourcer kan f.eks. bruge brugeragent-sniffing-teknologi (adaptiv visning) til at betjene bestemte browsere med versioner af indhold, der er optimeret specifikt til disse browsere. Disse teknologier er afhængige af regulære udtryk eller en database med HTTP-headeroplysninger for at finde ud af browserens muligheder. User-Agent. Når de ved, hvilken browser de har med at gøre, giver de den materialer designet til det.
Her kan du huske to gudstjenester. Den første er googlefonts.com. Den anden er polyfill.io. Google Fonts-tjenesten leverer, for en bestemt ressource, forskellig CSS-kode, afhængigt af browserens muligheder (der giver links til woff2-ressourcer vha. unicode-range).
Her er resultaterne af et par Google Fonts-forespørgsler lavet fra forskellige browsere.
Google Fonts-forespørgselsresultat fra Chrome
Resultat af Google Fonts-forespørgsel udført fra IE10
Polyfill.io giver browseren kun de polyfills, den har brug for. Dette gøres af præstationsmæssige årsager.
Lad os f.eks. se på, hvad der sker, hvis du kører følgende anmodning fra forskellige browsere:
Som svar på en sådan anmodning udført fra IE10 vil der blive modtaget 34 KB data. Og svaret på det, udført fra Chrome, vil være tomt.
Vred: Nogle privatlivsovervejelser
Dette punkt er i sidste række, men ikke mindst vigtigt. Pointen er, at selvhosting af tredjepartsressourcer på projektets hoveddomæne eller på dets underdomæne kan bringe brugernes privatliv i fare og påvirke hovedwebprojektet negativt.
Hvis dit CDN-system ikke er konfigureret korrekt, kan du ende med at sende dit domænes cookies til en tredjepartstjeneste. Hvis korrekt filtrering ikke er organiseret på CDN-niveau, vil dine sessionscookies, som normalt ikke kan bruges i JavaScript (med httponly), kan sendes til en udenlandsk vært.
Det er præcis, hvad der kan ske med trackere som Eulerian eller Criteo. Tredjeparts trackere kan have sat en unik identifikator i cookien. Hvis de var en del af webstedets materialer, kunne de læse identifikatoren efter eget skøn, mens brugeren arbejdede med forskellige webressourcer.
I disse dage inkluderer de fleste browsere beskyttelse mod denne type sporingsadfærd. Som et resultat bruger trackere nu teknologi , forklædt som deres egne manuskripter til forskellige projekter. Trackere tilbyder nemlig webstedsejere at tilføje et CNAME til deres indstillinger for et bestemt domæne, hvis adresse normalt ligner et tilfældigt sæt tegn.
Selvom det ikke anbefales at gøre webstedscookies tilgængelige for alle underdomæner (for eksempel - *.website.com), gør mange websteder dette. I dette tilfælde sendes sådanne cookies automatisk til en forklædt tredjeparts tracker. Som følge heraf kan vi ikke længere tale om noget privatliv.
Det samme sker også med HTTP-headere , som kun sendes til hoveddomænet, da de kan bruges til at oprette bruger. Sørg for, at den CDN-tjeneste, du bruger, filtrerer disse overskrifter korrekt.
Resultaterne af
Hvis du planlægger at implementere selvhosting af tredjepartsressourcer snart, så lad mig give dig nogle tips:
- Vær vært for dine vigtigste JS-biblioteker, skrifttyper og CSS-filer. Dette vil reducere risikoen for webstedsfejl eller ydeevneforringelse på grund af, at en ressource, der er afgørende for webstedet, er utilgængelig på grund af fejl fra en tredjepartstjeneste.
- Før du cacher tredjepartsressourcer på et CDN, skal du sørge for, at der bruges en form for versioneringssystem, når de navngiver deres filer, eller at du kan administrere disse ressourcers livscyklus ved manuelt eller automatisk at nulstille CDN-cachen, når du udgiver en ny version af manuskriptet.
- Vær meget forsigtig med dine CDN-, proxyserver- og cacheindstillinger. Dette vil give dig mulighed for at forhindre, at dit projekt eller overskrifter sendes til cookies
Client-Hintstredjepartstjenester.
Kære læsere! Hoster du andres materialer på dine servere, som er ekstremt vigtige for driften af dine projekter?
Kilde: www.habr.com