V posledných rokoch stále viac platforiem na optimalizáciu front-end projektov ponúka možnosti vlastného hosťovania alebo proxy zdrojov tretích strán. Akamai vám umožňuje nastaviť pre samostatne vygenerované adresy URL. Cloudflare má technológiu Edge Workers. Fasterzine môže Adresy URL na stránkach tak, aby odkazovali na zdroje tretích strán umiestnené na hlavnej doméne lokality.
Ak viete, že služby tretích strán používané vo vašom projekte sa veľmi často nemenia a že proces ich poskytovania klientom by sa mohol zlepšiť, pravdepodobne uvažujete o proxy takýchto službách. S týmto prístupom môžete tieto zdroje veľmi dobre priblížiť svojim používateľom a získať úplnejšiu kontrolu nad ich ukladaním do vyrovnávacej pamäte na strane klienta. To vám navyše umožňuje chrániť používateľov pred problémami spôsobenými „zlyhaním“ služby tretej strany alebo znížením jej výkonu.
Dobrý: Zlepšený výkon
Vlastné hostenie zdrojov niekoho iného zlepšuje výkon veľmi zrejmým spôsobom. Prehliadač nemusí znova pristupovať k DNS, nemusí vytvárať TCP spojenie a vykonávať TLS handshake na doméne tretej strany. Porovnaním nasledujúcich dvoch obrázkov môžete vidieť, ako vlastné hosťovanie zdrojov niekoho iného ovplyvňuje výkon.
Zdroje tretích strán sa sťahujú z externých zdrojov (prevzaté z )
Zdroje tretích strán sú uložené na rovnakom mieste ako ostatné materiály lokality (prevzaté z )
Situáciu zlepšuje aj fakt, že prehliadač využije možnosť multiplexovať a uprednostňovať dáta z už vytvoreného HTTP/2 spojenia s hlavnou doménou.
Ak nehostíte zdroje tretích strán, potom ich nemožno uprednostniť, keďže budú načítané z inej domény ako hlavnej. To spôsobí, že budú medzi sebou súťažiť o šírku pásma klienta. To môže viesť k časom načítania obsahu kritického pre vytvorenie stránky, ktoré sú oveľa dlhšie, ako by bolo možné dosiahnuť za ideálnych okolností. hovoriť o prioritizácii HTTP/2, ktorá to všetko veľmi dobre vysvetľuje.
Dá sa predpokladať, že použitie atribútov v odkazoch na externé zdroje preconnect pomôže pri riešení problému. Ak však existuje príliš veľa týchto odkazov na rôzne domény, môže to skutočne preťažiť komunikačnú linku v najdôležitejšom momente.
Ak sami hostíte zdroje tretích strán, môžete ovládať, ako presne sa tieto zdroje poskytujú klientovi. Konkrétne hovoríme o nasledujúcom:
- Môžete zabezpečiť, aby sa použil algoritmus kompresie údajov, ktorý najlepšie vyhovuje každému prehliadaču (Brotli/gzip).
- Môžete zvýšiť čas ukladania do vyrovnávacej pamäte pre zdroje, ktoré zvyčajne nie sú príliš dlhé, dokonca aj u najznámejších poskytovateľov (napríklad zodpovedajúca hodnota pre značku GA je nastavená na 30 minút).
Môžete dokonca predĺžiť TTL pre zdroj napríklad na rok začlenením relevantného obsahu do svojej stratégie správy vyrovnávacej pamäte (haše URL, vytváranie verzií atď.). O tom si povieme nižšie.
▍Ochrana pred prerušením prevádzky služieb tretích strán alebo ich odstavením
Ďalším zaujímavým aspektom vlastného hosťovania zdrojov tretích strán je, že vám umožňuje zmierniť riziká spojené s výpadkami služieb tretích strán. Predpokladajme, že testovacie riešenie A/B tretej strany, ktoré používate, je implementované ako blokovací skript, ktorý sa načítava v sekcii head stránky. Tento skript sa načítava pomaly. Ak sa príslušný skript nenačíta, stránka bude prázdna. Ak načítanie trvá veľmi dlho, stránka sa zobrazí s veľkým oneskorením. Alebo predpokladajme, že projekt používa knižnicu stiahnutú zo zdroja CDN tretej strany. Predstavme si, že tento zdroj zlyhal alebo bol zablokovaný v určitej krajine. Takáto situácia povedie k porušeniu logiky stránky.
Ak chcete zistiť, ako vaša stránka funguje, keď nie je dostupná niektorá externá služba, môžete použiť sekciu SPOF na .
Sekcia SPOF na webpagetest.org
▍A čo problémy s ukladaním materiálov do vyrovnávacej pamäte v prehliadačoch? (nápoveda: je to mýtus)
Možno si myslíte, že používanie verejných CDN by automaticky viedlo k lepšiemu výkonu zdrojov, keďže tieto služby majú pomerne kvalitné siete a sú distribuované po celom svete. Všetko je ale v skutočnosti trochu komplikovanejšie.
Povedzme, že máme niekoľko rôznych stránok: website1.com, website2.com, website3.com. Všetky tieto stránky používajú knižnicu jQuery. Pripájame ho k nim napríklad pomocou CDN – googleapis.com. Môžete očakávať, že prehliadač raz stiahne a uloží knižnicu do vyrovnávacej pamäte a potom ju použije na všetkých troch stránkach. To by mohlo znížiť zaťaženie siete. Možno vám to umožní niekde ušetriť peniaze a pomôže zlepšiť výkon zdrojov. Z praktického hľadiska všetko vyzerá inak. Safari má napríklad funkciu tzv : Vyrovnávacia pamäť používa duálne kľúče na základe zdroja dokumentu a zdroja zdroja tretej strany. dobrý článok na túto tému.
staré štúdie и , ako aj novšie Paul Calvano, ukazujú, že zdroje nie sú uložené vo vyrovnávacej pamäti prehliadača tak dlho, ako by sme mohli očakávať: „Existuje vážna medzera medzi časom ukladania vlastných zdrojov projektu a zdrojov tretích strán do vyrovnávacej pamäte. Hovoríme o CSS a webových fontoch. Konkrétne, 95 % natívnych písiem má životnosť vyrovnávacej pamäte viac ako týždeň, zatiaľ čo 50 % písiem tretích strán má životnosť vyrovnávacej pamäte menej ako týždeň! To dáva webovým vývojárom pádny dôvod hostiť súbory písiem sami!“
Výsledkom je, že ak hosťujete obsah iných ľudí, nezaznamenáte žiadne problémy s výkonom spôsobené ukladaním do vyrovnávacej pamäte prehliadača.
Teraz, keď sme pokryli silné stránky vlastného hosťovania tretej strany, poďme sa rozprávať o tom, ako rozlíšiť dobrú implementáciu tohto prístupu od zlej.
Zlý: Diabol je v detailoch
Presun zdrojov tretích strán do vašej vlastnej domény nie je možné vykonať automaticky bez toho, aby ste sa uistili, že tieto zdroje sú správne uložené vo vyrovnávacej pamäti.
Jedným z hlavných problémov je čas ukladania do vyrovnávacej pamäte. Napríklad informácie o verzii sú zahrnuté v názvoch skriptov tretích strán, ako je tento: jquery-3.4.1.js. Takýto súbor sa v budúcnosti nezmení a v dôsledku toho to nespôsobí žiadne problémy s jeho ukladaním do vyrovnávacej pamäte.
Ak sa však pri práci so súbormi nepoužíva nejaká schéma verzií, skripty uložené vo vyrovnávacej pamäti, ktorých obsah sa mení, zatiaľ čo názov súboru zostáva nezmenený, môžu byť zastarané. To môže byť vážny problém, pretože napríklad neumožňuje pridávať automatizované bezpečnostné záplaty do skriptov, ktoré klienti potrebujú dostať čo najrýchlejšie. Vývojár bude musieť vynaložiť úsilie na aktualizáciu takýchto skriptov vo vyrovnávacej pamäti. Okrem toho to môže spôsobiť zlyhania aplikácie v dôsledku skutočnosti, že kód použitý na klientovi z vyrovnávacej pamäte sa líši od najnovšej verzie kódu, pre ktorý je navrhnutá serverová časť projektu.
Pravda, ak hovoríme o materiáloch, ktoré sa často aktualizujú (správcovia značiek, riešenia pre A/B testovanie), tak ich ukladanie do vyrovnávacej pamäte pomocou nástrojov CDN je úloha, ktorá sa dá vyriešiť, no je oveľa zložitejšia. Služby ako Commanders Act, riešenie správy značiek, používajú webhooky pri zverejňovaní nových verzií. To vám dáva možnosť vynútiť vyprázdnenie vyrovnávacej pamäte na CDN alebo, ešte lepšie, možnosť vynútiť aktualizáciu hash alebo URL.
▍Adaptívne dodávanie materiálov klientom
Okrem toho, keď hovoríme o ukladaní do vyrovnávacej pamäte, musíme vziať do úvahy skutočnosť, že nastavenia ukladania do vyrovnávacej pamäte používané na CDN nemusia byť vhodné pre niektoré zdroje tretích strán. Takéto zdroje môžu napríklad využívať technológiu sniffovania používateľských agentov (adaptívne poskytovanie) na poskytovanie špecifických prehliadačov s verziami obsahu optimalizovanými špeciálne pre tieto prehliadače. Tieto technológie sa spoliehajú na regulárne výrazy alebo databázu informácií hlavičky HTTP, aby zistili možnosti prehliadača. User-Agent. Keď už vedia, s ktorým prehliadačom majú do činenia, dajú mu materiály na to určené.
Tu si môžete spomenúť na dve služby. Prvým je googlefonts.com. Druhým je polyfill.io. Služba Google Fonts poskytuje pre určitý zdroj rôzne kódy CSS v závislosti od možností prehliadača (poskytovanie odkazov na zdroje woff2 pomocou unicode-range).
Tu sú výsledky niekoľkých dopytov Google Fonts vytvorených z rôznych prehliadačov.
Výsledok dopytu Google Fonts z prehliadača Chrome
Výsledok dotazu Google Fonts spusteného z IE10
Polyfill.io poskytuje prehliadaču iba polyfilly, ktoré potrebuje. Toto sa robí z výkonnostných dôvodov.
Pozrime sa napríklad, čo sa stane, ak spustíte nasledujúcu požiadavku z rôznych prehliadačov:
Ako odpoveď na takúto požiadavku vykonanú z IE10 bude prijatých 34 KB dát. A odpoveď na ňu vykonaná z prehliadača Chrome bude prázdna.
Angry: Niektoré aspekty ochrany osobných údajov
Tento bod je posledný v poradí, no v neposlednom rade dôležitý. Ide o to, že self-hosting zdrojov tretích strán na hlavnej doméne projektu alebo na jeho subdoméne môže ohroziť súkromie používateľov a negatívne ovplyvniť hlavný webový projekt.
Ak váš systém CDN nie je správne nakonfigurovaný, môže sa stať, že budete posielať súbory cookie vašej domény službe tretej strany. Ak správne filtrovanie nie je organizované na úrovni CDN, potom vaše súbory cookie relácie, ktoré sa bežne nedajú použiť v JavaScripte (s httponly), môžu byť zaslané zahraničnému hostiteľovi.
To je presne to, čo sa môže stať so sledovačmi ako Eulerian alebo Criteo. Sledovače tretích strán mohli mať v súbore cookie nastavený jedinečný identifikátor. Ak boli súčasťou materiálov lokality, mohli si podľa vlastného uváženia prečítať identifikátor, zatiaľ čo používateľ pracoval s rôznymi webovými zdrojmi.
V súčasnosti väčšina prehliadačov obsahuje ochranu proti tomuto typu správania sledovania. Výsledkom je, že sledovače teraz používajú technológiu , ktoré sa vydávajú za vlastné scenáre pre rôzne projekty. Sledovacie programy totiž ponúkajú vlastníkom stránok pridať CNAME do svojich nastavení pre určitú doménu, ktorej adresa zvyčajne vyzerá ako náhodná sada znakov.
Hoci sa neodporúča sprístupňovať súbory cookie webových stránok všetkým subdoménam (napríklad *.website.com), mnohé stránky to robia. V tomto prípade sa takéto súbory cookie automaticky odošlú do skrytého sledovača tretej strany. Tým pádom sa už nemôžeme baviť o žiadnom súkromí.
To isté sa deje aj s HTTP hlavičkami , ktoré sa posielajú len do hlavnej domény, keďže ich možno použiť na vytvorenie užívateľ. Uistite sa, že služba CDN, ktorú používate, správne filtruje tieto hlavičky.
Výsledky
Ak plánujete čoskoro implementovať vlastné hosťovanie zdrojov tretích strán, dovoľte mi, aby som vám poradil:
- Hostite svoje najdôležitejšie knižnice JS, fonty a súbory CSS. Tým sa zníži riziko zlyhania lokality alebo zníženia výkonu v dôsledku nedostupnosti zdroja životne dôležitého pre lokalitu v dôsledku chyby služby tretej strany.
- Pred uložením zdrojov tretích strán do vyrovnávacej pamäte na CDN sa uistite, že pri pomenovávaní ich súborov sa používa nejaký druh verzovacieho systému, alebo že môžete spravovať životný cyklus týchto zdrojov manuálnym alebo automatickým resetovaním vyrovnávacej pamäte CDN pri publikovaní novej verzie scenár.
- Buďte veľmi opatrní pri nastavení siete CDN, proxy servera a vyrovnávacej pamäte. To vám umožní zabrániť odosielaniu súborov cookie vášho projektu alebo hlavičiek
Client-Hintsslužby tretích strán.
Vážení čitatelia! Hostujete na svojich serveroch materiály iných ľudí, ktoré sú mimoriadne dôležité pre chod vašich projektov?
Zdroj: hab.com