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

更新日期: 2020-06-29 阅读次数: 1044 字数: 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 呢。

领取阿里云/腾讯云服务器优惠券

关于作者

我是来自山东烟台的一名开发者,喜欢瞎折腾,顺便记记笔记。有敢兴趣的话题,欢迎加微信 zhongwei 聊聊, 查看更多联系方式。 白天写程序,晚上哄熊孩子,可能回复有点慢,见谅。同时也欢迎关注我的微信公众号“大象工具”: 大象工具微信公众号

tags: SSR

相关文章

爱评论不评论

近期节日

查看更多节日