我很想听听其他一些开发人员的意见，您在多大程度上利用了“预期预加载”？
我们的主页上有几个大小合适、缩小的 JS 和 CSS 文件集（每个大约 50k，在我们的 cdn 上设置了所有缓存），然后是 123kb 的缩小/可缓存/cdn'd JS 集文件和页面上的更多 CSS，用户不可避免地会在我们的主页之后立即访问。
因此，我一直在使用 jQuery 的 getScript()（设置了缓存选项）来进行预加载，并且一直在主页上的 pageload 上加载 123kb 文件，以使用户更快地过渡到站点的更丰富区域，并且更愉快。
事情在我的电脑上似乎表现得很好，但是 a) 这不是每个人的设置和 b) 在我的 Firebug Net 控制台上看到如此多的 KB (~550kb) 感觉有点有趣。当我返回它时，它被缓存了 565kb/568kb 并且只有大约 2.6 秒的加载时间......但仍然......
想法？至理名言？这对移动用户有很大影响吗？
很想听听你的想法，干杯
老实说，我认为别人发现了什么并不重要，你应该自己衡量它——否则，你将永远盲目。如您所知，您额外的 javascript 可能会损害您的实际主页性能。要记住的关键观察是每个站点都是不同的：不同的人口统计数据、浏览器的细分、移动设备与桌面设备，以及最重要的业务 KPI。
所有这一切都说：衡量它，不要依赖轶事。有很好的工具可以帮助你。如果您运行 Google Analytics，请查看自定义变量。您可以在整个会话期间或在 cookie 过期之前标记访问者，并根据该 cookie 采用条件路径。例如，一些用户获得预加载路径，而其他用户则没有。完成此操作后，将 GA 中的数据与您的 KPI 进行比较：广告点击率、跳出率、每次访问的页面数、购买量、漏斗率等。
或者，GA 最近还推出了“内容实验”，它允许您直接在 GA 中运行测试（包括站点优化），并使用所有统计机制来分析您的结果。
最后但并非最不重要的一点是，GA 并不是镇上唯一的游戏。搜索“a/b 测试”，您会发现大量的 3rd 方工具，以及可以放入您自己的框架的开源插件。