我对rel="preload"属性感到兴奋，因为它看起来有助于加快页面渲染时间。
用例是一个在首屏上方有大图像的网页。目前，Chrome在获取jQuery（一个相当繁重的文件）之后才开始下载图像。启用预加载后，它们会并行下载。
但我正在阅读有关我是否应该将preload用于其他地方可见HTML元素的内容的相互矛盾的报告（与用户交互可见的内容相反，如下拉菜单）。
This post似乎建议不要预加载：
何时不使用预加载：
- 当资产被引用到同一页面上的其他地方时。
- 当您不确定用户是否真的需要该资产时。就像在页面上一样，访问者只有3％的时间。
虽然this one似乎表明它对金融时报网站上的类似情况非常有帮助：
当英国“金融时报”向其网站引入了链接预加载标题时，他们将显示标头图像的时间减少了1秒......
那是哪个？我应该提供一个早期的“提示”来显示始终显示的，首屏图像吗？或者我应该让浏览器按照通常的顺序进行操作？
答案 0 :(得分：1)
我认为在涉及性能优化的情况下，您确实希望create an A/B test确定应该执行哪一项。对于适合每个人的图像预加载，确实没有cookie切割答案作为最佳实践。
我最喜欢的书籍Lean Enterprise的最大原则之一是用于A / B测试以证明或反驳HIPPO（高薪人士的意见）。在您的组织和互联网上，某些意见会带来很大的影响。由于它们的重要性和声誉，它们的观点转向事实领域，即使它可能不是。
经验衡量表现的做法也受到我喜欢的另一本关于性能调整的书的启发 - Code Complete 2nd Ed.在那本书中，McConnell给出了几个代码示例，你可以期望一段代码是最优的，但是事实上，它表现不佳（见第25章和第26章）。他的一个关键点是你应该总是测试性能优化。 如果不值得测试，那么就不值得写出高效的＆＃34;＆＃34;代码首先。 McConnell的前提并不仅仅适用于他的低级编码示例，而是适用于高级决策，例如在首屏上预加载图像。
我还可以证明A / B测试在专业水平上的重要性。我曾经在亚马逊的搜索引擎优化团队工作，我们A / B测试了一切。事实上，你真的不知道客户会如何回应某些事情。没有人可以预测客户的行为 - 甚至不是Jeff Bezos - 你真的需要用真实的数据来支持你的假设来证明或反驳你正在做的事情的有效性。
即使您可以找到多篇博客文章和在线资料来讨论预加载是否更好，但在您完成之前，您并不知道这是否适合您。不同的人拥有不同的服务器，具有不同的性能特征和不同的网络拓扑等。在您拥有数据之前，您不知道哪种方式更适合您 。如果您启动A / B测试并发现在预加载时发现您的击退率上升，那么您就知道您必须拨回治疗并返回您的控制。但是，如果您发现客户不会感到无聊等待并以比以前更高的速度点击，那么您就有了胜利者并拨打了处理 - 在一段时间后完全删除了控制代码。
我希望有所帮助。
答案 1 :(得分：0)
我只会在图像中使用rel =“preload”，如果要在css中找到它们，javascript会导致稍后在页面渲染中出现瓶颈，如果用户驱动的事件将请求图像和它会对用户体验产生不利影响，或者如果您在页面渲染过程中遇到因此大图像而导致的任何流量。
我理解你的形象在首页，如果从一开始就在源代码中找到它，我会让浏览器优先考虑先下载的内容。 另一方面，你总是可以A / B这个改变，看看它是否适合你。
答案 2 :(得分：0)
这些陈述的文章是错误的。开发人员使用预加载，因为他已经知道页面上需要这些资产。预加载不是＆＃34;提示＆＃34;。预取更符合他的陈述，即您告诉浏览器可能需要资产。
如果图像在首屏上方，那么您就知道它将是必需的，这正是预取的目的。
preload是一个声明性提取，允许您强制浏览器 在不阻止文档onload的情况下发出资源请求 事件