Knihovna hostovaná v Google jQuery – je to dobré?

Použití externí sítě CDN má dvě hlavní výhody. například Google pro hostování jQuery:

1. Je to rychlejší. Určitě to bude být rychlejší než vaše stránky a pravděpodobně rychlejší než jakékoli CDN, které si sami nastavíte.
2. Může být již uloženo v mezipaměti . Mnoho webů odkazuje na jQuery také na CDN Googlu, takže pokud s ním navštívili jiné stránky než ty vaše, nebudou si je muset ani stáhnout.

Potenciál nevýhody:

1. Doména může být blokována (v místech jako Čína je to docela běžné) ). Můžete to vyřešit lokálním záložním řešením ( viz jak na to ).
2. fragmentace čísel verzí je poměrně vysoká, takže návštěvníci vašeho webu mohou mít v mezipaměti mnoho různých verzí, ale ne tu, na kterou jste odkazovali ( zde najdete některé nejnovější statistiky ). Toto je však problém pouze při prvním načtení stránky.

Komentáře

• Můžete zveřejnit odkaz, jak nastavit místní záložní řešení?
• Jak již Zistolen zdůrazňuje, další výhodou je, že bude stahovat souběžně s vašimi webovými stránkami další aktiva. Možná to budete chtít přidat také k této jinak skvělé odpovědi.
• To je ‚ trochu zavádějící. Prohlížeče stahují aktiva paralelně bez ohledu na to, kde jsou hostovány, ale existuje omezený počet věcí, které ‚ stahují najednou ze stejného hostitele.
• Přeskočil jsem, že to upřímně ‚ není ani zde, ani tam – soubor lze stáhnout paralelně, ale ‚ s také další DNS vyhledávání. Navíc je jakýkoli časový rozdíl obou těchto faktorů stejně zanedbatelný.
• Dost spravedlivé. Nemůže to však u rychlých připojení vést k rychlejší celkové době načítání, protože lze použít více “ potrubí „?

Další nevýhoda:

Použití CDN umožňuje operátorovi CDN sledovat návštěvníci stránek. Proto nestojí peníze.

Komentáře

• Sledování jisté, ale ne návštěvníci: oba jquery ‚ vlastní a google ‚ s jquery CDN jsou hostovány na doménách, které ‚ nenastavují ani nepoužívají soubory cookie (to je pravděpodobně také optimalizace výkonu) a v požadavku ‚ nejsou žádné skutečně identifikovatelné informace. Poskytovatel CDN může získat představu o IP adresách a některých statistikách řetězců a odkazů uživatelských agentů. To je pravděpodobně cenné, ale ‚ samo o sobě není velkým rizikem pro ochranu soukromí (pokud by tyto záznamy byly korelovány s jinou databází – řekněme personalizované reklamy zobrazované v podobných časech – pak by to mohlo být a prostředek sledování).
• Myslím, že lze považovat za samozřejmost (v případě google), že data jsou v korelaci s jinými databázemi, protože téměř každý používá google k neustálému vyhledávání. Totéž s písmy Google: Nedávno jsem se pokusil hostovat písma na serveru, ale zjistil jsem, že je velmi těžké to udělat. Google to nezakazuje (Open Source), ale ‚ vám neposkytne soubory v podobě připravené k použití: Můžete je buď zkompilovat sami (ale existuje no makefile), nebo můžete zfalšovat požadavky na servery, které se používají k jejich normálnímu doručování. Oba jsou pro netechnika nemožné.
• Možná. Nemám ‚ žádné vnitřní informace, takže ‚ je těžké říci na jistotu. ‚ jsem si jist, že ‚ budu buggy a budu mít značné mezery: Většina míst, kde používám internet, jsou NATed a některá mají poměrně málo uživatelů s podobnými stroji (pravděpodobně identickými řetězci UA) – je ‚ nemožné zjistit, který požadavek pochází od koho. A samozřejmě co s tlačítky adsense a sdílení na sociálních sítích mohou mít téměř vždy spolehlivější prostředky, takže si dovedu představit, že se neobtěžují. Co se týče písem – stáhl jsem je ‚ několikrát, takže nerozumím tomu, co tím myslíš, že je to těžké? ‚
• Aby bylo jasno: ‚ tak trochu předpokládám, že většina vámi navštěvovaných webových stránek může a bude sledována velkými sběrateli statistik na základě tlačítka sociálního sdílení (docela všudypřítomná) a reklamy, které jsou téměř všude. Zajímalo by mě tedy, jak cenné mohou být zavádějící informace ze silně mezipaměti požadavků JS – sázím ‚ m, ne moc, proto předpokládám, že don ‚ t obtěžovat se snaží osobně identifikovat lidi pomocí CDN obsluhovaných JS.
• Není to tak v mezipaměti, jak by si člověk myslel – Při vkládání písem pomocí způsobu, jakým to Google preferuje, vložením odkazu CSS do fonts.googleapis. com, každé zobrazení stránky otevírá spojení s google (můžete je vidět ve Firebugu). Nezáleží na tom, ‚ zda je v mezipaměti nebo ne. Pokud jde o stahování: Můžete mě nasměrovat na místo, kde si mohu stáhnout písma ve vysoce kvalitním formátu eot, woff, ttf a svg (stejné verze, které Google dodává, žádné externí převaděče)?

