我为此（Cloudfront）测试了CDN网络，认为将静态文件移近用户是一个很好的选择理念。但是，所有这些文件现在需要半秒左右的时间才能显示在屏幕上。我现在必须使用绝对路径，当然（https://xyzvf.cloufront.net/images/）
为什么？绝对路径有问题吗？我正在减少对我自己的服务器的HTTP请求，这是一件好事，但是这种延迟令人讨厌。 CDN不适用于此吗？
#1 楼
问题可能是DNS或keep-alive-也就是说，浏览器已经具有服务器的IP地址并已打开连接，而浏览器必须解析CDN的服务器名称，然后在其中打开新连接，并且其中一个这些或两者都构成了您所看到的延迟。发散虽然仍然是一个好主意，但对解决这些问题没有帮助。确实，没有解决方案浮现在脑海。唯一的安慰是，如果您有一千个图像（以及CSS文件和JS文件以及所需的任何其他静态文件），那么半秒的延迟将不会更长，并且如果成千上万的用户点击它。
评论
这响了。我应该提到，在需要第一个映像时（例如在页面中间）对CDN服务器进行了第一次调用。
–丹
2011年7月22日在9:43
嗯，如果您在页面的早期就引用了CDN，则可能会获得更好的（感知）性能。最好的方法可能是将CSS文件放在CDN上，并将链接标签放在头部，这样连接过程将立即开始。
–马尔沃里奥
2011年7月22日在14:26
评论
这在很大程度上取决于CDN的位置。如果您有很多小图像，是否可以将它们组合为子画面？那将意味着仅一个请求即可加载所有图像。他们在以下位置：michaelgaigg.com/blog/images/amazon-cloudfront.jpg我在欧洲，从美国的Web服务器加载图像比从德国或在欧洲为亚马逊服务的任何位置加载图像要快。也许加载时间不是问题，而是其他问题？使用精灵是个好主意。
您还可以使用带有主机名的无协议URL，例如“ //xyzf.cloudfront.net/images”。这使您可以利用ISP和公司代理缓存来缓存图像的非SSL版本。这可以为您的访客体验和服务器/带宽负载带来巨大的好处。我们网站的访问者几乎全部来自美国的金融机构，我们从某种形式的缓存代理后面检测到大约85％的访问。 YMMV，所以当然要测试您自己的网站和访问量。