The main benefit of having them on a CDN is that the files can be downloaded in parallel to files downloaded from your own website. This reduces latency on every page. So, the flip side of this is a pitfall of hosting locally - increased latency. The main reason for that is that browsers are limited in the number of connections that they can make at the same time to the same web domain. In IE6 this was defaulted to 2 concurrent connections to the same domain - shared between all open windows of IE!! In IE8+ it improved, defaulting to 6, which is inline with FF/Chrome, but still, if you have a lot of images and you are not using sprites, you will experience heavy latency.
Using a CDN, I would always set the library version explicitly rather than getting the latest one. This reduces the risk of new versions breaking your code. Not very likely with jQuery, but possible.
The other main benefit of using a CDN is reduced traffic on your site. If you pay per GB or you are on a virtual server with limited resources, you might find that overall site performance increases and hosting costs come down when you farm off some of your content to a public CDN.
Make sure you also read the other answer to this question by @Xaver. This is a very good trick
在包含来自第三方的任何脚本之前(即使是在站点的单个页面上),您必须 100% 信任它们,并拥有该主机名上可见的所有用户可访问功能(包括面向 Web 的管理功能)。
Others have covered the benefits. Pitfalls:
If you only include content from your own server, that's one server that needs to be running—and not blocked by firewalls etc—to make your site work. Pull script from a third party and now that's two servers that need to be running and unblocked to make your site work.
Any site you pull <script> from can completely control the user's experience on your site. If Google were feeling evil they could put something in their copy of jQuery to log your keypresses, steal personal information from the page you're on to tie into their web tracking database, make you post “I love Google!” comments to every form, and so on.
Google probably aren't actually going to do that, but it's a factor that's out of your control, and certainly something to worry about with other script-hosting services. There have been incidents before where stats scripts have been compromised with malware loaders.
Before including any script from a third party—even on one single page of your site—you must 100% trust them with all user-accessible functionality visible on that hostname (including web-facing admin functions).
I prefer to use my local version, because I don't have control about what they will provide. For example I don't want my users to get affected by google-analytics or anything similar, because this is a legal problem in my country.
Virtually every way you look at it, using Google's CDN is a good thing.
Performance will be improved (albeit fairly marginally, unless your site is really busy), and the amount of data your servers have to transmit will go down (although jQuery isn't exactly a massive thing to download), etc.
The only reason you wouldn't want to use it is if you don't trust Google. By using it, you are effectively giving Google an additional window of information into your site's traffic profile, including knowledge of URLs that you may otherwise not want to make public (eg secure areas of your site).
If you are paranoid about security then this may be enough to persuade you not to use them (after all, hosting it yourself isn't exactly going to slow your site down to a crawl), but in general most people would take the pragmatic view that Google knows enough about their site already that adding this won't make much difference.
Probably I'm in minority nowadays, but I'd say that you don't want to use CDN unless you really need to. Key factors to start using it are:
Cross geo users. If you host your website in the US but have visible amount of European users - CDN will improve the loading time.
Big amount of users and\or big content, so one main server is not enough any more. One can think of any porn-video website (or Netflix, if you want). Video stream is a heavy load, with CDN would be much much less load on the main server.
But... the point is that these points are not really applicable to 90% of websites in the world. I bet you're not Facebook with millions of online users around the globe, you're not Pornhub with hundreds of GB transferred every second.
If your website is targeted to users in your city/country and capacity of one server is enough for amount of users you have - why would you ever want a CDN? It's quicker for your users in your city and simpler for you to fetch everything from your main server locally.
It was more about CDNs in general, now let me be closer to the actual question about jQuery or any other library.
If you want your website to stay accessible and working without maintenance for more than a year, let's say - put it locally. Libraries nowadays are being updated in a crazy tempo which you probably don't want to follow. And old versions are being deleted eventually. Moreover, the whole library can die (probably not applicable to jQuery though).
From my recent experience - I updated TinyMCE on the website I maintain from 3.x.x (dated 2012) to 5.x.x (dated Spring 2019). This website was working for 7(seven!) years without any maintenance in this part of the logic. There was no "minifying" concept back then and CDNs were not as common as now. But even if they would be common - you never know what will happen in 3-5-10 years from now. Usually you want your website to stay alive even without you maintaining it, don't you? However if you pull jQuery from CDN today, then this link may (and, probably, will) break in 5 years.
Solution with CDN AND fallback to local version as @Xaver suggested can be a good compromise. But... maybe just get rid of CDN link? ;)
对我来说,这实际上取决于您想要拥有多少控制权。如果你像我一样,在工作和旅行时需要在本地主机上发展。将 jquery 文件放在本地比将其托管在 google 或其他地方要好。
To me it really depends on how much control you desire to have. If you are like me and need to develop on local host when working and traveling. Having the jquery files local is better than having it hosted on google or else where.
发布评论
评论(9)
我总是使用 Google 的 CDN(内容分发网络)。但以防万一它处于离线状态:
获取 Google CDN 的 jQuery,并在必要时回退到本地
编辑:
如果您不需要支持 IE6 并且您的网站有部分 https 使用,您也可以删除 http:
I always use the CDN (Content Delivery Network) from Google. But just in case it's offline:
Grab Google CDN's jQuery and fallback to local if necessary
Edit:
If you don't need to support IE6 and your site has partial https usage you can remove the http as well:
将它们放在 CDN 上的主要好处是可以与从您自己的网站下载文件并行下载这些文件。这减少了每个页面上的延迟。因此,另一方面是本地托管的陷阱 - 延迟增加。主要原因是浏览器可以同时与同一 Web 域建立的连接数量受到限制。在 IE6 中,这默认为同一个域的 2 个并发连接 - 在 IE 的所有打开窗口之间共享!! 在 IE8+ 中,它得到了改进,默认为 6,这与 FF/Chrome 内联,但仍然,如果您有很多图像并且不使用精灵,您将遇到严重的延迟。
使用 CDN,我总是明确设置库版本,而不是获取最新版本。这降低了新版本破坏代码的风险。对于 jQuery 不太可能,但有可能。
使用 CDN 的另一个主要好处是减少网站流量。如果您按 GB 付费或者您使用的虚拟服务器资源有限,您可能会发现,当您将某些内容转移到公共 CDN 时,网站整体性能会提高,托管成本会下降。
请确保您还阅读了 @Xaver 对此问题的其他答案。这是一个非常好的技巧
The main benefit of having them on a CDN is that the files can be downloaded in parallel to files downloaded from your own website. This reduces latency on every page. So, the flip side of this is a pitfall of hosting locally - increased latency. The main reason for that is that browsers are limited in the number of connections that they can make at the same time to the same web domain. In IE6 this was defaulted to 2 concurrent connections to the same domain - shared between all open windows of IE!! In IE8+ it improved, defaulting to 6, which is inline with FF/Chrome, but still, if you have a lot of images and you are not using sprites, you will experience heavy latency.
Using a CDN, I would always set the library version explicitly rather than getting the latest one. This reduces the risk of new versions breaking your code. Not very likely with jQuery, but possible.
The other main benefit of using a CDN is reduced traffic on your site. If you pay per GB or you are on a virtual server with limited resources, you might find that overall site performance increases and hosting costs come down when you farm off some of your content to a public CDN.
Make sure you also read the other answer to this question by @Xaver. This is a very good trick
其他人已经涵盖了这些好处。陷阱:
如果您仅包含来自您自己的服务器的内容,则该服务器需要运行(并且不被防火墙等阻止)才能使您的网站正常运行。从第三方提取脚本,现在需要运行两台服务器且不受阻止才能使您的网站正常运行。
您从中提取
的任何网站都可以完全控制用户在您网站上的体验。如果谷歌感到邪恶,他们可以在他们的 jQuery 副本中放入一些东西来记录你的按键,从你所在的页面窃取个人信息并与他们的网络跟踪数据库联系起来,让你发布“我爱谷歌!”对每个表单的评论等等。
谷歌实际上可能不会这样做,但这是一个你无法控制的因素,当然对于其他脚本托管服务来说也是值得担心的。之前曾发生过统计脚本被恶意软件加载程序破坏的事件。
在包含来自第三方的任何脚本之前(即使是在站点的单个页面上),您必须 100% 信任它们,并拥有该主机名上可见的所有用户可访问功能(包括面向 Web 的管理功能)。
Others have covered the benefits. Pitfalls:
If you only include content from your own server, that's one server that needs to be running—and not blocked by firewalls etc—to make your site work. Pull script from a third party and now that's two servers that need to be running and unblocked to make your site work.
Any site you pull
<script>
from can completely control the user's experience on your site. If Google were feeling evil they could put something in their copy of jQuery to log your keypresses, steal personal information from the page you're on to tie into their web tracking database, make you post “I love Google!” comments to every form, and so on.Google probably aren't actually going to do that, but it's a factor that's out of your control, and certainly something to worry about with other script-hosting services. There have been incidents before where stats scripts have been compromised with malware loaders.
Before including any script from a third party—even on one single page of your site—you must 100% trust them with all user-accessible functionality visible on that hostname (including web-facing admin functions).
Google CDN:
本地:
Google CDN:
Locally:
我更喜欢使用本地版本,因为我无法控制他们将提供的内容。
例如,我不希望我的用户受到谷歌分析或类似内容的影响,因为这在我的国家/地区是一个法律问题。
I prefer to use my local version, because I don't have control about what they will provide.
For example I don't want my users to get affected by google-analytics or anything similar, because this is a legal problem in my country.
优点:(特别适用于 Google 的 CDN)
Benefits: (Specifically for Google's CDN)
事实上,无论从哪个角度来看,使用 Google 的 CDN 都是一件好事。
将会得到改善(尽管幅度相当小,除非您的站点真的很忙),并且您的服务器必须传输的数据量将会下降(尽管 jQuery 并不是一个需要下载的大东西),等等。
性能 如果您不信任谷歌,就不会想使用它。通过使用它,您可以有效地为 Google 提供一个额外的信息窗口来了解您网站的流量概况,包括您可能不想公开的 URL 信息(例如网站的安全区域)。
如果您对安全性有疑虑,那么这可能足以说服您不要使用它们(毕竟,自己托管并不会让您的网站速度慢下来),但一般来说,大多数人会采取务实的观点谷歌已经足够了解他们的网站,添加这个不会有太大区别。
Virtually every way you look at it, using Google's CDN is a good thing.
Performance will be improved (albeit fairly marginally, unless your site is really busy), and the amount of data your servers have to transmit will go down (although jQuery isn't exactly a massive thing to download), etc.
The only reason you wouldn't want to use it is if you don't trust Google. By using it, you are effectively giving Google an additional window of information into your site's traffic profile, including knowledge of URLs that you may otherwise not want to make public (eg secure areas of your site).
If you are paranoid about security then this may be enough to persuade you not to use them (after all, hosting it yourself isn't exactly going to slow your site down to a crawl), but in general most people would take the pragmatic view that Google knows enough about their site already that adding this won't make much difference.
也许我现在属于少数派,但我想说除非确实需要,否则你不想使用 CDN。开始使用它的关键因素是:
但是……重点是,这些观点并不真正适用于世界上 90% 的网站。我敢打赌,您不是在全球拥有数百万在线用户的 Facebook,也不是每秒传输数百 GB 数据的 Pornhub。
如果您的网站面向您所在城市/国家/地区的用户,并且一台服务器的容量足以满足您拥有的用户数量,那么您为什么需要 CDN?对于您所在城市的用户来说,从本地主服务器获取所有内容的速度更快,您也更简单。
一般来说,更多的是关于 CDN,现在让我更接近关于 jQuery 或任何其他库的实际问题。
如果您希望您的网站保持可访问性并且无需维护即可运行一年以上,那么可以将其放在本地。如今,图书馆正在以疯狂的速度更新,您可能不想跟上。旧版本最终会被删除。此外,整个库可能会消失(但可能不适用于 jQuery)。
根据我最近的经验 - 我在我维护的网站上将 TinyMCE 从 3.xx(日期为 2012 年)更新到 5.xx(日期为 2019 年春季)。该网站运行了 7(七!) 年,这部分逻辑没有任何维护。那时还没有“缩小”的概念,CDN 也不像现在那么普遍。但即使它们很常见,你也永远不知道 3-5-10 年后会发生什么。通常,您希望您的网站即使没有维护也能保持活力,不是吗?然而,如果您今天从 CDN 中提取 jQuery,那么此链接可能(并且很可能)会在 5 年后中断。
正如 @Xaver 建议的那样,使用 CDN 并回退到本地版本的解决方案可能是一个很好的折衷方案。但是...也许只是摆脱 CDN 链接? ;)
Probably I'm in minority nowadays, but I'd say that you don't want to use CDN unless you really need to. Key factors to start using it are:
But... the point is that these points are not really applicable to 90% of websites in the world. I bet you're not Facebook with millions of online users around the globe, you're not Pornhub with hundreds of GB transferred every second.
If your website is targeted to users in your city/country and capacity of one server is enough for amount of users you have - why would you ever want a CDN? It's quicker for your users in your city and simpler for you to fetch everything from your main server locally.
It was more about CDNs in general, now let me be closer to the actual question about jQuery or any other library.
If you want your website to stay accessible and working without maintenance for more than a year, let's say - put it locally. Libraries nowadays are being updated in a crazy tempo which you probably don't want to follow. And old versions are being deleted eventually. Moreover, the whole library can die (probably not applicable to jQuery though).
From my recent experience - I updated TinyMCE on the website I maintain from 3.x.x (dated 2012) to 5.x.x (dated Spring 2019). This website was working for 7(seven!) years without any maintenance in this part of the logic. There was no "minifying" concept back then and CDNs were not as common as now. But even if they would be common - you never know what will happen in 3-5-10 years from now. Usually you want your website to stay alive even without you maintaining it, don't you? However if you pull jQuery from CDN today, then this link may (and, probably, will) break in 5 years.
Solution with CDN AND fallback to local version as @Xaver suggested can be a good compromise. But... maybe just get rid of CDN link? ;)
对我来说,这实际上取决于您想要拥有多少控制权。如果你像我一样,在工作和旅行时需要在本地主机上发展。将 jquery 文件放在本地比将其托管在 google 或其他地方要好。
To me it really depends on how much control you desire to have. If you are like me and need to develop on local host when working and traveling. Having the jquery files local is better than having it hosted on google or else where.