网站推广营销怎么做,wordpress瀑布流分页,双11销售数据,做网站的IT行业BBC 发现其网站加载时间每增加一秒#xff0c;用户便会流失 10%。为提高页面的秒开率#xff0c;我们不断探索着优化策略#xff0c;仅仅在浏览器领域下的优化已经满足不了我们的极致要求#xff0c;开始往服务端方向不断探索。本文将讨论业务接入SSR的几个问题#xff1a… BBC 发现其网站加载时间每增加一秒用户便会流失 10%。为提高页面的秒开率我们不断探索着优化策略仅仅在浏览器领域下的优化已经满足不了我们的极致要求开始往服务端方向不断探索。本文将讨论业务接入SSR的几个问题 SSR究竟适合哪些业务接入SSR后性能带来了哪些提升业务接入SSR有哪些成本 SSR适合哪些业务 SSR是将页面渲染的过程放在了服务端去执行对于性能较低的低端机或者网络情况不佳的时候不需要等待js下载执行就可以直接渲染页面。再加上通常我们会在node层去做首屏接口的聚合对于用户来说是可以更快得看到完整渲染的首页没有抖动的渲染过程有着更好的用户体验。 总的来说SSR的优劣势是 优势 有利于首屏渲染有利于SEO对于中低端机型有较大的性能提升 劣势 页面白屏时间会较长渲染完成到真正可交互还需要一段时间服务端压力较大会大量占用服务端cpu资源开发要求高学习成本相对较高 对于以上的优劣势再结合本次优化的页面具有以下几个特点决定采用SSR的渲染方案进行优化 多渠道投放分享场景多引流新用户业务方会和各种渠道合作将页面外投来获客。作为需要快速留住用户的落地页对首屏渲染性能会有着较高的要求。 中低端设备占比高中低端用户占比 60-70%。低端机主要的性能瓶颈在于代码执行和渲染时间长。 结果对比 左csr右ssr浏览器访问高速3G网络下 jsTracker SFSP 2022-10-28 00:00:00 —— 2022-11-02 00:00:00渲染方式低端机中端机高端机CSR1648.02ms 1543.64ms1257.86ms-211msSSR1545.39ms-103ms1531.11ms 1468.47ms 用户平均数据 TMQ首屏时间渲染方式低端机 vivo vivo Y67 高端机Realme X50CSR2510 ms1640msSSR1420 ms-1090ms-43%880ms-760ms-46% 单个机型数据 从用户数据对比上来看低端机性能有所提升但是高端机反而有降低。这个是符合预期的因为对于高端机来说特别是IOS端侧的性能反而是优于服务器的SSR的优势反而得不到发挥。但是在天猫优品大促的场景下用户低端机的平均数据并没有得到很大提升我们分析有如下几个原因 我们的页面是一个新页面目前比较简单js大小只有97.1 kB没能体现出SSR请求资源方面的优越性在CSR和SSR的场景下我们都使用了首屏的聚合接口。唯一的差别就是渲染方式的差别在目前手机性能普遍提升的大环境下就导致数据差异并不大。 so从这次实践中可以得出SSR在一些资源较大较复杂首屏接口较多的页面能发挥出更大的优势。 从tmq的单个机型的性能对比中我们还是可喜的发现数据有不错的提升。so在之后我们可以针对某些低性能机型进行相应的SSR优化。 SSR选型 ICE3.0和RAX的SSR方案对比 方案工程化SSR能力优势劣势Rax1、支持一体化在一个工程中完成页面逻辑和渲染服务的维护开发、调试、发布更加简单2、前后端同构同一份代码既可以进行 CSR 渲染也可以进行 SSR 渲染2、低运维成本无需维护独立 Node 应用部署即获得 SSR 页面可降级/自动降级/个性化/自定义日志稳定、建设时间较久rax体系难以应用到一些最新react社区能力ICE 3.01、react体系能力更丰富2、提供流式渲染能力现有的业务组件都是rax体系需要兼容和踩坑 因为项目对时间和稳定性都有比较高的要求所以最后我们还是选择了Rax体系。在稳定性的保障上Serverless 平台提供了基础的灰度、回滚、监控的能力Rax提供了自动降级能力当SSR链路出错时会自动降级到CSR。 目前我们上线以来通过监控观测SSR的降级率保持在4%以下服务还是很稳定的。 开发成本 会有很多同学关心如果将原有的rax应用直接切换到SSR一体化应用中来成本会有多大 在SSR的工程中和CSR工程还是比较类似的增加了apis目录用于承载渲染函数还有一些FaaS工程的基本配置。 pages 目录和普通 CSR 工程一样承载着页面的渲染逻辑开发模式和 CSR 应用一样只需保持代码同时可在 Node 环境下运行即可。apis 目录是面向 FaaS 函数的在 render 目录下提供了 SSR 渲染函数的入口其主要工作是调用 Pages 的产物进行渲染。通常业务开发需要介入的部分是进行业务数据接口的调用来准备用于渲染的业务数据。 .
├── build.json
├── f.yml # 函数平台配置
├── jest.config.js
├── midway.config.ts
├── package.json
├── src
│ ├── apis # 函数源码
│ │ ├── configuration.ts
│ │ ├── lambda # 接口
│ │ │ ├── index.test.ts
│ │ │ └── index.ts
│ │ ├── render # 渲染函数
│ │ │ └── index
│ │ │ └── index.ts
│ │ └── typings
│ │ └── context.d.ts
│ ├── app.json
│ ├── app.ts
│ ├── components/
│ ├── document/
│ ├── pages/
│ └── typings.d.ts
└── tsconfig.json 从CSR到SSR的主要工作就是在于聚合首屏接口改变一下之前获取数据的方式同时兼容一下SSR和CSR两种渲染方式保证稳定性。 在前端的工程中难免会有方法或者库会使用到浏览器环境才有的变量如 location、navigator等。为保证 SSR 和 CSR 编码的一致性需要提供在服务器端模拟浏览器环境的能力。 还需注意的是Server 端的渲染过程是一个同步的操作其本质是将 JSX 组件渲染为 HTML 字符串。因此setState、hooks 这类异步更新状态的方法以及组件的 生命周期 方法在 Server 端不会被执行。 在开发过程中应尽量避免将用于渲染初始页面的数据通过异步的方式来更新。 总结思考 ▐ SSR并不是适合所有业务 要结合业务场景和项目状况来综合考虑性能优化的手段SSR并不是一个万能神方还是需要对症下药。 ▐ 更好的SSR 选择性结合数据我们发现中低端机更适合SSR根据机型来选择不同的渲染方式会更科学并且也会减少服务器压力。流式渲染当服务端计算时间过长或者网络环境不好时用户会看到比较长的白屏时间可以通过 ER 先返回一段 HTML 流给用户让用户可见骨架屏减少白屏时间。静态 SSR 、动态更新在页面没有个性化要求的时候可以走静态化SSR将html缓存到cdn上来达到性能更优的目标。在个性化要求较高的时候可以使用静态SSR和动态更新的方案来优化静态链路。 团队介绍 我们是大淘宝技术创新业务前端团队目前负责消费电子、家装家居、汽车的线上线下零售新模式的探索面向淘内淘外提供商家、门店、消费者最佳用户体验。团队沉淀了一定的XR、3D、2D渲染引擎创新体验技术同时面向全栈领域团队探索了 Serverless 云端研发模式在消费者前台通过端智能等手段提升消费者效率同样面向工程领域在跨端、前端工程化、中后台微前端都有一些沉淀。如果你是一位充满想象的终端极客欢迎你的加入通过自己的技术想法去改变创新业务的终端表达。目前急需校招生小伙伴简历请投递至: murong.zralibaba-inc.com。 ¤ 拓展阅读 ¤ 3DXR技术 | 终端技术 | 音视频技术 服务端技术 | 技术质量 | 数据算法
