React在中后台业务里已经很好落地了，但对于C端（给用户使用的端，比如PC/H5）业务有其特殊性，对性能要求比较苛刻，且有SEO需求。另外团队层面也希望能够统一技术栈，小伙伴们希望成长，那么如何能够完成既要、也要、还要呢？
本次分享主要围绕C端业务下得ReactSSR实践，会讲解各种SSR方案，包括Next.js同构开发，并以一次优化的过程作为实例进行讲解。其实这些铺垫都是在工作中做的Web框架的设计而衍生出来的总结。这里先卖个关子，自研框架基于Umi框架并支持SSR的相关内容留到广州QCon上讲。下面开始正题。
曾和小弟讨论什么是SSR？他开始以为ReactSSR就是SSR，这是不完全对的，忽略了Server-sideRender的本质。其实从早期的cgi，到PHP、ASP，jsp等serverpage，这些动态网页技术都是服务器端渲染的。而ReactSSR更多是强调基于React技术栈进行的服务器端渲染，是服务器端渲染的分类之一，本文会以ReactSSR为主进行讲解。
1、为什么要上SSR？对于SSR，大家的认知大概是以下3个方面。
SEO：强需求，被搜索引擎收录是网站的基本能力。
C端性能：至少要保证首屏渲染效率，如果秒开率都无法保证，那么用户体验是极差的。
统一技术栈：目前团队以React为主，无论从团队成长，还是个人成长角度，统一技术栈的好处都是非常明显的。
诚然，以上都是大家想用SSR的原因，但对笔者来说，SSR的意义远不止如此。在技术架构升级的过程中，如果能够同时带给团队和小伙伴成长，才是两全其美的选择。目前我负责优酷PC/H5业务，在优酷落地Node.js，目前在做ReactSSR相关整合工作。玉伯曾讲过在AllinMobile的时代的尴尬——对于多端来说是毁灭性的灾难。押宝移动端在当时是正确的选择，但在今天获客成本过高，且移动端增速不足，最好的选择就是多端在产品细节上做PK，PC/H5业务的生机也正在于此。
然而历史包袱如此的重，有几方面原因：
1）页面年久失修；
2）移动端在AllinMobile时代并没有给多端提供技术支持，PC/H5是掉队的，需要补齐App端的基本能力；3）技术栈老旧，很多页面还是采用jQuery开发的，对于团队来说，这才是最痛苦的事儿。
其实所有公司都是类似的，都是用有限资源做事，希望最少的投入带来最大化的产出。可以说，通过整合SSR一举三得，将Node.js和React一同落地，顺便将基础框架也落地升级，这样的投入产出是比较高的。
2、从CSR到SSR演进之路SSR看起来很简单，如果细分一下，还是略微负责的，下面和我一起看一下从CSR到SSR演进之路。
客户端渲染(CSR)客户端渲染是目前最简单的开发方式，以React为例，CSR里所有逻辑，数据获取、模板编译、路由等都是在浏览器做的。
Webpack在工程化与构建方便提供了足够多便利，除了提供Loader和Plugin机制外，还将所有构建相关步骤都进行了封装，甚至连模块按需加载都内置，还具备Tree-shaking等能力，外加Nodecluster利用多核并行构建。很明显这是非常方便的，对前端意义重大的。开发者只需要