Vue SSR 服务端渲染是否有必要

更新日期: 2020-06-29 阅读次数: 90 字数: 886 分类: VueJS

最近遇到一个问题,一个内容站是否适合前后端分离。对于我这之前并不是一个问题:

  • 因为对于内容站我压根不会考虑前后端分离,毕竟后端模板已经足够灵活,完全没有分离的必要。
  • 而 APP 和小程序是天然的前后端分离,也没有选择性。

但是,如果是一个团队协作呢?

SSR 是什么

SSR 是 Server Side Rendering 的缩写,即服务端渲染。

Vue 有独立的专题页来讨论 SSR:

  • https://vuejs.org/v2/guide/ssr.html
  • https://ssr.vuejs.org/zh/

可见这是一个绕不过的问题。

为什么会有 SSR 概念的出现

前提是页面已经用了类似 Vue 这样的前端框架来做了单页应用,或者异步渲染内容的页面,然后不得不面对两个绕不过的问题

  • SEO。虽然 Google 足够智能,但是也没有达到可以完全支持 JS 异步渲染的页面内容。SEO 对于很多网站来说就是命根子,没有流量,再好的功能也没人能体验到。
  • 异步加载的内容,需要多等待至少一个 HTTP 请求,那么用户看到有价值内容的等待时间又变长了。

服务器端渲染 vs 预渲染 (SSR vs Prerendering)

如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面(例如 /, /about, /contact 等)的 SEO,那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML,而是使用预渲染方式,在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单,并可以将你的前端作为一个完全静态的站点。

即,非动态内容,适合预渲染。

SSR 的原理是什么

即在后台再加一层,这层夹在前端和后端之间,用后台接口数据通过 node 来生成渲染后的页面。也就是做了终端浏览器的事情。

那么问题就来了,这部分 CPU 的损耗可想而知,对于内容众多的网站来说,服务器成本会骤增。即便加上 cache,内存也会带来成本。

而这些成本,为何不能直接通过后台模板渲染来直接规避呢?只能说 SSR 已经入魔。

你真的需要 SSR 么

我觉得京东这个技术文章跟我的观点是一样的:

https://jdc.jd.com/archives/212768

SSR 它很明显可以解决首屏白屏或者SEO等问题。但是它也引入很多问题,其一,对工程师要求较高,需要同时掌握的前后端知识。其二,要考虑在服务端 Node.js 环境中的内存泄露、运行速度、并发压力等问题。 Node 层的服务可以用“脆弱”两个字来形容。其三,开发成本增加,研发周期变长等。一般来说,是需要一个强大且稳定的基础架构来支撑服务端的压力。

简单、健壮、易维护的服务才是硬道理。单纯地追求前端还是后端的势力范围,只会产生更大的内耗。对生产力毫无帮助。

真实案例

正面案例:我做的一个股价涨跌幅波段计算器,页面内做了大量的关键词 SEO 优化,排名还不错。完全是后台模板渲染,然后页面的功能部分才是用一部分 Vue 代码,方便双向绑定处理。开发效率又高,还不会影响 SEO。何必 SSR 呢。

爱评论不评论

近期节日

2020年07月06日 国际接吻日
2020年07月06日 小暑
2020年07月07日 抗日战争纪念日
2020年07月11日 世界人口日
2020年07月22日 大暑
2020年07月30日 非洲妇女日
2020年08月01日 八一建军节
2020年08月06日 国际电影节
2020年08月07日 立秋
2020年08月15日 日本投降日
2020年08月22日 处暑
2020年08月25日 七夕
查看更多节日