javascript CDN 上的多个文件与本地一个文件
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/21099528/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Multiple files on CDN vs. one file locally
提问by Tzach
My website uses about 10 third party javascript libraries like jQuery, jQuery UI, prefixfree, a few jQuery plugins and also my own javascript code. Currently I pull the external libraries from CDNs like Google CDN and cloudflare. I was wondering what is a better approach:
我的网站使用了大约 10 个第三方 javascript 库,如 jQuery、jQuery UI、prefixfree、一些 jQuery 插件以及我自己的 javascript 代码。目前,我从 Google CDN 和 cloudflare 等 CDN 中提取外部库。我想知道什么是更好的方法:
- Pulling the external libraries from CDNs (like I do today).
- Combining all the files to a single js and a single css file and storing them locally.
- 从 CDN 中提取外部库(就像我今天所做的那样)。
- 将所有文件合并为一个 js 和一个 css 文件并将它们存储在本地。
Any opinions are welcome as long as they are explained. Thanks :)
只要得到解释,任何意见都是受欢迎的。谢谢 :)
回答by Barney
The value of a CDN lies in the likelihood of the user having already visited another site calling that same file from that CDN, and becomes increasingly valuable depending on the size of the file. The likelihood of this being the case increases with the ubiquity of the file being requested and the popularity of the CDN.
CDN 的价值在于用户可能已经访问过另一个站点,从该 CDN 调用相同的文件,并且根据文件的大小变得越来越有价值。随着所请求文件的普遍性和 CDN 的普及,这种情况的可能性会增加。
With this in mind, pulling a relatively large and popular file from a popular CDN makes absolute sense. jQuery, and, to a lesser degree, jQuery UI, fit this bill.
考虑到这一点,从流行的 CDN 中提取相对较大且流行的文件是绝对有意义的。jQuery,以及在较小程度上的 jQuery UI,都符合这个要求。
Meanwhile, concatenating files makes sense for smaller files which are not likely to change much — your commonly used plugins will fit this bill, but your core application-specific code probably doesn't: it might change from week to week, and if you're concatenating it with all your other files, you'd have to force the user to download everything all over again.
同时,连接文件对于不太可能发生太大变化的较小文件是有意义的——您常用的插件符合这个要求,但您的核心应用程序特定代码可能不适合:它可能每周都在变化,如果你将它与所有其他文件重新连接,您必须强制用户重新下载所有内容。
The HTML5 boilerplatedoes a pretty good job of providing a generic solution for this:
HTML5 样板在为此提供通用解决方案方面做得非常好:
- Modernizr is loaded from local in the head: it's very small and differs quite a lot from instance to instance, so it doesn't make sense to source it from a CDN and it won't hurt the user too much to load it from your server. It's put in the head because CSS may be making use of it, so you want it's effects to be known before the body renders. Everything else goes at the bottom, to stop your heavier scripts blocking rendering while they load and execute.
- jQuery from the CDN, since almost everyone uses it and it's quite heavy. The user will probably already have this cached before they visit your site, in which case they'll load it from cache instantly.
- All your smaller 3rd party dependencies and code snippets that aren't likely to change much get concatenating into a
plugins.js
file loaded from your own server. This will get cached with a distant expiry header the first time the user visits and loaded from cache on subsequent visits. - Your core code goes in
main.js
, with a closer expiry header to account for the fact that your application logic may change from week to week or month to month. This way when you've fixe a bug or introduced new functionality when the user visits a fortnight from now, this can get loaded fresh while all the content above can be brought in from cache.
- Modernizr 是从本地加载的:它非常小,并且每个实例的差异很大,因此从 CDN 获取它没有意义,并且从您的 CDN 加载它不会对用户造成太大伤害服务器。它放在头部是因为 CSS 可能正在使用它,所以您希望在主体渲染之前知道它的效果。其他所有内容都放在底部,以阻止较重的脚本在加载和执行时阻止渲染。
- 来自 CDN 的 jQuery,因为几乎每个人都使用它,而且它很重。用户在访问您的网站之前可能已经缓存了它,在这种情况下,他们会立即从缓存中加载它。
- 所有不太可能发生太大变化的较小的第 3 方依赖项和代码片段都会连接到
plugins.js
从您自己的服务器加载的文件中。这将在用户第一次访问时使用远程过期标头进行缓存,并在后续访问时从缓存中加载。 - 您的核心代码
main.js
包含在更接近的到期标题中,以说明您的应用程序逻辑可能每周或每月更改的事实。这样,当您在两周后访问用户时修复了错误或引入了新功能时,这可以重新加载,而上述所有内容都可以从缓存中引入。
For your other major libraries, you should look at them individually and ask yourself whether they should follow jQuery's lead, be loaded individually from your own server, or get concatenated. An example of how you might come to those decisions:
对于您的其他主要库,您应该单独查看它们并问问自己它们是否应该遵循 jQuery 的引导,从您自己的服务器单独加载,还是连接在一起。您可能如何做出这些决定的示例:
- Angular is incredibly popular, and very large. Get it from the CDN.
- Twitter Bootstrap is on a similar level of popularity, but you've got a relatively slim selection of its components, and if the user doesn't already have it it might not be worth getting them to download the full thing. Having said that, the way it fits into the rest of your code is pretty intrinsic, and you're not likely to be changing it without rebuilding the whole site — so you may want to keep it hosted locally but keep it's files separate from your main
plugins.js
. This way you can always update yourplugins.js
with Bootstrap extensions without forcing the user to download all of Bootstrap core.
- Angular 非常受欢迎,而且非常大。从 CDN 获取。
- Twitter Bootstrap 的流行程度相似,但您可以选择的组件相对较少,如果用户还没有它,那么让他们下载完整的内容可能不值得。话虽如此,它适合您的其余代码的方式是非常内在的,并且您不可能在不重建整个站点的情况下对其进行更改 - 因此您可能希望将其托管在本地,但将其文件与您的文件分开主要的
plugins.js
。通过这种方式,您可以随时plugins.js
使用 Bootstrap 扩展更新您的扩展,而无需强制用户下载所有 Bootstrap 核心。
But there's no imperative — your mileage may vary.
但是没有必要——您的里程可能会有所不同。