在前端页面的渲染这块，近几年来感觉经历了从服务端渲染(多页面)=>客户端渲染(SPA)=>同构渲染的演变，虽然对各自概念大致了解，也在网上粗略看过一些资料，但始终不求甚解。趁此机会做个简单的总结。
概念
客户端渲染
在浏览器中通过JS直接进行页面的渲染路由跳转等操作，与后端的交互主要为API微服务接口的数据调用。得到数据后在前端进行分析处理和界面生成展现。比较代表性的为React,Vue,Angular三大前端框架的SPA(Single Page Application)应用。
服务端渲染
后端不仅仅进行数据的获取处理操作，同时也负责页面的生成，最终传到客户端(浏览器)的是生成的包含数据的页面。客户端所需要做的仅仅是html页面的展现和之后的DOM事件处理。代表为传统的JSP,PHP,ASP应用。
同构
前后端共用一套JS代码，采用不同的构建方式。通过Node服务器进行页面的首屏生成。在我的理解上，有点中间件的意思。
优缺点
服务端渲染
- 优点
- 优秀的SEO
- 首屏加载快
- 缺点
- 负载大：由于渲染任务都交由服务端进行，在高并发的情况下，对于服务端负载压力大，同时丧失了浏览器端作为一个天然分布式系统的优势。
- 复用性能差：因为返回的是整个页面，对于每个路由都要重新进行页面刷新，复用性能 上不友好。
- 前后端耦合严重，前端开发依赖于后端，开发形式上不友好
前端渲染
- 优点
- 天然的浏览器分布式环境
- 组件复用度高，还可以通过懒加载等进行性能的进一步优化
- 除首屏外性能响应快速
- WEB/MOBILE多端渲染
- 前后端分离开发
- 缺点
- 首屏性能差：由于页面渲染、三方包等逻辑都置于一个JS文件中，首屏加载会导致一定时间的白屏现象。
- 浏览器SEO：由于现阶段大多搜索引擎采用的爬虫算法是直接抓取页面代码分析，而SPA应用只有一个入口文件而没实质内容，SEO性能差。
同构
- 优点
- 兼顾前端渲染的大部分优点和后端渲染SEO和首屏加载的优点
- 缺点
- 需要额外的开发构建成本
- 对服务器有一定负载
细化
前端，不管采用什么渲染方式，最终都是为了增强用户体验这个相同的目的。以目前的趋势，客户端渲染和同构已为主流。对于各自的缺点，社区均涌现出大量优秀的解决方案。
首屏加载
我们说过前端渲染一个重要的不足就是首屏加载性能。究其原因是因为渲染逻辑都在浏览器端，而在开始渲染前，浏览器需要预先加载完打包的JS文件，因此出现白屏的现象。对此，社区一般采用两种方式解决。
- 代码分割
代码分割解决方案的原理是因为首屏展现内容有限，所以我们没必要将所有内容都预先加载，仅需要加载必要资源，在访问其他页面的时候再动态加载相应页面逻辑，便能通过压缩减少首屏加载JS文件大小从质上解决首屏加载慢/白屏的问题。
- 预展示
预展示从另一个角度对首屏加载提供解决办法。首屏问题带来的用户体验差原因是打开页面时用户会有一定的白屏空窗期，那我让用户知道这段时间网页在进行什么操作不就好了？因此，采用预先展示一个Loading界面或者Skeleton Screen的方式增强用户的交互性以避免用户体验中的断层和页面撕裂感，在真实页面加载完成后取消过渡层，达到一个顺滑过渡的效果。
SEO
在SEO这个问题上，前端渲染的确处于劣势。虽然Chrome和部分浏览器开始对页面进行JS的执行后抓取，但我们并不能短期内抱有太大期望。因为前端渲染的页面源文件只有几个加载项。如果要考虑SEO，就我了解的大致有以下几点：
- 通过
meta的元属性进行关键字的SEO - 提供一套静态HTML模版供浏览器抓取用以SEO
同构
同构作为一个解决前端渲染缺点的技术，主要缺点在于会增加服务器的负载，对此一般推荐对于首屏和个别页面进行SSR服务端的渲染，此外仍保持应用为SPA，充分利用浏览器特点，达到最优性能。这方面各主流框架都提供了相应解决方案，React推荐使用Next.js
渲染方案的选择
通过对三种渲染方案的分析，我们大致了解了相应的优缺点。那么在实际项目中应该如何选择。对此我认为我们可以根据实际项目的类型和特征分析。
如果是公司内部或者注重交互性，对于内容和SEO不是要求特别高的应用，推荐采用SPA前端渲染的方式。
如果是内容展示型应用，例如博客、知乎、微博这些，SEO就显得尤为重要，这时候SEO带来的收益就超过了额外的开发成本，因此采用SSR同构方案，既能保持SPA的强交互性，又能保证SEO。当然采用传统服务端渲染也是可以的。