C端服务端渲染和性能优化方案

1、React SSR的C端实践C端服务端渲染和性能优化方案狼叔和狼书的故事今天的前端目录1、为什么要上SSR？2、从CSR到SSR演进之路3、API与模块拆分4、优化实践1、为什么要上SSR？背景：改版而起为什么要上SSR？运维 很差前端 事多API超多能做的更多，想做的更多前端痛点有限资源做事三大场景和六种组合SSRReactAPI1. React：现有中后台开发模式2. Api： 只做Api聚合，内置配置、缓存、rpc等3. Api + SSR：对于c端，将接口中间层和ssr放到一起4. Api + React：典型的BFF模式5. Api + SSR + React：全栈模式6. SSR

2、+ React：已有项目快速提升性能，尤其是对toB的项目非常有帮助前端能否承担全部的端侧应用开发？能不能更简单？既要也要还要无服务 NoOPS函数粒度降低构建复杂度拥抱变化今年重点工作收回npm包youku和tudou包名 今年会做些开源项目2、从CSR到SSR的演进之路很古老的bigpipe分块编码(Transfer-Encoding: chunked)性能基础2.1、Client-Side Rendering (CSR)所有逻辑，数据获取，模板编译，路由等都是在浏览器做的CSR最佳实践和问题dynamic importsumi vs cra2.2、预渲染(Prerending)jsx编译

3、成html模板+webpack stats布局SPA静态页面Lazy load（可选）Jekyll/Hexo/Gatsby/Next.js/Vuepress2.3、React SSR模板 + 数据 = HTMLbundle.js布局CSRNode获取数据Ajax获取数据2.3.1、常规SSR布局，首屏渲染，seo加载bundle.js，hydrate绑定事件渲染方式1：renderToString渲染方式2：renderToNodeStream核心原理有render的地方大都可以用缓存前端资源获取的数据编译结果Next.js特性SSRStatic ExportingCSS-in-JS在scr/

4、pages/*.js都是遵守 文件名即path的做法。内 部使用react-router封装。在执行过程中-loadGetInitialProps()， 获得执行getInitialProps 静态方法的返回值props- 将props传给src/pages/*.js里标准react组件的propsUmi SSR方案1：页面级别类似于Next模式loadGetInitialProps()执行获得执行getInitialProps 赋值给组件的props方案2：组件级别bigpipe方式组件写法同nextloadGetInitialProps()执行获得执行getInitialProps 赋值给

5、组件的props2.3.2、扩展SSR常规SSR，只处理了一个Stream通过bigpipe，组合多个StreamCSR 和 SSR能融合么？核心是请求约定为getInitialProps通过高阶组件包一下同构思考Faas和 SSR能融合么？Aws lambda完美兼容faas runtime构建or直接用Serverless Server-Side Rendering当前端更纯粹视图+Ajax=CSR API视图+API（Node）=SSRAPI开发简化 NoOPS面向组件开发CasF =as function页面即服务页面即函数3、API与模块拆分你会的越多，解决问题越容易产品需要应变，后

6、端不好变，前端更容易后端讨厌（应付）前端，几种api都懒得根据ui/ue去定 制，能偷懒就偷懒一个页面的Api非常多跨域(Jsonp?)Api返回的数据对前端不友好需求决定Api，Api不一定给的及时API问题常见做法：BFFSSR里API与模块拆分每个模块是一个APIlayout main others拆还是合？同步还是异步没有对错，只是看哪种场景更合适。最重要的是手里有选择权页面即服务函数即API1.可靠性：99.999999999%2.可用性：99.99%-无限存储空间-按量付费4、优化实践QPS提升和性能排查Node没问题Node + SSR怎么会有问题？编译 vs缓存优化过程性能调优基本知识和工具火焰图0 x非常简单，已经收入到/这个里面