C端服务端渲染（SSR）和性能优化实践 桑世龙

1. React SSR的C端实践 狼叔 阿里巴巴前端技术专家

2. 自我介绍

3. 自我介绍

4. 狼叔和狼书的故事

5. 今天的前端…

6.

7. 目录 1、为什么要上SSR？ 2、从CSR到SSR演进之路 3、API与模块拆分 4、优化实践

8. 1、为什么要上SSR？ 背景：改版而起

9. 为什么要上SSR？

10. 前端痛点 有限资源做事 能做的更多，想做的更多 前端 事多 运维 很差 API 超多

11. 三大场景和六种组合 React 1.React：现有中后台开发模式 2.Api： 只做Api聚合，内置配置、缓存、rpc等 3.Api + SSR：对于c端，将接口中间层和ssr放到一起 SSR 4.Api + React：典型的BFF模式 5.Api + SSR + React：全栈模式 API 6.SSR + React：已有项目快速提升性能，尤其是对 toB的项目非常有帮助

12. 前端能否承担全部的端侧应用开发？

13. 能不能更简单？ 既要也要还要 无服务 NoOPS 函数粒度 降低构建复杂度 拥抱变化

14. 今年重点工作 收回npm包youku和tudou包名 今年会做些开源项目

15. 2、从CSR到SSR的演进之路

16. 很古老的bigpipe 分块编码(Transfer-Encoding: chunked)

17. 性能基础

18. 2.1、Client-Side Rendering (CSR) 所有逻辑，数据获取，模板编译，路由等都是在浏览器做的

19.

20. CSR最佳实践和问题 dynamic imports umi vs cra

21.

22.

23. 2.2、预渲染(Prerending) Jekyll/Hexo/Gatsby/Next.js/Vuepress jsx编译成html 模板+webpack stats 布局SPA静态页面 Lazy load（可选）

24.

25. 2.3、React SSR 模板 + 数据 => HTML 布局 Node获取数据 bundle.js CSR Ajax获取数据

26. 2.3.1、常规SSR 布局，首屏渲染，seo 加载bundle.js， hydrate绑定事件

27. 渲染方式1：renderToString

28. 渲染方式2：renderToNodeStream

29. 核心原理

30. 有render的地方大都可以用缓存 1. 前端资源 2. 获取的数据 3. 编译结果

31. Next.js特性 1. SSR 2. Static Exporting 3. CSS-in-JS 在scr/pages/*.js都是遵守 文件名即path的做法。内 部使用react-router封 装。在执行过程中 -loadGetInitialProps()， 获得执行getInitialProps 静态方法的返回值props - 将props传给 src/pages/*.js里标准 react组件的props

32. Umi SSR 方案1：页面级别 类似于Next模式 loadGetInitialProps() 执行获得执行getInitialProps 赋值给组件的props 方案2：组件级别 bigpipe方式组件写法同next loadGetInitialProps() 执行获得执行getInitialProps 赋值给组件的props

33. 2.3.2、扩展SSR 常规SSR，只处理了一个Stream 通过bigpipe，组合多个Stream

34. CSR 和 SSR能融合么？ 核心是请求约定为getInitialProps 通过高阶组件包一下

35. 同构思考

36. Faas和 SSR能融合么？ 完美兼容faas runtime Aws lambda 构建or直接用

37. Serverless Server-Side Rendering

38. 当前端更纯粹 视图+Ajax=CSR API 视图+API（Node）=SSR 页面即服务 API开发简化 NoOPS 面向组件开发 页面即函数 CasF = as function

39. 3、API与模块拆分 你会的越多，解决问题越容易 •产品需要应变，后端不好变，前端更容易 •后端讨厌（应付）前端，几种api都懒得根据ui/ue去定 制，能偷懒就偷懒

40. API问题 1. 一个页面的Api非常多 2. 跨域(Jsonp?) 3. Api返回的数据对前端不友好 4. 需求决定Api，Api不一定给的及时

41. 常见做法：BFF

42. SSR里API与模块拆分 每个模块是一个API layout main others

43. 拆还是合？同步还是异步 没有对错，只是看哪种场景更合适。最重要的是手里有选择权

44. 页面即服务

45. 函数即API 1. 2. 3. 4. 可靠性：99.999999999% 可用性：99.99%无限存储空间按量付费

46. 4、优化实践 Node没问题 Node + SSR怎么会有问题？ 编译 vs 缓存 QPS提升和性能排查

47. 优化过程

48.

49. 性能调优基本知识和工具

50. 火焰图 0x非常简单，已经收入到https://clinicjs.org/这个里面了

51. 未来的前端思考 前端 事多 页面即应用 函数即组件 运维 很差 API 超多 Servless，上云 不需要运维 函数即API 整个前端简单了，但应用会越来越多，未来会很好 少抱怨，多思考，未来更美好

52.

53.