前言
最近在大规模的改造SSR页面,所以对 SSR 技术有了一定的技术认识,想着写一篇文章来总结一下对于 SSR 初步的认识。这是一篇对产品经理友好的介绍性文章,具体的实现性技术文章在后头(主要是我们产品经理想学啊,不写可能会被打死吧狗头)PS 偶尔下楼看一看天气,真的好好看,像是P出来的屏保
目录
- ssr 是什么
- ssr 实现了什么
- ssr 适合什么样的业务
- ssr 该如何实现
正文
0. ssr 是什么
- ssr 中文名词解释即服务器渲染,就是把前端的网页放在服务器上面先跑出来一个结果,然后给用户,用户就直接能看到页面了。
1. ssr 实现了什么
- 结果:降低第一屏直出的可视时间,从而达到增加用户的可到达率,并且在某些特定场景下可以提高 SEO 能力,从而提升其他的业务指标。
- 过程:在服务端进行 html 渲染,渲染完成后将其返回到用户端,用户端直接接收到html进行渲染,从而降低用户的web端渲染时间
- 弊端:可能会增加服务端的压力,但是这种压力在特定场景下是可以进行规避,甚至降低服务端的压力
- 很多人都认为 SSR 解决的最大痛点是 SEO,但是我们有非常多的场景是不依赖搜索的,比如APP内部的商品,这时候 SSR 的场景解决的就是首屏到达速率的问题
2. ssr 适合什么样的业务
- 技术都是为了业务服务的,因此弄懂一项技术是为了什么样的业务提升目标服务是非常重要的
- ssr 分为静态页面渲染和后续的动态渲染,因此它适合强 SEO 要求的页面,静态页面渲染用于提高 SEO 水平
- ssr 也适合需要用户快速接收信息来吸引用户的页面,比如满1送一万这种超级吸引力的页面就需要很快的显示出来直击用户的心底,留住用户来让他接受下一步的信息
- ssr 如果要降低服务器的压力,就需要针对用户是千人一面的页面,或者针对用户需要快速知道第一屏信息然后愿意接收页面刷新的业务
3. ssr 该如何实现
-
- 首先是服务器端,需要有人部署中间件程序用于呈上启下的处理页面渲染的程序,大多数采用 node 来实现
-
- 移动端的页面要去支持 ssr 改造,一些特殊的变量可能在 node 环境下不存在
-
- 如果要实现服务器压力的降低,就需要在额外的服务器上面增加页面缓存,这样一个请求就不再需要进行渲染和数据请求,这样就不会增加服务器的压力。
缓存前
- 如果要实现服务器压力的降低,就需要在额外的服务器上面增加页面缓存,这样一个请求就不再需要进行渲染和数据请求,这样就不会增加服务器的压力。
缓存后
后记
写了一下 SSR 大概的运行逻辑和业务适配以及简化简化版的原理,后面应该要写三篇来具体探索一下 SSR 的原理和 SSR 实现中踩的坑以及解决方案,希望得到大家的支持~