Ssr

前言当咱们应用 Webpack 搭建一个基于 Vue 的服务端渲染我的项目时，通常会遇到一个很麻烦的问题，即咱们无奈提前获取到以后页面所需的资源，从而不能提前加载以后页面所需的 CSS，导致客户端在获取到服务端渲染的 HTML 时，失去的只有 HTML 文本而没有 CSS 款式，之后须要期待一会儿能力将 CSS 加载进去，也就是会遇到『款式闪动』这样的问题。 问题剖析这是因为 webpack 利用的代码加载机制导致的。 在大型利用中，webpack 不可能将我的项目只打包为独自的一个 js、css 文件，而是会利用 webpack 的 代码宰割 机制，将宏大的代码依照肯定的规定（比方超过肯定的大小、或者被屡次援用）进行拆分，这样代码的产出就会成为如下的样子： 注：xxx 指的是每次打包生成的文件哈希，用于更新浏览器的本地缓存，更多详情参考 官网文档// 入口文件main.xxx.jsmain.xxx.css// runtime 文件，后续重点介绍runtimechunk~main.xxx.js// 应用了异步加载形式引入而被拆分的包，如 vue-router 的路由懒加载layout.xxx.jslayout.xxx.csshome-page.xxx.jshome-page.xxx.cssuser-page.xxx.jsuser-page.xxx.css// 被拆分的子包（如果被拆分的子包中没有 css 文件的引入，那么就不会生成 css 子包）73e8df2.xxx.js73e8df2.xxx.css980e123.xxx.js如上，如果没有进行非凡的 webpack 分包配置，个别就会生成如上四种类型的包，并且如果应用了 css-minimizer-webpack-plugin 的话（PS：这个包是必须的），还会为每个援用了 css 的子包再独自生成一个对应的 css 文件。这四种类型的包在整体上还能够被具体划分为两类： 具名子包（namedChunk）随机命名子包main.xxx.js 这种入口文件，以及 home-page.xxx.js 这样异步引入同时并应用 Comments 进行命名的包，被称为『具名子包』；而相似 73e8df2.xxx.js 这种文件名是由一串随机哈希组成的文件，咱们将其称为『随机命名子包』。 通常这两种包是存在依赖关系的，随机命名子包其实就是从命名子包中拆分进去的代码，或者是多个命名子包共用的某一部分代码，依赖关系示例如下： 当咱们打包好一个 Vue 利用之后，假如 chunk 之间的依赖关系如上图所示，打包好的 HTML 会按程序内联入如下几个 js 和 css： runtimechunk~main.js73e9df.js29fe22.jsmian.jsmain.cssmian.js 被内联入 HTML 的起因是因为其是以后 Vue 利用的入口文件，不管用户拜访哪个页面都会加载，因而必须被内联到 HTML 中；73e9df.js、29fe22.js 这两个文件被内联入 HTML 的起因是因为他们属于 main.js 的依赖 chunk，vue 相干的代码就很可能被打包到这两个子包中，main.js 如果想要失常运行就必须要先加载这两个包；main.css 被内联到 HTML 的起因是因为 main.js 中援用了一些 css，这些 css 也会被视作利用加载的必要加载项。 ...

