目录

传统的服务端渲染SSR

传统服务端渲染，是服务端html模板+数据直接输出html字符串给终端，终端根据html结构加载js、css、图片等资源，渲染页面及部分动态效果。

  • 优点

    • 加载速度快，js计算少
    • 更适合SEO

  • 不足

    • 需要编写模板文件
    • js编码零散，与后端模板强关联，甚至与后端数据强关联
    • 在不使用ajax技术下，对用户不够友好，性能相对差

客户端渲染CSR

为了践行mvc或是术业有专攻或是前后端分离的理念，业界一致地将模板往前端移动，让前端统一负责模板与交互编码，单页应用也开始流行，出现了各种框架，比如react、vue、angular等渐进式框架，目的就为了提高前端自行实现终端模板与交互的开发效率与能力。

这个时候后端顶多就是提供结构化数据，终端根据结构化数据进行渲染页面。

也就是全由javascript来实现页面渲染的模式。

  • 优点

    • 前后端分离，代码不混乱
    • 容易跨pc、h5，甚至app开发
    • 节约后端资源
    • 开发者统一，分工更明确

  • 不足

    • SEO不友好，这是CSR渲染最大的弊端，如果需要SEO的话
    • 出现白屏，跳闪，首屏性能不佳
    • 仅就终端渲染来说，性能更差，毕竟整个页面完全由javascript驱动渲染

现代的服务端渲染SSR

我们即想要前后端分离，又想要SEO友好，渲染效率更好，也就是我们既想要CSR的优点，又想要传统SSR的有点。

有人提出了在服务端在拿到js文件后预先计算与解析出HTML结构，也就是当我们首次访问的时候（首屏，不是首页），服务端预先解析出html，终端直接渲染，可以解决首屏白屏、性能差及SEO不友好问题，在之后的交互，可以采用客户端渲染方式，无需每次都刷新页面，渲染效率提高，且页面友好度高。

  • 优点

    • 前后端编码与文件分离
    • 支持跨多端
    • SEO更友好
    • 界面交互更友好
    • 首屏性能相对更好

  • 不足

    • ssr很优秀，但相对更复杂
    • 需要提供服务端渲染能力
    • 还得考虑部署、负载均衡、高并发等带来的特殊问题

SSR有必要吗

如果讲究让用户的体验更友好，那SSR是很有必要的。

如果很看重SEO，又想跨多端，又想要采用CSR渲染的方式实现，那SSR是有必要的。

一切从自己的实际情况出发，复杂的不一定是最好的，简单的不一定是不好的那个，最适合你的才是最好的。

如果用户是大爷，用户很看重体验，如果项目平台是大爷，用户只关心功能与可用性，选择就不一样。

还得根据团队能力，如果团队的能力认为前后端分离不是件困恼的事，那也可以采用传统的SSR方式实现，只要在请求、数据处理、计算、获取数据、缓存、加载、渲染等环节下下功夫优化，提升性能，提升用户界面交互友好度，也是可以的。