⑴ 如何进行前端优化
1.减少 HTTP 请求....
2.使用 HTTP2
3.使用服务端渲染
4.静态资源使用 CDN
5.将 CSS 放在文件头部，JavaScript 文件放 ...
6.使用字体图标 iconfont 代替图片图标
7.善用缓存，不重复加载相同的资源
8.压缩文件
9.图片优化
(1).图片延迟加载
(2). 响应式图片
(3). 调整图片大小
(4). 降低图片质量
(5). 尽可能利用 CSS3 效果代替图片
(6). 使用 webp 格式的图片
10. 通过 webpack 按需加载代码，提取第三库代码，减少 ES6 转为 ES5 的冗余代码
11. 减少重绘重排
12. 使用事件委托
13. 注意程序的局部性
14. if-else 对比 switch
15. 查找表
16. 避免页面卡顿
17. 使用 requestAnimationFrame 来实现视觉变化
18. 使用 Web Workers
19. 使用位操作
20. 不要覆盖原生方法
21. 降低 CSS 选择器的复杂性
(1). 浏览器读取选择器，遵循的原则是从选择器的右边到左边读取。
(2). CSS 选择器优先级
22. 使用 flexbox 而不是较早的布局模型
23. 使用 transform 和 opacity 属性更改来实现动画
24. 合理使用规则，避免过度优化
性能优化主要分为两类：
加载时优化
运行时优化
⑵ web前端工程师如何提升技术水平
一名优秀的前端开发工程师，不单单需要掌握前端必须的各种技术，同时还要掌握其它技术，需要掌握一点后台的知识，同时也要对网站构架有一定的了解，同时还要掌握一定的SEO网站优化技术，这样才可以称之为一个“优秀的web前端开发工程师”。除了技术以外，还需要一定的时间来沉淀自己。一名资深的优秀web前端开发工程师，是每个大型企业都渴望的人才。业内人士表示，宁可高薪招人，险企也不愿自己培养相关的技术人才。
Web前端开发工程师如何才能做得更好呢？千锋武汉为你详细分析一下。
第一，必须掌握基本的Web前端开发技术，其中包括：CSS、HTML、SEO、DOM、BOM、Ajax、Java等，在掌握这些技术的同时，还要清楚地了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug。
第二，在一名合格的前端工程师的知识结构中，网站性能优化、SEO和服务器端的基础知识也是必须掌握的。
第三，必须学会运用各种工具进行辅助开发。
第四，除了要掌握技术层面的知识，还要掌握理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持，等等。
可见，看似简单的网页制作，如果要做得更好、更专业，真的是不简单。这就是前端开发的特点，也是让很多人困惑的原因。如此繁杂的知识体系让新手学习起来无从下手，对于老手来说，也时常不知道下一步该学什么。
代码质量是前端开发中应该重点考虑的问题之一。例如，实现一个网站界面可能会有无数种方案，但有些方案的维护成本会比较高，有些方案会存在性能问题，而有些方案则更易于维护，而且性能也比较好。这里的关键影响因素就是代码质量。CSS、HTML、Java这三种前端开发语言的特点是不同的，对代码质量的要求也不同，但它们之间又有着千丝万缕的联系。
⑶ 前端性能优化之路——图片篇。
本人是一名前端开发者，在公司负责目前负责信息流服务，为五大手机厂商和各大App提供服务，每天的请求就是以亿计算，加上我们又做了SSP和DSP，就是类似于网络广告联盟，腾讯广点通这种。接触过的应该知道，所以前端优化一直是我头痛的问题，不仅要注重用户体验，同时要兼顾收益，有时候必须牺牲一些用户体验，但是作为一名有思想的前端，还是努力规避掉，希望能和从事相同业务的同学一起学习交流一下，话不多说，就来分享我的性能优化之路，有什么不对的知识点，麻烦大家指出批评。
yahoo军规把大部分的前端优化都提到了，而在js优化这一块如果有兴趣的额，推荐大家去看《 高性能javascript 》,书里讲的非常详细。 https://segmentfault.com/a/1190000008481413
Media Queries 调用高清背景图
通过 devicePixelRatio的值，就可以区分普通显示屏和高清屏，当devicePixelRatio值等于1时（也就是最小值），那么它普通显示屏，当devicePixelRatio值大于1(通常是1.5、2.0)，那么它就是高清显示屏。这时候我们可以让UI准备2套图片，甚至是3套图片，不同像素的图利用媒体查询结合 devicePixelRatio 可以区分普通显示屏和高清显示屏，并给出了如下CSS设计方案：
也可以用less或者sass
如果省时间通用性高，就像我们是服务端用nginx对图片进行处理，想要什么样尺寸的图片自己裁切,我们提供了按比例缩放和自定尺寸的裁切方法，地址后拼接字符串就行。
与其他图片格式相比，在肉眼无法分辨图片质量差异的情况下，WebP的空间占用是最小的，目前国内外各大互联网公司都已经开始应用这一图片格式。比如美团
想实现首先是判断，即识别单次访问的来源浏览器是否支持 webp 格式，其次是执行，如果该浏览器支持，则将原图替换为 webp 格式，并返回。如果不支持，则显示原格式图片。 http://caniuse.mojijs.com/Home/Html/item/key/webp/index.html
在识别阶段，我们有两种方法：
1. Server 处理
只要有请求，服务端就能拿到你的User-Agent信息，通过对浏览器进行分类，支持webp放在白名单里，不支持的则为黑名单。判断为白名单，则直接调用，返回webp格式图片；反之，则显示原图。这种方式的优点在于，只需定期维护白名单即可，逻辑简单；缺点则在于不可扩展、不可测试、UA判断会出现不准确的情况。
Server处理中的另一种方式是通过读取 JavaScript 种下的 cookie来实现判断。这种方式的优点是表现稳定，访问速度更快，切换无压力。但缺点是，页面静态化会导致用户切换浏览器时不能自主更新，图片服务失效。比如用户用支持webp的浏览器A请求页面，这时缓存的静态页面均使用webp图片，但当该用户使用不支持webp的浏览器B时，访问网页则会出现请求不到图片的报错。
Client 处理，是美团云为美团主站提供的处理方式。在这种处理方式中，浏览器端发送的beacon webp 请求后，通过检测其加载情况来判定 webp 支持情况，然后浏览器写一个cookie。之后通过读取浏览器cookie判断是否支持webp，就可以进行下一步替换操作了。
2.替换图片过程中也是有两种处理方式：
在 server 端处理的优点是对下游开发者透明，缺点是静态页面的缓存数量会翻倍。
替换方式如下：
在 client 端处理可以比较好地应对页面静态化的情况，主要针对懒加载（非首屏）的图片进行处理，直接通过修改懒加载器来实现。
对非懒加载的图片暂时没有特别好的办法。目前，可用替换路径的方式来处理。
Client 处理实际上效果也是不错的，美团页面里90%以上的图片都是懒加载的，基本上都可以满足需求。对于大多数用户来说，采用Client 处理实现webp转换是个不错的选择。
既然提到图片这一块，我有忍不住想扯写些题外的tracking Pixel（像素追踪），几乎所有网站都会做数据的采集，上报统计。特别是我们做SSP、DSP广告这块需要获取例如
数据永远说的是实话，数据证明一切可能。如facebook广告投放的跨境电商朋友都会使用facebook Pixel(像素追踪)以获得各环节的精准数据。这样追踪数据后，我们才能投放广告后销量上去了，哪个才是效果最好的，哪个效果不好，进而通过多个数据对比，对广告进行合理的调整优化。
国内搜狗、网络、360、新浪都是用这种 tracking Pixel 方法，实际就是利用1px 的图片，在图片地址后缀拼接你需要的信息参数，浏览器在请求任何资源的时候会发送当前系统的数据，比如浏览器信息，操作系统信息，作为http请求头送过去，他们就能统计了。
为什么不用js请求统计？
并不是所有的页面都支持JS的！NoJSStats的实现机制就是网站分析中点击流数据获取的方式之一——Web Beacons，即在页面中嵌入一个1像素的透明图片，当该页面被浏览时，图片就会被请求加载，于是在后端的服务器日志中就会记录该图片的请求日志，这样就可以获得日志记录。
例如网络：
本文引用@美团云 提供的webP方法，感谢。
⑷ 常用的前端性能优化方法有哪些
常用的优化有两部分
第一：面向内容的优化
1. 减少 HTTP 请求
2. 减少 DNS 查找
3. 避免重定向
4. 使用 Ajax 缓存
5. 延迟载入组件
6. 预先载入组件
7. 减少 DOM 元素数量
8. 切分组件到多个域
9. 最小化 iframe 的数量
10. 不要出现http 404 错误
第二：面向 Server
1. 缩小 Cookie
2. 针对 Web 组件使用域名无关性的
⑸ 前端性能优化的具体方法有哪些
解决办法一：
减少http请求次数：CSS Sprites, JS、CSS源码压缩、图片大小控制合适；网页Gzip，CDN托管，data缓存 ，图片服务器。
前端模板 JS+数据，减少由于HTML标签导致的带宽浪费，前端用变量保存AJAX请求结果，每次操作本地变量，不用请求，减少请求次数
用innerHTML代替DOM操作，减少DOM操作次数，优化javascript性能。
当需要设置的样式很多时设置className而不是直接操作style。
少用全局变量、缓存DOM节点查找的结果。减少IO读取操作。
避免使用CSS Expression（css表达式)又称Dynamic properties(动态属性)。
图片预加载，将样式表放在顶部，将脚本放在底部 加上时间戳。
解决办法二：
减少HTTP请求次数
使用CDN：CDN在前端开发的作用
避免空的src和href
为文件头指定Expires
使用gzip压缩内容
把CSS放到顶部
把JS放到底部
避 免使用CSS表达式
将CSS和JS放到外部文件中
避免跳转
可缓存的AJAX
使用GET来完成AJAX请求
⑹ 做前端需要什么技术
前端程序猿切页面写页面，Web上、H5上的炫酷效果，是前端开发大展身手的地方。最常见的用于前端开发的技术组合是：
HTML+CSS+JavaScript。
前端的应用非常广泛，基本网站、APP、HTML5小程序等都需要前端开发，所以只要是互联网产品基本都需要前端。
web前端是在开发人员中最直接面向产品、面向用户的设计人员，一个开发团队的成果是要靠web前端去展现，因为用户不会去关心后台的处理有多么强大。
后端开发是写后台，各种业务逻辑、数据处理、模块接口、客户端接口等等。后端开发者通常精通于一种Web编程语言和一个数据库管理系统。电商平台点击筛选条件下面为你筛选出来的宝贝的功能以及付款人数数据的变化等都是由后台来实现提供的。
目前web产品交互越来越复杂，用户使用体验和网站前端性能优化这些都得靠web前端去做。
前端开发则是网站的前台代码实现，包括基本的HTML和CSS以及JavaScript/ajax，最新的高级版本HTML5、CSS3，以及SVG等。
前端开发需要学习的技术
1 掌握基本web前端开发技术：HTML、CSS、JavaScript、DOM、BOM、AJAX等，而且要了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug
2 必须掌握网站性能优化、SEO和服务器端开发技术的基础知识
3 必须学会运用各种web前端开发与测试工具进行辅助开发
4 除了掌握技术层面的知识，还要掌握理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持等
5 未来web前端开发工程师还要研究HTML5、web视觉设计、网站配色、网站交互设计模式等相关技术
web前端有广阔的发展空间，app、小程序、移动端、pc端等都网站是需要前端技术的开发支持才能够完成，技术门槛相对较低、需求量较大，薪资待遇良好。只要是互联网端的客户界面，就需要前端来制作完成，前端开发的编程量不大，但是需要部分编程，入门简单，但是要学的深入需要一个过程。
Web前端招聘岗位
• 前端开发工程师、Web开发工程师、网页开发工程师、HTML开发工程师...
• H5开发工程师、移动应用开发工程师、App开发工程师、小程序开发工程师...
• JS开发工程师、Vue.js开发工程师、Node.js开发工程师、前端架构师...
• 小游戏开发工程师、数据可视化开发工程师、WebGL开发工程师、WebVR开 发工程师、Web安全工程师...
⑺ 如何对前端性能进行优化
前端开发代码优化、可维护性、浏览器兼容性是非常重要的课题。从实际的工程应用角度出发，最常遇见的前端优化问题。前端性能进行优化规则，基本可以涵盖现在前端大部分的性能优化原则了，很多更加geek和精细优化方法都是从这些原则里面延伸出来的。
前端性能进行优化都有哪些规则
减少HTTP请求次数
尽量合并图片、CSS、JS。比如加载一个页面有5个css文件的话，把这个5个文件合成一个的话，就只需要发出一次http请求，节省网络请求时间，加快页面的加载。
2. 使用CDN
网站上静态资源即css、js全都使用cdn分发，包括图片
3. 避免空的src和href
当link标签的href属性为空、script标签的src属性为空的时候，浏览器渲染的时候会把当前页面的URL作为它们的属性值，从而把页面的内容加载进来作为它们的值。所以要避免犯这样的疏忽。
4. 为文件头指定Expires
Exipres是用来设置文件的过期时间的，一般对css、js、图片资源有效。 他可以使内容具有缓存性，这样下回再访问同样的资源时就通过浏览器缓存区读取，不需要再发出http请求。如下例子：
新浪微博的这个css文件的Expires时间是2016-5-04 09:14:14.
5. 使用gzip压缩内容
gzip能够压缩任何一个文本类型的响应，包括html，xml，json。大大缩小请求返回的数据量。
6. 把CSS放到顶部
网页上的资源加载时从上网下顺序加载的，所以css放在页面的顶部能够优先渲染页面，让用户感觉页面加载很快。
7. 把JS放到底部
加载js时会对后续的资源造成阻塞，必须得等js加载完才去加载后续的文件 ，所以就把js放在页面底部最后加载。
8. 避免使用CSS表达式
举个css表达式的例子
font-color: expression( (new Date()).getHours()%3 ? “#FFFFFF" : “#AAAAAA" );
这个表达式会持续的在页面上计算样式，影响页面的性能。并且css表达式只被IE支持。
9. 将CSS和JS放到外部文件中
目的是缓存文件，可以参考原则4。 但有时候为了减少请求，也会直接写到页面里，需根据PV和IP的比例权衡。
10. 权衡DNS查找次数
减少主机名可以节省响应时间。但同时，需要注意，减少主机会减少页面中并行下载的数量。
IE浏览器在同一时刻只能从同一域名下载两个文件。当在一个页面显示多张图片时，IE 用户的图片下载速度就会受到影响。所以新浪会搞N个二级域名来放图片。
下面是新浪微博的图片域名，我们可以看到他有多个域名，这样可以保证这些不同域名能够同时去下载图片，而不用排队。不过如果当使用的域名过多时，响应时间就会慢，因为不用响应域名时间不一致。
11. 精简CSS和JS
这里就涉及到css和js的压缩了。比如下面的新浪的一个css文件，把空格回车全部去掉，减少文件的大小。现在的压缩工具有很多，基本主流的前端构建工具都能进行css和js文件的压缩，如grunt，glup等。
12. 避免跳转
有种现象会比较坑爹，看起来没什么差别，其实多次了一次页面跳转。比如当URL本该有斜杠（/）却被忽略掉时。例如，当我们要访问http:// .com时，实际上返回的是一个包含301代码的跳转，它指向的是http:// .com/（注意末尾的斜杠）。在nginx服务器可以使用rewrite；Apache服务器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash来避免。
另一种是不用域名之间的跳转， 比如访问http:// .com/bbs跳转到http:// bbs..com/。那么可以通过使用Alias或者mod_rewirte建立CNAME（保存一个域名和另外一个域名之间关系的DNS记录）来替代。
13. 删除重复的JS和CSS
重复调用脚本，除了增加额外的HTTP请求外，多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存，它们都存在重复运算JavaScript的问题。
14. 配置ETags
它用来判断浏览器缓存里的元素是否和原来服务器上的一致。比last-modified date更具有弹性，例如某个文件在1秒内修改了10次，Etag可以综合Inode(文件的索引节点(inode)数)，MTime(修改时间)和Size来精准的进行判断，避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用，可取后两个参数。使用ETags减少Web应用带宽和负载
15. 可缓存的AJAX
异步请求同样的造成用户等待，所以使用ajax请求时，要主动告诉浏览器如果该请求有缓存就去请求缓存内容。如下代码片段, cache:true就是显式的要求如果当前请求有缓存的话，直接使用缓存
$.ajax({ url : 'url', dataType : "json", cache: true, success : function(son, status){ }
16. 使用GET来完成AJAX请求
当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。因此使用GET获取数据时更加有意义。
17. 减少DOM元素数量
这是一门大学问，这里可以引申出一堆优化的细节。想要具体研究的可以看后面推荐书籍。总之大原则减少DOM数量，就会减少浏览器的解析负担。
18. 避免404
比如外链的css、js文件出现问题返回404时，会破坏浏览器的并行加载。
19. 减少Cookie的大小
Cookie里面别塞那么多东西，因为每个请求都得带着他跑。
20. 使用无cookie的域
比如CSS、js、图片等，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名的影响。
21. 不要使用滤镜
IE独有属性AlphaImageLoader用于修正7.0以下版本中显示PNG图片的半透明效果。这个滤镜的问题在于浏览器加载图片时它会终止内容的呈现并且冻结浏览器。在每一个元素（不仅仅是图片）它都会运算一次，增加了内存开支，因此它的问题是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替，这种格式能在IE中很好地工作。如果你确实需要使用AlphaImageLoader，请使用下划线_filter又使之对IE7以上版本的用户无效。
22. 不要在HTML中缩放图片
比如你需要的图片尺寸是50* 50
那就不用用一张500*500的大尺寸图片，影响加载
23. 缩小favicon.ico并缓存
⑻ ☆前端优化：浏览器缓存技术介绍
在前端开发中，性能一直都是被大家所重视的一点，然而判断一个网站的性能最直观的就是看网页打开的速度。 其中提高网页反应速度的一个方式就是使用缓存 。缓存技术一直一来在WEB技术体系中扮演非常重要角色，是快速且有效地提升性能的手段。
一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。
所以，缓存技术是无数WEB开发从业人员在工作过程中不可避免的一大问题。 在产品开发的时候我们总是想办法避免缓存产生，而在产品发布之时又在想策略管理缓存提升网页的访问速度 。了解浏览器的缓存命中原理，是开发WEB应用的基础，本文着眼于此，学习浏览器缓存的相关知识，总结缓存避免和缓存管理的方法，结合具体的场景说明缓存的相关问题。希望能对有需要的人有所帮助。
在实际WEB开发过程中，缓存技术会涉及到不同层、不同端，比如：用户层、系统层、代理层、前端、后端、服务端等， 每一层的缓存目标都是一致的，就是尽快返回请求数据、减少延迟 ，但每层使用的技术实现是各有不同，面对不同层、不同端的优劣，选用不同的技术来提升系统响应效率。所以，我们首先看下各层的缓存都有哪些技术，都缓存哪些数据，从整体上，对WEB的缓存技术进行了解，如下图所示：
本篇文章重点讲的就是上面红色框部分缓存内容。
当浏览器请求一个网站的时候，会加载各种各样的资源，比如：HTML文档、图片、CSS和JS等文件。对于一些不经常变的内容，浏览器会将他们保存在本地的文件中，下次访问相同网站的时候，直接加载这些资源，加速访问。
那么如何知晓浏览器是读取了缓存还是直接请求服务器？如下图网站来做个示例：
第一次打开该网站后，如果再次刷新页面。会发现浏览器加载的众多资源中，有一部分size有具体数值，然而还有一部分请求，比如图片、css和js等文件并没有显示文件大小，而是显示了 from dis cache 或者 from memory cache 字样。这就说明了，该资源直接从本地硬盘或者浏览器内存读取，而并没有请求服务器。
浏览器启用缓存至少有两点显而易见的好处： （1）减少页面加载时间；（2）减少服务器负载；
浏览器是否使用缓存、缓存多久，是由服务器控制的 。准确来说，当浏览器请求一个网页（或者其他资源）时， 服务器发回的响应的“响应头”部分的某些字段指明了有关缓存的关键信息 。下面看下，HTTP报文中与缓存相关的首部字段：
根据上面四种类型的首部字段不同使用策略， 浏览器中缓存可分为强缓存和协商缓存 ：
当浏览器对某个资源的请求命中了强缓存时， 返回的HTTP状态为200 ，在chrome的开发者工具的network里面 size会显示为from cache ，比如：京东的首页里就有很多静态资源配置了强缓存，用chrome打开几次，再用f12查看network，可以看到有不少请求就是从缓存中加载的：
Expires是HTTP 1.0提出的一个表示资源过期时间的header，它描述的是一个绝对时间，由服务器返回，用GMT格式的字符串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires头标签的文件，就说明浏览器对于该文件缓存具有非常大的控制权。
例如，一个文件的Expires值是2020年的1月1日，那么就代表，在2020年1月1日之前，浏览器都可以直接使用该文件的本地缓存文件，而不必去服务器再次请求该文件，哪怕服务器文件发生了变化。
所以， Expires是优化中最理想的情况，因为它根本不会产生请求 ，所以后端也就无需考虑查询快慢。它的缓存原理，如下：
Expires是较老的强缓存管理header， 由于它是服务器返回的一个绝对时间 ，在服务器时间与客户端时间相差较大时，缓存管理容易出现问题， 比如：随意修改下客户端时间，就能影响缓存命中的结果 。所以在HTTP 1.1的时候，提出了一个新的header， 就是Cache-Control，这是一个相对时间，在配置缓存的时候，以秒为单位，用数值表示 ，如：Cache-Control:max-age=315360000，它的缓存原理是：
Cache-Control描述的是一个相对时间 ，在进行缓存命中的时候， 都是利用客户端时间进行判断 ，所以相比较Expires，Cache-Control的缓存管理更有效，安全一些。
这两个header可以只启用一个，也可以同时启用， 当response header中，Expires和Cache-Control同时存在时，Cache-Control优先级高于Expires ：
此外，还可以为 Cache-Control 指定 public 或 private 标记。 如果使用 private，则表示该资源仅仅属于发出请求的最终用户，这将禁止中间服务器（如代理服务器）缓存此类资源 。对于包含用户个人信息的文件（如一个包含用户名的 HTML 文档），可以设置 private，一方面由于这些缓存对其他用户来说没有任何意义，另一方面用户可能不希望相关文件储存在不受信任的服务器上。需要指出的是，private 并不会使得缓存更加安全，它同样会传给中间服务器（如果网站对于传输的安全性要求很高，应该使用传输层安全措施）。 对于 public，则允许所有服务器缓存该资源 。通常情况下，对于所有人都可以访问的资源（例如网站的 logo、图片、脚本等）， Cache-Control 默认设为 public 是合理的 。
当浏览器对某个资源的请求没有命中强缓存， 就会发一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的http状态为304并且会显示一个Not Modified的字符串 ，比如你打开京东的首页，按f12打开开发者工具，再按f5刷新页面，查看network，可以看到有不少请求就是命中了协商缓存的：
查看单个请求的Response Header， 也能看到304的状态码和Not Modified的字符串，只要看到这个就可说明这个资源是命中了协商缓存，然后从客户端缓存中加载的 ，而不是服务器最新的资源：
【Last-Modified，If-Modified-Since】的控制缓存的原理，如下 ：
【Last-Modified，If-Modified-Since】都是根据服务器时间返回的header，一般来说， 在没有调整服务器时间和篡改客户端缓存的情况下，这两个header配合起来管理协商缓存是非常可靠的，但是有时候也会服务器上资源其实有变化，但是最后修改时间却没有变化的情况 ，而这种问题又很不容易被定位出来，而当这种情况出现的时候，就会影响协商缓存的可靠性。 所以就有了另外一对header来管理协商缓存，这对header就是【ETag、If-None-Match】 。它们的缓存管理的方式是：
Etag和Last-Modified非常相似，都是用来判断一个参数，从而决定是否启用缓存。 但是ETag相对于Last-Modified也有其优势，可以更加准确的判断文件内容是否被修改 ，从而在实际操作中实用程度也更高。
协商缓存跟强缓存不一样，强缓存不发请求到服务器， 所以有时候资源更新了浏览器还不知道，但是协商缓存会发请求到服务器 ，所以资源是否更新，服务器肯定知道。大部分web服务器都默认开启协商缓存，而且是同时启用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:
如果没有协商缓存，每个到服务器的请求，就都得返回资源内容，这样服务器的性能会极差。
【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同时启用，这是为了处理Last-Modified不可靠的情况。有一种场景需要注意：
比如，京东页面的资源请求，返回的repsonse header就只有Last-Modified，没有ETag：
协商缓存需要配合强缓存使用，上面这个截图中，除了Last-Modified这个header，还有强缓存的相关header， 因为如果不启用强缓存的话，协商缓存根本没有意义 。
如果资源已经被浏览器缓存下来，在缓存失效之前，再次请求时，默认会先检查是否命中强缓存，如果强缓存命中则直接读取缓存，如果强缓存没有命中则发请求到服务器检查是否命中协商缓存，如果协商缓存命中，则告诉浏览器还是可以从缓存读取，否则才从服务器返回最新的资源。其浏览器判断缓存的详细流程图，如下：