最近遇到一个问题，一个内容站是否适合前后端分离。对于我这之前并不是一个问题：
- 因为对于内容站我压根不会考虑前后端分离，毕竟后端模板已经足够灵活，完全没有分离的必要。
- 而 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 聊聊， 查看更多联系方式