ErrorHydration failed because the initial UI does not match what was rendered on the server. 起因在出现您的应用程序时，预出现的 React 树 (SSR/SSG) 与在浏览器中首次出现期间出现的 React 树之间存在差别。第一个渲染称为 Hydration，这是 React 的一个个性。这可能会导致 React 树与 DOM 不同步，并导致出现意外的内容/属性。注：还有一种水合谬误起因是，Nextjs中并不倡议应用p标签中包裹div标签，如果呈现如此构造，那么也将导致呈现谬误。此外，antd的Typography 组件默认是p标签，当对此应用时，那么也可能会导致呈现此类问题。 水合作用是什么？为什么应用它？服务器端渲染（SSR）被 nextjs 等框架用来进步性能（LCP 和 FCP）和用户体验（SEO），它首先在服务器上渲染应用程序。它向用户返回一个残缺格局的 HTML 文档，但应用程序是“动静的”，并不是所有事件都能够通过 HTML 和 CSS 实现，所以咱们通知 React 将事件处理程序附加到 HTML 以使应用程序具备交互性。这个渲染咱们的组件和附加事件处理程序的过程被称为“水化”。这就像用交互性（JS）的“水”浇灌“干燥”的 HTML。水合作用后，咱们的应用程序变得交互式或“动静”。hydration 和 rehydration 通常能够调换应用，然而在 rehydration 期间，它在用户的设施上运行，并构建了一幅世界应该是什么样子的图画。而后将其与文档中内置的 HTML 进行比拟。这是一个称为再水合的过程。在再水合中，React 假如 DOM 不会扭转。它只是试图适应现有的 DOM。当 React 应用程序从新水合时，它假设 DOM 构造将匹配。如果不是那么你晓得将会呈现问题。用大白话来说就是，服务端渲染了一幅dom构造，而后浏览器端又依据某个状态从新渲染了一副dom构造，这时候就会产生，前后两幅构造进行交融（再水合），ssr默认构造是不变的，然而如果构造产生了扭转，那么问题就呈现了！解决一export default function Nav() { const [hasMounted, setHasMounted] = React.useState(false); React.useEffect(() => { setHasMounted(true); }, []); if (!hasMounted) { return null; } const user = getUser();{user ? <AuthenticatedNav /> : <UnauthenticatedNav />}解决二export function UserState() { const { user } = useUser(); const [isUserLoggedIn, setIsUserLoggedIn] = useState(false); useEffect(() => { setIsUserLoggedIn(!!user); }, [user]); return isUserLoggedIn;}import { UserState } from './userProvider'export default function Nav() { UserState() ? <AuthenticatedNav /> : <UnauthenticatedNav />}

前言之前接触到了 NuxtJs ，做了一些案例，发现自己还是对整个 SSR 构建流程了解的没有很透彻，决定本人入手试试从0开始搭建 Vue SSR，并且因为苦于想重构本人的博客我的项目，也借此机会将 最新的SSR技术 使用到理论我的项目中。 前端技术选型前端技术选型的核心在于 对 SSR 的反对水平，如果一个第三方库编写时没有思考到通用性，那么要将它集成到一个 SSR 利用中可能会很辣手，很有可能会呈现在node中调用浏览器API的状况。 开发框架(Vue3) 选用 Vue3 作为次要开发框架，能够应用 hooks 写法抽离局部逻辑，使代码构造更加清晰。 预处理器(Stylus) 和平时应用的 SCSS 预处理器比照， Stylus 在 CSS 代码书写上比前者简洁了不少，而且在遵循书写标准的根底上容纳度也很高，甚至能够省去不必要的冒号和分号等。 开发语言(TypeScript) 应用 TypeScript 进行类型束缚，缩小未知谬误产生概率，大胆批改逻辑内容。 网络(Axios) 选用 Axios 的起因是其成熟的双端运行能力，这为我的项目中的 SSR 带来了劣势。 UI框架(Element-plus) 选用适配 Vue3 的成熟 UI 库 Element-plus，其对 SSR 也有高度反对。 路由库(Vue-Router) 搭配 Vue3 的 Vue-Router4 ，同样也反对 SSR。 状态存储库(Pinia) 选用 Pinia ，第1点是其与 Vue3 适配，其给到了 TypeScript 智能补全的性能，且比 Vuex 更轻量更简洁(去除了 mutation )，反对 hook 写法，第2点是反对 SSR ,并且官网文档有很好的服务端反对。 ...

前言在开发SSR网站的时候，我置信大家或多或少会遇到好多问题，然而理解SSR网站的实质之后，这些都不是问题，上面就分享一下我的总结，心愿可能帮忙到大家！ 总结以next.js为例1、页面第一次加载或者跳转到某个页面、刷新页面的时候，都会先getServerSideProps办法中拿数据再渲染到客户端浏览器 2、getServerSideProps办法中的数据会全副缓存到客户端浏览器__NEXT_DATA__中，所以其它页面须要这个数据不须要再申请，能够间接拿了。 3、getServerSideProps接口申请传递cookie要从context中拿，申请完之后如果后盾接口有set-cookie又要从ctx.res.setHeader.set-cookit带回客户端浏览器 4、getServerSideProps数据能够注入到客户端浏览器中，然而客户端的数据不能注入到服务端，举个例子：你点击登录之后申请完接口返回用户的信息是客户端获取的数据，这个时候你刷新页面登录信息会失落，为什么？因为客户端数据服务端(刷新页面进入getServerSideProps办法时)获取不到，这也就是为什么开发者要把登录信息如token存储到cookie中，刷新页面也能拿！

运行在 SSR 模式下的 Angular 利用，为了防止服务器端和客户端两次调用同样的 API 引起屏幕的 Flickering 问题，通过都会应用 Angular TransferState 服务将信息从服务器发送到客户端，其工作原理如下图所示： 首先在应用程序 app.module.ts 中导入 BrowserTransferStateModule： import { BrowserModule, BrowserTransferStateModule } from '@angular/platform-browser';imports: [ BrowserModule.withServerTransition({appId: 'my-app'}), BrowserTransferStateModule, ...]而后在服务器端模块 app.server.module.ts 中导入 ServerTransferStateModule： import { ServerModule, ServerTransferStateModule } from '@angular/platform-server';imports: [ AppModule, ServerModule, ServerTransferStateModule, ...]咱们能够应用 makeStateKey 函数来创立一个键，以存储状态中的数据（将传递给浏览器）。 应用 this.state.get 从状态中获取数据，并应用 this.state.set 设置状态中的数据。 进行 API 调用时，应用之前调用 makeStateKey 创立的密钥将返回的数据存储在Angular state 中。 采纳了 TransferState 服务的 Spartacus SSR 利用，在呈现内存透露时通常有下列体现： 用户申请响应工夫减少jsapps pods 频繁重启运行时呈现如下日志：(1) SSR rendering exceeded timeout 3000, fallbacking to CSR for /xyz(2) PM2 Process 0 restarted because it exceeds --max-memory-restart value (current_memory=4009730048 max_memory_limit=3865051136 [octets])(3) Rendering of /xyz was not able to complete. This might cause memory leaks! ...

当初咱们都是通过组件的形式来开发前端页面，在浏览器外面，组件渲染时会通过 dom api 对 dom 做增删改来显示相应的内容。但在服务端并没有 dom api，咱们能够把组件渲染成 html 字符串，而后下发到浏览器渲染，因为曾经有了 html 了，就能够间接渲染成 dom，不再须要执行 JS，所以很快。 第一种浏览器渲染的形式叫做 CSR （client side render），第二种服务端渲染的形式叫做 SSR（server side render）。 很显著，SSR 渲染出画面的速度会很快，因为不须要执行 JS ，而是间接解析 html。因而，app 里嵌的页面根本都用 SSR，这样体验会更好。而且低端机执行 JS 是可能很慢的，要是 CSR，那页面可能会有很长一段白屏工夫。 此外，SSR 是间接返回了 html，这样搜索引擎的爬虫就能从中抓取到具体的内容，就会给更高的搜寻权重，也就是更有利于 SEO （search engine optimize）。 在 app 里嵌的页面、搜索引擎排名优化这两种场景下，咱们都要做 SSR。 晓得了 SSR 是什么和为什么要做 SSR，那如何实现 SSR 呢？ SSR 实现原理咱们晓得 vue 是通过 template 形容页面构造，而 react 是通过 jsx，但不论是 template 还是 jsx，编译后都会产生 render function，而后执行产生 vdom。 vdom 在浏览器里会通过 dom api 增删改 dom 来实现 CSR，在服务端会通过拼接字符串来实现 SSR。 ...

前言当初的web网站都是十分考究用户体验，个别都会采纳服务端渲染加客户端渲染一起实现性能。服务端渲染有利于搜索引擎优化（SEO），利于被网页爬虫抓取数据，多见于电商网站商品信息获取等。客户端渲染不利于搜索引擎优化，网页数据异步获取，首页加载工夫长，用户体验绝对较好，罕用于不须要对SEO敌对的中央 内容1.服务端渲染（SSR）简略了解就是浏览器发送申请后，服务器把客户端网页和数据在后盾渲染解析，之后把渲染后的后果返回客户端。服务器端渲染的页面交互能力无限，如果要实现简单交互，还是要通过引入 JavaScript 文件来辅助实现。 客户端拿到的是渲染后的后果，能够间接展现。服务器端渲染的页面在网络中传输的时候，传输的是一个实在的页面。因而，爬虫客户端当爬到咱们的页面后，会分系咱们给他提供的这个页面，此时，咱们页面中的要害数据就会被爬虫给收录了。服务端渲染能够解决首页白屏工夫过久，然而也容易导致服务器压力大，因而，能够应用服务器端的页面缓存技术，加重服务器的渲染压力。 流程让 React 代码在服务器端先执行一次，使得用户下载的 HTML 曾经蕴含了所有的页面展现内容，这样，页面展现的过程只须要经验一个 HTTP 申请周期，TTFP 工夫失去一倍以上的缩减。同时，因为 HTML 中曾经蕴含了网页的所有内容，所以网页的 SEO 成果也会变的十分好。之后，咱们让 React 代码在客户端再次执行，为 HTML 网页中的内容增加数据及事件的绑定，页面就具备了 React 的各种交互能力。 实现原理下面咱们说过，SSR 的工程中，React 代码会在客户端和服务器端各执行一次。你可能会想，这没什么问题，都是 JavaScript 代码，既能够在浏览器上运行，又能够在 Node 环境下运行。但事实并非如此，如果你的 React 代码里，存在间接操作 DOM 的代码，那么就无奈实现 SSR 这种技术了，因为在 Node 环境下，是没有 DOM 这个概念存在的，所以这些代码在 Node 环境下是会报错的。 好在 React 框架中引入了一个概念叫做虚构 DOM，虚构 DOM 是实在 DOM 的一个 JavaScript 对象映射，React 在做页面操作时，实际上不是间接操作 DOM，而是操作虚构 DOM，也就是操作一般的 JavaScript 对象，这就使得 SSR 成为了可能。在服务器，我能够操作 JavaScript 对象，判断环境是服务器环境，咱们把虚构 DOM 映射成字符串输入；在客户端，我也能够操作 JavaScript 对象，判断环境是客户端环境，我就间接将虚构 DOM 映射成实在 DOM，实现页面挂载。 SSR框架图剖析 ...

前言服务端渲染的概念这几年能够说是炒得炽热，它不是一种新型的技术，而是互联网最开始时所应用的加载技术。 那么到底是什么起因，使得人们违心拭去历史的尘埃，让服务端渲染这一古老的概念从新绽开光辉呢？ 什么是服务端渲染？服务端渲染简称 SSR，全称是 Server Side Render，是指一种传统的渲染形式，就是在浏览器申请页面URL的时候，服务端将咱们须要的HTML文本组装好，并返回给浏览器，这个HTML文本被浏览器解析之后，不须要通过 JavaScript 脚本的执行，即可间接构建出心愿的 DOM 树并展现到页面中。 SSR 有两种模式，单页面和非单页面模式，第一种是后端首次渲染的单页面利用，第二种是齐全应用后端路由的后端模版渲染模式。他们区别在于应用后端路由的水平。 与之绝对的是 CSR（Client Side Render），是一种目前风行的渲染形式，它依赖的是运行在客户端的JS，用户首次发送申请只能失去小局部的指引性HTML代码。第二次申请将会申请更多蕴含HTML字符串的JS文件。 为什么须要 SSR ？目前前端风行的框架大都是实用于构建 SPA（单页面应用程序），在SPA这个模型中，是通过动静地重写页面的局部与用户交互，而防止了过多的数据交换，响应速度天然绝对更高。 然而，SPA利用的首屏关上速度个别都很慢，因为用户首次加载须要先下载SPA框架及应用程序的代码，而后再渲染页面，并且 SPA 利用不利于 SEO 优化。 这时候，人们想着是不是能够将利用首页先加载进去，而后让首页用不到的其余 JS 文件再缓缓加载。然而因为 JS 引擎是单线程的，数据的组装过程会受到阻塞，单靠浏览器端的话不容易实现。 SSR 从新焕发生机的契机就在于此，如果将组装数据、渲染 HTML 页面的过程放在服务端，而浏览器端只负责显示接管到的 HTML 文件，那首屏的关上速度无疑会快很多。 SSR 的优缺点那么，SSR 技术到底有哪些长处呢？咱们来列举一下： 更快的响应工夫，绝对于客户端渲染，服务端渲染在浏览器申请URL之后曾经失去了一个带有数据的HTML文本，浏览器只须要解析HTML，间接构建DOM树就能够。有利于 SEO ，能够将 SEO 的要害信息间接在后盾就渲染成 HTML，而保障搜索引擎的爬虫都能爬取到要害数据，而后在他人应用搜索引擎搜寻相干的内容时，你的网页排行能靠得更前，这样你的流量就有越高。以上是 SSR 技术最次要的两大长处，虽有劣势，但毛病也不容忽视： 绝对于仅仅须要提供动态文件的服务器，SSR中应用的渲染程序天然会占用更多的CPU和内存资源。一些罕用的浏览器API可能无奈失常应用，比方window、docment和alert等，如果应用的话须要对运行的环境加以判断。开发调试会有一些麻烦，因为波及了浏览器及服务器，对于SPA的一些组件的生命周期的治理会变得复杂。可能会因为某些因素导致服务器端渲染的后果与浏览器端的后果不统一。总结以上就是对 SSR 技术的一些简要介绍，总结一下就是： SSR 进步 SPA 利用的首屏响应速度，有利于 SEO 优化。SSR 最实用于动态展现页面，如果页面动态数据较多时须要审慎应用。是否应用 SSR、应用到什么水平都须要开发者认真衡量。~ ~本文完，感激浏览！ ~ 学习乏味的常识，结识乏味的敌人，塑造乏味的灵魂！ 大家好，我是〖编程三昧〗的作者 隐逸王，我的公众号是『编程三昧』，欢送关注，心愿大家多多指教！ 你来，怀揣冀望，我有墨香相迎！ 你归，无论得失，唯以余韵相赠！ ...

1. 介绍构建过程如上图所示，应用webpack利用咱们配置不同的入口生成服务端和客户端的bundle，服务端的bundle是用来生成html字符串，客户端bundle是用来注入到服务端生成的html字符串中的，因为服务端返回的是字符串，一系列的事件须要依赖客户端打包的js代码（客户端的js + 服务端渲染的字符串）由浏览器渲染这样就实现了一个ssr的构建 长处1.利于seo优化在浏览器渲染的时候当咱们查看源代码只能看到一个<div id='app'></div> 内容是由js生成，这样不利于爬虫所爬取到，服务端渲染是将解析过程放到了服务端来做，服务端将解析好的字符串传给前端，当查看源代码时就会显示解析后的元素，爬虫更容易被检索 2.解决首页白屏的成果如果数据量比拟大那么浏览器会卡顿处于白屏状态,应用服务端渲染间接将解析好的HTML字符串传递给浏览器,大大放慢了首屏加载工夫 毛病1.占用内存所有的渲染逻辑都在服务端进行的，那么会占用更多的CPU和内存资源，当申请过多时不停的解析页面返回给客户端，会导致卡顿成果 2.浏览器Api不能应用因为页面在服务端渲染那么服务端是不能调用浏览器的api的 3.生命周期因为服务器端不晓得什么时候挂载实现，在vue中只反对beforeCreated和created两个生命周期 2. 开发前配置1.装置依赖包cnpm i webpack webpack-cli webpack-dev-server koa koa-router koa-static vue vue-router vuex vue-server-renderer vue-loader vue-style-loader css-loader html-webpack-plugin @babel/core @babel/preset-env babel-loader vue-template-compiler webpack-merge url-loader2.意识目录 3.根底代码App.vue<template> <!-- id="app" 客户端激活，服务端解析成字符串返回给客户端，使其变为由 Vue 治理的动静 DOM 的过程 --> <div id="app"> <Bar></Bar> <Foo></Foo> </div></template><script>import Bar from "./components/Bar";import Foo from "./components/Foo";export default { components: { Bar, Foo, },};</script>Bar.vue<template> <div id="bar"> Bar </div></template><style scoped>#bar { background: red;}</style>Foo.vue<template> <div> Foo <button @click="clickMe">点击</button> </div></template><script>export default { methods: { clickMe() { alert("点我"); }, },};</script>public/server.html<!DOCTYPE html><html lang="en"> <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> <!--vue-ssr-outlet--> </body></html>main.jsNode.js 服务器是一个长期运行的过程。当咱们的代码进入该过程时，它将进行一次取值并留存在内存中。这意味着如果创立一个单例对象，它将在每个传入的申请之间共享。所以咱们须要保障每次拜访都会产生一个新的Vue实例，裸露一个函数每次调用都保障是新的根实例 ...

In SAP Spartacus document there is a page for "How to Debug a Server–Side Rendered Storefront" using Visual Studio Code. https://sap.github.io/spartac... This document just introduces another way to debug, using Chrome Dev Tools instead of Visual Studio Code.The steps are written based on Spartacus library with version 3.4.1. (1) create a Storefront using Spartacus library and enable it with SSR support using Schematics，by following this document: https://sap.github.io/spartac... (2) By default a script build:ssr is generated to build Storefront and launch it in SSR mode. ...

搭建本人的SSR、动态站点生成（SSG）及封装 Vue.js 组件库搭建本人的SSR一、渲染一个Vue实例 mkdir vue-ssrcd vue-ssrnpm init -ynpm i vue vue-server-renderderserver.jsconst Vue = require('vue')const renderer = require('vue-server-renderer').createRenderer()const app = new Vue({ template: ` <div id="app"> <h1>{{message}}</h1> </div> `, data: { message: '拉钩教育' }})renderer.renderToString(app, (err, html) => { if (err) throw err console.log(html)})node server.js，运行后果：<div id="app" data-server-rendered="true"><h1>拉钩教育</h1></div>data-server-rendered="true"这个属性是为了未来客户端渲染激活接管的接口二、联合到Web服务器中 server.jsconst Vue = require('vue')const express = require('express')const renderer = require('vue-server-renderer').createRenderer()const server = express()server.get('/', (req, res) => { const app = new Vue({ template: ` <div id="app"> <h1>{{message}}</h1> </div> `, data: { message: '拉钩教育' } }) renderer.renderToString(app, (err, html) => { if (err) { return res.status(500).end('Internal Server Error.') } res.setHeader('Content-Type', 'text/html; charset=utf8') // 设置编码，避免乱码 res.end(` <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title> </head> <body> ${html} </body> </html> `) })})server.listen(3000, () => { console.log('server running at port 3000...')})三、应用HTML模板 ...

在之前的一篇文章里，初步介绍了 Jamstack 这套建站技术栈的背景以及各方面优劣势。 所以这次这篇文章会更加深刻，聊聊这套技术栈的演进以及业界的一些最佳实际。 在开始浏览之前，先解释一下文章里用到的英文缩写： CSR：Client Side Rendering，客户端（通常是浏览器）渲染；SSR：Server Side Rendering，服务端渲染；SSG：Static Site Generation，动态网站生成；ISR：Incremental Site Rendering，增量式的网站渲染；DPR：Distributed Persistent Rendering，分布式的继续渲染。从 SSR 到 SSGSSR 这套技术栈置信很多人应该都十分相熟了（如果你不相熟的话能够先浏览相干文章），React/Vue/Angular 等等都从框架层面间接提供了反对，例如在 React 中你能够这样应用： import React from 'react'import ReactDOMServer from 'react-dom/server'const html = ReactDOMServer.render(<h1>Hello, world!</h1>)SSR 最早是为了解决单页利用（SPA）产生的 SEO、首屏渲染工夫等问题而诞生的，在服务端间接实时同构渲染用户看到的页面，能最大水平上进步用户的体验，流程相似上面： 但 SSR 引入了另一个问题，既然要做服务端渲染，就必然须要一个实时在线的后盾服务（通常是基于 Node.js 的服务）用来承载页面申请，那么： 须要服务器的计算资源和公网流量来部署这套服务，并且耗费的资源与页面的访问量成正相干，当页面的访问量突增时，渲染服务也须要进行扩容；服务端只能部署在无限的几个地区，对于间隔服务端较远的用户而言，加载速度跟动态资源的 CDN 相比，慢了一个数量级（通常是 1-5ms VS 50-100+ms）；日常也存在传统服务端同样的运维、监控告警等方面的累赘，团队须要额定的人力来开发和保护。有没有方法解决这些问题呢？ 咱们从新对 SSR 进行扫视，服务端渲染出的页面，逻辑上讲能够分成上面两大块： 变动不频繁，甚至不会变动的内容：例如文章、排行榜、商品信息、举荐列表等等，这些数据非常适合缓存；变动比拟频繁，或者千人千面的内容：例如用户头像、Timeline、登录状态、实时评论等。例如，在一篇文章的页面中，文章的主题内容是偏差于动态的，很少有改变，那么每次用户的页面申请，都通过服务端来渲染就变得十分不值得，因为每次服务端渲染进去大部分内容都是一样的！ 咱们齐全能够将文章的页面渲染为动态页面，至于页面内那些动静的内容（用户头像、评论框等），就通过 HTTP API 的模式进行浏览器端渲染（CSR）： 这样做有很多益处： 因为文章内容曾经被动态化了，所以它是 SEO 敌对的，能被搜索引擎轻松爬取；大大加重了服务端渲染的资源累赘，不须要额定做一套 Node.js 服务；用户始终通过 CDN 加载页面核心内容，CDN 的边缘节点有缓存，速度极快；通过 HTTP API + CSR，页面内主要的动静内容也能够被很好地渲染；数据有变动时，从新触发一次网站的异步渲染，而后推送新的内容到 CDN 即可。因为每次都是全站渲染，所以网站的版本能够很好的与 Git 的版本对应上，甚至能够做到原子化公布和回滚。这便是 Gatsby.js、Next.js 这样的网站生成器解决的问题，他们属于 React/Vue 更上一层的框架（Meta Framework），通过 SSR 把动态化的 Web 利用渲染为多个动态页面，并且对高度动静的内容也保留了 CSR 的能力。 ...

首先感叹一句，next 真是一个版本狂人啊，一周就一个下版本1. 依照官网的形式初始化一个Next.js我的项目遇到的一些问题默认初始化的框架款式反对sass，组件级别的[name].module.css，但默认不反对less，官网提供了配置less的办法 `yarn add @zeit/next-less less`// next.config.jsconst withLess = require('@zeit/next-less')module.exports = withLess({ webpack(config, options) { config.resolve = { alias: { ...config.resolve.alias, // 配置alias同时要在tsconfig.json 配置 baseUrl，paths "@": path.resolve(__dirname, ".") }, extensions: [".ts", ".tsx", ".js", ".jsx", ".less", ".css"] }; return config }})重新启动后会报 Error: Cannot find module 'webpack' 于是就装置webpack但默认装置的是webpack@5.x，依照这个 issue，要替换成 webpack@4.x 才能够 Next.js 打包后动态资源门路中的 _next 目录哪来的 ？参考此文 打包配置 配置assetPrefix，相当于webpack外面的publicPath（将动态资源放在cdn） 但打包后html引入的动态资源地址会多一层_next目录，解决方案： 本人代码里创立 _next 目录太过繁琐，且耗费性能，故让运维在拷贝动态资源时，在oss目录上多加一层 _next 目录ssr框架 ajax 申请库的抉择node-fetch、window, document的应用注意事项getInitialProps getStaticProps getStaticPaths getServerSideProps 的区别clint Link 跳转时子页面款式文件获取不到（如同只有开发阶段有次问题，临时未解决）当进行重构我的项目时，如果不想扭转老我的项目的url（可能因为url曾经被百度seo收录），能够利用自定义node服务器，将老url转发到新的url，参考文档，然而有个问题这种被转发的url为什么浏览器申请会是 404，但页面还是会失常显示，不晓得是为什么？？？2. 生产部署接入公司cicd标准，部署没有应用传统的pm2，而是把服务放在一个容器内，服务重启靠node提供一个健康检查接口，容器来保障服务稳固，当该接口没有失常返回docker容器就会重启利用因为公司标准启动node服务都是在容器内用 node app.js，但next默认启动是靠next start启动生产服务的。解决方案是：next提供了自定义服务器，我这里采纳了koa，将next作为一个中间件来解决参考 ...

一、前言在后面几篇文章中，置信大家对vivo官网商城的前端架构演变有了肯定的理解，从稳步推动前后端拆散到小程序多端摸索实际，团队不断创新尝试。 在本文中，咱们来分享一下vivo官网商城在Node 服务端渲染（Server Side Rendering, SSR）方面的实战经验。本文次要围绕以下几个方面进行论述： CSR与SSR的比照性能优化自动化部署容灾、降级日志、监控二、背景vivo官网商城目前前后端拆散采纳的是SPA单页模式，SPA会把所有 JS 整体打包，无奈漠视的问题就是文件太大，导致渲染前期待很长时间。特地是网速差的时候，让用户期待白屏完结并非一个很好的体验。因而 vivo 官网商城前端团队尝试引入了SSR技术，以此来放慢页面首屏的访问速度，从而晋升用户体验。 三、SSR简介3.1 什么是SSR？页面渲染次要分为客户端渲染(Client Side Render)和服务端渲染(Server Side Rendering)： 客户端渲染(CSR)服务端只返回一个根本的html模板，浏览器依据html内容去加载js，获取数据，渲染出页面内容； 服务端渲染(SSR)页面的内容是在服务端渲染实现，返回到浏览器间接展现。 3.2 为什么要应用SSR？与传统 SPA (单页应用程序 (Single-Page Application)) 相比，SSR的劣势次要在于： 更好的搜索引擎优化(SEO)，SPA应用程序初始展现loading菊花图，而后通过Ajax获取内容，搜索引擎并不会期待异步实现后再行抓取页面内容；更快的内容达到工夫 (time-to-content)，特地是对于迟缓的网络状况或运行迟缓的设施，无需期待所有的JavaScript都实现下载并执行，才显示服务器渲染的标记，用户可能更疾速地看到残缺渲染的页面，晋升用户体验。下图可能更直观的反馈加载时成果。CSR和SSR页面渲染比照: 四、SSR 实际vivo官网商城我的项目的技术栈是Vue, 思考到从头搭建一套服务端渲染的利用比较复杂，所以抉择了Vue官网举荐的Nuxt.js框架，这是基于 Vue 生态的更高层的框架，为开发服务端渲染的 Vue 利用提供了极其便当的开发体验。 这里不做根底应用的分享，有趣味的同学能够到Nuxt.js官网学习根底用法；咱们次要聚焦于在整个实际过程中，次要遇到的一些挑战： 性能：如何进行性能优化，晋升QPS，节约服务器资源?容灾：如何做好容灾解决，实现主动降级？日志：如何接入日志，不便问题定位？监控：如何对Node服务进行监控？部署：如何买通公司CI/CD流程，实现自动化部署？4.1 性能优化尽管Vue SSR渲染速度曾经很快，然而因为创立组件实例和虚构DOM节点的开销，与基于字符串拼接的模板引擎的性能相差很大，在高并发状况下，服务器响应会变慢，极大的影响用户体验，因而必须进行性能优化。 4.1.1 计划1 启用缓存a、页面缓存： 在创立render实例时利用LRU-Cache来缓存渲染好的html，当再有申请拜访该页面时，间接将缓存中的html字符串返回。 nuxt.config.js减少配置： serverMiddleware: ["~/serverMiddleware/pageCache.js"]根目录创立serverMiddleware/pageCache.js b、组件缓存： 将渲染后的组件DOM存入缓存，定时刷新，有效期内取缓存中DOM。次要实用于重复使用的组件，多用于列表，例如商品列表。 配置文件nuxt.config.js： const LRU = require('lru-cache')module.exports = { render: { bundleRenderer: { cache: LRU({ max: 1000, // 最大的缓存个数 maxAge: 1000 * 60 * 5 // 缓存5分钟 }) } }}缓存组件减少name及serverCacheKey作为惟一键值： ...

React CSR：水车模型当初在了解 React CSR 时做过一个比喻，把单向数据流比作瀑布模型： 瀑布模型：由props（水管）和state（水源）把组件组织起来，组件间数据流向相似于瀑布。数据流向总是从先人到子孙（从根到叶子），不会顺流（摘自深刻 React） 单组件的宏观视角下，咱们把props了解为水管（数据通道），接管内部传递进来的数据（水），每一份state都是一处水源（设想泉眼冒水，即产生数据的中央），将这棵通过props管道连贯而成的组件建立起来，就造成了自上而下的水流（瀑布）： 设想上图整面瀑布墙上有有数的泉眼，state值顺着props管道流淌 从更巨大的视角来看，组件树就像是一系列竹管连接起来的水车，数据是水源（state、props、context以及内部数据源），水自上而下地流经整个组件树达到叶子组件，渲染出丑陋的视图 先通过一张图来感触竹管输水： 再感触水源以及水车整体的运行： 左侧的小桶就是内部数据源，随时舀起一瓢灌到某个组件（竹管）中，让其外部的state（储水）发生变化，变动的水流通过整个子树达到叶子组件，渲染出变动后的视图，这就是交互操作导致数据变动时的组件更新过程 React SSR：三体人模型CSR 模式下，咱们把水了解为数据，同样实用于 SSR，只是过程稍简单些： 服务端渲染：在服务端注入数据，构建出组件树序列化成 HTML：脱水成人干客户端渲染：达到客户端后泡水，激活水流，变回活人类比三体人的生存模式，乱纪元来长期先脱水成人干（SSR 中的服务端渲染局部），恒纪元到来后再泡水复活（SSR 中的客户端 hydrate 局部） 喝水（render）首先要有水可脱，所以先要拉取数据（水），在服务端实现组件首次渲染（mount）的过程： 也就是依据内部数据构建出初始组件树，过程中仅执行render及之前的几个生命周期，是为了尽可能缩短保命招数的前摇，尽快脱水 脱水（dehydrate）接着对组件树进行脱水，使其在顽劣的环境同样可能以一种更简略的状态“生存”下来，比方禁用了 JavaScript 的客户端环境 比组件树更简略的状态是 HTML 片段，脱去生命的水气（动态数据），成为风干标本一样的动态快照： 内存里的组件树被序列化成了动态的 HTML 片段，还能看进去人样（初始视图），不过曾经无奈与之交互了，但这种便携的状态尤其适宜运输，可能通过网络传输到地球上的某个客户端 注水（hydrate）到达客户端后，如果环境合适（没有禁用 JavaScript），就立刻开始“浸泡”（hydrate），组件随之复苏 客户端“浸泡”的过程实际上是从新创立了组件树，将新生的水（state、props、context等）注入其中，并将鲜活的组件树塞进服务端渲染的干瘪躯壳里，使之复活： 注水复活其实比三体人浸泡复苏更弱小一些，可能修复肢体性的伤害（缺失的 HTML 构造会从新创立），但并不纠正口歪眼斜之类的小毛病（疏忽属性多了少了、属性值对不上之类的问题，具体见React SSR 之原理篇） P.S.浸泡也须要肯定工夫，所以在 SSR 模式下，客户端有一段时间是无奈失常交互的，注水实现之后能力彻底复活（单向数据流和交互行为都恢复正常） 参考资料三体 I：地球往事三体 II：光明森林有所得、有所惑，真好关注「前端向后」微信公众号，你将播种一系列「用心原创」的高质量技术文章，主题包含但不限于前端、Node.js以及服务端技术 本文首发于 ayqy.net ，原文链接：http://www.ayqy.net/blog/ssr-...

前言会场是每年双十一的配角之一，会场的用户体验天然也是每年最关注的点。在日趋简单的业务需要下，如何保障咱们的用户体验不劣化甚至能更优化是永恒的命题。 往年（2020）咱们在不扭转现有架构，不扭转业务的前提下，在会场上应用了 SSR 技术，将秒开率进步到了新的高度（82.6%）；也察看到在用户体验失去优化的同时，业务指标如 UV 点击率等也有小幅的增长（视不同业务场景有不同的晋升，最大可达 5%），带来了不错的业务价值。 本文将从服务端、前端两个角度介绍咱们在 SSR 上的计划与教训 前端在解决工程化、业务成果评估上的具体实际与方法论服务端在解决前端模块代码于服务端执行、隔离和性能优化上的具体实际与方法论（更多干货欢送关注【淘系技术】公众号） 页面体验性能的外围指标在注释开始前咱们先介绍一下掂量的相干指标，从多年前雅虎 yslow 定义出了绝对残缺的体验性能评估指标，到起初的谷歌的 Lighthouse 等新工具的呈现，体验性能的评估规范逐步的对立且更加被大家认同。 会场的评估体系基于 Web.Dev 以及其余的一些参考，咱们定义了本人的简化评估体系 TTFB(Time to First Byte): 第一个字节的工夫 - 从点击链接到收到第一个字节内容的工夫 FP(First Paint): 第一次绘制 - 用户第一次看到任何像素内容的工夫 FCP(First Contentful Paint): 第一次内容绘制 - 用户看到第一次无效内容的工夫 FSP(First Screen Paint，首屏可视工夫): 第一屏内容绘制 - 用户看到第一屏内容的工夫 LCP(Largest Contentful Paint): 第一次最大内容绘制 - 用户看到最大内容的工夫 TTI(Time To Interactive): 可交互工夫 - 页面变为可交互的工夫（比方可响应事件等） 大体上来说 FSP 约等于 FCP 或 LCP 会场的现状咱们的会场页面是应用基于低代码计划的页面搭建平台产出的，一个由搭建平台产出的会场页面简略而言由两局部组成：页面框架（layout）和楼层模块。 页面框架有一份独自的构建产物（即页面的 layout html 以及根底公共的 js、css 等 assets 资源）。每个楼层模块也有独自的一份构建产物（模块的 js、css 等 assets 资源，根底公共 js 的依赖版本信息等）。 ...

写在后面React 提供的 SSR API 分为两局部，一部分面向服务端（react-dom/server），另一部分仍在客户端执行（react-dom） <img src="http://cdn.ayqy.net/data/home/qxu1001840309/htdocs/cms/wordpress/wp-content/uploads/2020/11/1_VG33xLBOqcpfctgiyh0jtA.png" alt="react ssr" width="625" height="446" class="size-large wp-image-2317" /> 一.ReactDOMServerReactDOMServer相干 API 可能在服务端将 React 组件渲染成动态的（HTML）标签： The ReactDOMServer object enables you to render components to static markup.把组件树渲染成对应 HTML 标签的工作在浏览器环境也能实现，因而，面向服务端的 React DOM API 也分为两类： 能跨 Node.js、浏览器环境运行的 String API：renderToString()、renderToStaticMarkup()只能在 Node.js 环境运行的 Stream API：renderToNodeStream()、renderToStaticNodeStream()renderToStringReactDOMServer.renderToString(element)最根底的 SSR API，输出 React 组件（精确来说是ReactElement），输入 HTML 字符串。之后由客户端 hydrate API 对服务端返回的视图构造附加上交互行为，实现页面渲染： If you call ReactDOM.hydrate() on a node that already has this server-rendered markup, React will preserve it and only attach event handlers.renderToStaticMarkupReactDOMServer.renderToStaticMarkup(element)与renderToString相似，区别在于 API 设计上，renderToStaticMarkup只用于纯展现（没有事件交互，不须要 hydrate）的场景： ...

写在后面SSR（Server-Side Rendering）并不是什么离奇的概念，前后端分层之前很长的一段时间里都是以服务端渲染为主（JSP、PHP），在服务端生成残缺的 HTML 页面（摘自前端渲染模式的摸索） 也就是说，历经 SSR 到 CSR 的大改革之后，现在又从 CSR 登程去摸索 SSR 的可能性……仿佛兜兜转转又回到了终点，在这之间产生了什么？现在的 SSR 与当年的 JSP、PHP 又有什么区别？ 一.SSR 大行其道回到论坛、博客、聊天室仍旧炽热的年代，行业最佳实际是基于 JSP、PHP、ASP/ASP.NET 的动静网站 以 PHP 为例： <?php if ( count( $_POST ) ): ?><?php include WTG_INCPATH . '/wechat_item_template.php' ?><div style="..."> <div id="wechat-post" class="wechat-post" style="..."> <div class="item" id="item-list"> <?php $order = 1; foreach ( $_POST['posts'] as $wechat_item_id ) { echo generate_item_list( $wechat_item_id, $order ); $order++; } ?> </div> <?php $order = 1; foreach ( $_POST['posts'] as $wechat_item_id ) { echo generate_item_html( $wechat_item_id, $order ); $order++; } ?> <fieldset style="..."> <section style="..."> <p style="...">如果心中仍有疑难，请查看原文并留下评论噢。（<span style="font-size:0.8em; font-weight:600">特地要紧的问题，能够间接微信分割 ayqywx</span> ）</p> </section> </fieldset></div><script> function refineStyle () { var post = document.getElementById('wechat-post'); // ul ol li var uls = post.getElementsByTagName('ul'); for (var i = uls.length - 1; i >= 0; i--) { uls[i].style.cssText = 'padding: 0; margin-left: 1.8em; margin-bottom: 1em; margin-top: -1em; list-style-type: disc;'; uls[i].removeAttribute('class'); }; } document.addEventListener('DOMContentLoaded', function() { refineStyle(); }); </script></div><?php endif ?>（摘自ayqy/wechat_subscribers，一款用来主动生成微信公众平台图文音讯的 WordPress 插件） ...

写在后面上篇SSR 的利与弊列举了 SSR 渲染模式的 6 大难题： 难题 1：如何利用存量 CSR 代码实现同构难题 2：服务的稳定性和性能要求难题 3：配套设施的建设难题 4：钱的问题难题 5：hydration 的性能损耗难题 6：数据申请这些问题是 SSR 始终以来远不如 CSR 利用宽泛的次要起因，但时至今日，Serverless、low-code、4G/5G 网络环境三大时机让 SSR 呈现了新的转折，落地开花正过后 第一大时机：Serverless无服务器计算（serverless computing）将服务器相干的配置管理工作通通交给云供应商去做，以加重用户治理云资源的累赘对云计算用户而言，Serverless 服务可能（主动）弹性伸缩而无需显式预配资源，不仅免去了云资源的管理负担，还可能按应用状况计费，这一特点在很大水平上解决了“难题 4：钱的问题”： 引入 SSR 渲染服务，实际上是在网络结构上加了一层节点，而大流量所过之处，每一层都是钱将组件渲染逻辑从客户端改到服务器执行，势必会减少老本，但无望通过 Serverless 将个中老本降到最低 另一方面，Serverless Computing的要害是 FaaS（Function as a Service），由云函数提供惯例计算能力： 间接运行后端代码，而无需思考服务器等计算资源以及服务的扩展性、稳定性等问题，甚至连日志、监控、报警等配套设施也都开箱即用也就是说，喂给 FaaS 一个 JavaScript 函数，就能上线一个高可用的服务，无需操心如何承载大流量（几万 QPS）、如何保障服务稳固牢靠……听起来有些跨时代是么，实际上，AWS Lambda、阿里云 FC、腾讯云 SCF 都曾经是成熟的商业产品了，甚至可能收费试用 无状态的模板渲染工作尤其适宜用云函数（输出 React/Vue 组件，输入 HTML）来实现，“难题 2：服务的稳定性和性能要求”最要害的后端专业性问题迎刃而解，SSR 面临的技术难题从一个高可用的组件渲染服务放大到了一个 JavaScript 函数中： 与客户端程序相比，服务端程序对稳定性和性能的要求严苛得多，例如： 稳定性：异样解体、死循环（由前端人员自行解决）性能：内存/CPU 资源占用（由 FaaS 基础设施解决）、响应速度（网络传输间隔等都要思考在内）如何应答大流量/高并发，如何辨认故障，如何降级/疾速复原（由 FaaS 基础设施解决），哪些环节须要加缓存，缓存如何更新…… FaaS 基础设施解决了大部分的性能问题和可用性问题，函数内的稳定性问题可通过纯前端伎俩解决，至于剩下的响应速度、缓存/缓存更新问题，则须要引入另一个云计算概念——边缘计算 边缘计算所谓的边缘计算，就是将计算和数据存储散布到离用户更近的（CDN）节点（或者叫边缘服务器，Edge server）上，节俭带宽的同时更快响应用户申请： ...