我对rel =“preload”属性感到兴奋,因为它看起来有助于加快页面渲染时间.

用例是一个在首屏上方有大图像的网页.目前,Chrome在获取jQuery(一个相当繁重的文件)之后才开始下载图像.启用预加载后,它们会并行下载.

但我正在阅读有关我是否应该在其他地方使用可见HTML元素的预加载的相互矛盾的报告(而不是通过用户交互可见的内容,如下拉菜单).

This post似乎建议不要预加载：

When not to use preloading:

• When the asset is referred to somewhere else on the same page.
• When you’re not sure the user will actually require that asset. Like on a page visitors only go to 3% of the time.

虽然this one似乎表明它对金融时报网站上的类似情况非常有帮助：

When the Financial Times introduced a Link preload header to their site, they shaved 1 second off the time it took to display the masthead image…

那是哪个呢？我应该提供一个早期的“提示”来显示始终显示的,首屏图像吗？或者我应该让浏览器按照通常的顺序进行操作？

最佳答案 我认为在涉及性能优化的情况下,你真的想要
create an A/B test确定你应该做哪一个.对于每个人来说,图像预加载确实没有cookie切割答案作为最佳实践.

我最喜欢的书籍之一的最大原则之一,Lean Enterprise,用于A / B测试以证明或反驳HIPPO(高薪人士的意见).在您的组织和互联网上,某些意见会带来很大的影响.由于它们的重要性和声誉,它们的观点转向事实领域,即使它可能不是.

经验测量性能的做法也受到我喜欢的另一本涉及性能调优的书的鼓吹 – Code Complete 2nd Ed.在那本书中,McConnell提供了几个代码示例,您可以期望一段代码是最佳的,但事实上,它表现不佳(见第25章和第26章).他的一个关键点是你应该总是测试性能优化.如果不值得测试,那么首先编写“高性能”代码是不值得的. McConnell的前提不仅仅适用于他的低级编码示例,而是适用于高级决策,例如在首屏上预加载图像.

我还可以证明A / B测试在专业水平上的重要性.我曾经在亚马逊的SEO团队工作,我们A / B测试了一切.事实上,你真的不知道客户会如何回应某些事情.没有人可以预测客户行为 – 甚至杰夫贝佐斯 – 你真的需要用真实数据来支持你的假设来证明或反驳你所做的事情的有效性.

即使您可以找到多篇博客文章和在线资料来讨论预加载是否更好,但在您完成之前,您并不知道这是否适合您.不同的人拥有不同的服务器,具有不同的性能特征和不同的网络拓扑等.在获得数据之前,您只是不知道哪种方式更适合您.如果您启动A / B测试并发现在预加载时发现您的击退率上升,那么您就知道您必须拨回治疗并返回您的控制.但是,如果您发现客户不会厌倦等待并以比以前更高的速率点击,那么您有一个胜利者并且您拨打处理 – 在一段时间后完全删除控制代码.

我希望有所帮助.