从一个 CDN 或多个 CDNS 加载文件
Posted
技术标签:
【中文标题】从一个 CDN 或多个 CDNS 加载文件【英文标题】:Load files from one CDN or multiple CDNS 【发布时间】:2018-02-12 19:38:58 【问题描述】:在一个典型的网页上,我从 CDN 加载以下内容:
jQuery 角度 引导程序 Icomoon 一些 Angular 插件是从 1 个 CDN(如果可能)还是从不同的 CDN 加载这些内容更好?是否有这方面的最佳做法,还是没有什么影响?
【问题讨论】:
只要使用unpkg.com @georgeawg 建议其他 CDN 并不能真正回答我的问题。 【参考方案1】:就使用一个或多个 CDN 而言,这取决于您从同一主机名下载多少组件,这不是问题,根据article from Yahoo UI Team,HTTP/1.1 建议浏览器应将并行下载限制为每个主机名两个。因此,使用多个 CDN 源,不同的主机名应该是一个好习惯。
如果使用相关组件只是为了避免意外的版本不匹配,例如 angular 和 angular-router,您可能希望使用相同的 CDN,但是,如果每个主机名的下载量增加,它会以同样的方式造成加载泄漏(至少对于遵循规范建议的浏览器而言)。
使用 CDN 绝对是提高网站加载性能的好习惯。但是,您应该考虑使用您能找到的更流行的 CDN,这将增加您从使用相同文件的不同站点获得正在使用的文件的缓存版本的机会,这将进一步提高加载性能网站。
正如@JeffPuckett 在 cmets 中指出的那样,当今浏览器对每个服务器/代理的同时下载有更高的限制:
Firefox 2: 2 Firefox 3+: 6 Opera 9.26: 4 Opera 12: 6 Safari 3: 4 Safari 5: 6 IE 7: 2 IE 8: 6 IE 10: 8 Chrome: 6
参考:https://***.com/a/985704/4488121
【讨论】:
此外,并行主机下载的限制因浏览器而异,超出了 http 规范。 ***.com/q/985431/4233593 确实,根据规范 suggests,borwsers 应该将并行下载限制为每个主机名两个(根据您的链接,只有 firefox 2 和 IE 7),这就是它的原因一个“应该”而不是一个“应该”。这是来自 HTTP/1.1 的建议,规范中不再存在,但兼容 HTTP/1.1 的旧浏览器可能有这个限制。现在的浏览器认为允许更多的并行下载会显着增加加载时间,所以老实说,你必须从同一个 CDN 加载大量文件才能成为问题,例如最多 8 个文件。跨度> 【参考方案2】:恐怕这个问题没有灵丹妙药的答案,因为它通常会发生。这是我的 2 美分。与关注同时连接的数量和浏览器/标准相反,我想从不同的角度来看待它。
对您的用户和服务器来说最重要的是页面加载时间和服务可用性。最快的加载时间是从缓存加载。 您的用户使用特定CDN中的特定文件越多,缓存命中的机会就越大。
基于这个目标,有意义
从流行的 CDN 加载流行的库,取决于库列表可以是相同的 CDN 或不同的 CDN。我认为,浏览器的并行 HTTP 连接数量是次要参数。 将自定义脚本和很少使用的第三方库加入并最小化到尽可能少的文件中(例如单个 CSS 和单个 JS)并从您自己的主机或自己的 CDN 加载(如果您有大量来自不同位置的用户甚至大洲 CDN 对你来说可能都不是奢侈品)。 如果基于 CDN 的脚本由于某种原因未从 CDN 加载,则回退到本地副本。 如果您有该选项,请选择最常用的库版本,这很可能不是最新版本。我会将您可以找到 CDN 和使用统计数据的库分类为受欢迎的,其他的 - 不是那么多,尽管您可以根据其他 recommendations 自行决定在本地托管什么。
对于统计数据,您可能想要使用 w3techs 之类的东西:
jQuery AngularJS Bootstrap可以根据对您的网站受众的一些有根据的猜测在“少数高流量”和“许多低流量”网站之间进行选择,但如果您想确定,您可以尝试测量缓存命中率。这并不简单,但这里有一些idea。
现在,对于版本,您是否可以选择更改版本。如果您决定使用“少数高流量”站点的第一个选项,那么绝对值得检查他们使用的 CDN 库的哪个版本。否则,对于“许多低流量”选项,最受欢迎的版本是可取的。同样的 w3tech 应该有statistics。
这听起来可能很麻烦,但很少这样做(如果不是一次),因为统计数据的变化往往非常缓慢。
【讨论】:
【参考方案3】:接受的答案已经过时了,雅虎的参考文档于 2007 年发布,它与 HTTP/1.1 特别相关。请参阅 HTTP/2 的正确信息:Does the per-host connection limit is raised with HTTP/2?
我会说完全相反。最好从同一主机加载越来越多的资源,在这种情况下是 CDN,如果它支持 HTTP/2。浏览器对 HTTP/2 的支持是pretty high,并且在几年内将达到接近 100%(如果与 HTTP/3 结合使用)。
此外,使用更多 CDN 加载文件也会产生成本:
-
多个 DNS 查找。
每次页面加载多个连接。
不适合移动设备。
现在,回答您的具体问题:
从 1 个 CDN 或不同的 CDN 加载这些更好吗? 由于现在所有的 CDN 默认都支持 HTTP/2,所以如果可能的话,建议使用一个 CDN 来处理越来越多的内容。顺便说一句,有一个 CDN,PageCDN,就是built just to solve 这个附带的域分片问题。它们在单个主机上提供javascript libraries、Fonts 和私有 CDN,以充分利用单个 HTTP/2 连接。
有这方面的最佳做法吗? 最佳做法是: 1. 减少 DNS 查询。 2. 减少连接。比起更多的 CDN/主机,更喜欢更少的 CDN/主机。 3.DO NOT BUNDLE FILES。许多开发人员会建议您捆绑文件,但 Google Chrome V8 团队不建议这样做。 4.使用preconnect meta标签节省连接时间。
没有区别吗? 是的,使用 CDN 会有所不同,因为它可以将其他网站的浏览器缓存用于您的目的,这样即使您的第一次访问者也能获得非常快的页面加载。
【讨论】:
【参考方案4】:您应该避免在单个页面中直接使用多个 CDN 链接,因为它会影响性能。您可以尝试以下代码来添加多个 CDN 链接
bundles.UseCdn = true;
bundles.Add(new ScriptBundle("~/bundles/jquery",
@"//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.10.2.js"
).Include(
"~/Scripts/jquery-version.js"));
它将多个文件合并到一个文件中,它减少了检索和显示网页所需的服务器请求数。
【讨论】:
【参考方案5】:正如其他人已经回答的那样,使用 CDN 是可行的方法 - 但添加更多 CDN 只会扩大到每个 CDN 的 DNS 查找时间可能开始主导总下载时间的程度。
因此,通过尝试加载至少 2 到 6 个资源来最大化每个 CDN 可能是最好的权衡。
【讨论】:
【参考方案6】:现在开始询问大多数浏览器支持 HTTP2 的一个好问题是:我的 CDN 是否支持 HTTP2?如果是这样,通过 1 个 CDN 流水线化这些请求可能会更快。如果其他 CDN 尚未缓存,它还可以保存 DNS 查找。如果 CDN 支持推送,它还可以提高速度,因为其中许多库需要多个文件。
【讨论】:
【参考方案7】:最佳做法是同时使用 CDN 和后备(本地文件)。要回答您的问题,您应该使用多个 CDN 路径,就好像一个 CDN 已关闭一样,至少其余的 CDN 已启动并正常工作。对于向下的 CDN,后备将进行锻炼。
简而言之,这是我在项目中遵循的最佳实践。
【讨论】:
【参考方案8】:您可以轻松使用 cdn 获取数据
【讨论】:
【参考方案9】:您应该尽量避免将 CDN 用作:-
-
如果由于某种原因完成 CDN,它也会影响您的应用,并且您还可能面临在生产代码中绝不应该发生的停机时间
对于 CDN,浏览器需要爬取不同的域,然后下载必要的文件,这将需要更多时间
没有对不同域的请求也会减慢您的应用加载时间
浏览器一次限制为 6 个请求,因此如果您一次发出多个请求,它们将在队列中并需要更多时间,因此请尽量减少请求数。
推荐 -
用户 Bower/Grunt 或 Webpack 在您的应用程序中 -
-
Bower 会将您的应用程序的所有依赖项带到您的本地服务器/机器上,这样它就不需要搜索不同的域来获取所需的文件
Grunt 会将所有不同的文件连接并合并到一个文件中,这样文件的大小就会减小,并且从浏览器发出的下载文件请求数也会减少。
如果您对 bower/grunt 有任何疑问,我可以为您提供帮助。
【讨论】:
这是个糟糕的建议 - 如果 CDN 出现故障,任何称职的程序员都应该有备用方案来加载本地版本的依赖项。 CDN 也可能在用户的浏览器缓存中,从而略微减少加载时间。 我们可以直接使用本地版本的依赖项,而不是管理回退,我们可以最小化和连接所有依赖项并加载单个文件,我认为如果您有很多依赖项,这会更快。 “浏览器一次限制为 6 个请求” - 每个服务器 - 看看这个问题:***.com/questions/985431/…以上是关于从一个 CDN 或多个 CDNS 加载文件的主要内容,如果未能解决你的问题,请参考以下文章