Google jQuery värdbibliotek – är det bra?

Det finns två stora fördelar med att använda ett externt CDN som Google för att vara värd för jQuery:

1. Det är snabbare. Det kommer säkert att vara vara snabbare än din webbplats, och förmodligen snabbare än något CDN du själv ställer in.
2. Det kan vara att redan är cachat . Många webbplatser hänvisar också till jQuery på Googles CDN, så om de besökte en annan webbplats med den före din behöver de inte ens ladda ner den.

Potentiellt nackdelar:

1. -domänen kan blockeras (detta är ganska vanligt på platser som Kina Du kan lösa detta genom att ha en lokal reserv ( se han re för hur ).
2. -fragmenteringen av versionsnumren är ganska hög, så besökare på din webbplats kan ha många olika versioner cachade, men inte den du refererade till ( se här för ny statistik ). Det här är dock bara ett problem vid första sidans laddning.

Kommentarer

• Kan du lägga upp en referens för hur du skapar en lokal reserv?
• Som Zistolen påpekar tidigare är en annan fördel att den kommer att ladda ner parallellt med andra tillgångar på dina webbplatser. Du kanske vill lägga till det också i det här annars fantastiska svaret.
• Att ’ är lite vilseledande. Webbläsare laddar ner tillgångar parallellt oavsett var de är värd, men det finns en gräns för antalet saker som de ’ laddar ner från samma värd samtidigt.
• Jag hoppade över att det ärligt ’ varken här eller där – filen kan laddas ner parallellt men den ’ är också en ytterligare DNS-sökning. Plus, oavsett vilken tidsskillnad någon av dessa gör är försumbar ändå.
• Rättvis. Men vid snabba anslutningar kan det inte resultera i en snabbare total laddningstid, eftersom mer av ” röret ” kan användas?

En annan nackdel:

Med hjälp av ett CDN kan CDN-operatören spåra webbplatsens besökare. Därför kostar de inte pengar.

Kommentarer

• Spårning är säker, men inte besökare: båda jquery ’ s egna och google ’ s jquery CDN är värd på domäner som inte ’ t anger eller använder cookies (detta är förmodligen också en prestandaoptimering), och det finns ’ ingen riktigt identifierbar information i begäran. CDN-leverantören kan få en uppfattning om IP-adresser och viss statistik om användaragentsträngar och referenser. Detta är förmodligen värdefullt, men det ’ är inte i sig en enorm integritetsrisk (om dessa poster var korrelerade med en annan databas – säg personliga annonser som visas vid liknande tidpunkter – då kan det kanske vara ett sätt att spåra).
• Jag tror att det kan tas för givet (när det gäller google) att data är korrelerade med andra databaser, eftersom nästan alla använder google för att söka hela tiden. Samma sak med google-teckensnitt: Jag har nyligen försökt att självhålla teckensnitten på en server, men fick reda på att det är väldigt svårt att göra det. Google förbjuder inte det (öppen källkod), men de ’ t ger dig filerna på ett färdigt sätt: Du kan antingen kompilera dem själv (men det finns ingen makefile), eller så kan du smida förfrågningar till servrarna som används för att leverera dem normalt. Båda är inte genomförbara för en icke-tekniker.
• Kanske. Jag har ’ ingen insiderinformation, så det är ’ svårt att säga säkert. Jag ’ är säker på att det ’ kommer att vara buggig och har stora luckor, dock: De flesta platser jag använder internet är NATed, och flera har en hel del användare med liknande maskiner (troligen identiska UA-strängar) – det ’ d är omöjligt att veta vilken begäran kommer från vem. Och naturligtvis vad med adsense och sociala delningsknappar, de kan ha ett mer tillförlitligt medel nästan alltid, så jag kan föreställa mig att de inte ’ bryr sig. När det gäller teckensnitten – Jag ’ har laddat ner dem flera gånger, så jag förstår inte ’ vad du menar med att det här är svårt?
• För att vara tydlig: Jag ’ antar att de flesta webbplatsbesök du kan och kommer att spåras av de stora statssamlarna på grund av sociala delningsknappar (ganska genomgripande) och annonser, som finns nästan överallt. Så jag undrar bara hur värdefullt eventuellt vilseledande information från starkt cachade js-förfrågningar är – jag ’ satsar, inte särskilt, därför antar jag att de inte ’ t bry sig om att personligen identifiera personer som använder CDN-serverad JS.
• Det är inte så cachat som man skulle tro – När man bäddar in teckensnitt på det sätt som Google föredrar genom att infoga en CSS-länk till fonts.googleapis. com, varje sidvy öppnar en anslutning till google (du kan se dem i Firebug). Spelar ingen roll ’ om det är cachat eller inte. När det gäller nedladdningen: Kan du peka på en plats där jag kan ladda ner teckensnitt i högkvalitativt eot-, woff-, ttf- och svg-format (samma versioner som Google levererar, inga externa omvandlare)?

Använda CDN (er) för att skärpa dina beroenden på många sådana servrar i huvudsak representerar en avvägning mellan bandbredd och latens, förutsatt att du bara bryr dig om prestanda.

Jag antar för övrigt att alternativet inte bara är värd för det lokalt, utan att sammanfoga det med en annan lokal begäran – det finns vanligtvis ingen god anledning att inte sammanfoga när du kan.

Om bandbredden är oändlig är det bäst att du INTE skärper, eftersom du kommer att vara lika långsam som din långsammaste tjänst – eftersom latenser inte är helt förutsägbara, med tillräckligt med tjänster, även om de är snabba, du behöver bara lite otur för att orsaka en långsam sidbelastning.

Om latens är 0 kan spridning av din belastning över många servrar förbättra bandbredden genom att använda många servar rs (inte så användbart eftersom sannolikt begränsningarna för bandbredd är nära klienterna, inte servrarna), men ännu viktigare, det kan minska mängden data som överförs något genom att öka cachingens effektivitet.

Det beror på ditt scenario, men jag förväntar mig i allmänhet att latens är mer problem än bandbredd, såvida inte dina skript är galet enorma (vilket jquery inte är). Vid den tidpunkten är det vanligtvis snabbare att vara värd för jquery som en del av en sammanhängande lokal fil.

Anledningar att inte vara värd lokalt är t.ex. när du betalar för bandbredd, eller om du är värd på någon långsam server ( din anslutning till klienten är flaskhalsad på din sida, inte klientens, eller om du vet att dina klienter kommer att ha en riktigt låg bandbredd (low-end dsl eller modem, säg – mobil tenderar att ha fler latensproblem än bandbreddsproblem) , eller dina kunder betalar för bandbredd (t.ex. mobil) och skript är en så märkbar del av att mindre cachning vinner sak (inte troligt).

I vilket fall som helst: mycket mer relevant kommer att vara om du ” har täckt grunderna först; lämpliga cachinghuvuden, sammankoppling, minifiering och gippning (helst med högt kompressionsförhållande). Och här är kärnan: om du GÖR inte T gör det, kommer åtminstone CDN att, så att ”s vinner …

TL; DR: Om du har sammankoppling + minifiering + gzipping + cachning alla täckta, så att servera små skript lokalt går snabbare än från en CDN trots CDN: s bättre prestanda – men bara om du har gjort dina läxor, kanske inte på första sidladdning, och det finns definitivt undantag från denna regel.

Kommentarer

• För övrigt finns det vissa byte-spån som vinns med bara en begäran: rubriker enbart uppgår till nästan 1 kb, vilket vid en nyttolast på 28 k inte är ’ t ingenting. gzip fungerar bättre med mer sammanhang, vilket sparar ytterligare 0,5 k. TCP, DNS, HTTPS-omkostnader kan alla enkelt lägga till en KB här eller där, och värre, RTT ’ s. Att ’ är varför för små filer som detta är ett CDN ett inte som snabbt som du kanske tror.

Med hjälp av det jQuery-värdbiblioteket som Google tillhandahåller tillåter din sida att laddas snabbare. Faktum är att biblioteket laddas samtidigt på din sida istället för efter.

Kommentarer

• Men hur påverkar det sidbelastningen?
• Lokala bibliotek laddas också medan sidan laddas – I båda fallen startar nedladdningen av tillgången när (modern) webbläsare ser kodavsnittet som utlöser nedladdningen, vilket vanligtvis sker innan hela dokumentet laddas ner . Se denna Firebug skärmdump för ett exempel