浅谈SSR/MPA CSR/ SPA SSG ISR

最新推荐文章于 2024-05-31 10:04:55 发布

美幻5

最新推荐文章于 2024-05-31 10:04:55 发布

阅读量164

点赞数 1

分类专栏：随记-基础知识文章标签：前端

本文链接：https://blog.csdn.net/mh_250250/article/details/133886488

版权

随记-基础知识专栏收录该内容

2 篇文章 0 订阅

订阅专栏

前言

> 这一篇想介绍一下前端 SSR/MPA CSR/SPA SSG ISR 中的名词是什么意思。毕竟是很常见的词汇。

SSR(Server Side Render)与MPA(Multi-Page Application)

SSR 全名:Server Side Render 中文翻译是服务器渲染，服务器渲染是什么意思呢?举例来说,你正在要开启浏览器(Google Chrome、Firefox、Edge...)，当你开启浏览器输入一个地址或者通过我得收藏进入一个网址的时候，这个过程中我们的浏览器会通过网络发送一个请求(Request)给服务器跟服务器说你要进入哪个页面，例如你现在要进入网站的首页，然后服务器收到这个需求之后就会回复或者回应(Response)你要的界面给浏览器，然后浏览器再去依照服务器给的东西来呈现页面给你。

上面一段如果用比较生活化的描述这一整个流程:

使用者——我
浏览器——一张白纸
网络——邮差
服务器——画家

情景概念类似:今天我(使用者)想看梵高的描述，但是这边画家很穷，每次想看什么，我都必须要提供一张白纸。并附上一张信件的内容(Request)描述，举例来讲:

> 画家你好，我希望请你帮忙画一张梵高的画像。

接下来我们就会请邮差帮我们将信件内容交给画家(服务器)，接下来画家就会依照我们信件内容开始绘画并在我们一起寄给他的白纸上进行绘画。画完之后，画家在请邮差将画好的画一起寄回去给我观看。

而这也是一般的传统开发模式，与后面要聊的东西有关系，在传统的开发上这就叫MPA(Multi-Page Application)也就是多页面应用模式，通常一个页面会搭配一个HTML页面，所以你可以看到上面的描述场景，如果我们的界面空白，而这一段也会导致使用者必须等待画家画完，在现今社会快速发展的情况下，若你的画面超过一定的秒数才出现的画，使用者就会跑掉，这里所有页面都需要服务器来处理，这里还需要每个页面都有自己的Css、Javascript文件需要下载。

如果你了解后端代码的话，我举一个例子

extends layout
block content
    .container
    h1=title

通过后端处理之后就会渲染成一个常见的HTML

<!DOCTYPE html>
<html>
  <head>
    <title>首页</title>
  </head>
  <body>
    <div class="container">
      <h1>首页</h1>
    </div>
  </body>
</html>

> 浏览器只能看懂Javascript、Html与Css，所以这一段就必须通过后端处理完之后再将Html与相对应的Css以及Javascript展示给使用者的浏览器来渲染界面，因此SSR就是渲染内容输出画面。

优缺点:

首屏速度快：每个页面相互独立，需要单独维护多个html页面，每个请求都直接返回html
切换页面比较慢：基于原生浏览器的文档跳转，因此每一次的页面更新都是一次页面的重载，这将带来巨大的重启性能消耗

CSR(Client Side Render)与SPA(Single-page Application)

CSR 全名 Client Side Render 中文翻译是客户端渲染如果你对Vue、React、或者Angular，预设上走的都是CSR。上面的SSR会通过服务器来渲染界面给使用者观看，而CSR则反过来，而是变成通过使用者的浏览器去渲染画面，这一段就不用在经过服务器了。

那服务器这时候要干什么?因为CSR的关系，服务器就可以比较单纯一点，纯粹做一些逻辑与资料处理给使用者就好，然后通过使用者的浏览器自己去处理界面，通常来讲够短就只需要丢JSON给使用者的浏览器处理就好例如:

{
  "keyID": 0,
  "blogList": [ // 文章列表
    {
      "title": "PixiJS V5 教學 (0)", // 文章標題
      "url": "https://israynotarray.com/javascript/20200203/3949702627/" // 文章 URL
    },
    ...
  ],
  "updateTime": "2020/2/18 下午 7:49:36", // 表單更新時間
  "blogUrl": "https://israynotarray.com/", // 部落格網址
  "name": "Ray" // 若有勾選願意公開暱稱則會顯示暱稱
}

> 与SSR模式相比比较，服务器端减少了处理绘画这一过程，而是单纯的处理资料给使用者就好。

上面一段如果用比较生活化的描述这一整个流程:

使用者——我
浏览器——一张白纸
网络——邮差
服务器——画家

情景概念类似:今天我(使用者)想看梵高的描述，但是这个时候因为时代进步了！所以我们不在使用白纸，而是使用一个画家准备好的电子版，这时候当然我们依然会需要和信差说我们需要什么样的画面

画家你好，我希望请你帮忙画一张梵高的画像。

这时候邮差将新建给画家后，画家这时候竟然不用开始绘画，而是在写一封信内容是:你帮我点一下电子版上的某处就可以看到了。接下来我收到信之后，依旧这份资料照做一次，确认画面就出来了。这个过程中我们缺少了绘画这一段，而是通过画家已经备好的电子版，只要依照他提供的操作我们点一点就可以看到我哦们需要的画面了。使用者体验上不但好而且快。

