CDN 最佳实践是什么？
我最近开始使用 Rackspace Cloudfiles CDN (Limelight)，对此我有一些疑问：
- 除了自定义 JS 代码之外，我还使用 jQuery、jQuery UI 和 jQuery 工具。另外，我的网站是用 ASP.Net 编写的，这意味着有一些 ASP.Net 生成的 JS 代码。
现在我所做的就是将除 ASP.Net 生成的 JS 之外的所有 js（包括 jquery 代码）合并到一个文件中。我将其托管在 Rackspace CDN 上。
我想知道从 Google 托管的 CDN 获取 jQuery、jQuery UI 文件是否更有意义（我怀疑这在服务这些文件方面会很好，因为它们已经在许多用户的缓存中）？
这意味着一个额外的 HTTP 请求，所以我不确定它是否有帮助。
现在我有多个容器来存放我的资产。例如，在 Rackspace 中我有 3 个容器：JS、CSS 和 Images。这 3 个的 URL 子域都不同。这会导致性能损失吗？我应该只使用一个容器（因此 CDN 需要一个域）吗？
有没有办法从 MS CDN 加载 MS ASP.Net 生成的 JS？按照上述问题，这会影响性能吗？
I have recently started using the Rackspace Cloudfiles CDN (Limelight), about which I have some questions:
- I am using jQuery, jQuery UI and jQuery tools in addition to custom JS code. Also, my site is written in ASP.Net, which means there is some ASP.Net generated JS code.
Right now what I have done is that I have combined all of the js (including the jquery code), except the ASP.Net generated JS into one file. I am hosting this on the Rackspace CDN.
I am wondering if it would make more sense to just get the jQuery, jQuery UI files from the Google hosted CDN (which I suspect would work very well in serving these files, since they will be in many users' cache already)?
This would mean one extra HTTP request, so I'm not sure if it'll help.
Right now I have multiple containers for my assets. For example, in Rackspace I have 3 containers: JS, CSS and Images. The URL subdomain for all 3 is different. Will that lead to a performance penalty? Should I just use one container (and thus one domain for the CDN)?
Is there a way of having the MS ASP.Net generated JS loaded from MS CDN? Would this have a performance hit as per the above question?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
加快网站速度的第一种方法是尽量减少 HTTP 请求（雅虎的最佳实践 ）。因此，如果您已经从 CDN 提供组合的 CSS 文件，那么您就这样做了。一些来自 google 的服务和一些来自 CDN 的服务会增加请求。
不幸的是，您无法将 CSS 和 JS 合并到一个文件中，因此您将陷入 CSS 和 JS 各一个请求的困境。您可能想要验证这些是否以 GZIPPE 形式提供。
就您的图像而言，加快速度的最佳方法是尽可能使用图像精灵。
从不同的域提供文件可能确实有意义，因为这会增加并行下载的数量。 （雅虎关于此的另一篇文章） 。如果你的js & css 只是两个文件，您可以将其放在一个域上，将图像放在另一个域上。
The #1 way to speed up your website is to minimize HTTP requests (Best Practices from Yahoo). So if you already are serving up your combined CSS files from a CDN, you're doing it. Serving some from google and some from your CDN adds requests.
You can't combine CSS and JS into one file unfortunately, so you're going to be stuck with one request each for CSS and JS. You might want to verify that these are served up GZIPPED.
As far as your images are concerned, the best way to speed those up is to use image sprites whenever possible.
It probably does make sense to serve the files from separate domains as this increases the number of parallel downloads. (Another article from yahoo on this). If your js & css are just two files you can probably put this on one domain and your images on another.
将您的资产放在不同的域上绝对是更好的选择。
浏览器从单个主机逐个或按顺序加载 Web 资源。在完成来自同一域的上一个资产之前，他们不会开始请求和下载下一个资产。因此，将主机或域加倍可以将下载速度加快约 100%，因为浏览器可以同时从 2 个不同的域下载内容。
如果您的网站启用了 cookie 或会话，则浏览器每次向域发出请求时都会发送会话 cookie，这种方式是无用的，因为它是静态内容 – 服务器根本不需要 cookie 来提供静态服务图像等内容。这不仅浪费带宽，而且浪费通信时间。为了避免这种情况，请从未启用 cookie 的域提供所有静态内容。
相反，在更新维护 JS 代码的网站上提供 JS 服务可能会变得很棘手，因为您失去了首先针对新框架测试当前 JS 的机会。
Is is definitely better to have your assets on a different domain.
browsers load web assets one by one or sequentially from a single host. They will not start requesting and downloading the next asset until they are finished with the previous one from the same domain. Therefore, doubling the hosts or domains can accelerate the downloading speed by about 100% because browsers can simultaneously download stuff from 2 different domains.
if cookie or session is enabled on your website, the browser would send the session cookie every time it makes a request to the domain, which sort of is useless because it’s static content – the server doesn’t need the cookie at all to serve static content such as images. It’s not only a waste of bandwidth but also a waste of communication time. To avoid this, serve all static content from a domain that is not cookie enabled.
on the contrary having JS served on sites who update the maintain that JS code could become tricky as you lose the chance to first test your current JS against the new frameworks.