Under de senaste åren har fler och fler plattformar för att optimera front-end-projekt erbjuder möjligheter för självhosting eller proxy från tredje parts resurser. Akamai låter dig ställa in för självgenererade webbadresser. Cloudflare har Edge Workers-teknik. Fasterzine kan URL:er på sidor så att de pekar på tredjepartsresurser som finns på webbplatsens huvuddomän.
Om du vet att tredjepartstjänsterna som används i ditt projekt inte ändras särskilt ofta, och att processen för att leverera dem till kunderna skulle kunna förbättras, funderar du förmodligen på att ge sådana tjänster proxy. Med detta tillvägagångssätt kan du mycket väl föra dessa resurser närmare dina användare och få mer fullständig kontroll över deras cachning på klientsidan. Detta låter dig dessutom skydda användare från problem som orsakas av "krasch" av en tredjepartstjänst eller försämring av dess prestanda.
Bra: Förbättrad prestanda
Att själv vara värd för någon annans resurser förbättrar prestandan på ett mycket uppenbart sätt. Webbläsaren behöver inte komma åt DNS igen, den behöver inte upprätta en TCP-anslutning och utföra en TLS-handskakning på en tredjepartsdomän. Du kan se hur självhotell någon annans resurser påverkar prestanda genom att jämföra följande två siffror.
Tredjepartsresurser laddas ner från externa källor (hämtade från )
Tredjepartsresurser lagras på samma plats som resten av webbplatsens material (hämtat från )
Situationen förbättras också av att webbläsaren kommer att använda möjligheten att multiplexa och prioritera data från HTTP/2-anslutningen som redan är etablerad med huvuddomänen.
Om du inte är värd för tredjepartsresurser kan de inte prioriteras, eftersom de kommer att laddas från en annan domän än den huvudsakliga. Detta kommer att få dem att konkurrera med varandra om kundens bandbredd. Detta kan resultera i laddningstider för innehåll som är avgörande för att bygga en sida som är mycket längre än vad som skulle vara möjligt under idealiska omständigheter. prata om HTTP/2-prioritering som förklarar allt detta mycket bra.
Det kan antas att användningen av attribut i länkar till externa resurser preconnect kommer att hjälpa till att lösa problemet. Men om det finns för många av dessa länkar till olika domäner kan det faktiskt överbelasta kommunikationslinjen vid det mest avgörande ögonblicket.
Om du själv är värd för tredjepartsresurser kan du kontrollera hur exakt dessa resurser ges till klienten. Vi pratar nämligen om följande:
- Du kan se till att den datakomprimeringsalgoritm som bäst passar varje webbläsare används (Brotli/gzip).
- Du kan öka cachningstiden för resurser som vanligtvis inte är särskilt långa, även hos de mest kända leverantörerna (till exempel är motsvarande värde för GA-taggen satt till 30 minuter).
Du kan till och med utöka TTL för en resurs till, säg, ett år genom att införliva relevant innehåll i din cachehanteringsstrategi (URL-haschar, versionshantering, etc.). Vi kommer att prata om detta nedan.
▍Skydd mot avbrott i driften av tredjepartstjänster eller avstängning av dem
En annan intressant aspekt av självvärdande tredjepartsresurser är att det låter dig minska riskerna i samband med avbrott i tredjepartstjänster. Låt oss anta att A/B-testlösningen från tredje part som du använder är implementerad som ett blockeringsskript som läses in i huvuddelen av sidan. Det här skriptet laddas långsamt. Om motsvarande skript inte kan laddas kommer sidan att vara tom. Om det tar mycket lång tid att ladda, kommer sidan att dyka upp med en lång fördröjning. Eller anta att projektet använder ett bibliotek som laddats ner från en CDN-resurs från tredje part. Låt oss föreställa oss att denna resurs upplevde ett misslyckande eller blockerades i ett visst land. En sådan situation kommer att leda till en kränkning av webbplatsens logik.
För att ta reda på hur din webbplats fungerar när någon extern tjänst inte är tillgänglig kan du använda SPOF-sektionen på .
SPOF-sektionen på webpagetest.org
▍Hur är det med problem med cachning av material i webbläsare? (tips: det är en myt)
Du kanske tror att användning av offentliga CDN automatiskt skulle leda till bättre resursprestanda, eftersom dessa tjänster har ganska högkvalitativa nätverk och distribueras över hela världen. Men allt är faktiskt lite mer komplicerat.
Låt oss säga att vi har flera olika sajter: website1.com, website2.com, website3.com. Alla dessa webbplatser använder jQuery-biblioteket. Vi kopplar den till dem med till exempel ett CDN - googleapis.com. Du kan förvänta dig att webbläsaren laddar ner och cachelagrar biblioteket en gång och sedan använder det på alla tre webbplatserna. Detta kan minska belastningen på nätverket. Kanske gör det att du kan spara pengar någonstans och hjälpa dig att förbättra resursprestanda. Ur praktisk synvinkel ser allt annorlunda ut. Safari har till exempel en funktion som heter : Cachen använder dubbla nycklar baserat på källan till dokumentet och källan till tredjepartsresursen. bra artikel om detta ämne.
gamla studier и , såväl som nyare Paul Calvano, visar att resurser inte lagras i webbläsarens cacheminne så länge som vi kan förvänta oss: "Det finns ett allvarligt gap mellan cachningstiden för ett projekts egna och tredjepartsresurser. Vi pratar om CSS och webbtypsnitt. Nämligen, 95% av inbyggda typsnitt har en cachetid på mer än en vecka, medan 50% av tredjepartstypsnitt har en cachetid på mindre än en vecka! Detta ger webbutvecklare en övertygande anledning att själva vara värd för teckensnittsfiler!"
Som ett resultat, om du är värd för andras innehåll, kommer du inte att märka några prestandaproblem orsakade av webbläsarcache.
Nu när vi har täckt styrkorna med tredjeparts self-hosting, låt oss prata om hur man kan skilja en bra implementering av detta tillvägagångssätt från en dålig.
The Bad: Djävulen ligger i detaljerna
Att flytta tredjepartsresurser till din egen domän kan inte göras automatiskt utan att säkerställa att sådana resurser är korrekt cachade.
Ett av huvudproblemen här är cachningstid. Till exempel ingår versionsinformation i tredje parts skriptnamn så här: jquery-3.4.1.js. En sådan fil kommer inte att ändras i framtiden, och som ett resultat kommer detta inte att orsaka några problem med cachen.
Men om något versionsschema inte används när man arbetar med filer, kan cachade skript, vars innehåll ändras medan filnamnet förblir oförändrat, bli föråldrade. Detta kan vara ett allvarligt problem, eftersom det till exempel inte tillåter att automatiska säkerhetskorrigeringar läggs till i skript som klienter behöver ta emot så snabbt som möjligt. Utvecklaren måste anstränga sig för att uppdatera sådana skript i cachen. Dessutom kan detta orsaka applikationsfel på grund av att koden som används på klienten från cachen skiljer sig från den senaste versionen av koden som serverdelen av projektet är designad för.
Det är sant att om vi pratar om material som uppdateras ofta (tagghanterare, lösningar för A/B-testning), så är cachelagring av dem med CDN-verktyg en uppgift som kan lösas, men är mycket mer komplex. Tjänster som Commanders Act, en tagghanteringslösning, använder webhooks när de publicerar nya versioner. Detta ger dig möjligheten att tvinga fram en cache-spolning på CDN, eller ännu bättre, möjligheten att tvinga fram en hash- eller URL-uppdatering.
▍Anpassad leverans av material till kunder
Dessutom, när vi pratar om cachning, måste vi ta hänsyn till det faktum att cachningsinställningarna som används på CDN:n kanske inte är lämpliga för vissa tredjepartsresurser. Till exempel kan sådana resurser använda teknik för sniffning av användaragenter (adaptiv visning) för att betjäna specifika webbläsare med versioner av innehåll som är optimerade specifikt för dessa webbläsare. Dessa tekniker förlitar sig på reguljära uttryck, eller en databas med HTTP-huvudinformation, för att ta reda på webbläsarens funktioner. User-Agent. När de väl vet vilken webbläsare de har att göra med, ger de det material som är designat för det.
Här kan du minnas två gudstjänster. Den första är googlefonts.com. Den andra är polyfill.io. Tjänsten Google Fonts tillhandahåller, för en viss resurs, olika CSS-koder, beroende på webbläsarens funktioner (ger länkar till woff2-resurser med unicode-range).
Här är resultaten av ett par Google Fonts-frågor från olika webbläsare.
Google Fonts frågeresultat från Chrome
Resultat av Google Fonts-frågan körd från IE10
Polyfill.io ger webbläsaren endast de polyfills den behöver. Detta görs av prestationsskäl.
Låt oss till exempel ta en titt på vad som händer om du kör följande begäran från olika webbläsare:
Som svar på en sådan begäran från IE10 kommer 34 KB data att tas emot. Och svaret på det, kört från Chrome, kommer att vara tomt.
Arg: Vissa sekretessöverväganden
Denna punkt är sist i ordningen, men inte minst viktig. Poängen är att självhosting av tredjepartsresurser på projektets huvuddomän eller på dess underdomän kan äventyra användarnas integritet och negativt påverka huvudwebbprojektet.
Om ditt CDN-system inte är korrekt konfigurerat kan det sluta med att du skickar din domäns cookies till en tredjepartstjänst. Om korrekt filtrering inte är organiserad på CDN-nivå, då dina sessionscookies, som normalt inte kan användas i JavaScript (med httponly), kan skickas till en utländsk värd.
Detta är precis vad som kan hända med spårare som Eulerian eller Criteo. Tredjepartsspårare kan ha satt en unik identifierare i cookien. Om de ingick i webbplatsens material kunde de läsa identifieraren efter eget gottfinnande medan användaren arbetade med olika webbresurser.
Nuförtiden har de flesta webbläsare skydd mot denna typ av spårningsbeteende. Som ett resultat använder spårare nu teknik , maskerad som sina egna manus för olika projekt. Spårare erbjuder nämligen webbplatsägare att lägga till ett CNAME i sina inställningar för en viss domän, vars adress vanligtvis ser ut som en slumpmässig uppsättning tecken.
Även om det inte rekommenderas att göra webbplatscookies tillgängliga för alla underdomäner (till exempel - *.website.com), gör många webbplatser detta. I det här fallet skickas sådana cookies automatiskt till en förklädd tredjepartsspårare. Som ett resultat kan vi inte längre prata om någon integritet.
Samma sak händer också med HTTP-huvuden , som endast skickas till huvuddomänen, eftersom de kan användas för att skapa användare. Se till att CDN-tjänsten du använder filtrerar dessa rubriker korrekt.
Resultat av
Om du planerar att implementera självvärd för tredjepartsresurser snart, låt mig ge dig några råd:
- Värd för dina viktigaste JS-bibliotek, typsnitt och CSS-filer. Detta kommer att minska risken för webbplatsfel eller prestandaförsämring på grund av att en resurs som är avgörande för webbplatsen inte är tillgänglig på grund av fel från en tredjepartstjänst.
- Innan du cachelagrar resurser från tredje part på ett CDN, se till att något slags versionssystem används när du namnger deras filer, eller att du kan hantera livscykeln för dessa resurser genom att manuellt eller automatiskt återställa CDN-cachen när du publicerar en ny version av manuset.
- Var mycket försiktig med dina inställningar för CDN, proxyserver och cache. Detta gör att du kan förhindra att ditt projekt eller rubriker skickas till cookies
Client-Hintstredjepartstjänster.
Kära läsare! Hostar du andras material på dina servrar som är extremt viktigt för driften av dina projekt?
Källa: will.com