Door Google jQuery gehoste bibliotheek – is het goed?

Er zijn twee grote voordelen aan het gebruik van een extern CDN zoals Google om jQuery te hosten:

1. Het is sneller. Het zal zeker sneller zijn dan uw site, en waarschijnlijk sneller dan elk CDN dat u zelf instelt.
2. Het kan al in de cache zijn opgeslagen . Veel sites verwijzen ook naar jQuery op het CDN van Google, dus als ze er eerder een andere site mee hebben bezocht dan die van jou, hoeven ze het niet eens te downloaden.

Potentieel nadelen:

1. Het domein kan worden geblokkeerd (dit komt vrij vaak voor in plaatsen zoals China ). U kunt dit oplossen door een lokale fallback ( zie hij re voor hoe ).
2. De fragmentatie van versienummers is vrij hoog, dus bezoekers van uw site kunnen veel verschillende versies in het cachegeheugen hebben, maar niet de versie waarnaar u verwijst ( zie hier voor enkele recente statistieken ). Dit is echter alleen een probleem bij het laden van de eerste pagina.

Reacties

• Kun je een referentie plaatsen voor het opzetten van een lokale fallback?
• Zoals Zistolen al eerder opmerkte, is een ander voordeel dat het parallel met uw websites andere activa zal downloaden. Misschien wil je dat ook toevoegen aan dit overigens geweldige antwoord.
• Dat ‘ is een beetje misleidend. Browsers downloaden middelen parallel, ongeacht waar ze worden gehost, maar er is een limiet aan het aantal dingen dat ze ‘ in één keer van dezelfde host kunnen downloaden.
• Ik heb dat overgeslagen omdat het ‘ hier noch daar is – het bestand kan parallel worden gedownload, maar het ‘ is ook een extra DNS-lookup. Bovendien is het verschil in tijd dat een van beide maakt, hoe dan ook verwaarloosbaar.
• Redelijk genoeg. Maar kan dit bij snelle verbindingen niet resulteren in een snellere totale laadtijd, aangezien er meer ” pipe ” kan worden gebruikt?

Nog een nadeel:

Door een CDN te gebruiken, kan de operator van het CDN volgen de bezoekers van de site. Daarom kosten ze geen geld.

Reacties

• Tracking zeker, maar niet bezoekers: beide jquery ‘ s eigen en google ‘ s jquery CDN worden gehost op domeinen die niet ‘ cookies instellen of gebruiken (dit is waarschijnlijk ook een prestatie-optimalisatie), en er ‘ is geen echt identificeerbare informatie in het verzoek. De CDN-provider kan een idee krijgen van IP-adressen en enkele statistieken over user-agent-strings en verwijzingen. Dit is waarschijnlijk waardevol, maar ‘ op zichzelf vormt het geen enorm privacyrisico (als deze records zouden worden gecorreleerd met een andere database, bijvoorbeeld gepersonaliseerde advertenties die op vergelijkbare tijdstippen worden weergegeven, dan zou het misschien een middel om te volgen).
• Ik denk dat het als vanzelfsprekend kan worden beschouwd (in het geval van Google) dat de gegevens worden gecorreleerd met andere databases, aangezien bijna iedereen Google gebruikt om de hele tijd te zoeken. Hetzelfde met Google-lettertypen: ik heb onlangs geprobeerd de lettertypen zelf op een server te hosten, maar ontdekte dat het erg moeilijk is om het te doen. Google verbiedt het niet (Open Source), maar ze ‘ bieden u de bestanden niet op een gebruiksklare manier: u kunt ze zelf compileren (maar er is no makefile), of u kunt verzoeken vervalsen naar de servers die worden gebruikt om ze normaal te bezorgen. Beiden zijn niet te doen voor een niet-techneut.
• Misschien. Ik heb ‘ geen voorkennis, dus het is ‘ moeilijk met zekerheid te zeggen. Ik ‘ ben er zeker van dat het ‘ buggy zal zijn en aanzienlijke hiaten vertoont, maar: de meeste plaatsen waar ik internet gebruik zijn NAT, en verschillende hebben nogal wat gebruikers met soortgelijke machines (waarschijnlijk identieke UA-strings) – het ‘ zou onmogelijk zijn om te weten welk verzoek van wie komt. En natuurlijk, wat met adsense- en social sharing-knoppen, ze kunnen bijna altijd een betrouwbaarder middel hebben, dus ik kan me voorstellen dat ze ‘ niet de moeite nemen. Wat betreft de lettertypen – ik ‘ heb die verschillende keren gedownload, dus ik ‘ begrijp niet helemaal wat je bedoelt met dit moeilijk zijn?
• Voor alle duidelijkheid: ik ‘ ga ervan uit dat het merendeel van de websitebezoeken die u aflegt, kunnen en zullen worden bijgehouden door de grote stat-verzamelaars op grond van knoppen voor sociaal delen (behoorlijk doordringend) en advertenties, die bijna overal zijn. Dus ik vraag me af hoe waardevol mogelijk misleidende informatie van zwaar in het cachegeheugen opgeslagen js-verzoeken is – ik ‘ m wedden, niet erg, daarom neem ik aan dat ze ‘ doe niet de moeite om mensen persoonlijk te identificeren met behulp van door CDN bediende JS.
• Het is niet zo in de cache als je zou denken – Bij het insluiten van lettertypen op de manier waarop Google dat verkiest door een CSS-link naar fonts.googleapis in te voegen. com opent elke paginaweergave een verbinding met Google (je kunt ze zien in Firebug). Maakt ‘ niet uit of het in de cache is of niet. Wat betreft de download: kunt u mij naar een plaats wijzen waar ik de lettertypen kan downloaden in eot-, woff-, ttf- en svg-indeling van hoge kwaliteit (dezelfde versies die Google levert, geen externe converters)?

