前言
1. 基础概念
在讲前端渲染和后端渲染之前，我们需要首先明白一些概念：前端渲染、后端渲染、同构渲染、SEO 优化...
前端渲染：
- 指使用 JS 来渲染页面大部分内容，代表是现在流行的 SPA 单页面应用
- 那些写死的 HTML 页面不是前端渲染
后端渲染：
- 指传统的 ASP、Java 或 PHP 的渲染机制，后端将数据套入模板生成最终 HTML 返回给浏览器渲染
同构渲染：
- 前后端共用 JS，首次渲染时使用 Node.js 来直出 HTML。一般来说同构渲染是介于前后端中的共有部分（还不是很理解）
SEO 优化（Search Engine Optimization）：
- 搜索引擎优化是一种利用搜索引擎的搜索规则来提高目前网站在有关搜索引擎内的自然排名的方式（使网站更适合搜索引擎的索引原则的行为）- 百度百科
- 搜索引擎优化包括内部优化和外部优化
2. 历史背景
了解了这些基础概念，我们现在需要了解一些历史。早起，前后端未完全分离时，我们的网站都是后端生成的，几乎所有网站都使用 ASP、Java、PHP 这类做后端渲染。后来随着业务的愈加复杂，浏览器性能的飞速发展，jQuery、Angular、React、Vue 等 JS 框架的崛起，开始转向了前端渲染。从 2014 年起又开始流行了同构渲染，号称是未来，集成了前后端渲染的优点，但转眼间三年过去了，很多当时壮心满满的框架（rendr、Lazo）从先驱变成了先烈。同构到底是不是未来？自己的项目该如何选型？我想不应该只停留在追求热门和拘泥于固定模式上，忽略了前后端渲染之“争”的“核心点”，关注如何提升“用户体验”
前后端优缺点
了解了前后端渲染，那哪种方式更好？这个问题是没有意义的，因为脱离业务场景谈架构都是耍流氓。那么我们首先来看看前后端渲染的优缺点，再来取长补短。
1. 前后端渲染比较
前端渲染的优势：
- 局部刷新。无需每次都进行完整页面请求
- 懒加载。如在页面初始时只加载可视区域内的数据，滚动后rp加载其它数据，可以通过 react-lazyload 实现
- 富交互。使用 JS 实现各种酷炫效果
- 节约服务器成本。省电省钱，JS 支持 CDN 部署，且部署极其简单，只需要服务器支持静态文件即可
- 天生的关注分离设计。服务器来访问数据库提供接口，JS 只关注数据获取和展现
后端渲染的优势：
- 服务端渲染不需要先下载一堆 js 和 css 后才能看到页面（首屏性能）
- SEO
- 服务端渲染不用关心浏览器兼容性问题（随着浏览器发展，这个优点逐渐消失）
- 对于电量不给力的手机或平板，减少在客户端的电量消耗很重要
以上比较可以看出，服务端渲染在++首屏性能++和 ++SEO++ 上比较突出，因为服务端无需在等待 JS 加载成功后渲染页面内容，同时由于传统的搜索引擎只会从 HTML 中抓取数据，导致前端渲染的页面无法被抓取。
前端渲染常使用的 SPA 会把所有 JS 整体打包，无法忽视的问题就是文件太大，导致渲染前等待很长时间。特别是网速差的时候，让用户等待白屏结束并非一个很好的体验。所以目前很多应用都采用首屏服务端渲染，其他采用客户端渲染。
2. 同构解决的问题
同构恰恰就是为了解决前端渲染遇到的问题才产生的，至 2014 年底伴随着 React 的崛起而被认为是前端框架应具备的一大杀器，以至于当时很多人为了用此特性而放弃 Angular 1 而转向 React。然而近3年过去了，很多产品逐渐从全栈同构的理想化逐渐转到首屏或部分同构。让我们再一次思考同构的优点真是优点吗？
同构的优点：
- 有助于 SEO
- 共用前端代码，节省开发时间
- 提高首屏性能
同构的缺点：
- 性能
- 不容忽视的服务器端和浏览器环境差异
- 内存溢出
- 异步操作
- simple store（redux）
总结
我们赞成客户端渲染是未来的主要方向，服务端则会专注于在数据和业务处理上的优势。但由于日趋复杂的软硬件环境和用户体验更高的追求，也不能只拘泥于完全的客户端渲染。同构渲染看似美好，但以目前的发展程度来看，在大型项目中还不具有足够的应用价值，但不妨碍部分使用来优化首屏性能。做同构之前 ，一定要考虑到浏览器和服务器的环境差异，站在更高层面考虑
所以，针对目前的前端环境，合理选择架构：
- 如果你的项目需要做 SEO，如果是一个后台应用，那么只要首页做一些静态内容宣导就可以了。如果是内容型的网站，那么可以考虑专门做一些页面给搜索引擎。
- 对于前端渲染首屏问题，我们可以采用分拆打包、交互优化、部分同构等一些方式
- 合理利用同构
