服务端渲染基础

3,076 阅读7分钟

我正在参与掘金创作者训练营第4期,点击了解活动详情,一起学习吧!

概述

ReactVueAngular 等基于客户端渲染的前端框架,这类框架所构建的单页应用(SPA)具有用户体验好、渲染性能好、可维护性高等优点。但也也有一些很大的缺陷,其中主要涉及到以下两点:

  1. 首屏加载时间过长

与传统服务端渲染直接获取服务端渲染好的 HTML 不同,单页应用使用 JavaScript 在客户端生成 HTML来呈现内容,用户需要等待客户端 JS 解析执行完成才能看到页面,这就使得首屏加载时间变长,从而影响用户体验。

2.不利于 SEO

当搜索引擎爬取网站 HTML 文件时,单页应用的 HTML 没有内容,因为他它需要通过客户端 JavaScript 解析执行才能生成网页内容,而目前的主流的搜索引擎对于这一部分内容的抓取还不是很好。为了解决这两个缺陷,业界借鉴了传统的服务端直出 HTML 方案,提出在服务器端执行前端框架(React/Vue/Angular)代码生成网页内容,然后将渲染好的网页内容返回给客户端,客户端只需要负责展示就可以了;

这里为了让大家更好的理解服务端渲染应用,我们要从以下这几个小点出发,一点点进行学习

  • 渲染是什么?本质是什么?
  • 传统的服务端渲染优势在哪?,不足在哪里
  • 客户端渲染
  • 现代化的服务端渲染(同构渲染)

什么是渲染

  1. 浏览器会解析三个东西【1】:
  • 一个是HTML/SVG/XHTML,事实上,Webkit有三个C++的类对应这三类文档。解析这三种文件会产生一个DOM Tree。

  • CSS,解析CSS会产生CSS规则树。

  • Javascript,脚本,主要是通过DOM API和CSSOM API来操作DOM Tree和CSS Rule Tree.

  1. 解析完成后,浏览器引擎会通过DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。注意:Rendering Tree 渲染树并不等同于DOM树,因为一些像Header或display:none的东西就没必要放在渲染树中了。 CSS 的 Rule Tree主要是为了完成匹配并把CSS Rule附加上Rendering Tree上的每个Element。也就是DOM结点。也就是所谓的Frame。然后,计算每个Frame(也就是每个Element)的位置,这又叫layout和reflow过程。

  2. 最后通过调用操作系统Native GUI的API绘制。

例如对于我们前端开发者来说最常见的一种场景就是:请求后端接口数据,然后将数据通过模板绑定语法绑定到页面中,最终呈现给用户。这个过程就是我们这里所指的渲染

渲染本质其实就是字符串的解析替换,实现方式有很多种

传统的服务端渲染

服务端运行过程中将所需的数据结合页面模板渲染为HTML,响应给客户端浏览器。

实现原理:

  1. 客户端发送请求给服务器
  2. 服务器查询数据库,使用视图、模板引擎等拼接成html字符串,返回给客户端
  3. 客户端渲染html

优缺点【2】

  • 缺点
    • 应用的前后端部分完全耦合在一起,前端写完页面样式和结构后,再将页面交给后端套数据,最后再一起联调。
    • 前端的发布过于依赖于后端的同学;
    • 前端没有足够的发挥空间,无法充分利用现在前端生态下的一些更优秀的方案;(能不能让前端又可以摸鱼事情还不用做就更好了)
    • 由于内容都是在服务端动态生成的,所以服务端的压力较大;
    • 相比目前流行的 SPA 应用来说,用户体验一般; 优点
    • 页面渲染速度快
    • 同时 SEO 效果好。

但是不得不说,在网页应用并不复杂的情况下,这种方式也是可取的。

客户端渲染

传统的服务端渲染有很多问题,但是这些问题随着客户端 Ajax 技术的普及得到了有效的解决,Ajax 技术可以使得客户端动态获取数据变为可能,也就是说原本服务端渲染这件事儿也可以拿到客户端做了

我们就可以把【数据处理】和【页码渲染】这两件事儿分开了,也就是【后端】负责数据处理,【前端】负责页面渲染,这种分离模式极大的提高了开发效率和可维护性。

优缺点

  • 优点
    • 节省服务端资源,js动态生成页面,部署简单
    • 局部刷新,无需每次都请求完整的页面,体验更好
    • 前后端分离
  • 缺点
    • 首屏渲染慢,渲染前需要下载css和js资源
    • 无法进行SEO 当然主要还是前后端分离了,让前端工作性质上了一个档次!

感谢客户端渲染!

对于客户端渲染的 SPA 应用的问题有没有解决方案呢?

  • 服务端渲染,严格来说是现代化的服务端渲染,也叫同构渲染

现代化的服务端渲染

我们在上一小节了解到 SPA 应用有两个非常明显的问题:

  • 首屏渲染慢
  • 不利于 SEO 但是我们在复习过了服务端渲染之后,就会想到将客户端渲染的工作放到服务端渲染,这个问题不就解决了吗?

那当然不是用老版本的服务端渲染了啦,这就引出了同构渲染,也就是【服务端渲染】 + 【客户端渲染】。

分析优缺点:

  • 优点

    • 首屏渲染速度快
    • 有利于 SEO
  • 缺点

    • 开发成本高。
    • 涉及构建设置和部署的更多要求。
    • server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)

相关技术:

  • React 生态中的 Next.js

    • 没用过,不知道坑点哈哈哈哈哈
  • Vue 生态中的 Nuxt.js

    这就不得不说我在这里遇到的一些坑壁的事情了!

    • 服务端必须是 node.js 或者专门跑个 node.js 来支持;
    • document 对象找不到,在 node 环境不存在;
    • 数据预获取时,组件尚未实例化(无法使用 this )
  • Angular 生态中的 Angular Universal

    • 没用过,不知道坑点哈哈哈哈哈

总结

在对你的应用程序使用服务器端渲染 (SSR) 之前,你应该问的第一个问题是: 是否真的需要它

  • 例如,如果你正在构建一个内部仪表盘初始加载时的额外几百毫秒并不重要,这种情况下去使用服务器端渲染 (SSR) 将是一个小题大作之举
  • 如果内容到达时间要求是绝对关键的指标,在这种情况下,服务器端渲染(SSR) 可以帮助你实现最佳的初始加载性能

事实上,很多网站是出于效益的考虑才启用服务端渲染,性能倒是在其次。

  • 假设 A 网站页面中有一个关键字叫“前端性能优化”,这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。
  • 那么客户端渲染模式下,我们在搜索引擎搜索这个关键字,是找不到 A 网站的——搜索引擎只会查找现成的内容,不会帮你跑 JS 代码。
  • A网站的运营方见此情形,感到很头大:搜索引擎搜不出来,用户找不到我们,谁还会用我的网站呢?

为了把“现成的内容”拿给搜索引擎看,A 网站不得不启用服务端渲染

说白了,一切实用性为主,业务为辅,一切为炫技而做的事情说白了,都是要贴近团队、产品的!