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

QCon大会

2019/06/25 发布于 技术 分类

QCon  QCon2019 

文字内容
1. React SSR的C端实践 狼叔 阿里巴巴前端技术专家
2. 自我介绍
3. 自我介绍
4. 狼叔和狼书的故事
5. 今天的前端…
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) 所有逻辑,数据获取,模板编译,路由等都是在浏览器做的
20. CSR最佳实践和问题 dynamic imports umi vs cra
23. 2.2、预渲染(Prerending) Jekyll/Hexo/Gatsby/Next.js/Vuepress jsx编译成html 模板+webpack stats 布局SPA静态页面 Lazy load(可选)
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. 优化过程
49. 性能调优基本知识和工具
50. 火焰图 0x非常简单,已经收入到https://clinicjs.org/这个里面了
51. 未来的前端思考 前端 事多 页面即应用 函数即组件 运维 很差 API 超多 Servless,上云 不需要运维 函数即API 整个前端简单了,但应用会越来越多,未来会很好 少抱怨,多思考,未来更美好