记录项目中使用服务端渲染 ssr的体会


什么?又回到大学里面写JSP的形式了?

最近在重构一个移动端原生的项目,采用的RN+H5的结构,对于某些偏展示和活动页之类的页面都用H5做,开发和迭代都方便很多。

在APP中从Native页面跳转H5页面时,如果白屏时间稍微长一点,就会导致用户有割裂的体验,怎么在native畅快体验和RN+H5的快速开发迭代中权衡是需要好好考虑的。

为了解决H5加载慢的问题,我们采用了一系列的优化措施,目前在首次打开H5页面(无缓存)的情况下,测试环境中页面能在60+ms内出现主结构+ui,并且采用了单页应用的形式(spa),所以从H5中的链接再跳转体验就完全没问题了。


这里主要记录一下为了优化首屏加载速度才有的服务端渲染(ssr)模式。

为什么要使用服务端渲染

前面也说到了,我们的H5采用了单页应用形式,单页应用无疑会带来更加沉浸式的H5体验,尤其是在我们这种UI主架构保持一致的应用内。但是单页应用也会带来两个问题:

  1. 页面搜索引擎优化(SEO)的困难:因为单页应用通常前端在开发时只是在html中放置一个容器div,后续根据不同路由来填充内容,这样对于爬虫来说一点都不香。
  2. 首页加载慢:单页应用体积肯定要大一些撒,如果等所有js都拉下来才渲染首页,那白屏时间就太长了,体验太差。

借用next的图看一下服务端渲染和客户端渲染(这里就是浏览器)的区别:




从图中可以看出,这两种渲染方式的区别主要在于出现首屏渲染的时机。对于SSR来说,服务器返回的是结构相对完整的HTML文件,浏览器只需要解析HTML文件,就能渲染出页面。而对CSR来说,浏览器拿到的只是包含JavaScript代码的HTML文件,在浏览器渲开始渲染出页面之前,需要动态创建HTML标签。

对于上面的第一点来说,爬虫请求这个url就能直接拿到相对完整的页面结构,所以单页应用SEO的问题就迎刃而解了。当然也有其他解决SEO的方法(某些框架可以单独针对爬虫渲染一套html文件),不过目前看来服务端渲染算是比较方便成熟的解决方案。

我们是开发的原生APP内嵌H5,所以没必要考虑SEO。接下来介绍一下采用服务端渲染对于首页加载速度的提升。

从输入一个网址到展示出页面经历了哪些呢?答案复杂到可以写一本书了吧,我们这里简单的把它分为网络请求和浏览器渲染两个部分,其中网络请求占大头。而传统的模式里面,需要下载下来html文档,再下载js,执行js,通过ajax请求数据,然后再渲染出完整首屏。

对于服务端渲染,服务端收到请求后,会先去拿需要的数据(相比浏览器ajax请求,要更稳定,性能更好),然后把数据和模板结合,生成html文档直接返回给浏览器。这时浏览器只需要把拿到的html渲染出来(渲染耗时极短)。这个过程相比于传统模式,将几次网络请求合并到了一次,并且提高了性能和稳定性,首屏出现的时间能提前不少。

对于进入了首屏,跳转其他页面,通常我们是做js分片的,在首屏加载完成后,异步而非按需加载剩余js,这样在非首屏的跳转就相当迅速了,虽然会多费点流量(我身边的同学今年都换了无限流量套餐了)。所以在非首屏是没有必要再去做服务端渲染来优化的。

具体使用nuxt框架中的缺点

我们的H5项目使用的vue框架,vue比较推荐的ssr框架是nuxt.js。官方文档还不错,参见nuxt.js

在实际使用中,发现框架还是有几个问题,记录一下:

  1. 服务端渲染会加重服务端的复核,框架的服务端是在node环境运行,毕竟请求数据和渲染html都放到了服务端,所以node端压力肯定比浏览器端渲染要大一些
  2. nuxt提供方法asyncData(这里明明是同步请求,居然取这个名字)来在服务端获取首屏需要的数据,但是是单页应用内跳转,这个方法会阻塞跳转,也就是点击了跳转链接,需要等这个方法执行结束才会跳转,而不是直接进入跳转动画,这样就会造成点击了链接延迟一下的问题。不知道是否是禁用了框架自带的页面跳转动画导致的,但是默认的动画是一个进度条,在最顶部,我们的单页应用顶部的导航栏是不变的。。。。

3.项目目录结构,nuxt项目目录如下:

可以看到项目规定以page来存放每个页面,而项目的路由也是更具page的目录来生成的。但是不管是vue还是react应该都是组件化的思想,这样的结构目录在大型项目中可能会有问题。

感谢浏览,下一篇准备分享一下项目中使用React Native的体会。

声明:高翔的博客|版权所有,违者必究|如未注明,均为原创|本网站采用BY-NC-SA协议进行授权

转载:转载请注明原文链接 - 记录项目中使用服务端渲染 ssr的体会


大家好:我是练习时常两年半的前端练习生