网页白屏

前端优化⾸屏加载

前⾔

⾃JavaScript诞⽣以来，前端技术发展⾮常迅速。移动端⽩屏优化是前端界⾯体验的⼀个重要优化⽅向，Web前端诞⽣了SSR、CSR、

预渲染等技术。在美团⽀付的前端技术体系⾥，通过预渲染提升⽹页⾸帧优化，从⽽优化了⽩屏问题，提升⽤户体验，并形成了最佳实践。

在前端渲染领域，主要有以下⼏种⽅式可供选择：

CSR预渲染SSR同构

优

点

不依赖数据FP时间最快客

户端⽤户体验好内存数据

共享

不依赖数据FCP时间⽐CSR

快客户端⽤户体验好内存数据

共享

SEO友好⾸屏性能

⾼，FMP⽐CSR和预

渲染快

SEO友好⾸屏性能⾼，FMP⽐CSR和预渲染快客户端⽤

户体验好内存数据共享客户端与服务端代码公⽤，开发效率

⾼

缺

点

SEO不友好FCP、FMP

慢

SEO不友好FMP慢

客户端数据共享成本⾼

模板维护成本⾼

Node容易形成性能瓶颈

通过对⽐，同构⽅案集合CSR与SSR的优点，可以适⽤于⼤部分业务场景。但由于在同构的系统架构中，连接前后端的Node中间层处

于核⼼链路，系统可⽤性的瓶颈就依赖于Node，⼀旦作为短板的Node挂了，整个服务都不可⽤。

结合到我们团队负责的⽀付业务场景⾥，由于⽀付业务追求极致的系统稳定性，服务不可⽤直接影响到客诉和资损，因此我们采⽤浏览器端

渲染的架构。在保证系统稳定性的前提下，还需要保障⽤户体验，所以采⽤了预渲染的⽅式。

那么究竟什么是预渲染呢？什么是FCP/FMP呢？我们先从最常见的CSR开始说起。

以Vue举例，常见的CSR形式如下：

⼀切看似很美好。然⽽，作为以⽤户体验为⾸要⽬标的我们发现了⼀个体验问题：⾸屏⽩屏问题⾸屏⽩屏问题。

为什么会⾸屏⽩屏

浏览器渲染包含HTML解析、DOM树构建、CSSOM构建、JavaScript解析、布局、绘制等等，⼤致如下图所⽰：

要搞清楚为什么会有⽩屏，就需要利⽤这个理论基础来对实际项⽬进⾏具体分析。通过DevTools进⾏分析：

等待HTML⽂档返回，此时处于⽩屏状态。

对HTML⽂档解析完成后进⾏⾸屏渲染，因为项⽬中对

加了灰⾊的背景⾊，因此呈现出灰屏。

进⾏⽂件加载、JS解析等过程，导致界⾯长时间出于灰屏中。

当Vue实例触发了mounted后，界⾯显⽰出⼤体框架。

调⽤API获取到时机业务数据后才能展⽰出最终的页⾯内容。

由此得出结论，因为要等待⽂件加载、CSSOM构建、JS解析等过程，⽽这些过程⽐较耗时，导致⽤户会长时间出于不可交互的⾸屏灰⽩

屏状态，从⽽给⽤户⼀种⽹页很“慢”的感觉。那么⼀个⽹页太“慢”，会造成什么影响呢？

“慢”的影响

的报告中指出：

57%的⽤户更在乎⽹页在3秒内是否完成加载。

52%的在线⽤户认为⽹页打开速度影响到他们对⽹站的忠实度。

每慢1秒造成页⾯PV降低11%，⽤户满意度也随之降低降低16%。

近半数移动⽤户因为在10秒内仍未打开页⾯从⽽放弃。

我们团队主要负责美团⽀付相关的业务，如果⽹站太慢会影响⽤户的⽀付体验，会造成客诉或资损。既然⽹站太“慢”会造成如此重要的影

响，那要如何优化呢？

优化思路

在⼀⽂中，共提到了4个页⾯渲染的关键指标：

基于这个理论基础，再回过头来看看之前项⽬的实际表现：

可见在FP的灰⽩屏界⾯停留了很长时间，⽤户不清楚⽹站是否有在正常加载，⽤户体验很差。

试想：如果我们可以将FCP或FMP完整的HTML⽂档提前到FP时机预渲染，⽤户看到页⾯框架，能感受到页⾯正在加载⽽不是冷冰冰

