Crie o hábito de escrever juntos! Este é o terceiro dia da minha participação no "Nuggets Daily New Plan · April Update Challenge", clique para ver os detalhes do evento .
I. Visão geral
Com a maturidade iterativa da pilha de tecnologia de front-end e da cadeia de ferramentas, a engenharia de front-end e a modularização tornaram-se as principais soluções de tecnologia. Nesta onda de tecnologia de front-end, como React, Vue, Angular , etc. frameworks, aplicativos de página única (SPAs) construídos por tais frameworks têm as vantagens de boa experiência do usuário, bom desempenho de renderização e alta capacidade de manutenção. Mas também existem algumas grandes falhas, que envolvem principalmente os dois pontos a seguir:
- O carregamento acima da dobra demora muito
Diferente da renderização tradicional do lado do servidor, que obtém diretamente o HTML renderizado pelo servidor, o aplicativo de página única usa JavaScript para gerar HTML no lado do cliente para renderizar o conteúdo. O usuário precisa aguardar a análise JS do lado do cliente e a execução seja concluída antes que eles possam ver a página, o que faz com que o tempo de carregamento da primeira tela se torne mais longo, afetando assim a experiência do usuário.
- Ruim para SEO
Quando o mecanismo de pesquisa rastreia o arquivo HTML do site, o HTML do aplicativo de página única não tem conteúdo, porque precisa ser analisado e executado pelo JavaScript do lado do cliente para gerar o conteúdo da página da Web, e os principais mecanismos de pesquisa atuais são não é muito bom em rastrear esta parte do conteúdo.
Para resolver esses dois defeitos, a indústria se baseia na tradicional solução HTML direta do lado do servidor e propõe executar o código do framework front-end (React/Vue/Angular) no lado do servidor para gerar o conteúdo da página da web, e, em seguida, retornar o conteúdo da página da Web renderizada para o cliente. O cliente só precisa ser responsável pela exibição.
Claro, não só isso, para obter uma melhor experiência do usuário, o conteúdo renderizado do servidor será ativado no lado do cliente como um aplicativo SPA, ou seja, a interação subsequente do conteúdo da página é processada através do lado do cliente Renderização.
Desta forma em poucas palavras:
- Através da renderização do lado do servidor da primeira tela, resolva o problema de renderização lenta da primeira tela e SEO desfavorável
- Assuma a interação do conteúdo da página por meio da renderização do lado do cliente para uma melhor experiência do usuário
这种方式我们通常称之为现代化的服务端渲染，也叫同构渲染，所谓的同构指的就是服务端构建渲染 + 客户端构建渲染。同理，这种方式构建的应用称之为服务端渲染应用或者是同构应用。
为了让大家更好的理解服务端渲染应用以及我们为什么需要现代化的服务端渲染，我将从以下三个方面来讲解：
- 传统的服务端渲染
- 客户端渲染
- 现代化的服务端渲染（同构渲染）
二、传统的服务端渲染
早期Web页面渲染都是在服务端完成的，即服务端运行过程中将所需的数据结合页面模板渲染为HTML，响应给客户端浏览器，所以浏览器呈现出来的是直接包含内容的页面。相信接触过JSP的同学应该对它的工作流程不陌生吧：
我本科学校开设的课程学过一点JSP这个技术，但是这是一篇针对前端同学的文章，无论如何这种方式对于没有玩儿过后端开发的同学来说可能会比较陌生，所以下面通过我们前端同学比较熟悉的 Node.js 来了解一下这种方式。
创建工作目录:
mkdir preSSR-demo
cd preSSR-demo
复制代码安装依赖：
# 创建 http 服务
npm i express
# 服务端模板引擎
npm i art-template express-art-template
复制代码服务端代码：
- 基本的 Web 服务
- 使用模板引擎
- 渲染一个页面
server.js
const express = require('express')
const fs = require('fs')
const template = require('art-template')
const app = express()
app.get('/', (req, res) => {
// 1. 得到模板内容
const templateStr = fs.readFileSync('./index.html', 'utf-8')
// 2. 得到数据
const data = JSON.parse(fs.readFileSync('./data.json', 'utf-8'))
// 3. 渲染：数据 + 模板 = 完整结果
const html = template.render(templateStr, data)
// 4. 把渲染结果发送给客户端
res.send(html)
})
app.listen(3000, () => console.log('running...'))
复制代码客户端代码：
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>传统的服务端渲染</title>
</head>
<body>
<h1>传统的服务端渲染</h1>
<h2>{{ title }}</h2>
<ul>
{{ each posts }}
<li>{{ $value.title }}</li>
{{ /each }}
</ul>
</body>
</html>
复制代码这也就是最早的网页渲染方式，也就是动态网站的核心工作步骤。在这样的一个工作过程中，因为页面 中的内容不是固定的，它有一些动态的内容。
在今天看来，这种渲染模式是不合理或者说不先进的。因为在当下这种网页越来越复杂的情况下，这种模式存在很多明显的不足：
- 应用的前后端部分完全耦合在一起，在前后端协同开发方面会有非常大的阻力；
- 前端没有足够的发挥空间，无法充分利用现在前端生态下的一些更优秀的方案；
- 由于内容都是在服务端动态生成的，所以服务端的压力较大；
- 相比目前流行的 SPA 应用来说，用户体验一般；
但是不得不说，在网页应用并不复杂的情况下，这种方式也是可取的。
三、客户端渲染
传统的服务端渲染有很多问题，但是这些问题随着客户端 Ajax 技术的普及得到了有效的解决，Ajax 技术可以使得客户端动态获取数据变为可能，也就是说原本服务端渲染这件事儿也可以拿到客户端做了。下面是基于客户端渲染的 SPA 应用的基本工作流程:
我们平时使用Vue.js开发单页面应用就是这个流程，这里就不再演示。这种模式下，我们就可以把【数据处理】和【页码渲染】这两件事儿分开了，也就是【后 端】负责数据处理，【前端】负责页面渲染，这种分离模式极大的提高了开发效率和可维护性。
但是这种模式下，也会存在一些明显的不足，其中最主要的就是：
- 首屏渲染慢：因为 HTML 中没有内容，必须等到 JavaScript 加载并执行完成才能呈现页面内容。
- SEO 问题：同样因为 HTML 中没有内容，所以对于目前的搜索引擎爬虫来说，页面中没有任何有用的信息，自然无法提取关键词，进行索引了。
对于客户端渲染的 SPA 应用的问题有没有解决方案呢？答案是：有
服务端渲染，严格来说是现代化的服务端渲染，也叫同构渲染
四、现代化的服务端渲染（前端进阶必备）
我们在上一小节了解到 SPA 应用有两个非常明显的问题：
- 首屏加载慢
- 不利于SEO
我们只是把问题抛出来了，那有没有解决办法呢？ 答案就是：服务端渲染。 也就是将客户端渲染的工作放到服务端渲染，这个问题不就解决了吗？ 但是有的同学肯定会想要问，是再让我们回到传统的服务端渲染吗？
不不不，本质上确实是需要使用到传统的服务端渲染，但是严格来讲应该叫现代化的服务端渲染，也叫同构渲染，也就是【服务端渲染】 + 【客户端渲染】。可能听起来有点晕，这个概念我们待会儿就会了解到。
Nuxt.js 是一个基于 Vue.js 生态开发的一个第三方服务端渲染框架，通过它我们可以轻松构建现代化的 服务端渲染应用。 isomorphic web apps（同构应用）：isomorphic/universal，基于 react、vue 框架，客户端渲染和 服务器端渲染的结合，在服务器端执行一次，用于实现服务器端渲染（首屏直出），在客户端再执行一 次，用于接管页面交互，核心解决 SEO 和首屏渲染慢的问题。
- 客户端发起请求
- 服务端渲染首屏内容 + 生成客户端 SPA 相关资源
- 服务端将生成的首屏资源发送给客户端
- 客户端直接展示服务端渲染好的首屏内容
- 首屏中的 SPA 相关资源执行之后会激活客户端 Vue
- 之后客户端所有的交互都由客户端 SPA 处理
我们来分析一下同构渲染的优缺点：
- 优点：首屏渲染速度快、有利于 SEO
- 缺点：
- 开发成本高。
- 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。
- 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。
相关技术
- React 生态中的 Next.js
- Vue 生态中的 Nuxt.js
- Angular 生态中的 Angular Universal
五、该不该使用服务端渲染
A primeira pergunta que você deve fazer antes de usar a renderização do lado do servidor (SSR) com seu aplicativo é se ela é realmente necessária. Isso depende em grande parte da importância do tempo para o conteúdo do aplicativo. Por exemplo, se você estiver criando um painel interno, as poucas centenas de milissegundos extras no carregamento inicial não importam; nesse caso, usar a renderização do lado do servidor (SSR) seria um acéfalo. No entanto, o requisito de tempo até o conteúdo é uma métrica absolutamente crítica e, nesse caso, a renderização do lado do servidor (SSR) pode ajudá-lo a obter o melhor desempenho de carregamento inicial.
Na verdade, muitos sites permitem a renderização do lado do servidor por motivos de eficiência, e o desempenho fica em segundo lugar. Suponha que haja uma palavra-chave chamada "otimização de desempenho de front-end" na página do site A. Essa palavra-chave é adicionada à página HTML depois que o código JS é executado nela. Então, no modo de renderização do lado do cliente, não podemos encontrar o site A quando pesquisamos essa palavra-chave no mecanismo de pesquisa - o mecanismo de pesquisa encontrará apenas conteúdo pronto e não executará o código JS para você. Quando o operador do site A viu essa situação, sentiu-se muito grande: o buscador não encontrou e o usuário não nos encontrou.Quem usaria meu site? Para mostrar "conteúdo pronto" aos mecanismos de pesquisa, o Site A teve que habilitar a renderização do lado do servidor. Mas o desempenho é o segundo, isso não significa que o desempenho não é importante.