服务端渲染or客户端渲染

Palate

已于 2022-04-30 00:54:04 修改

阅读量2.9k

点赞数 11

分类专栏：服务端渲染文章标签：前端 js

于 2022-04-27 14:24:48 首次发布

本文链接：https://blog.csdn.net/weixin_51670675/article/details/124449807

版权

服务端渲染专栏收录该内容

2 篇文章 0 订阅

订阅专栏

其实，服务端渲染不是一个新鲜的事情。
最开始的时候，其实网站都是服务端渲染的，后来是出现SPA框架进行客户端渲染。现在热点又回归服务端渲染。
通过这篇文章，带你了解服务端渲染和客户端渲染是怎么一回事。

如果想深入了解，可以看我另外一篇：
实现一个简单的SSR，了解服务端渲染

一、客户端渲染

客户端通过ajax向服务端发送请求，获取到数据后，通过JS生成DOM插入HTML页面，最终渲染给用户。
简单点说：客户端页面中的DOM是执行JS生成的。
特点：页面代码在浏览器查看不到源代码

💡 浏览器查看页面源代码：ctrl+u

例如：element官网html结构的body只有一个div：<div id="app"></div>，其他的是头部和script、link等外部引入的资源。

在这里插入图片描述

因为DOM是JS动态生成的，所以在刚开始渲染出页面的时候是空白的，等加载完JS才会生成内容。
这个不管怎么首页渲染优化都会存在的空白问题。
加上loading效果和骨架屏只是在体验上好一定，并不会加快速度。

二、服务端渲染

什么是服务端渲染

在服务器完成HTML的拼接，然后再发送给浏览器，浏览器解析HTML并加载少量必要的JS，执行JS将页面进行激活。

简单点说说

服务端发送拼接好的HTML字符串和少量JS脚本给客户端
客户端只负责解析HTML，执行JS将页面进行激活

实现简单的服务端渲染

通过一个小例子，来对服务端渲染有一个直观的认识。

开启一个express服务

const express = require("express")
const app = express()

app.get('/', (req, res) => {
  res.send(
    `	
    <html>	
      <head>	
        <title>hello</title>	
      </head>	
      <body>	
        <h1>hello</h1>	
        <p>world</p>	
      </body>	
    </html>	
  `
  )
})

app.listen(4000, () => { console.log('running 4000') })

启动之后，打开localhost: 4000可以看到页面显示了hello world。

在这里插入图片描述

ctrl+u查看源码

在这里插入图片描述

三、为什么选服务端渲染

关于在客户端渲染还是在服务端渲染的选择，更多的是要看业务场景。

1. SEO

问题描述

假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。

解决

A 网站启用服务端渲染，直接返回现成的内容

2. 性能

性能对比

其实前后端的渲染本质是一样的，都是字符串的拼接，将数据渲染进一些固定格式的html代码中形成最终的html展示在用户页面上。
因为字符串的拼接必然会损耗一些性能资源。
如果在服务器端渲染，那么消耗的就是服务端的性能。
如果是在客户端渲染，消耗的是客户端的性能

首屏加载快

客户端只需要加载并解析当前页HTML

四、替代方案

如果不是对用户体验或SEO要求到极致的话，我们依然可以选择客户端渲染，并在客户端渲染上解决首屏优化慢和不利于SEO的缺点。

处理 SEO 问题时，使用 prerender、升级搜索引擎。
白屏可以使用loading效果、骨架屏等。

五、SSR框架

最近几年，React和Vue都发布了自己的SSR框架：

React的SSR框架Next.js在2016年10月发布了1.0。
Vue的SSR框架Nuxt.js在2016年11月发布了V0.2（1.0在2017年05月发布）

六、客户端渲染和服务端渲染的左右横跳

以下内容引用方应杭（编辑于2020年）：

这要从大概八年前说起，事情是这样的

一开始，html 就是后端渲染的。不过后端发现页面中的 js 好麻烦（虽然简单，但是坑多），于是让公司招聘专门写 js 的人，也就是前端。
前端名义上是程序员，实际上就是在切图（CSS）和做特效(JS)，所以所有程序员中前端工资最低，职位也最低。所以前后端的鄙视链就出现了。
nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，于是全力支持这两种技术，造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，实际上是为了「人员分离」，也就是「前后端分家」，前端不再附属于后端团队）。
spa 之后发现 seo 问题很大，而且首屏渲染速度贼慢，但是自己选的路再难走也要走下去，于是用 nodejs 在服务端渲染这一条路被看成是一条出路。
其实这是第二个翻身的机会，如果 nodejs 服务器渲染成为主流，其实就相当于前端把后端的大部分工作给抢了，工资压过普通后端指日可待。
然而结果是 nodejs 服务端渲染始终是小众，因为后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 做渲染（比如阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。
于是 nodejs 退一步说好好好我不抢你们的工作，我只做中间层（大部分工作就是渲染页面和调用后台接口），绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。