显然，这只是其中一个因素，但如果我在英国主办一个网站，知道我的大部分用户都在美国，那么我应该给予这些用户多less体重的访问速度？ （目前大约70％的美国用户，约20％的英国，其余的都已经全部结束了。）跨大西洋蛇麻草曾经有点大不了，但它在当今世界真的是一个很重要的因素吗？
我再一次意识到这只是整体组合中的一个因素，只是看看社区认为我应该给它多less分量。
（在build议之前，使用大型CDN /云之一 – 亚马逊S3 + EC2，Google AppEngine等）目前不是一种select。
编辑 ：所有的答案欢迎; 任何直接经验的故事都会特别有帮助。
曾经存在与跨大西洋链路的延迟和吞吐量有关的重大问题。 尽pipe可用的带宽（假设你的ISP /主机有合适的对等安排），但是在大多数情况下吞吐量并不是真正的问题。
延迟可能仍然是一个问题，但只有当您的应用程序特别是延迟敏感。 例如我的家用机器（通过一个好的ADSL ISP在线）和服务器之间的小包往返时间（即一个标准的ping请求），我有状态方面（因为它往往更便宜）通常大约100ms （有些时候它一直处于接近120的状态）。 对于绝大多数基于networking的服务来说，这个等级的延迟根本不成问题。
我不会给它太多的重量…美国/英国不是一个巨大的跃点。 只要端点networking不拥塞，即使是跨太平洋也不是一个破坏交易的手段。 一个坚实的networking提供商远比你所在的位置重要得多，从而为网站的用户提供良好的体验。
他们抱怨这是慢吗？ 你的出场速度是多less？
你可能会考虑在美国build立一个鱿鱼代理服务器/caching服务器，或者把你的网站复制到美国的服务器上，如果这真的是一个大问题的话。
但是，我不会[个人]期待它那么重要。
正如其他人所提到的，延迟问题可能是一个因素。 由于应用程序非常“健谈”，在打开页面时多次出差，因此我们在CRM和SharePoint上的延迟小于100M的链接上遇到了问题。 我们在北美的大部分网站都是我们本地的。 现场的广域网加速器阻止了呼叫，现在性能很好，我们不必从供应商那里获得更快的连接。
延迟是一个问题。 页面加载速度会让连接速度变慢。 确保你在美国有良好的连通性，在美国有很好的平台。 如果您位于Chicago ， New York或California数据中心，这将有所帮助。 如果你的客户不在亚洲， 芝加哥或纽约更可取。 运行跟踪路由。 这真的有助于select一个虚拟主机。 Traceroute到last.fm（欧洲主机）和google.com。
如果您需要美国境内最快的连接，请在英国伦敦selectISP。