Google jQuery hostet bibliotek – er det noget godt?

Der er to store fordele ved at bruge et eksternt CDN såsom Google til at være vært for jQuery:

1. Det er hurtigere. Det vil helt sikkert være være hurtigere end dit websted og sandsynligvis hurtigere end ethvert CDN, du selv konfigurerer.
2. Det er muligvis allerede cache . Masser af sider henviser til jQuery også på Googles CDN, så hvis de besøgte et andet websted med det før dit, behøver de ikke engang at downloade det.

Potentielt ulemper:

1. domænet kan være blokeret (dette er ret almindeligt steder som Kina Du kan løse dette ved at have en lokal reserve ( se han re for hvordan ).
2. fragmentering af versionsnumre er ret høj, så besøgende på dit websted kan have mange forskellige versioner i cache, men ikke den, du henviste til ( se her for nogle nylige statistikker ). Dette er dog kun et problem ved indlæsning af første side.

Kommentarer

• Kan du sende en reference til, hvordan du opretter en lokal tilbageførsel?
• Som Zistolen påpegede før, er en anden fordel, at den downloader parallelt med dine hjemmesider andre aktiver. Du vil måske også tilføje det til dette ellers fantastiske svar.
• At ‘ er lidt vildledende. Browsere downloader aktiver parallelt uanset hvor de hostes, men der er en grænse for antallet af ting, de ‘ downloader fra samme vært på én gang.
• Jeg sprang det ærligt over ‘ hverken her eller der – filen kan downloades parallelt, men det ‘ er også en ekstra DNS-opslag. Plus, uanset hvilken tidsforskel en af disse gør, er den alligevel ubetydelig.
• Fair nok. Men ved hurtige forbindelser, kan det ikke resultere i en hurtigere total belastningstid, da mere af ” rør ” kan bruges?

En anden ulempe:

Brug af et CDN giver operatøren af CDN mulighed for at spore webstedets besøgende. Derfor koster de ikke penge.

Kommentarer

• Sporing er sikker, men ikke besøgende: begge jquery ‘ s egen og google ‘ s jquery CDN hostes på domæner, der ikke ‘ t indstiller eller bruger cookies (dette er sandsynligvis også en ydeevneoptimering), og der er ‘ ingen rigtig identificerbare oplysninger i anmodningen. CDN-udbyderen kan få en idé om IP-adresser og nogle statistikker om brugeragentstrenge og henvisninger. Dette er sandsynligvis værdifuldt, men det ‘ er ikke i sig selv en enorm privatlivsrisiko (hvis disse poster var korreleret med en anden database – f.eks. Personlige annoncer, der blev vist på lignende tidspunkter – så kunne det måske være et middel til sporing).
• Jeg tror, det kan tages for givet (i tilfælde af google), at dataene er korreleret med andre databaser, da næsten alle bruger google til at søge hele tiden. Samme ting med google skrifttyper: Jeg har for nylig forsøgt at være vært for selv at være vært for skrifttyperne på en server, men fandt ud af, at det er meget svært at gøre det. Google forbyder det ikke (Open Source), men de giver ikke ‘ filerne på en brugsklar måde: Du kan enten kompilere dem selv (men der er ingen makefile), eller du kan smede anmodninger til de servere, der bruges til at levere dem normalt. Begge er ikke gennemførlige for en ikke-tekniker.
• Måske. Jeg har ‘ ikke nogen intern viden, så det er ‘ svært at sige med sikkerhed. Jeg ‘ er sikker på, at det ‘ vil være buggy og have betydelige huller, dog: De fleste steder, jeg bruger internettet, er NATed, og flere har en hel del brugere med lignende maskiner (sandsynligvis identiske UA-strenge) – det ‘ d er umuligt at vide, hvilken anmodning der kommer fra hvem. Og selvfølgelig hvad med adsense og sociale delingsknapper, de kan have en mere pålidelig måde næsten altid, så jeg kan forestille mig, at de ikke ‘ ikke gider. Hvad angår skrifttyperne – jeg ‘ har downloadet dem flere gange, så jeg forstår ikke ‘, hvad du mener med, at det er svært?
• For at være klar: Jeg ‘ Jeg antager, at størstedelen af webstedsbesøg, du besøger, kan og vil blive sporet af de store statssamlere i kraft af sociale delingsknapper (ganske gennemgribende) og annoncer, som næsten er overalt. Så jeg spekulerer bare på, hvor værdifuld muligvis vildledende information fra kraftigt cachede js-anmodninger er – jeg ‘ satser ikke meget, derfor antager jeg, at de ikke ‘ t gider at forsøge at identificere personer, der bruger CDS-serveret JS.
• Det er ikke så cachelagret som man ville tro – Når man indlejrer skrifttyper på den måde, google foretrækker det ved at indsætte et CSS-link til fonts.googleapis. com, hver enkelt sidevisning åbner en forbindelse til google (du kan se dem i Firebug). Betyder ikke ‘ noget, om det er cache eller ikke. Med hensyn til download: Kan du henvise mig til et sted, hvor jeg kan downloade skrifttyperne i høj kvalitet eot-, woff-, ttf- og svg-format (samme versioner, som Google leverer, ingen eksterne konvertere)?

Brug af CDN (er) til at splitte dine afhængigheder på tværs af mange servere som dette repræsenterer i det væsentlige en afvejning mellem båndbredde og latenstid, forudsat at du kun er ligeglad om ydeevne.

Jeg antager i øvrigt, at alternativet ikke bare er vært for det lokalt, men sammenkædning af det med en anden lokal anmodning – der er normalt ingen god grund til ikke at sammenkæde, når du kan.

Hvis båndbredden er uendelig, er det bedst at I IKKE sharding, fordi du vil være lige så langsom som din langsomste service – da ventetid ikke er helt forudsigelig med nok tjenester, selvom de er hurtige, du behøver bare en smule uheld for at forårsage en langsom sideindlæsning.

Hvis latens er 0, kan spredning af din belastning over mange servere forbedre båndbredden ved at bruge mange servere rs (ikke så nyttigt, da båndbreddebegrænsningerne sandsynligvis er tæt på klienterne, ikke serverne), men vigtigere, det kan reducere mængden af data, der transmitteres lidt ved at øge effektiviteten af caching.

Det afhænger af dit scenario, men jeg forventer generelt, at ventetid er mere et problem end båndbredde, medmindre dine scripts er sindssygt enorme (hvilket jquery ikke er). På det tidspunkt er det normalt hurtigere at være vært for jquery som en del af en sammenkædet lokal fil.

Årsager til ikke at være vært lokalt er f.eks. Når du betaler for båndbredde, eller hvis du hoster på en langsom server ( din forbindelse til klienten er flaskehals på din side, ikke klientens, eller du ved, at dine klienter vil have en virkelig lav båndbredde (low-end dsl eller modemer, siger – mobil har tendens til at have flere latenstidsproblemer end båndbreddeproblemer) , eller dine kunder betaler for båndbredde (f.eks. mobil), og scripts er en så mærkbar del af, at mindre caching vinder noget (ikke sandsynligt).

Under alle omstændigheder: langt mere relevant vil være, om du ” har først dækket det grundlæggende; passende cache-overskrifter, sammenkædning, minificering og gzipping (helst med et højt kompressionsforhold). Og her er kernen: Hvis du IKKE gør gør det, så vil i det mindste CDN, så “vinder …

TL; DR: Hvis du har sammenkædning + minifikation + gzipping + caching alt dækket, så servering af små scripts lokalt er hurtigere end fra et CDN på trods af CDNens bedre ydeevne – men kun hvis du har lavet dit hjemmearbejde, muligvis ikke på den første sideindlæsning, og der er bestemt undtagelser fra denne regel.

Kommentarer

• I øvrigt er der nogle byte-barberinger vundet ved kun at bruge en anmodning: overskrifter alene beløber sig til næsten 1 kb, hvilket ved en nyttelast på 28 k ikke er ‘ t ingenting. gzip fungerer bedre med mere kontekst, hvilket sparer yderligere 0,5 k. TCP, DNS, HTTPS-omkostninger kan alle let tilføje en KB her eller der, og værre, RTT ‘ s. At ‘ hvorfor for små filer som dette er en CDN en ikke som hurtigt som du måske tror.

Brug af jQuery hostet bibliotek fra Google tillader, at din side er indlæst hurtigere. Biblioteket indlæses faktisk på samme tid på din side i stedet for efter.

Kommentarer

• Men hvordan påvirker det sidebelastningen?
• Lokale biblioteker indlæses også, mens siden indlæses – I begge tilfælde starter download af aktivet, når (moderne) browseren ser det kodestykke, der udløser download, hvilket normalt sker, før hele dokumentet downloades . Se dette Firebug-skærmbillede for et eksempel