[Next] 服务端渲染知识补充

渲染

渲染：就是将数据和模版组装成 html

客户端渲染

客户端渲染模式下，服务端把渲染的静态文件给到客户端，客户端拿到服务端发送过来的文件自己跑一遍 js，根据 JS 运行结果，生成相应 DOM，然后渲染给用户。
html 仅仅作为静态文件，客户端在请求时，服务端不做任何处理，直接以原文件的形式返回给客户端客户端，然后根据 html 上的 JavaScript，生成 DOM 插入 html。

前端渲染的方式起源于 JavaScript 的兴起，ajax 的大热更是让前端渲染更加成熟，前端渲染真正意义上的实现了前后端分离，前端只专注于 UI 的开发，后端只专注于逻辑的开发，前后端交互只通过约定好的 API 来交互，后端提供 json 数据，前端循环 json 生成 DOM 插入到页面中去。

客户端渲染利弊

好处：网络传输数据量小、减少了服务器压力、前后端分离、局部刷新，无需每次请求完整页面、交互好可实现各种效果

坏处：不利于 SEO、爬虫看不到完整的程序源码、首屏渲染慢（渲染前需要下载一堆 js 和 css 等）

服务端渲染

页面由服务端渲染过后直接返回 html 页面给前端，url 的变更会刷新整个页面，也就是以前的 php 和 jsp 模式

服务端在返回 html 之前，在特定的区域，符号里用数据填充，再给客户端，客户端只负责解析 HTML 。
服务端渲染的模式下，当用户第一次请求页面时，由服务器把需要的组件或页面渲染成 HTML 字符串，然后把它返回给客户端。客户端拿到手的，是可以直接渲染然后呈现给用户的 HTML 内容，不需要为了生成 DOM 内容自己再去跑一遍 JS 代码。使用服务端渲染的网站，可以说是“所见即所得”，页面上呈现的内容，我们在 html 源文件里也能找到。

服务端渲染利弊

好处:首屏渲染快、利于 SEO、可以生成缓存片段，生成静态化文件、节能（对比客户端渲染的耗电）

坏处:用户体验较差、不容易维护，通常前端改了部分 html 或者 css，后端也需要修改。

对比

其实前后端的渲染本质是一样的，都是字符串的拼接，将数据渲染进一些固定格式的 html 代码中形成最终的 html 展示在用户页面上。因为字符串的拼接必然会损耗一些性能资源。

如果在服务器端渲染，那么消耗的就是 server 端的性能。
如果是在客户端渲染，常见的手段，比如是直接生成 DOM 插入到 html 中，或者是使用一些前端的模板引擎等。他们初次渲染的原理大多是将原 html 中的数据标记（例如{{text}}）替换。

为什么使用服务端渲染，它解决的是什么问题

首屏加载快相比于加载单页应用，我只需要加载当前页面的内容，而不需要像 React 或者 Vue 一样加载全部的 js 文件
SEO 优化对于单页应用，搜索引擎并不能收录到 ajax 爬取数据之后然后再动态 js 渲染出来的页面。

事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。A 网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。但性能在其次，不代表性能不重要。服务端渲染解决了一个非常关键的性能问题——首屏加载速度过慢。在客户端渲染模式下，我们除了加载 HTML，还要等渲染所需的这部分 JS 加载完，之后还得把这部分 JS 在浏览器上再跑一遍。这一切都是发生在用户点击了我们的链接之后的事情，在这个过程结束之前，用户始终见不到我们网页的庐山真面目，也就是说用户一直在等！相比之下，服务端渲染模式下，服务器给到客户端的已经是一个直接可以拿来呈现给用户的网页，中间环节早在服务端就帮我们做掉了，用户岂不“美滋滋”？

什么情况下使用服务端渲染？

通过服务端渲染的概念以及它的两个特点：首屏加载速度快、SEO 优化。
我们知道，服务端渲染其实就是由浏览器做的一些事情，我们放到了服务端去做，那么对于掘金、简书、CSDN、知乎等网站的搭建，这种在网上一搜搜出一堆东西的网站，SEO 做的很好，应该多少都用到服务端渲染了吧？当然，做服务端渲染成本是高昂的。
vue 全家桶或者 react 全家桶，都是推荐通过服务端渲染来实现路由的。
服务端渲染并非完全之策（服务器稀少而宝贵），关于首屏渲染体验以及 SEO 的优化方案很多，在不使用服务端渲染这个操作下，我们最好的处理方式就是找寻替代优化方案。

关于在 server 端还是在 browser 端渲染的选择，更多的是要看业务场景。

同构

一套代码既可以在服务端运行又可以在客户端运行，这就是同构应用。简而言之, 就是服务端直出和客户端渲染的组合, 能够充分结合两者的优势，并有效避免两者的不足。

高端点的词 Universal APP，为什么要同构，因为客户端渲染存在一个缺点，就是首屏加载过大文件或过多文件会变得特别慢，因此可以把首屏放在服务端来渲染来提升首屏速度，首屏加载过后路又开始交给客户端控制，又变成了 SPA 应用，整个代码都是用 JavaScript 来编写，服务端采用 nodejs。

同构优点

性能: 通过 Node 直出, 将传统的三次串行 http 请求简化成一次 http 请求，降低首屏渲染时间
SEO: 服务端渲染对搜索引擎的爬取有着天然的优势，虽然阿里电商体系对 SEO 需求并不强，但随着国际化的推进, 越来越多的国际业务加入阿里大家庭，很多的业务依赖 Google 等搜索引擎的流量导入，比如 Lazada.
兼容性: 部分展示类页面能够有效规避客户端兼容性问题，比如白屏。