SPDY CDN + 异步脚本加载后端答案

【问题标题】：SPDY CDN + Async Script-loading backendSPDY CDN + 异步脚本加载后端
【发布时间】：2015-01-13 17:17:25
【问题描述】：

如果已经使用支持 SPDY 的 CDN，像 LABjs 或 $script.js 这样的异步脚本加载器会证明是有益的、中性的还是负面的？

我将使用带有 SPDY 的全站点 CDN，例如 Cloudflare
我已阅读Script-injected "async scripts" considered harmful，但由于 jQuery 依赖项，我需要控制执行顺序。
我希望尽可能不捆绑依赖项

即我有一系列 JS 脚本，<script src= 可以正常工作而<script async src= 不能。我不想同步，因为它会阻塞。而且defer 太不稳定了，无法考虑。

鉴于上述情况，如果不是因为 SPDY 的不确定性，我会毫不犹豫地使用脚本加载器。我可能只需要知道这些脚本使用的方法是否仍能获得与“常规”方法相同的 SPDY 好处（流水线、压缩等）？

提出问题的另一种方式是：从使用 SPDY CDN 的同步脚本加载切换到使用带有 SPDY CDN 的异步脚本加载器会有什么影响？

【问题讨论】：

【解决方案1】：

我在使用 Cloudflare 作为 SPDY 代理时遇到了非常糟糕的性能问题，我的基准测试从 SPDY 的 1.5 秒到大约 4 秒（慢了 266%）。您应该自己测试一下，通过直接连接到您的服务器，您应该会看到更快的结果。

CDN 会减慢您的速度，因为 SPDY 允许从一个套接字连接中提取所有资源，而 CDN (https) 需要多次 TLS 握手和往返连接，这可能会降低您的网站速度下来。

此测试显示通过 SPDY 加载了大约 350 个资源，您不会使用 CDN 获得这些结果：http://httpvshttps.com/

这是一篇有趣的文章：

【讨论】：

这篇文章很有趣但无关紧要——他们当时正在测试一个不支持 SPDY 的 CDN。
请解释为什么“CDN (https) 需要多次 TLS 握手和往返连接”是正确的。您是否考虑过有人拥有 www.site.com 和 cdn.site.com 作为静态资源的情况？
是的，完全正确。 > 1 次 TLS 握手会减慢速度。
这就是为什么我提到“全站 CDN”，即 CDN 服务于 www.site.com，并且没有额外的主机名。即 0 次额外的 TLS 握手，您也可以获得 SPDY 的好处。我不知道这是否有一个公认的技术术语，但如果您搜索“全站点 CDN”或“全站点交付 CDN”，您会发现几乎所有主要的 CDN 提供商都在讨论他们的解决方案。
是的，效果会很好。