捆绑 .js 文件与 CDN
为了提高网页的性能，建议我们使用 CDN 来提供
此外，建议我们捆绑 .js 文件，以减少负载时向服务器发出的请求数量。
因此，我们需要坐下来决定是使用 CDN 还是捆绑 .js 文件。
有什么优点和缺点？哪些更有意义？
In order to improve performance of our web pages, we are recommended to use CDNs to serve .js files on our web pages. That makes sense.
Also, we are recommended to bundle our .js files in order to reduce the number of requests which are being made to server on load.
So, we need to sit down and make decision between if we use CDN or bundle .js files.
What are the pros and cons? Which ones make more sense?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为什么不能将它们捆绑并放置在 CDN 中？这不应该是一个人或另一个人的决定吗？
如果您必须选择其中之一，则取决于您包含的
.js文件数量。对于少量文件，我建议 CDN 会更快，而对于大量文件，一组.js文件将 <强>肯定更快。切换的地方是你可以尝试的地方。Why can't you bundle them and place them are the CDN? It should hardly be a decision of one or the other?
If you have to choose one or the other, it depends on how many
.jsfiles you are including. For a small number of files, I'd suggest that a CDN would be quicker, where-as for a greater number of files, a bundle of.jsfiles would definitely be quicker. Where the switch-over would be, is something for you to experiment with.我的回答是：两者。将它们捆绑起来并将其放置在 CDN 上。
这样做的缺点是什么？视情况而定。您的构建流程是什么样的？您可以轻松地实现捆绑和缩小的自动化吗？您使用 Yahoo YUI 或 Google Closure 还是其他东西？
另外，如果有很多依赖于 GUI 的 jQuery，则由于元素/效果/css 的不断变化，可能会产生一些耗时的摩擦。
测试也很重要，因为可能存在缩小的怪癖。
底线：5 个 JavaScript 文件安全捆绑到 1 个文件中 === 减少 4 个请求。
一个页面只有普通的旧 Html 和一个外部 javascript 引用 === 向您的服务器发出 2 个请求。然而，一个页面只有普通的旧 Html 和一个 CDN 上的外部 javascript 引用 === 1 向您的服务器发出请求。
目前我们正在使用 Google Closure 工具。 Google Closure Inspector 可帮助完成以下任务：
My answer: both. Bundle them and place them on a CDN.
The downside of doing this? Depends. What does you build process look like? Can you easily automate the bundling and minification? Are you using Yahoo YUI or Google Closure or something else?
Also, if there is a lot of GUI dependent jQuery there might be some time consuming friction due to constantly changing elements/effects/css.
Testing is important too because due to possible minification quirks.
Bottom line: 5 javascript files safely bundled into 1 file === 4 fewer requests.
A page with just plain old Html and one external javascript reference === 2 requests to your server. However, a page with just plain old Html and one external javascript reference on a CDN === 1 request to your server.
Currently we are using the Google Closure tools. The Google Closure Inspector helps with the following:
正如其他人已经说过的，如果可能的话，答案是两者兼而有之。捆绑（和缩小）可以为您的用户带来好处，因为它可以减少页面重量。 CDN 可以让您的服务器受益，因为您可以减轻工作负担。一般来说，除非您观察到性能问题或者您没有更好的事情可做，否则您不需要优化。
As others have already stated, the answer is both if possible. Bundled (and minifying) gives a benefit to your users because it decreases the page weight. The CDN benefits your servers because you are offloading work. Generally speaking, you need not optimize either unless you have observed performance issues or you just have nothing better to do.
有几件事你需要考虑...
在页面加载初期你需要加载多少 JS，以及你可以推迟多少？
如果您可以延迟加载 JS（例如将其放在页面底部）或像 Google Analytics 那样异步加载它，那么您将最大限度地减少下载 JS 所花费的阻塞 UI 线程的时间。
在弄清楚如何拆分 JS 的负载后，我将处理各种 JS 文件的合并/缩小 - 减少 HTTP 请求是提高性能的关键。
然后考虑迁移到 CDN，并确保 CDN 可以提供压缩的 JS 内容，并允许您设置标头，使其“永久缓存”（如果永久缓存，则需要对文件进行版本控制）。 CDN 有助于减少延迟，但也会通过无 cookie 来减小大小。
您可能需要考虑的其他事情是为静态内容设置一个单独的域，在您整理内容时将其指向您的服务器，然后切换到 CDN如果它看起来值得的话。
安迪
There's a few things you need to think about...
How much of the JS do you need to load early in the page load, and how much can you delay until later?
If you can delay loading JS (e.g. put it at the bottom of the page) or load it asynchronously as Google Analytics does, then you will minimise the amount of time downloading the JS spends blocking the UI thread.
After working out how the load of the JS can be split, I'd deal with the merge / minify of the various JS files - cutting down HTTP requests is key to improving performance.
Then look at moving to the CDN and ensure the CDN can serve the JS content compressed and allow you to set headers so it's "cached forever" (you'll need to version the files if you cache forever). A CDN helps reduce the latency but will also reduce size by being cookieless
Other thing you might want to consider is setting up a separate domain for static content, point it to your server(s) while you sort things out and then switch to a CDN if it looks worthwhile.
Andy