懒加载具有很多的性能优势，比如一个页面中就要加载数百个产品图片的电子商务公司，懒加载可以使其初始页面的加载时间得到显著的优化，同时还能降低传输带宽。但即便如此，依然有许多公司未曾采用，这是因为他们觉得这不利于更好的用户体验——图片未加载时的占位很丑，感知等待时间久等。上一篇文章我们详细介绍了图片懒加载的实现细节，所以这一篇我们主要谈谈懒加载过程中有关用户体验方面的一些问题。
1. 使用恰当的图片进行占位
占位指的是在真实图片加载出来之前，图片显示的位置上临时应当有所填充。通常，我们经常会看到开发者会使用纯色块来占位，或者用一个图片占所有图片的位。为了追求令人更满意的用户体验，建议可以进行以下尝试：
1.1 主色占位
与千篇一律的使用一个固定颜色的色块占位，建议尝试用原始图片中的主色调进行占位，这个策略其实已经在百度图片和谷歌图片的搜索结果中使用了很长一段时间了
1.2 低分辨率图片占位
依然延续上面主色占位的思路，所不同的是，此处可尝试使用原始图片的一个非常低分辨率，甚至是模糊的版本作为占位。这样不仅看起来更为友好，而且还能给用户关于真实图片一些猜测，和稍后真实图片加载出来更为平滑的过度。这样的改进显然有更好的用户体验。
2. 为图片加载增加缓冲时间
在上一篇文章中，我们讨论了触发图片加载的不同方式时，所采用的时间点都是图片进入视窗的时间点，即在页面滚动过程中，图片占位区域的上边缘到达视窗的下边缘时。这样的实现隐含了一个体验上的瑕疵：通常用户会快速地滚动页面，但触发图片加载后到显示在屏幕上还需要一段时间，而且采用事件绑定的实现方案出于节流的考虑，又为事件触发增加了一小段延迟。这些所造成的体验效果便是：我们滚动页面当图片的占位区域出现在视窗中后，还需要再等一段时间（短则几十毫秒）图片才会显示出来，不能不说这是一个糟糕的体验。
这里来介绍另一种优化的技巧：当图片占位距离出现在视窗中还有一段距离（比如500px）时，便开始触发加载，这就为了图片争取到了一小段预加载的时间。
对于事件绑定的触发方式，直接进行计算就好。而使用intersection observer API的方式可以通过配置root和rootMargin参数来设置触发距离，详情可参考MDN。
3. 避免内容异动
这篇文章我们一直都默认，页面中使用图片的地方，即便它暂时未加载出真实的图片，也为他指定了占位空间的宽和高。这么做基于的考虑是这么一个场景，假设我们不为图片事先指定占位空间的宽和高，那么在它加载展示出来之前的尺寸便是0x0像素的。那么当图片被加载出来后，页面原有的排版就会被图片撑开，而导致页面内容出现异动的体验。
这样突兀的感受，对于体验来说很不优雅。所以建议为图片设置确定宽高的占位，以避免图片突然加载出来后产生的页面异动。
4. 不要对所有图片都懒加载
每当学会一个新的技术方法后，好像都会有种得到了放之四海而皆准的灵丹妙药，想要立马推广普及，而可能忽视了每种方法都有其限制条件。
假设我们对页面中所有图片都施用懒加载，虽然会降低初始页面的加载时间，但页面顶部本应一上来就加载展示的图片，现在需要等JavaScript执行后才会加载。这显然不妥，那么到底哪些图片应当被懒加载呢，我们可以依据如下一些原则：
- 页面首屏中涉及的图片，不应当作懒加载。这些包括：logo，页面营销横幅，头部的一些图片等，另外考虑到移动设备与PC桌面不同的显示尺寸，那么初始页面首屏中包括的图片数量也会有所不同，所以在判断懒加载图片时也要将设备类型考虑在内。
- 任何稍微偏离页面首屏视窗的图片，也都不应该被懒加载。这个稍微偏离的程度，可以根据页面特点去进一步设置，比如上面"为图片加载增加缓冲时间"一节中谈到的
500px。 - 对于整个页面满共也没几张图，用懒加载也不能获得多少明显收益的时候，也不建议使用。因为为了懒加载那不多的几张而增加的JavaScript代码量，两相抵消不划算。
5. 常见的实现库
虽然我们在上一篇文章中已经详细介绍了懒加载的实现原理和过程，相信你也能依此在自己的项目中开发出懒加载功能。但使用社区成熟且经过验证的库来实现，或许是性价比最高的选择，当然如果你有重复造轮子的诉求，也可以自己动手丰衣足食。
下面罗列一些比较流行的懒加载库作为参考：
6. 测试懒加载是否工作
当我们实现完懒加载后，肯定会想怎么来验证一下，页面上的图片是否如愿以偿。方法也很简单，Chrome浏览器下打开开发者工具如下：
带页面加载完后，我们滚动页面，观察请求栏中是否有新的图片请求到来。
最后希望对大家有帮助。
