V posledních letech stále více platforem pro optimalizaci frontendových projektů nabízí možnosti samostatného hostování nebo proxy třetích stran. Akamai umožňuje nastavit pro samostatně vytvářené URL. U Cloudflare existuje technologie Edge Workers. Fasterzine může URL na stránkách tak, aby ukazovala na třetí strany, které se nacházejí na hlavní doméně webu.
Pokud víte, že služby třetích stran používané ve vašem projektu se nemění příliš často a že proces jejich dodávání klientům může být vylepšen, určitě přemýšlíte o proxy takových služeb. Takový přístup vám může "přiblížit" tyto zdroje k uživatelům a získat plnou kontrolu nad jejich ukládáním do cache na straně klienta. To navíc chrání uživatele před problémy způsobenými "výpadkem" služby třetí strany nebo zhoršením jejího výkonu.
Dobré: zvýšení výkonu
Samostatné hostování cizích zdrojů zlepšuje výkon zcela zřejmým způsobem. Prohlížeči není potřeba znovu se obracet na DNS, nemusí navazovat TCP spojení a vykonávat TLS handshake na doméně třetí strany. Jak samostatné hostování cizích zdrojů ovlivňuje výkon, lze vidět porovnáním dvou následujících obrázků.
Cizí zdroje se načítají z externích zdrojů (vzal )
Cizí zdroje se ukládají ve stejném místě jako ostatní materiály webu (vzal )
Situaci navíc vylepšuje to, že prohlížeč využije schopnosti multiplexování a prioritizace dat HTTP/2 spojení, které již bylo navázáno s hlavní doménou.
Pokud nebudete mít cizí zdroje umístěny na svém webu, budou se načítat z domény, odlišné od hlavní, a nebude možné je prioritizovat. To povede k tomu, že si budou konkurovat navzájem o šířku pásma klienta. Může se to projevit tím, že doba načítání materiálů, které jsou kriticky důležité pro formování stránky, bude mnohem delší, než doba dosažitelná za ideálních okolností. prezentace o prioritizaci HTTP/2, ve které je to všechno velmi dobře vysvětleno.
Můžeme předpokládat, že použití atributů v odkazech na externí zdroje preconnect pomůže vyřešit problém. Pokud však bude těchto odkazů na různé domény příliš mnoho, může to ve skutečnosti přetížit komunikační linku v nejkritičtějším okamžiku.
Pokud hostingujete externí zdroje sami, můžete řídit to, jak se tyto zdroje klientovi poskytují. A to konkrétně zahrnuje následující:
- Můžete zajistit použití algoritmu komprese dat, který nejlépe vyhovuje každému prohlížeči (Brotli/gzip).
- Můžete zvýšit dobu cachování zdrojů, která je obvykle, i u nejznámějších poskytovatelů, poměrně malá (například odpovídající hodnota pro tag GA je nastavena na 30 minut).
Můžete dokonce prodloužit ukazatel TTL pro zdroj, například na rok, a zahrnout odpovídající materiály do své strategie správy cache (URL-hashe, verzování atd.). O tom budeme hovořit níže.
▍Ochrana před výpadky externích služeb nebo jejich odpojením
Další zajímavý aspekt samostatného hostingu externích zdrojů spočívá v tom, že to umožňuje zmírnit rizika spojená s výpadky externích služeb. Předpokládejme, že použité externí řešení pro A/B testování je implementováno jako blokující skript, který se načítá v hlavičce stránky. Tento skript se načítá pomalu. Pokud se příslušný skript nenačte, stránka zůstane prázdná. Pokud jeho načtení zabere hodně času, stránka se objeví s velkým zpožděním. Nebo předpokládejme, že se v projektu používá knihovna načítaná z externího CDN zdroje. Představme si, že tento zdroj zažil výpadek nebo byl zablokován v nějaké zemi. Taková situace by vedla k narušení logiky fungování webu.
Abyste zjistili, jak váš web funguje v případě nedostupnosti nějaké externí služby, můžete využít sekci SPOF na .
Sekce SPOF na webpagetest.org
▍Jak to vypadá s problémy s cachováním materiálů v prohlížečích? (nápověda: to je mýtus)
Můžete si myslet, že použití veřejných CDN automaticky zlepší výkon zdrojů, protože tyto služby mají dostatečně kvalitní sítě a jsou rozloženy po celém světě. Ale ve skutečnosti je to trochu složitější.
Představme si, že máme několik různých webových stránek: website1.com, website2.com, website3.com. Na všech těchto stránkách používáme knihovnu jQuery. Připojujeme ji pomocí CDN, například – googleapis.com. Mohli bychom očekávat, že prohlížeč ji jednou načte a vyrovná ji do cache, a poté ji použije při práci se všemi třemi weby. To by mohlo snížit zatížení sítě. Možná to někde ušetří a pomůže zlepšit výkon zdrojů. Z praktického hlediska to však vypadá jinak. Například v Safari je implementována funkce zvaná : v cache se používají dvojité klíče založené na zdroji dokumentu a na zdroji třetí strany. dobrý článek na toto téma.
Staré studie a , a také novější Pola Calvano, ukazují, že zdroje nejsou uchovávány v prohlížečových cachech tak dlouho, jak bychom mohli očekávat: „Existuje značný rozdíl mezi dobou cachování vlastních a cizích zdrojů projektu. Jde o CSS a webové fonty. A konkrétně, doba cachování 95% vlastních fontů přesahuje týden, zatímco doba cachování 50% cizích fontů je méně než týden! To dává webovým vývojářům důvod pro samostatné hostování souborů fontů!“
Výsledkem je, že pokud budete hostit cizí materiály, nebudete si všímat problémů s výkonem způsobených prohlížečovým cachováním.
Nyní, když jsme prozkoumali silné stránky samostatného hostování cizích zdrojů, pojďme si promluvit o tom, jak odlišit dobré provedení tohoto přístupu od špatného.
Špatné: ďábel se skrývá v detailech
Přesunutí cizích zdrojů na vlastní doménu nelze provést automaticky, aniž byste se postarali o správné cachování těchto zdrojů.
Jedním z hlavních problémů zde je doba cachování. Například informace o verzích jsou zahrnuty do názvů cizích skriptů přibližně takto: jquery-3.4.1.js. Takový soubor se v budoucnu nezmění, což nezpůsobí žádné problémy s jeho pamětí.
Ale pokud se při práci se soubory nepoužívá nějaká verziová schéma, mohou být kešované skripty, jejichž obsah se mění při nezměněném názvu souboru, zastaralé. To může představovat vážný problém, protože to například neumožňuje automatické provádění oprav zabezpečení ve skriptech, které by měly co nejdříve dostat klienti. Vývojář se bude muset snažit tyto skripty v paměti aktualizovat. Navíc to může způsobit chyby v chodu aplikace, způsobené tím, že kód používaný klientem z paměti se liší od nové verze kódu, na kterou je serverová část projektu nastavena.
Pravda, pokud mluvíme o materiálech, které se často aktualizují (správci značek, řešení pro A/B testování), jejich cachování na CDN je úkol sice řešitelný, ale mnohem složitější. Služby jako Commanders Act, řešení pro správu značek, při publikování nových verzí používají webhooky. To umožňuje organizovat vyprázdnění cache na CDN, nebo co je ještě lepší, umožňuje vyvolání aktualizace hashe nebo verze URL.
▍ Adaptivní poskytování materiálů klientům
Když mluvíme o cache, je třeba také zohlednit skutečnost, že nastavení cache používaná na CDN nemusejí vyhovovat některým externím zdrojům. Například tyto zdroje mohou používat technologii snímání uživatelského agenta (user agent sniffing, adaptive serving) k vydávání konkrétním prohlížečům verze materiálů optimalizovaných speciálně pro tyto prohlížeče. Tyto technologie pro zjištění schopností prohlížeče spoléhají na regulární výrazy nebo databázi, ve které jsou shromážděny informace o HTTP hlavičce. User-Agent. Zjistivše, s jakým prohlížečem mají co do činění, vydávají mu materiály, které jsou pro něj určené.
Můžeme si připomenout dvě služby. První je googlefonts.com. Druhá je polyfill.io. Služba Google Fonts poskytuje pro určitý zdroj různý CSS kód, který závisí na schopnostech prohlížeče (dává odkazy na woff2 zdroje, používající unicode-range).
Tady jsou výsledky několika dotazů na Google Fonts provedených z různých prohlížečů.
Výsledek dotazu na Google Fonts provedený z Chrome
Výsledek dotazu na Google Fonts provedený z IE10
Polyfill.io poskytuje prohlížeči pouze ty polyfily, které potřebuje. Dělá se tak z důvodů výkonnosti.
Například se podívejme, co se stane, pokud provedeme následující dotaz z různých prohlížečů:
Na takový dotaz provedený z IE10 dorazí 34 kB dat. Odpověď na něj provedenou z Chrome bude prázdná.
Zlý: některé úvahy o ochraně soukromí
Tento bod je poslední v pořadí, ale nikoli v důležitosti. Hovoříme o tom, že samostatné hostování externích zdrojů na hlavní doméně projektu nebo na jeho subdoméně může ohrozit soukromí uživatelů a negativně ovlivnit hlavní webový projekt.
Pokud je vaše CDN nastaveno špatně, může to skončit tím, že budete posílat soubory cookies vaší domény externí službě. Pokud na úrovni CDN nebude zajištěno správné filtrování, mohou být vaše relace cookies, které normálně nelze použít v JavaScriptu (s atributem httponly), odeslány na cizí host.
Přesně to se může stát s trackery jako Eulerian nebo Criteo. Externí trackery mohly nastavovat jedinečný identifikátor do souborů cookies. Ty, pokud byly součástí obsahu stránek, mohly číst identifikátor podle svého uvážení při práci uživatele s různými webovými zdroji.
Dnes většina prohlížečů zahrnuje ochranu proti takovému chování trackerů. Výsledkem je, že nyní trackery používají technologii , skrývají se pod vlastními skripty různých projektů. Konkrétně trackery nabízejí majitelům webových stránek, aby přidali do svých nastavení CNAME pro nějakou doménu, jejíž adresa obvykle vypadá jako náhodná posloupnost znaků.
Ačkoli se nedoporučuje, aby byly soubory cookies webové stránky přístupné pro všechny subdomény (například — *.website.com), na mnoha stránkách se to dělá. V takovém případě se takové soubory cookies automaticky odesílají zamaskovanému externímu trackeru. Jako výsledek — o nějakém soukromí již nemůže být řeči.
Kromě toho to stejné platí i pro HTTP hlavičky , které se odesílají pouze hlavní doméně, protože mohou být použity k vytvoření uživatele. Ujistěte se, že použitá CDN služba správně filtruje podobné hlavičky.
Závěry
Pokud plánujete brzy implementovat samostatný hosting cizích zdrojů – dovolte mi poskytnout vám několik rad:
- Hostujte u sebe své nejdůležitější JS knihovny, fonty a CSS soubory. To sníží riziko selhání webu nebo snížení jeho výkonu v důsledku toho, že zdroj, nezbytný pro funkčnost webu, byl nedostupný vinou externího služby.
- Před tím, než začnete ukládat externí zdroje na CDN, ujistěte se, že při pojmenovávání jejich souborů používáte nějaký systém verzování, nebo že můžete spravovat životní cyklus těchto zdrojů, buď ručně, nebo automaticky vymazáním cache CDN při vydání nové verze skriptu.
- Velmi pečlivě zacházejte s nastavením CDN, proxy serveru a cache. To vám pomůže zabránit odesílání cookies vašeho projektu nebo hlaviček
Client-Hintscizím službám.
Vážení čtenáři! Umisťujete na své servery cizí materiály, které jsou nesmírně důležité pro fungování vašich projektů?
Zdroj: habr.com
