1. 前述

在前端产品中，我们无法保证用户的网络情况，也很难从最末端节点优化自有网络部署。 这些或多或少地都会反映到用户端的加载延迟。

Loading 的产生是为了在无法立即呈现的界面中优化用户的使用体验。 反过来看，Loading 动画能够为资源准备工作提供更多的加载时间，提高用户的转化率。

也就是说 Loading 是为了缓解加载延迟提供的一个视觉\交互方案，形成一个连贯的视觉体系。

Loading 设计在不同实用场景下有不同的最优方案：

2. 加载模式分类

2.1 骨架屏

样例： 饿了么 PWA 骨架屏

这种加载模式已经成为主流的内容源加载模式（如微博博文，饿了么餐厅列表等）

在用户访问时不等服务器返回列表内容，先用骨架（内容用矩形填充）渲染撑起整个页面（DOM 树），等待服务端返回内容数据再进行重绘。

这种加载模式重绘时有较少的前端样式波动，相对有更好的使用体验，对于整个交互流程的侵入性较小。

2.2 部分加载

样例： 网易新闻图片 loading

对于内容量较多的加载需求场景（比如：新闻，博客），本身数据查询时间不是耗时瓶颈。瓶颈在于图片等资源大小，因此更多的是分开加载。

一开始返回的页面带有完整的文字信息，图片用矩形框填充占位，矩形框内显示 loading。待图片、视频等大资源加载完成之后再替换图片。

2.3 全屏加载

在使用全屏加载的时候一定要谨慎，用户对于全屏加载的容忍度最低，目前通过观察，基本上3秒钟为用户等待上线。

在骨架屏中，用户对于即将出来的内容以及有了一定预期，对于等待的容忍性也更好。在全屏加载中，用户面对的就是一个黑盒子，完全不知道后面将会出来什么内容，因此对于全屏加载的容忍性更低。

因此对于加载过程中，全屏加载尽量通过骨架屏来优化用户体验，为网络和后端查询留出充足时间。

2.4 进度条

首先说明一点，目前市面上的进度条基本上都是假的进度条。 通过非线性衰减进度条的移动速度来延缓用户的等待焦灼感，同时给用户提供一定的心里预期，即：什么时候完成加载。

进度条主要分为两种：

• 放在 header 或者 footer，不阻塞用户的操作行为
• 放在模态框里面，阻塞用户操作（不推荐）

在有明确进度说明的加载场景下，用户的等待容忍时间可以延长到 9S - 12S，用户容忍时间为全屏加载的 3-4 倍。 显著提升了用户的容忍程度。

3. 加载优化

3.1 体验错觉

例如进度条的存在就是利用了用户的体验错觉，在相同的等待时间下面，减小用户感受的时间长度，从而提升转化率和用户留存。

3.2 补充消息

在加载过程中，为用户提供当前状态信息也可以在一定程度上优化用户等待的焦灼感。

例如在全屏 loading 中加入当前状态的文字提示，或者一些 tips 都有帮助。

3.3 预先缓存/加载

代入一个场景，比如你在订票软件中，输入完出发地，目的地和时间之后点击确认。 在这个流程中，触发查询请求的不是点击确认这个动作，而是选择完时间。

如果数据统计出来可以预估你下一个行为，就可以把相应的后台逻辑提前一步，优化体验。

3.4 技术改造（根本优化等待时间）

要从根本上解决加载延迟，只能从dns查询，内容分发，接口请求速度，前端渲染逻辑来优化。这几个部分的优化往往是伤筋动骨的技术改造，有较大实现成本。

真正理想的情况不是有好的 Loading，而是没有 Loading。