那么CSR通常是在讲SPA(Single-Page Application)居多，而SPA又称为单一页面应用模式，通常我们在操作的界面指挥有一个，就如同前面所讲的电子版一样，我们从头到尾都在同一个板子上，而不会应为我们要看到其他的画面，而必须一直提供新的白纸给画家，在CSR的状况下，效能会比SSR好上许多，因为CSR的效能主要来自使用者身上，所以对于服务器的负担也会降低很多。你可以试着思考一下在原本SSR开发下，当只有你一个人请求界面的时候没有什么差别可能很快，但是当有上千上万的人同时和服务器要界面的时候，这个时候效能是不是就会变差了。因为所有的资源都在服务器上。服务器的压力很大。然后使用CSR是变成我们将界面的处理交给了使用者，也就是使用者的浏览器上，因此每一个人的效果都能依据自己的电脑来决定。所以对服务的负担降低很多，而且切换界面的速度非常快速，这个过程中就会通过一个技术叫做AJAX(Asynchronous JavaScript and XML)来跟后端请求资料。

因此界面的呈现通通交给使用者后，服务器就可以专心的处理资料，在效能上就会非常强大，但是可能会有首次进入网络界面时会稍微比较慢的问题发生。CSR的模式下通常是使用了JavaScript来处理界面的渲染，可能这个JavaScript的资料就会特别大，变成使用要先下载JavaScript的资料，当下载完成之后每一次切换就会非常的流程了，刚刚也有讲到CSR大多都在讲SPA,因此SPA开发模式下，通常我们都一直固定在一个页面，可能是在index.html,然后通过模拟后端路由切换的模式达到切换界面的感觉，比较常见在Url后面郑家一个[#]例如首页切换到其他界面。

https://israynotarray.com/w3cHexSchool-Search/#/ -> https://israynotarray.com/w3cHexSchool-Search/#/user

缺点:作为一个内容网站的话，搜索引擎是非常差的，毕竟所有的界面都是通过使用者的浏览器去渲染与后端渲染模式不同，后端再给你画面时会是已经渲染完成的静态页面资料，而CSR则是通过JavaScript后来才渲染的，也叫动态页面资料，因此SEO就比较差

优缺点：

页面切换速度快:路由跳转是基于特性的实现(如vue-router,rect-router 等前端路由)而非原生浏览器的文档跳转，避免了不必要的整个页面重载
前后端分离:基于前端路由，SPA与应用后端解耦，使得前端不在依赖于后端的路由分配。
首屏时间慢:首屏除了html还要额外请求并执行js文件，通过js的空页面上渲染首屏
SEO不友好：内容都是靠js渲染生成出来的，但搜索引擎并不识别这部分内容，导致SEO效果差

辨别网站是SSR还是CSR

基本上CSR是比较好辨别的，最简单的方法使用浏览器源码模式(浏览器右键-查看网页源码)

除此之外，通常CSR就是讲SPA所以都会出现以下两个标签

<noscript><strong>We're sorry but w3hexschool-search-ts doesn't work properly without JavaScript enabled. Please enable it to continue.</strong></noscript>

中间只有一个元素

<div id="app"></div>
//如果使用网页开发者工具看上面元素里面会有很多的元素内容

以上的页面就是CSR网页，反之，如果检查原始代码，可以看到网页和代码内容相同[基本上]是SSR,但是无法一定保证，因为有些网站是纯静态网站，并没有和后台合作，所以说SSR辨别上可能没办法很准确的辨别。

就结论来讲CSR还是SSR各有优缺点，虽然看似CSR比较好，而且效能问题主要在使用者身上，因此就会有一句话[如果你想帮公司赚钱的话，就选择CSR]，但是还是需要看开发侧重点在哪里，毕竟有些网站注重的不是使用者的体验，而是SEO的排名。

SSG(Static site Generation)

SSG有两种解释 ((名词上看似不同，但是这两者生成的东西都是相同的，也就是生成一个静态的页面也称同构渲染))

Static Site Generation 静态页面生成
Server Side Generation 服务器生成

为什么提到SSG？最主要原因是CSR模式会有SEO问题，虽然前面说到Google已经有针对他们搜索引擎支援SPA开发的界面，但SSR模式的网页还是会有一定的SEO趋势，毕竟所有资料都是直接从服务器渲染而非Javascript动态渲染。

那这些状况我们会为了SEO抛弃SPA吗?不！很难，毕竟SPA的出现就是为了解决使用者体验的问题，抛弃他的话就本末倒置了,因此就诞生了一些为了解决SEO问题的框架，例如Nuxt.js(Vue)、Next.js(React)

而SSG的概念将你原本CSR只有一行标签的情况

<!DOCTYPE html>
<html lang="zh-Hant-TW">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <div id="app"></div>
</body>
</html>

变成类似SSR的情况，你可以看到一大堆的文字与HTML真是的原本#app标签内

<!DOCTYPE html>
<html lang="zh-Hant-TW">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <div id="app">
    <header>Ray</header>
    <ul>
      <li>這是一段話</li>
      <li>這是一段話</li>
      <li>這是一段話</li>
      <li>這是一段話</li>
    </ul>
    <footer>這是 footer</footer>
  </div>
</body>
</html>

执行过程：