我对rel="preload"属性感到兴奋，因为它看起来可以帮助加快页面渲染时间。我应该预先加载一个大的图像吗？
用例是一个网页，上面有一个大图像。现在，直到获取jQuery（一个相当重的文件）之后，Chrome才会开始下载图像。启用预加载后，它们将并行下载。
但是我正在阅读冲突的报告，关于是否应将preload用于其他地方可见HTML元素（与用户交互可见的内容相比，如下拉菜单）。
This post似乎建议不要预加载：
当不使用预压：
- 当资产被称为别处在同一页上。
- 如果您不确定用户是否真的需要该资产。就像在一个页面上，访问者只有3％的时间。
虽然this one似乎表明它是金融时报的网站上有类似的情况非常有帮助：
当金融时报推出了链接预压头到他们的网站，他们剃光1秒关闭显示标头图像所用的时间...
那么这是哪一个？我应该提供一个早期的“提示”来显示始终显示的上面的图像吗？或者我应该让浏览器按照通常的顺序进行操作？
我认为，在涉及性能优化的情况下，您真的需要create an A/B test来确定您应该执行哪一个。作为最佳实践，图像预加载并不适用于所有人。
我最喜欢的一本书Lean Enterprise的最大原则之一是用于A/B测试来证明或反驳HIPPO（高薪的人的观点）。某些意见在你的组织和互联网上都有很大的影响力。由于他们的重要性和声誉，他们的意见转向事实的领域，尽管事实并非如此。
另一本我喜欢的关于性能调优的书也吹捧了我测试性能的做法 - Code Complete 2nd Ed.在这本书中，McConnell给出了几个代码示例，您可能希望一段代码是最优的，但事实上，它表现不佳（见第25和26章）。他的一个关键点是你应该总是测试性能优化。 如果它不值得测试，那么不值得在第一个地方编写“高性能”代码。麦康奈尔的前提不仅适用于他的低级别编码示例，还适用于高级别决策，例如在图像上预加载图像。
我也可以证明专业级别的A/B测试的重要性。我曾经在亚马逊的搜索引擎优化团队工作，我们A/B测试了一切。事实是你永远不知道顾客会如何回应。没有人能够预测顾客的行为 - 甚至连杰夫贝佐斯也没有 - 你真的需要用真实数据来支持你的假设，以证明或反驳你正在做的事情的有效性。
尽管您可以找到多篇博客文章和在线资源，讨论预加载是否更好，但在完成之前，您并不知道它是否适用于您。不同的人有不同的服务器，具有不同的性能特征和不同的网络拓扑结构等等，直到获得数据为止，您只是不知道哪种方式更好。如果您启动A/B测试并发现在预加载时您的排斥率升高，那么您知道必须回拨您的治疗并返回到您的控制。但是，如果您发现客户不会感到无聊的等待并以比以前更高的速率点击，那么您将获得胜利者并拨打治疗 - 在一段时间后完全删除控制代码。
我希望有帮助。
我只会在图像中使用rel =“preload”，因为如果用户驱动的事件会请求图像，那么javascript会在稍后时间渲染页面时出现瓶颈并且会对用户体验造成不利影响，或者如果您在呈现页面时遇到由此大图像引起的任何流量。
我知道你的图像是最重要的，如果它在源代码中从一开始就能找到，我会让浏览器优先考虑首先下载的内容。 另一方面，你可以随时A/B这种变化，看看它是否适合你。
这篇文章对这些陈述是错误的。开发人员使用预加载，因为他已经知道页面上需要这些资源。预加载不是一个“提示”。预取更符合他陈述的内容，即你告诉浏览器可能需要资产。
如果图像超出了折叠范围，那么您就知道这将是需要的，而这正是预取的目的。
预紧力是一种声明获取，让你强制浏览器 使一个资源的请求，而不会阻塞文档的onload事件 。
很多时候，感知加载时间比真实感更重要。根据内容的不同，有时您会希望尽快准备好文字，或者尽早提供相互交流，有时还会提供图片......您应该尝试一下，看看它的感觉如何。我记得一个具体的例子：6-7秒的白色加载屏幕是不可接受的，但9-10秒有一个小徽标和加载动画是完全没问题的。 – 2017-10-23 23:45:16
什么是页面结构？包括js脚本在内，是页眉/页脚？这些脚本是否包含在同步/异步模式中？我认为你的问题归结为特定的页面优化问题，所以最好能看到具有类似结构的URL或页面草图，以检查Chrome如何调度资源加载 – ffeast