Google jQuery vert bibliotek – er det noe bra?

Det er to store fordeler med å bruke en ekstern CDN som Google for å være vert for jQuery:

1. Det er raskere. Det vil helt sikkert være være raskere enn nettstedet ditt, og sannsynligvis raskere enn noe CDN du selv har satt opp.
2. Det kan være at allerede er bufret . Mange nettsteder refererer også til jQuery på Googles CDN, så hvis de besøkte et annet nettsted med det før ditt, trenger de ikke engang å laste det ned.

Potensial ulemper:

1. domenet kan være blokkert (dette er ganske vanlig på steder som Kina Du kan løse dette ved å ha en lokal reserve ( se han re for how ).
2. fragmentering av versjonsnumrene er ganske høy, så besøkende på nettstedet ditt kan ha mange forskjellige versjoner hurtigbufret, men ikke den du refererte til ( se her for nyere statistikk ). Dette er bare et problem ved førstesidens innlasting.

Kommentarer

• Kan du legge ut en referanse for hvordan du setter opp en lokal tilbakefall?
• Som Zistolen påpeker tidligere, er en annen fordel at den vil laste ned parallelt med andre eiendeler på nettsteder. Det kan være lurt å legge til det også i dette ellers flotte svaret.
• At ‘ er litt misvisende. Nettlesere laster ned eiendeler parallelt uansett hvor de er vert, men det er en grense for antall ting de ‘ laster ned fra samme vert samtidig.
• Jeg hoppet over at det ærlig talt ‘ hverken her eller der – filen kan lastes ned parallelt, men den ‘ er også en ekstra DNS-oppslag. I tillegg er uansett hvilken tidsforskjell noen av disse utgjør ubetydelig uansett.
• Greit nok. Men på raske tilkoblinger, kan det ikke resultere i raskere total belastningstid, siden mer av » pipe » kan brukes?

En annen ulempe:

Ved å bruke et CDN kan operatøren av CDN spore nettstedets besøkende. Derfor koster de ikke penger.

Kommentarer

• Sporing sikkert, men ikke besøkende: begge jquery ‘ s egen og google ‘ s jquery CDN er vert på domener som ikke ‘ t angir eller bruker informasjonskapsler (dette er sannsynligvis også en ytelsesoptimalisering), og ‘ er ingen virkelig identifiserbar informasjon i forespørselen. CDN-leverandøren kan få en ide om IP-adresser og litt statistikk over brukeragentstrenger og referanser. Dette er sannsynligvis verdifullt, men det ‘ er ikke i seg selv en enorm personvernrisiko (hvis disse postene ble korrelert med en annen database – si personlige annonser som ble vist på lignende tidspunkter – så kanskje det kan være et middel til sporing).
• Jeg tror det kan tas for gitt (når det gjelder google), at dataene er korrelert med andre databaser, siden nesten alle bruker google til å søke hele tiden. Det samme med google-skrifter: Jeg har nylig prøvd å være vert for fontene på en server, men fant ut at det er veldig vanskelig å gjøre det. Google forbyr det ikke (åpen kildekode), men de gir ikke ‘ filene på en klar måte å bruke: Du kan enten kompilere dem selv (men det er ingen makefile), eller du kan forfalske forespørsler til serverne som brukes til å levere dem normalt. Begge kan ikke gjøres for en ikke-tekniker.
• Kanskje. Jeg har ikke ‘ noe innsideinformasjon, så det er vanskelig å si helt sikkert ‘. Jeg ‘ er sikker på at det ‘ vil være buggy og har store hull, men: De fleste steder jeg bruker internett er NATed, og flere har ganske mange brukere med lignende maskiner (sannsynligvis identiske UA-strenger) – det ‘ d ville være umulig å vite hvilken forespørsel som kommer fra hvem. Og selvfølgelig hva med adsense og sosiale delingsknapper, de kan ha et mer pålitelig middel nesten alltid, så jeg kan forestille meg at de ikke bryr seg ‘. Når det gjelder skriftene – jeg har ‘ lastet dem ned flere ganger, så jeg forstår ikke ‘ hva du mener med at dette er vanskelig?
• For å være tydelig: Jeg ‘ antar at de fleste nettstedsbesøk du gjør kan og vil bli sporet av de store statssamlerne i kraft av sosiale delingsknapper (ganske gjennomgripende) og annonser, som er omtrent overalt. Så jeg lurer bare på hvor verdifullt mulig misvisende informasjon fra kraftig bufret js-forespørsler er – jeg ‘ satser, ikke veldig, derfor antar jeg at de ikke ‘ t bry å prøve å identifisere personer som bruker CDS-servert JS.
• Det er ikke så hurtigbufret som man skulle tro – Når du legger inn skrifttyper på den måten google foretrekker det ved å sette inn en CSS-kobling til fonts.googleapis. com, hver enkelt sidevisning åpner en forbindelse til google (du kan se dem i Firebug). Spiller ingen rolle ‘ om den er hurtigbufret eller ikke. Når det gjelder nedlastingen: Kan du peke meg til et sted hvor jeg kan laste ned skriftene i høykvalitets eot-, woff-, ttf- og svg-format (samme versjoner google leverer, ingen eksterne omformere)?

Bruk av CDN (er) for å skjære avhengighetene dine over mange servere som dette, representerer i hovedsak en avveining mellom båndbredde og ventetid, forutsatt at du bare bryr deg om ytelse.

Jeg antar forresten at alternativet ikke bare er å være vert for det lokalt, men sammenkoble det med en annen lokal forespørsel – det er vanligvis ingen god grunn til ikke å sammenkoble når du kan.

Hvis båndbredden er uendelig, er det best du IKKE deler, fordi du vil være like treg som din tregeste tjeneste – siden ventetider ikke er helt forutsigbare, med nok tjenester, selv om de er raske, du trenger bare en bit uflaks for å forårsake treg sideinnlasting.

Hvis ventetiden er 0, kan spredning av belastningen over mange servere forbedre båndbredden ved å bruke mange servere rs (ikke så nyttig siden sannsynligvis er båndbreddebegrensningene nær klientene, ikke serverne), men enda viktigere, det kan redusere mengden data som overføres litt ved å øke effektiviteten til caching.

Det avhenger av scenariet ditt, men jeg forventer generelt at ventetid er mer et problem enn båndbredde, med mindre manusene dine er sinnsykt store (hvilket jquery ikke er). På det tidspunktet er det vanligvis raskere å være vert for jquery som en del av en sammenkoblet lokal fil.

Årsaker til ikke å være vert lokalt er f.eks. Når du betaler for båndbredde, eller hvis du hoster på en langsom server ( forbindelsen din til klienten er flaskehals på din side, ikke klientene, eller du vet at kundene dine vil ha en veldig lav båndbredde (low-end dsl eller modemer, si – mobil har en tendens til å ha flere latensproblemer enn problemer med båndbredde) , eller kundene dine betaler for båndbredde (f.eks. mobil) og skript er en så merkbar del av at mindre caching vinner noe (ikke sannsynlig).

I alle fall: langt mer relevant vil være om du » har dekket det grunnleggende først; passende caching-topptekster, sammenkobling, minifisering og gipping (helst med høyt kompresjonsforhold). Og her «er kjernen: Hvis du IKKE T gjør det, vil i det minste CDN, slik at» vinner …

TL; DR: Hvis du har sammenkobling + minifisering + gzipping + caching alt dekket, så servering av små skript lokalt er raskere enn fra CDN til tross for CDNs bedre ytelse – men bare hvis du har gjort leksene dine, muligens ikke på den første sideinnlasting, og det er absolutt unntak fra denne regelen.

Kommentarer

• Forresten er det noen byte-spon som er vunnet ved å bruke bare en forespørsel: overskrifter alene utgjør nesten 1 kb, som på en nyttelast på 28 k ikke er ‘ t ingenting. gzip fungerer bedre med mer kontekst, noe som sparer ytterligere 0,5 k. TCP, DNS, HTTPS overhead kan alle enkelt å legge til en KB her eller der, og verre, RTT ‘ s. At ‘ er grunnen til at for små filer som dette er en CDN en ikke som raskt som du kanskje tror.

Ved å bruke det jQuery-vertsbiblioteket fra Google, kan siden din være lastet raskere. Biblioteket lastes faktisk inn på siden din i stedet for etter.

Kommentarer

• Men hvordan påvirker det sidelastningen?
• Lokale biblioteker lastes også inn mens siden lastes inn – I begge tilfeller starter nedlasting av eiendelen når (moderne) nettleser ser kodebiten som utløser nedlastingen, noe som vanligvis skjer før hele dokumentet lastes ned . Se dette Firebug-skjermbildet for et eksempel