干货 | 前端智能化探索，骨架屏低代码自动生成方案实践

作者简介

 

ZiLin Wang，前端开发者，函数式编程爱好者，最近沉迷于低代码平台和WebAssembly；Ivan Zhang，擅长前端打杂，最近专注于Sketch插件和DesignOps平台；Sheila，携程资深前端开发工程师，关注前端性能优化。

在进入页面的过程中，用户不可避免地会看到一个加载动画。但加载动画往往比较古板，如果加载耗时稍微长一点，用户就会失去耐心离开页面。为了让用户有更好的浏览体验，骨架屏是一种较好的渐进式加载方案。

骨架屏的实现，也是视觉稿直出代码实现方案的 MVP (Minimum Viable Product)。本文会探讨骨架屏方案的优劣，以及一种前端智能化的骨架屏代码自动生成方案实践。

一、背景

早在2013年，Luke Wroblewski 就介绍了Skeleton Screens的概念。骨架屏作为一个空白的页面载体，它的作用是传递出一种页面正在渐进式加载中的信息。

A skeleton screen is essentially a blank version of a page into which information is gradually loaded.

Skeleton Screens 比单纯的 spin 优秀的地方，就在于让用户知道即将加载的页面信息结构，给予了一定的信息量，可以缓解用户等待页面的焦虑情绪。苹果也把骨架屏作为一种加载标准，在应用中推荐包含文本或者元素基本的轮廓。

1.1 为什么需要骨架屏

UX 研究咨询公司 Nielsen Norman Group 提出了在提升 web / app 性能方面的四个重要的响应时间节点：0.1s、1s、4s以及10s。

在 1s 以内，是不需要额外的加载信息提示的，因为用户尚在心流之中；在 1-4 秒，需要 loading 指示器来告知用户正在加载中；在4s以上，则需要告知用户当前的加载进度，超过一定的时长需要有失败反馈，让用户进行重试。

除了一些前后端同构的方案可以快速返回前端数据，对页面进行直接渲染以外，大部分的页面都需要经过一定的加载时间，来获取服务返回数据进行展示。如果呈现给用户的是白屏，或者是一个固定的加载动画，都会让用户产生一种焦虑情绪，或者怀疑页面是否加载出来了。

骨架屏是一种有效减少用户负面体验的方案，通常在页面首屏或者一些关键性节点会进行骨架屏的渲染。同时，它也是缩短 FMP (First Meaning Paint) 的重要方式。

Lara Swanson 在 《Designing for Performance》 中提到，大部分用户期待在2秒内完成加载，超过3秒后会有 40% 的用户离开页面。骨架屏给出了页面的大体轮廓结构，让用户产生一种已经有内容返回了的错觉，也是一种有效降低用户焦虑情绪的方式。

如果返回服务的速度够快，或者页面的结构简单，对于骨架屏的需求是没有那么强烈的。推荐在以下场景中使用骨架屏：

• 首屏内容，让用户快速定位到需要关注的模块

• 图文结构、卡片式模块、列表较多的页面

• 作为局部加载、渐进加载的 loading 样式

如果我们能采用自动的骨架屏渲染的方式，也会大大减少我们的使用和维护成本，配置的灵活性高，保持高还原度，不要影响页面本身的加载性能。

• 提升用户体验，让用户获知当前页面的大体结构，比常见 loading 的视觉更加流畅

• 骨架屏内容的渲染，缩短了 FMP (First Meaningful Paint)，提升站点 / 应用性能

• lowcode / nocode 骨架屏自动填充方案，降低维护成本

1.2 方案调研及对比

首屏展现骨架屏，能够提前给予用户一定的信息量，在短时间内获取到用户的关注点，聚焦到他所关心的模块位置。

加载后使用真实的数据模块替换骨架屏结构，可以自然平滑地进行过渡。渐进式的渲染让用户可以更快地感知，提供更加良好的用户体验。

但是方案的缺陷在于人工成本稍高，需要针对设计师给出的首屏内容结构，手写一份对应的骨架屏代码。为了降低开发与维护成本，我们需要一套自动化的骨架屏生成方案。目前业界对于自动化骨架屏的实现方式有以下两种主流方案。

1.2.1 puppeteer 自动生成骨架

针对浏览器环境的 web 页面，可以使用 puppeteer 无头浏览器抓取页面相应的 DOM 节点，进行骨架屏的结构渲染。业界实现方案中，这样的方案最后通用化为平台自动抓取。

通过传入页面的 url 地址，使用 puppeteer 去打开需要渲染的首屏页面，抓取到整个页面的 DOM 节点结构后，给页面上的部分内容填充类 loading 态的灰色背景。

得到骨架屏后，接下来可以有两种使用方法