Should I use a local copy of jquery, or should I link to a copy provided by Google or Microsoft? I'm primarily concerned about speed. I've heard that just pulling content from other domains can have performance advantages related to how browsers limit connections. In particular, has anyone benchmarked the speed and latency of Google vs. Microsoft vs. local?
我应该使用jquery的本地副本,还是应该链接到Google或Microsoft提供的副本?我主要关注速度。我听说只是从其他域中提取内容可以获得与浏览器限制连接相关的性能优势。特别是,有没有人对谷歌与微软和本地的速度和延迟进行基准比较?
Also, do I have to agree to any conditions or licenses to link from a third-party?
此外,我是否必须同意从第三方链接的任何条件或许可?
7 个解决方案
#1
11
One advantage would be that a user may already have it cached since another site also linked to a 3rd party.
一个优点是用户可能已经将其缓存,因为另一个站点也链接到第三方。
I've been using google for this and haven't experienced any problems with it so far. You can easily load jQuery using:
我一直在使用谷歌,到目前为止没有遇到过任何问题。您可以使用以下命令轻松加载jQuery:
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("jquery", "1.4");
</script>
#2
7
Anytime you use an asset hosted by a third party you increase the number of possible points of failure in your application. You also risk potential bugs resulting from changes made to the asset (say, fixing a bug or updating to a new version) by the hosting party.
只要您使用由第三方托管的资产,您就会增加应用程序中可能出现的故障点数。您还可能面临主机方对资产所做的更改(例如,修复错误或更新到新版本)所导致的潜在错误。
Page performance can potentially suffer due to latency differences between your site and the host. Network outages between the client and the host can cause your page to fail, as can internet filtering on the part of their ISP. For instance, using code hosted by Google will cause problems for anyone viewing your site from China.
由于您的站点与主机之间的延迟差异,页面性能可能会受到影响。客户端和主机之间的网络中断可能导致您的页面失败,ISP的互联网过滤也会失败。例如,使用Google托管的代码会给从中国查看您网站的任何人带来问题。
It's better for security, performance, stability and version integrity to keep all of your assets in one place. Unless you're running a ridiculously high-traffic site, you shouldn't worry about distributing your content.
将所有资产保存在一个位置,更好的安全性,性能,稳定性和版本完整性。除非您正在运行一个可笑的高流量网站,否则您不必担心分发您的内容。
It's also worth noting that while jQuery isn't exactly a featherweight include, it's not obnoxiously large and, like any JavaScript includes, should be (but is not guaranteed to be) cached by the browser.
同样值得注意的是,虽然jQuery并不是一个轻量级的包含,但它并不是很大,并且像任何JavaScript包含的那样,应该(但不能保证)被浏览器缓存。
#3
6
Most recommendations I have seen have been to use the hosted version of Google or Microsoft etc.
我见过的大多数建议都是使用托管版本的Google或Microsoft等。
Dave Ward has a nice article explaining the reasons.
戴夫沃德有一篇很好的文章解释了原因。
3-reasons-why-you-should-let-google-host-jquery-for-you
- Decreased Latency
- Increased parallelism
- Better caching
See his post for stats.
查看他的帖子了解统计数据。
Dave does point out that you should only do this for Public Facing websites.
戴夫确实指出,你应该只对Public Facing网站这样做。
#4
3
I have been using Google's AJAX library hosting in production for several clients. Works like a charm, and is definitely the best way to go.
我一直在为几个客户使用Google的AJAX库托管。像魅力一样,绝对是最好的方式。
#5
2
I would suggest loading jQuery from the CDN that jQuery provides itself:
我建议从jQuery提供的CDN加载jQuery:
http://code.jquery.com/jquery-1.4.2.min.js
You don't have to sign up for any accounts, the source will download from as close to the user as possible, and you don't have to worry about licensing.
您不必注册任何帐户,源代码将尽可能靠近用户下载,您不必担心许可。
#6
2
I would recommend always hosting your own local copy.
我建议总是托管你自己的本地副本。
- The server could go down.
- The server could change version of the hosted file.
- Your user's could arbitrarily create too much load on the hosted server which they may not be thrilled about.
服务器可能会崩溃。
服务器可以更改托管文件的版本。
您的用户可能会在托管服务器上任意创建过多负载,而这些负载可能并不令人激动。
I think its reasonable to use a hosted link when you are posting sample code you want to "work" without the user having to download jquery.
我认为在发布您希望“工作”的示例代码时,使用托管链接是合理的,而无需用户下载jquery。
#7
2
I would strongly recommend at least trying to use a hosted version of the library for the reasons others have mentioned, but at the same time, I would also recommend using your own hosted version as well.
我强烈建议至少尝试使用托管版本的库,原因是其他人提到的,但与此同时,我也建议使用您自己的托管版本。
It may sound a bit bonkers to use both, but the 3rd party library hosts are not 100% infallible and may go down. In those rare instances, it is nice to be able to have a backup in place, and this is exactly what the HTML5Boilerplate project recommends.
使用两者可能听起来有些疯狂,但第三方库主机并非100%无懈可击,可能会崩溃。在极少数情况下,能够备份到位是很好的,这正是HTML5Boilerplate项目推荐的内容。
Here's the snippet of code from the project that loads jQuery from google's service, and falls back to a locally hosted copy if it fails:
这是项目中从谷歌服务加载jQuery的代码片段,如果失败则返回到本地托管的副本:
<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.5.1.min.js">\x3C/script>')</script>
As far as I can tell, the only possible down-side to this that doesn't exist for either the vanilla "local copy" or "3rd party" strategies is that there is an extra lookup (always) to see if the attempt to load the library from the 3rd party succeeded or not. This is a rediculously small price to pay, however, for all of the benefits this method gives you.
据我所知,对于香草“本地复制”或“第三方”策略而言,唯一可能存在的缺点是,有一个额外的查找(总是)来查看是否尝试是否成功加载第三方库。然而,这是一个非常小的代价,因为这种方法可以为您带来所有好处。
Another up-side is that this same strategy can be used for any multi-server hosting scenario, so you could (and I do) use this for other libraries, such as jQuery UI.
另一个好处是,同样的策略可以用于任何多服务器托管场景,因此您可以(并且我)将其用于其他库,例如jQuery UI。
You can also extend it to use multiple 3rd-parties, so if Google was down, you could fall back to Microsoft's hosted version, and then to your locally hosted copy if needed.
您还可以将其扩展为使用多个第三方,因此如果Google关闭,您可以回退到Microsoft的托管版本,然后根据需要转到本地托管的副本。
Lastly, this approach is also protocol relative, so it works equally well on http and https pages without causing any browser complaints about insecure page elements.
最后,这种方法也是协议相对的,因此它在http和https页面上同样有效,而不会引起浏览器对不安全页面元素的抱怨。
#1
11
One advantage would be that a user may already have it cached since another site also linked to a 3rd party.
一个优点是用户可能已经将其缓存,因为另一个站点也链接到第三方。
I've been using google for this and haven't experienced any problems with it so far. You can easily load jQuery using:
我一直在使用谷歌,到目前为止没有遇到过任何问题。您可以使用以下命令轻松加载jQuery:
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("jquery", "1.4");
</script>
#2
7
Anytime you use an asset hosted by a third party you increase the number of possible points of failure in your application. You also risk potential bugs resulting from changes made to the asset (say, fixing a bug or updating to a new version) by the hosting party.
只要您使用由第三方托管的资产,您就会增加应用程序中可能出现的故障点数。您还可能面临主机方对资产所做的更改(例如,修复错误或更新到新版本)所导致的潜在错误。
Page performance can potentially suffer due to latency differences between your site and the host. Network outages between the client and the host can cause your page to fail, as can internet filtering on the part of their ISP. For instance, using code hosted by Google will cause problems for anyone viewing your site from China.
由于您的站点与主机之间的延迟差异,页面性能可能会受到影响。客户端和主机之间的网络中断可能导致您的页面失败,ISP的互联网过滤也会失败。例如,使用Google托管的代码会给从中国查看您网站的任何人带来问题。
It's better for security, performance, stability and version integrity to keep all of your assets in one place. Unless you're running a ridiculously high-traffic site, you shouldn't worry about distributing your content.
将所有资产保存在一个位置,更好的安全性,性能,稳定性和版本完整性。除非您正在运行一个可笑的高流量网站,否则您不必担心分发您的内容。
It's also worth noting that while jQuery isn't exactly a featherweight include, it's not obnoxiously large and, like any JavaScript includes, should be (but is not guaranteed to be) cached by the browser.
同样值得注意的是,虽然jQuery并不是一个轻量级的包含,但它并不是很大,并且像任何JavaScript包含的那样,应该(但不能保证)被浏览器缓存。
#3
6
Most recommendations I have seen have been to use the hosted version of Google or Microsoft etc.
我见过的大多数建议都是使用托管版本的Google或Microsoft等。
Dave Ward has a nice article explaining the reasons.
戴夫沃德有一篇很好的文章解释了原因。
3-reasons-why-you-should-let-google-host-jquery-for-you
- Decreased Latency
- Increased parallelism
- Better caching
See his post for stats.
查看他的帖子了解统计数据。
Dave does point out that you should only do this for Public Facing websites.
戴夫确实指出,你应该只对Public Facing网站这样做。
#4
3
I have been using Google's AJAX library hosting in production for several clients. Works like a charm, and is definitely the best way to go.
我一直在为几个客户使用Google的AJAX库托管。像魅力一样,绝对是最好的方式。
#5
2
I would suggest loading jQuery from the CDN that jQuery provides itself:
我建议从jQuery提供的CDN加载jQuery:
http://code.jquery.com/jquery-1.4.2.min.js
You don't have to sign up for any accounts, the source will download from as close to the user as possible, and you don't have to worry about licensing.
您不必注册任何帐户,源代码将尽可能靠近用户下载,您不必担心许可。
#6
2
I would recommend always hosting your own local copy.
我建议总是托管你自己的本地副本。
- The server could go down.
- The server could change version of the hosted file.
- Your user's could arbitrarily create too much load on the hosted server which they may not be thrilled about.
服务器可能会崩溃。
服务器可以更改托管文件的版本。
您的用户可能会在托管服务器上任意创建过多负载,而这些负载可能并不令人激动。
I think its reasonable to use a hosted link when you are posting sample code you want to "work" without the user having to download jquery.
我认为在发布您希望“工作”的示例代码时,使用托管链接是合理的,而无需用户下载jquery。
#7
2
I would strongly recommend at least trying to use a hosted version of the library for the reasons others have mentioned, but at the same time, I would also recommend using your own hosted version as well.
我强烈建议至少尝试使用托管版本的库,原因是其他人提到的,但与此同时,我也建议使用您自己的托管版本。
It may sound a bit bonkers to use both, but the 3rd party library hosts are not 100% infallible and may go down. In those rare instances, it is nice to be able to have a backup in place, and this is exactly what the HTML5Boilerplate project recommends.
使用两者可能听起来有些疯狂,但第三方库主机并非100%无懈可击,可能会崩溃。在极少数情况下,能够备份到位是很好的,这正是HTML5Boilerplate项目推荐的内容。
Here's the snippet of code from the project that loads jQuery from google's service, and falls back to a locally hosted copy if it fails:
这是项目中从谷歌服务加载jQuery的代码片段,如果失败则返回到本地托管的副本:
<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.5.1.min.js">\x3C/script>')</script>
As far as I can tell, the only possible down-side to this that doesn't exist for either the vanilla "local copy" or "3rd party" strategies is that there is an extra lookup (always) to see if the attempt to load the library from the 3rd party succeeded or not. This is a rediculously small price to pay, however, for all of the benefits this method gives you.
据我所知,对于香草“本地复制”或“第三方”策略而言,唯一可能存在的缺点是,有一个额外的查找(总是)来查看是否尝试是否成功加载第三方库。然而,这是一个非常小的代价,因为这种方法可以为您带来所有好处。
Another up-side is that this same strategy can be used for any multi-server hosting scenario, so you could (and I do) use this for other libraries, such as jQuery UI.
另一个好处是,同样的策略可以用于任何多服务器托管场景,因此您可以(并且我)将其用于其他库,例如jQuery UI。
You can also extend it to use multiple 3rd-parties, so if Google was down, you could fall back to Microsoft's hosted version, and then to your locally hosted copy if needed.
您还可以将其扩展为使用多个第三方,因此如果Google关闭,您可以回退到Microsoft的托管版本,然后根据需要转到本地托管的副本。
Lastly, this approach is also protocol relative, so it works equally well on http and https pages without causing any browser complaints about insecure page elements.
最后,这种方法也是协议相对的,因此它在http和https页面上同样有效,而不会引起浏览器对不安全页面元素的抱怨。