Použití CDN k rozdělení vašich závislostí na mnoha serverech, jako je tato, v podstatě představuje kompromis mezi šířkou pásma a latencí, za předpokladu, že vás zajímá o výkonu.

Mimochodem předpokládám, že alternativou není pouze lokální hostování, ale zřetězení s jiným místním požadavkem – obvykle není dobrý důvod nezřetězovat, když můžete.

Je-li šířka pásma nekonečná, pak se vám bude NEJEN SDÍLET, protože budete tak pomalý jako vaše nejpomalejší služba – protože latence nejsou dokonale předvídatelné, s dostatkem služeb, i když jsou rychlé, vy potřebujete jen trochu smůly, abyste způsobili pomalé načítání stránky.

Pokud je latence 0, rozložení zatížení na mnoho serverů může zlepšit šířku pásma využitím mnoha služeb rs (není to užitečné, protože omezení šířky pásma jsou pravděpodobně v blízkosti klientů, nikoli serverů), ale co je důležitější, může mírně snížit množství přenášených dat zvýšením účinnosti ukládání do mezipaměti.

Závisí to na váš scénář, ale obecně očekávám, že latence bude spíše problém než šířka pásma, pokud vaše skripty nejsou šíleně obrovské (což jquery není). V tomto okamžiku je obvykle rychlejší hostovat jquery jako součást zřetězeného místního souboru.

Důvody, proč hostovat lokálně, nejsou, např. Když platíte za šířku pásma, nebo hostujete na nějakém pomalém serveru ( vaše připojení ke klientovi je zúženo na vaší straně, nikoli na straně klienta, nebo víte, že vaši klienti budou mít opravdu nízkou šířku pásma (low-end dsl nebo modemy, řekněme – mobilní zařízení mají tendenci mít více problémů s latencí než problémy se šířkou pásma) , nebo vaši klienti platí za šířku pásma (např. mobilní zařízení) a skripty jsou tak výraznou součástí, že na nich záleží na menší ukládání do mezipaměti (není pravděpodobné).

V každém případě: mnohem důležitější bude, zda vy “ Nejdříve jsme pokryli základy; vhodné záhlaví ukládání do mezipaměti, zřetězení, minifikace a gzipování (nejlépe s vysokým kompresním poměrem). A tady je podstata: pokud to NEPROVÁDÍTE, pak alespoň CDN, takže to vyhraje …

TL; DR: Pokud máte všechna zřetězení + minifikace + gzipping + ukládání do mezipaměti, pak místní poskytování malých skriptů je rychlejší než z CDN navzdory lepšímu výkonu CDN – ale pouze pokud jste si udělali domácí úkol, možná ne na první načtení stránky a z tohoto pravidla určitě existují výjimky.

Komentáře

• Mimochodem, existují nějaké zkratky bajtů, které byly získány pomocí jediného požadavku: samotné hlavičky dosahují téměř 1 kB, což při užitečném zatížení 28 kB není nic ‚ nic. gzip funguje lépe s více kontexty, což šetří dalších 0,5 kB. Režijní náklady TCP, DNS a HTTPS mohou všichni snadno sem nebo tam přidejte KB, a co je horší, RTT ‚ s. Proto ‚ proč je pro malé soubory, jako je tento, CDN ne jako rychle, jak si možná myslíte.

Použití knihovny hostované jQuery Googlem umožňuje, aby vaše stránka byla načteno rychleji. Knihovna je skutečně načtena současně s vaší stránkou místo po ní.

Komentáře

• Jak to ale ovlivní načtení stránky?
• Při načítání stránky se načítají také místní knihovny – V obou případech se stahování aktiv spustí, když (moderní) prohlížeč uvidí fragment kódu, který spustí stahování, což se obvykle stane před stažením celého dokumentu . Příklad naleznete na tomto snímku obrazovky Firebug