的灰⽩屏，那么⽤户更愿意等待页⾯加载完成，从⽽降低了流失率。并且这种改观在弱⽹环境下更明显。

通过对⽐FP、FCP、FMP这三个时期DOM的差异，发现区别在于：

FP：仅有⼀个div根节点。

FCP：包含页⾯的基本框架，但没有数据内容。

FMP：包含页⾯所有元素及数据。

仍然以Vue为例，在其⽣命周期中，mounted对应的是FCP，updated对应的是FMP。那么具体应该使⽤哪个⽣命周期的HTML结

构呢？

mounted(FCP)updated(FMP)

缺

点

只是视觉体验将FCP提前，实际的TTI时

间变化不⼤

构建时需要获取数据，编译速度慢构建时与运⾏时的数据存在差异性有复杂交互的页⾯，仍需等待，实

际的TTI时间变化不⼤

优

点

不受数据影响，编译速度快⾸屏体验好对于纯展⽰类型的页⾯，FP与TTI时间近乎⼀致

通过以上的对⽐，最终选择在mounted时触发构建时预渲染。由于我们采⽤的是CSR的架构，没有Node作为中间层，因此要实现

DOM内容的预渲染，就需要在项⽬构建编译时完成对原始模板的更新替换。

⾄此，我们明确了构建时预渲染的⼤体⽅案。

构建时预渲染⽅案

构建时预渲染流程：

配置读取

由于SPA可以由多个路由构成，需要根据业务场景决定哪些路由需要⽤到预渲染。因此这⾥的配置⽂件主要是⽤于告知编译器需要进⾏预

渲染的路由。

在我们的系统架构⾥，脚⼿架是基于Webpack⾃研的，在此基础上可以⾃定义⾃动化构建任务和配置。

触发构建

项⽬中主要是使⽤TypeScript，利⽤TS的，我们封装了统⼀的预渲染构建的钩⼦⽅法，从⽽只⽤⼀⾏代码即可完成构建时预渲染的触

发。

装饰器：

使⽤：

构建编译

从流程图上，需要在发布机上启动模拟的浏览器环境，并通过预渲染的事件钩⼦获取当前的页⾯内容，⽣成最终的HTML⽂件。

由于我们在预渲染上的尝试⽐较早，当时还没有、、等，因此在选型上使⽤的是（PrerenderSPAPlugin早期版本也是基于

phantomjs-prebuilt实现的）。

通过phantom提供的API可获得当前HTML，⽰例如下：

为了提⾼构建效率，并⾏对配置的多个页⾯或路由进⾏预渲染构建，保证在5S内即可完成构建，流程图如下：

⽅案优化

理想很丰满，现实很⾻感。在实际投产中，构建时预渲染⽅案遇到了⼀个问题。

我们梳理⼀下简化后的项⽬上线过程：

开发->编译->上线

假设本次修改了静态⽂件中的⼀个JS⽂件，这个⽂件会通过CDN⽅式在HTML⾥引⽤，那么最终在HTML⽂档中的引⽤⽅式是

src="/">。然⽽由于项⽬还没有上线，所以其实通过完整URL的⽅式是获取不到这个⽂件的；⽽预渲染的构

建⼜是在上线动作之前，所以问题就产⽣了：

构建时预渲染⽆法正常获取⽂件，导致编译报错

怎么办？

请求劫持

因为在做预渲染时，我们使⽤启动了⼀个模拟的浏览器环境，根据phantom提供的API，可以对发出的请求加以劫持，将获取CDN⽂件

的请求劫持到本地，从⽽在根本上解决了这个问题。⽰例代码如下：

构建时预渲染研发流程及效果

最终，构建时预渲染研发流程如下：

开发阶段：

通过TypeScript的装饰器单⾏引⼊预渲染构建触发的⽅法。

发布前修改编译构建的配置⽂件。

发布阶段：

先进⾏常规的项⽬构建。

若有预渲染相关配置，则触发预渲染构建。

通过预渲染得到最终的⽂件，并完成发布上线动作。

完整的⽤户请求路径如下：

通过构建时预渲染在项⽬中的使⽤，FCP的时间相⽐之前减少了75%。

作者简介

寒阳，美团资深研发⼯程师，多年前端研发经历，负责美团⽀付钱包团队和美团⽀付前端基础技术。