客户端（前端）渲染 VS 服务端渲染
客户端渲染（CSR, Client Site Rendering）
定义：html 仅仅作为静态文件，客户端端在请求时，服务端不做任何处理，直接以原文件的形式返回给客户端客户端，然后根据 html 上的 JavaScript，生成 DOM 插入 html。
特点：fat-client，thin-server
服务端渲染（SSR, Server Site Rendering）
定义： 服务端在返回 html 之前，在特定的区域，符号里用数据填充，再给客户端，客户端只负责解析 HTML 。
特点：thin-client，fat-server
异同
- 渲染本质一样，都是字符串拼接，将数据渲染进一些固定格式的html代码中形成最终的html展示在用户页面上。
- 拼接字符串必然引起性能的消耗。
- 服务端渲染性能消耗在服务端，当用户量比较多时，缓存部分数据以避免过多数据重复渲染。
- 客户端渲染，如当下火热的 SPA(Single Page Application) 框架，Angular、React、Vue，在首次渲染时，大多是将原 html 中的数据标记（如 {{ text }} ）替换。客户端渲染较难的一点是数据更新以后，页面响应式更新时如何节省资源，直接 DOM 的读写，是很消耗性能的。 React 和 Vue 采用虚拟DOM的方式，进行 diff 后，渲染到页面上。
利弊
| 服务端渲染 | 客户端渲染 | |
|---|---|---|
| 利 | 首屏渲染快，客户端只负责解析 HTML 利于SEO 可以生成缓存片段，生成静态文件 客户端负担小，节能 |
前后端分离，前端专注于 UI，服务端专注于逻辑 可以实现局部刷新，无需每次都请求完整页面，用户体验好 给服务器减负，部署简单 交互性好，方便实现各种效果 |
| 弊 | 用交互性差，需要整页重新加载，户体验较差 可维护性差，前端改了部分HTML 或 CSS，通常服务端也需要改 频繁的服务器请求，服务器负担大 |
不利于SEO，爬虫难以爬取内容 首屏渲染慢，渲染前需要加载一堆 js 和 css 文件 客户端负担重 |
ps: 据说 Google 已经实现了可以通过执行页面中js代码的方式来爬取数据，也就是说，Google已经有能力爬取客户端渲染的页面了
同构思想的出现
出现背景： 为了解决客户端渲染首屏慢与SEO问题
大致思想： 前后端使用同一套代码，首屏使用服务端（Nodejs）渲染，将渲染好的 html 直接交给浏览器去渲染，浏览器渲染出首屏之后继续下载 js ，运行 js ，并且重新渲染页面。由于渲染好的 html 流相较于 js 来说，体积小了很多，所以采用同构方式的web页面，一定程度上解决了首屏渲染慢的问题，而且合理利用缓存策略还可以一定程度减轻服务器压力。
存在问题： 只有首屏可以被爬取， 如果说项目不是类似于淘宝这种内容型网站（网站内部各个页面都有SEO需求），那么问题就不大了
采用同构思想的框架：Nuxt.js（基于Vue）、Next.js（基于React）