前端缓存的理解 或者 前端数据持久化的理解(强制缓存、协商缓存)

Posted 2023-05-06

参考技术A 缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于 缓存文件可以重复利用 ，还可以减少带宽，降低网络负荷。

        对于一个数据请求来说，可以分为发起 网络请求、后端处理、浏览器响应 三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。

①不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求

②存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存

③存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果

控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Control优先级比Expires高。

Cache-Control、Expires都是缓存到期时间，Cache-Control是相对值，Expires是绝对值，即再次发送请求时，如果时间没到期，强制缓存生效。

注：在无法确定客户端的时间是否与服务端的时间同步的情况下，Cache-Control相比于expires是更好的选择，所以同时存在时，只有Cache-Control生效。

①协商缓存生效，返回304

②协商缓存失效，返回200和请求结果

这里我们以博客的请求为例，状态码为灰色的请求则代表使用了强制缓存，请求对应的Size值则代表该缓存存放的位置，分别为from memory cache 和 from disk cache。那么from memory cache 和 from disk cache又分别代表的是什么呢？什么时候会使用from disk cache，什么时候会使用from memory cache呢？

from memory cache代表使用 内存中的缓存 ，from disk cache则代表使用的是 硬盘中的缓存 ，

前端工程化详解——理解与实践前端工程化

前言：
前端工程化一直是一个老生常谈的问题，不管是面试还是我们在公司做基建都会经常提到前端工程化，那么为什么经常会说到前端工程化，并没有听过后端工程化、Java工程化或者Python工程化呢？我们理解的前端工程化是不是一直都是Webpack的性能调优，或者是一个cli工具呢？今天我们带着问题来一起寻找一下答案吧！

文章目录

• • 一、前端工程化简介
  • • 1. 前端发展历史
  • 二、工程化整体流程
  • 三、相关面试题
  • • • 1. 一个新项目由你来做技术选型，你会从那几个方面来考虑？
      • 2. 前端项目应该如何部署上线
      • • • a. 集成
          • b. 发布
  • 四、大厂工程化实践及开源方案
  • 五、迷你工程化脚手架实践

一、前端工程化简介

我们整天再说前端工程化，那我我们思考一下，为什么会有前端工程化这个
概念？我们来一起回顾前端的发展历史，通过这个发展历史我们就能知道为什么会有【前端工程化】这个概念。

1. 前端发展历史

看下面流程图我们可以看出来
第一阶段：前端最早期的只是HTML、CSS、JS(此时只是前端发展的一个雏形，【JS】还没有模块化的概念)，随着页面发展我们发现一个页面引入太多JS脚本，将大大增加维护成本；
第二阶段：已经出现了模块的概念，会按照模块的概念进行拆分，我们如何拆分模块，如何放置这些模块？此时已经有了一个工程化的概念；
第三个阶段：模块已经划分出来，但是我们部署的时候还是想合并在一起，就涉及到了早起的打包处理；
第四个阶段：前端进一步复杂之后，前端需要承载的功能更多了，逐步开始进行前后端分离，前端也可以独立的开发了。此时前端也出来了一些新的概念，比如说：SPA、Angular、Vue等。此时就要开始考虑路由如何规划？开发时如何调试？开发完如何构建？构建完如何发布？这一切的东西才构成了【前端工程化的概念】；

综上所述我们可以看出来，前端工程化绝不只是webpack或babel构建这一块，前端工程化是一个整体，从前端开始写代码 --> 如何构建 --> 如何发布测试 --> 如何上线 --> 上线后的应用状态如何监控等，这一套的流程我们把他叫做【前端工程化】。

二、工程化整体流程

**下图所示，就是我们从零开始整个前端工程化的考虑范围**
1. 从创建项目与开发阶段--> 我们要使用脚手架，对应的Eslint规范以及我们要使用什么UI组件库
2. CI --> 持续集成： 在一个集中的环境去构建我们的项目(避免不同协作人员环境不同带来的Bug)
3. CD --> 持续部署
下面面试题 【前端项目应该如何部署上线】 会对 CI/CD做详细的介绍

为什么开篇说到后端没有工程化的概念？
我们比如Java语言，他天生就是一种企业级的开发语言，他已经把上述流程包括在里面，不需要自己在去做这些基础建设；而JS是一门脚本语言，在不断开发不断迭代的进展中演变出了前端工程化的这个概念。

三、相关面试题

1. 一个新项目由你来做技术选型，你会从那几个方面来考虑？

第二个大话题，【工程化整体流程 】都是我们需要考虑的

2. 前端项目应该如何部署上线

老规矩，先看图，下图是正常的前端发布流程

下面的流程大家觉得有什么问题吗？
很多公司都是这样的一个流程，我们要知道服务器是做什么的？服务器应该是运行一些动态的程序，比如我们的Java代码，NodeJs代码，他是动态去处理数据，处理我们客户端的请求的。但是我们打包构建好的JS是一个文件，我们把一个静态文件放置一台服务器是不是就会很浪费成本，所以下图的流程一般是后端的部署流程

前端部署一般会加上CDN(内容分发网络)
为什么要加CDN，第一优化加载速度(网络时延导致的速度过慢)，第二把不需要动态处理的文件(JS/CSS/Image/Video)放在CDN节省服务器资源。

最后两个步骤，主要是快速回滚，假如我们发布到线上的代码出现了问题，再重头集成，大概需要十分钟，而这十分钟客户一直看到的是有问题的页面！
每次 HTML 加载的时候我们会先去读取版本，然后拿到对应版本的JS/CSS,这样的话所有的CSS和JS都是有对应版本的，一旦发现问题直接通过HTML 加载上一次的版本即可。

a. 集成

这里详细解释一下为什么要在集成的环境(也叫云构建)去进行 npm run build ？
为什么不在本地环境进行构建，要在集成的环境构建，这里核心的问题就是，没有办法保证每个人的环境(比如：npm版本、node版本)是一样的，假设不环境不一样的话，构建出来的产物就会有差异，发布上线以后出现问题很难排查。

b. 发布

前端的代码应该是运行在哪里？ 运行在一台物理服务器或者云服务器上

四、大厂工程化实践及开源方案

1. 蚂蚁金服开源的 UmiJS;
   它提前预定好很多功能，我们可以做到开箱即用，其实 UmiJS 已经是前端工程化一个很好的范例与实践(包含基础配置比如路由、mock、构建(Webpack)、部署)。
   

2. 阿里开源的 飞冰
   它和 UmiJS 一样也是基于React去设计的，飞冰比 UmiJS 内置的功能要更多一点，比如：数据请求、状态管理、日志打印、菜单配置等等。
   
   

3. 字节跳动开源的 MODERN.js
   MODERN 会比飞冰与UmiJS包含的内容更多一些，它是按照业务场景把功能做了一个更细致的分类，比如：正常网站、中后台、桌面应用、微前端等等，主要的是支持Vue。
   

五、迷你工程化脚手架实践

时间有限稍后给大家补上，抱歉抱歉！！！