赞
踩
CSR,即客户端渲染,数据的获取和加载都在客户端进行。而SSR则是服务端渲染,数据的获取和拼接都是在服务端进行,服务器直接返回拼接好的HTML文件,因此加载速度很快。CSR和SSR都各有优缺点。SSR对SEO更加友好,CSR反之;因为SSR到达的很快,因此不会有白屏问题,而CSR同样反之;SSR因为需要在服务端加载,因此会占用比较多的服务端资源,但CSR可以减少很多服务端资源的占用;在用户体验方面,CSR的页面跳转因为不是真正的跳转,因此会更加流畅,而SSR则是根据网络情况决定。总之,CSR和SSR都有它各自擅长的地方,如何选用主要根据具体的使用场景来决定。
同构渲染就是结合了CSR和SSR优势的一种渲染方式。同构渲染在首次渲染时与SSR是一样的,即直接返回静态HTML文件,但是有一点不同的是,同构渲染返回的文件中,不会包含已经处理好的数据。同构渲染返回的HTML文件中会包含link和script标签,浏览器在加载完这些标签后,会开始激活操作,此时,整个应用都会被CSR接管,作为CSR应用进行操作。
SSR | CSR | 同构渲染 | |
---|---|---|---|
SEO | 友好 | 不友好 | 友好 |
白屏问题 | 无 | 有 | 无 |
服务端资源占用 | 多 | 少 | 中 |
用户体验 | 差 | 好 | 好 |
可以看到,同构渲染中和了SSR和CSR各自的优势,这是一种权衡的设计方式。回顾整个Vue.js的设计,我们都能看到非常多的“权衡”,权衡之后的具体实践其实往往并不那么重要,重要的地方在于如何去思考和怎样去权衡。
在服务端的SSR渲染中,通常是只有beforeCreate和created两个生命周期的,因为在服务端中并没有可以挂载的真实DOM,因此无法执行其他的生命周期。同时,因为在服务端是没有浏览器的一些api的,因此对于这类代码,我们需要将其进行隔离处理。
第一种方法是将代码放入mounted钩子,这样代码就只会在客户端执行。
created() {
if(!import.meta.env.SSR) {
this.timer = setTimeOut(()=>{},1000);
}
}
在使用一些第三方库的时候,我们无法预测它其中是否有用到浏览器的API,因此通常最保险的方法是添加项目环境变量作为代码守卫。或者是使用一些跨平台的API,以此来减轻心智负担。
除了依赖项目环境变量外,我们还可以对不同的端,引入不同的模块。
let storage;
if(!import.meta.env.SSR) {
storage = import('./storage.js');
} else {
storage = import('./storage-server.js');
}
在CSR中,我们对于全局状态的使用和我们在SSR中是不一样的,因为CSR中的全局状态只在CSR环境中运行,而SSR中的全局状态确实当前所有访问的用户共用的,因此要避免因为一个用户修改全局状态,而其他用户得到与预想结果不同的操作这种情况。
在Vue3中,提供了组件。被他包裹的组件会再SSR渲染的过程中被忽略。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。