我应该预加载首屏以上的大图像吗？答案

【问题标题】：Should I preload a large image that's above the fold?我应该预加载首屏以上的大图像吗？
【发布时间】：2018-03-28 10:29:43
【问题描述】：

我对 rel="preload" 属性感到兴奋，因为它看起来可以帮助加快页面呈现时间。

用例是首屏带有大图像的网页。现在，Chrome 直到获取 jQuery（一个相当大的文件）之后才开始下载图像。启用预加载后，它们会并行下载。

但我正在阅读相互矛盾的报告，关于是否应将preload 用于其他地方可见 HTML 元素中的内容（与通过用户交互显示的内容相反，如下拉菜单）。

This post似乎不建议预加载：

何时不使用预加载：

当资产在同一页面上的其他地方被引用时。

当您不确定用户是否真的需要该资产时。访问者只有 3% 的时间会访问某个页面。

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

当《金融时报》在他们的网站上引入链接预加载标头时，他们将显示标头图片的时间缩短了 1 秒...

那是什么？我是否应该提供一个早期的“提示”来显示始终显示的首屏图像？还是我应该让浏览器按照通常的顺序访问它？

【问题讨论】：

很多时候，感知加载时间比实际加载时间更重要。根据内容的不同，有时您会期望更快地准备好文本，或者更快地提供交互，有时是图像......您应该尝试一下，看看感觉如何。我记得的一个具体案例：6-7 秒的白色加载屏幕是不可接受的，但带有小徽标和加载动画的 9-10 秒完全可以。
页面结构是什么？ js脚本包含在哪里，是页眉/页脚吗？脚本是否包含在同步/异步模式中？我认为您的问题归结为特定的页面优化问题，因此很高兴看到具有类似结构的 URL 或页面草图来检查 Chrome 如何安排资源加载

标签： html performance optimization preloading

【解决方案1】：

我认为在涉及性能优化的情况下，你真的很想create an A/B test 来确定你应该做哪一个。作为最佳实践，对于图像预加载确实没有千篇一律的答案。

我最喜欢的一本书Lean Enterprise 的最大原则之一是使用 A/B 测试来证明或反驳 HIPPO（高薪人士的意见）。某些观点在您的组织和互联网上都很重要。由于他们的重要性和声誉，他们的观点转向了事实领域，尽管事实可能并非如此。

我喜欢的另一本关于性能调优的书也吹捧了凭经验测量性能的做法 - Code Complete 2nd Ed. 在这本书中，McConnell 提供了几个代码示例，您认为其中一段代码是最佳的，但实际上，它表现不佳（见第 25 和 26 章）。他的关键点之一是您应该始终测试性能优化。 如果不值得测试，那么一开始就不值得编写“高性能”代码。 McConnell 的前提不仅适用于他的低级编码示例，还适用于高级决策，例如预加载首屏图像。

我还可以证明 A/B 测试在专业水平上的重要性。我曾经在亚马逊的 SEO 团队工作，我们对所有内容进行了 A/B 测试。事实是，您永远不知道客户会如何回应某事。没有人能预测客户的行为——即使是 Jeff Bezos 也不行——你真的需要用真实数据来支持你的假设，以证明或反驳你所做的事情的有效性。

尽管您可以找到多篇博客文章和在线资源来讨论预加载是否更好，但在您完成之前您并不知道这是否对您有用。不同的人有不同的服务器，具有不同的性能特征和不同的网络拓扑等。只有在掌握数据之前，您才知道哪种方式更适合您。如果您启动 A/B 测试并发现在预加载时您的排斥率上升，那么您知道您必须撤回您的治疗并返回您的控制。但是，如果您发现客户没有厌倦等待并以比以前更高的速度点击，那么您就有了赢家，您可以拨打治疗 - 一段时间后完全删除控制代码。

希望对你有帮助。

【讨论】：

【解决方案2】：

文章对这些陈述有误。开发人员使用预加载是因为他已经知道页面上需要这些资产。预加载不是“提示”。预取更符合他的说法，即您告诉浏览器可能需要该资产。

如果图像在首屏，那么您就知道需要它，而这正是预取的用途。

Addy Osmani of Google

preload 是一种声明式获取，允许您强制浏览器在不阻塞文档加载的情况下请求资源事件。

【讨论】：

【解决方案3】：

只有在 css 中找到图像时，我才会对图像使用 rel="preload"，如果用户驱动的事件将请求图像和这将对用户体验产生不利影响，或者如果您在页面呈现中由于此大图像而遇到任何流程。

我知道您的图片在首屏，如果从一开始就可以在源代码中找到它，我会让浏览器优先考虑首先下载的内容。另一方面，您可以随时 A/B 更改此更改，看看它是否适合您。

【讨论】：