Het gebruik van CDN (s) om uw afhankelijkheden over veel servers te verdelen, vertegenwoordigt in wezen een afweging tussen bandbreedte en latentie, ervan uitgaande dat het u alleen kan schelen over prestaties.

Ik ga er toevallig van uit dat het alternatief niet simpelweg het lokaal hosten is, maar het aaneenschakelt met een ander lokaal verzoek – er is meestal geen goede reden om het niet samen te voegen wanneer je kunt.

Als de bandbreedte oneindig is, kun je het beste NIET sharding gebruiken, want je zult net zo traag zijn als je langzaamste service – aangezien latenties niet perfect voorspelbaar zijn, met voldoende services, zelfs als ze snel zijn, kun je je hebt maar een beetje pech nodig om een langzame pagina te laden.

Als de latentie 0 is, kan het spreiden van je belasting over veel servers de bandbreedte verbeteren door veel service te gebruiken rs (niet zo handig omdat de bandbreedtebeperkingen waarschijnlijk dichtbij de clients liggen, niet de servers), maar wat nog belangrijker is, het kan de hoeveelheid verzonden gegevens enigszins verminderen door de effectiviteit van caching te vergroten.

Het hangt af van je scenario, maar ik verwacht over het algemeen dat latentie meer een probleem is dan bandbreedte, tenzij je scripts waanzinnig groot zijn (wat jQuery niet is). Op dat moment is het meestal sneller om jQuery te hosten als onderdeel van een aaneengeschakeld lokaal bestand.

Redenen om niet lokaal te hosten zijn bijvoorbeeld wanneer u betaalt voor bandbreedte, of wanneer u host op een trage server ( uw verbinding met de client heeft een bottleneck aan uw kant, niet die van de client), of u weet dat uw clients een erg lage bandbreedte hebben (bijvoorbeeld low-end DSL of modems – mobiel heeft meer latency-problemen dan bandbreedteproblemen) , of je klanten betalen voor bandbreedte (bijv. mobiel) en scripts maken zon duidelijk deel uit van dat kleine cachingwinsten van belang zijn (niet waarschijnlijk).

In ieder geval: veel relevanter is of je ” heb eerst de basis behandeld; geschikte caching-headers, aaneenschakeling, minificatie en gzipping (bij voorkeur met een hoge compressieverhouding). En hier is de crux: als je dat DON “T doet, dan zal het CDN dat tenminste doen, dus dat is winnen …

TL; DR: Als u aaneenschakeling + verkleining + gzipping + caching allemaal hebt afgedekt, het lokaal serveren van kleine scripts is sneller dan vanaf een CDN ondanks de betere prestaties van de CDN – maar alleen als je je huiswerk hebt gedaan, mogelijk niet bij de eerste pagina laden, en er zijn zeker uitzonderingen op deze regel.

Reacties

• Overigens zijn er enkele byte-krullen gewonnen door slechts één verzoek te gebruiken: headers alleen bedragen bijna 1kb, wat bij een payload van 28k niet ‘ t niets is. gzip werkt beter met meer context, wat nog eens 0,5k bespaart. TCP, DNS, HTTPS-overhead kan allemaal eenvoudig hier of daar een KB toevoegen, en erger nog, RTT ‘ s. Dat ‘ is waarom voor kleine bestanden zoals deze een CDN een niet zo snel als u misschien denkt.

Door de door jQuery gehoste bibliotheek van Google te gebruiken, kan uw pagina worden sneller geladen. De bibliotheek wordt inderdaad tegelijkertijd met uw pagina geladen in plaats van erna.

Opmerkingen

• Maar hoe beïnvloedt dit het laden van de pagina?
• Lokale bibliotheken worden ook geladen terwijl de pagina wordt geladen – In beide gevallen begint het downloaden van de asset wanneer de (moderne) browser het codefragment ziet dat de download activeert, wat meestal gebeurt voordat het volledige document is gedownload . Zie dit Firebug-screenshot voor een voorbeeld