머리말
캐시 성능 최적화는 간단하고 효율적인 방법으로 최적화 할 수 있다고 할 수있다. 좋은 캐싱 전략은 거리의 페이지 요청 자원을 단축 대기 시간 감소, 캐시 파일을 재생 할 수 있기 때문에 또한 대역폭을 감소시키고 네트워크 부하를 줄일 수 있습니다.
데이터 요청에 대한 요청은 발신 네트워크 백엔드 처리, 세 단계에 응답하여 상기 브라우저로 나눌 수있다. 브라우저 캐시는 우리가 첫 번째와 세 번째 단계에서 성능을 최적화하는 데 도움이 될 수 있습니다. 예를 들어, 대신에 캐시를 사용하는 직접 요청을 시작하거나 요청을 시작하지만 백엔드 일관된 프런트 엔드에 저장된 데이터는 다음 이에 응답 데이터를 감소 돌아와 다시 데이터를 통과 할 필요가 없다.
어떻게 우리가 캐시 위치를 통해 캐싱 정책을 적용 할 브라우저 캐시 메커니즘을 모색 할 것입니다 다음, 및 캐시 정책 실제 장면.
캐시 위치
이 캐시에서 4 개 곳입니다이며, 각각의 캐시를 찾을 수와 요청이 네트워크에 갈 때 때 공격하지 않았다 위해서는, 우선 순위를 가지고있다.
- 서비스 노동자
- 메모리 캐시
- 디스크 캐시
- 캐시를 밀어
1, 서비스 노동자
서비스 노동자 브라우저 뒤에 별도의 스레드를 실행하는, 일반적으로 캐싱 기능을 구현하는 데 사용할 수 있습니다. 사용 서비스 작업자 단어, 전송 프로토콜은 HTTPS를해야합니다. 서비스 노동자가 요청 인터셉터에 관여하기 때문에, 당신은 보안을 보장하기 위해 HTTPS 프로토콜을 사용해야합니다. 서비스 노동자 다른 브라우저 캐시 및 기타 내장 우리를 자유롭게하는 방법 캐시를 읽는 캐시를 일치하는 방법, 캐시 및 캐시가 지속적되는 파일을 제어 할 수있는 메커니즘을 캐싱.
서비스 노동자는 기능은 일반적으로 세 단계로 나누어 져 캐싱 구현할 : 당신이 후 이벤트를 설치 파일을들을 다음 서비스 노동자를 등록하고 먼저 필요가 필요 캐시 할 수있는 방법을 다음 캐시는 사용자가 쿼리를 차단하여 액세스를 요청할 수있는 다음 시간이 있는지 여부 캐시, 다음 캐시 파일을 직접 읽을 수 있습니다, 또는 그 데이터를 요청하는 것입니다.
서비스 노동자 캐시를 공격하지 않는 경우, 우리는 데이터를 얻을 수있는 기능을 가져 호출해야합니다. 우리는 서비스 노동자의 버퍼를 공격하지 않는 경우 즉, 다음, 찾을 수있는 데이터 캐시에 따라 우선 순위를 찾습니다. 우리가 또는 네트워크에서 메모리 캐시 요청 데이터에서 얻은 여부를하지만, 브라우저는 서비스 노동자에서 얻은 콘텐츠를 표시합니다.
메모리 캐시
주로 현재 페이지에 포함되어있는 메모리 캐시 메모리 캐시는 페이지 스타일, 스크립트, 이미지 다운로드 등되었습니다 같은 자원 기어했다. 데이터 읽기 메모리는 메모리 캐시가 효율적이지만 읽기 빠른 디스크에 비해 확실히이지만, 지속적인 캐시는이 릴리스 과정 발표 될 예정이다 매우 짧습니다. 우리는 탭 페이지를 닫으면, 인 메모리 캐싱이 해제됩니다.
메모리 캐시 때문에 효율적인 글쎄, 우리가 허용되지 않는 데이터는 그것의 메모리에 저장됩니다? 이 수 없습니다. 컴퓨터 메모리 용량이 하드 디스크보다 훨씬 작아야의 운영 체제는 그래서 우리가 많은 피할 메모리를 사용하자, 메모리 사용의 신중한 계획이 필요합니다.
우리는 페이지를 새로 페이지를 다시 방문했을 때, 당신은 메모리 캐시에서 데이터를 많이 찾을 수 있습니다.
캐시 메모리는 캐시 자원입니다 중요 프리 로더 관련 지침 (예를 들어 <linkrel = "프리 페치">) 다운로드 한 자원을 가지고있다. 총 잘 이미 프리 로더 관련 지침에 알려진 네트워크는 다음 리소스를 요청하면서, JS / CSS 파일을 해결할 수 있지만, 페이지 최적화에의 일반적인 방법입니다.
참고 것은 일치, 또한 콘텐츠 형식, CORS가있을 수 있습니다 않은 메모리 캐시는 캐시 자원이 캐시 제어 어떤 값 동안 매칭 자원을 헤더를 캐싱 HTTP 자원의 반환에 대해 걱정하지 않는다 때 단지 URL되지이다 및 기타 기능 점검을한다.
3, 디스크 캐시
디스크 캐시 캐시는 느린 하드 디스크의 읽기 속도에 저장되어 있지만, 메모리 캐시 저장 용량과 적시성에 승리보다는 어떤 일이 디스크에 저장할 수 있습니다.
모든 브라우저 캐시에서 디스크 캐시의 기본 범위는 최대이다. 그것은 자원이 만료 재 요청에 필요한 자원을 직접 요청하지 않을 수 있습니다 자원을 캐시 할 필요가있는 HTTP 지킴 분야에 따라 심판을받을 것입니다. 그리고 심지어 크로스 사이트의 경우, 같은 주소 자원은 하드 디스크 캐시 다운되면 다시 요청 된 데이터를 이동하지 않습니다. HTTP 프로토콜 헤더 캐시 필드에, 디스크 캐시에서 캐시의 대부분, 우리는 아래의 세부 것이다.
어떤 메모리에 던져 브라우저를 제기 할 것인가? 무엇 하드 디스크에 던져? 이와 관련하여, 온라인 달라질 수 있지만, 전망은 안정적이다 :
- 큰 파일의 경우, 높은 확률은 메모리에 저장되지 않으며, 우선 순위도 마찬가지 부사장
- 현재 시스템 메모리 사용률은 다음 파일은 하드 디스크 우선 순위에 저장
4, 캐시를 밀어
캐시 (푸시 캐시) 세 위의 캐시를 공격하지 않았을 때, 그것이 사용될는 HTTP / 2의 내용이다 밀어 넣습니다. 그것은 단지 세션 (세션)에 존재하는, 세션이 종료되면 해제, 그것은 엄격하게 HTTP 헤더 지시를 캐싱 적용되지 않습니다 동안 캐시 시간은 5 분에 대해 크롬 브라우저에서 매우 짧습니다.
캐시 정보는 국가에서 찾을 수 있습니다 푸시 작지만 HTTP / 2는 국내에서 인기가없는도 있기 때문이다. 그것은 HTTP / 2 푸시는이 기사, 기사의 결론을 생각보다 강하다는 것입니다 JakeArchibald을 읽는 것이 좋습니다 :
- 모든 자원을 밀어 수 있으며, 캐시 할 수 있지만, 에지 및 사파리 브라우저 지원은 상대적으로 가난
- 자료에는 캐시없이 매장의 밀어 수 없습니다
- 연결이 종료되면, 캐시 해제 밀어
- 여러 페이지가 같은 푸시 캐시를 사용할 수 있습니다 또한, 동일한 연결 HTTP / 2를 사용할 수 있습니다. 이 수, 성능의 이유로, 일부 브라우저가 같은 도메인 이름하지만 같은 HTTP 연결을 사용하여 다른 탭 레이블이됩니다 수있는 브라우저에 주로 의존 얻을 수있다.
- 캐시에게 한 번만 사용할 수있는 캐시를 밀어
- 당신은 브라우저 푸시 기존 자원을 받아들이기를 거부 할 수 있습니다
- 당신은 다른 도메인에 자원을 밀어 수 있습니다
위의 네 개의 캐시가 히트하지 않은 경우 만 자원을 획득하기위한 요청을 시작합니다.
그래서 성능을 고려하기 위해, 인터페이스의 가장 좋은 캐싱 전략을 선택해야, 브라우저 캐시는 일반적으로 두 가지 전략으로 구분됩니다 강력한 버퍼 캐시와 협의하고, 캐싱 전략을 달성하기 위해 HTTP 헤더에 의해 설정됩니다.
분석을 처리 캐시
인 방법 서버 응답 모드와 통신 할 수있는 브라우저 : 브라우저가 HTTP 요청을 전송 - 서버의 응답을 요청하려면, 다음 방법을 캐시해서는 안 자원을 확인하는 브라우저, 어떻게 그것을 캐시에? 서버 제 브라우저의 요청을 시작하기위한 요청의 결과를 얻을 캐시 요구 식별자와 상기 결과가 상기 브라우저의 캐시에 저장되고, 처리는 브라우저 캐시가 상기 제 1 응답에 기초하여 결정이 반환 될 때 요청 된 리소스 헤드 . 다음도 절차는 :
위의 차트에서 우리는 알 수 있습니다 :
- 결과 브라우저가 요청을 개시 할 때마다, 상기 요청은 제 브라우저 캐시 및 캐시 식별자 모양
- 때마다 결과가 반환됩니다 얻을 수있는 브라우저 요청하고 그 결과가 브라우저 캐시 식별자 캐시에 저장됩니다
주요 결론은 두 개 이상의 지점으로 우리가 이해 한 후 브라우저 캐시 규칙을 사용할 때 캐시가 저장되고 각 요청을 읽도록 보장하는 브라우저 캐시 메커니즘은, 다음, 모든 문제가 해결 될 것입니다, 우리 주위에있을 것입니다 이 상세한 분석. 우리가 여기서 이해를 용이하게하기 위해 HTTP는 필요에 따라 두 부분으로 나누어 져 캐시 서버 프로세스에 요청을 다시 시작, 그들은 강력한 캐시와 캐시 상담입니다.
강력한 캐시
강력한 캐시 : 서버에 요청을 보낼 수 없습니다, 자원이 캐시에서 직접 읽어, 네트워크 옵션 크롬 콘솔이 요청 수익률 디스크 캐시 나 메모리 캐시에서 상태 코드 (200), 및 크기의 디스플레이를 볼 수 있습니다. 강력한 캐시는이 HTTP 헤더 실현을 설정할 수 있습니다 만료 및 캐시 제어 할 수 있습니다.
1 만료
캐시 만료 시간, 지정된 자원의 만료 시간은 서버 측에서 시간의 특정 지점입니다. 만료 = 최대 사용 기간 + 요청 시간, 마지막으로 수정 된 바인딩을 사용할 필요하다. 만료 다시 요청하지 않고 브라우저 캐시 데이터에서 직접 만료되기 전에 시간이 걸릴 수 있습니다 요청 HTTP 브라우저에 대한 응답으로 브라우저를 알려주는 웹 서버의 응답 헤더 필드입니다.
만료는 HTTP / 1의 제품 및 캐시 무효화를 일으킬 수, 현지 시간으로 수정 한 경우 현지 시간으로 제한된다.
Expires:Wed,22Oct201808:41:00GMT表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期，需要再次请求。
2、Cache-Control
在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存。比如当 Cache-Control:max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。
Cache-Control 可以在请求头或者响应头中设置，并且可以组合使用多种指令：
public：所有内容都将被缓存（客户端和代理服务器都可缓存）。具体来说响应可被任何中间节点缓存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中间的proxy可以缓存资源，比如下次再请求同一资源proxy1直接把自己缓存的东西给 Browser 而不再向proxy2要。
private：所有内容只有客户端可以缓存，Cache-Control的默认取值。具体来说，表示中间节点不允许缓存，对于Browser <-- proxy1 <-- proxy2 <-- Server，proxy 会老老实实把Server 返回的数据发送给proxy1,自己不缓存任何数据。当下次Browser再次请求时proxy会做好请求转发而不是自作主张给自己缓存的数据。
no-cache：客户端缓存内容，是否使用缓存则需要经过协商缓存来验证决定。表示不使用 Cache-Control的缓存控制方式做前置验证，而是使用 Etag 或者Last-Modified字段来控制缓存。需要注意的是，no-cache这个名字有一点误导。设置了no-cache之后，并不是说浏览器就不再缓存数据，只是浏览器在使用缓存数据时，需要先确认一下数据是否还跟服务器保持一致。
no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
max-age：max-age=xxx (xxx is numeric)表示缓存内容将在xxx秒后失效
s-maxage（单位为s)：同max-age作用一样，只在代理服务器中生效（比如CDN缓存）。比如当s-maxage=60时，在这60秒中，即使更新了CDN的内容，浏览器也不会进行请求。max-age用于普通缓存，而s-maxage用于代理缓存。s-maxage的优先级高于max-age。如果存在s-maxage，则会覆盖掉max-age和Expires header。
max-stale：能容忍的最大过期时间。max-stale指令标示了客户端愿意接收一个已经过期了的响应。如果指定了max-stale的值，则最大容忍时间为对应的秒数。如果没有指定，那么说明浏览器愿意接收任何age的响应（age表示响应由源站生成或确认的时间与当前时间的差值）。
min-fresh：能够容忍的最小新鲜度。min-fresh标示了客户端不愿意接受新鲜度不多于当前的age加上min-fresh设定的时间之和的响应。
从图中我们可以看到，我们可以将多个指令配合起来一起使用，达到多个目的。比如说我们希望资源能被缓存下来，并且是客户端和代理服务器都能缓存，还能设置缓存失效时间等等。
3、Expires和Cache-Control两者对比
其实这两者差别不大，区别就在于 Expires 是http1.0的产物，Cache-Control是http1.1的产物，两者同时存在的话，Cache-Control优先级高于Expires；在某些不支持HTTP1.1的环境下，Expires就会发挥用处。所以Expires其实是过时的产物，现阶段它的存在只是一种兼容性的写法。强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容，那我们如何获知服务器端内容是否已经发生了更新呢？此时我们需要用到协商缓存策略。
协商缓存
协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：
协商缓存生效，返回304和Not Modified：
协商缓存失效，返回200和请求结果：
协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag 。
1、Last-Modified和If-Modified-Since
浏览器在第一次访问资源时，服务器返回资源的同时，在response header中添加 Last-Modified的header，值是这个资源在服务器上的最后修改时间，浏览器接收后缓存文件和header；
Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
浏览器下一次请求这个资源，浏览器检测到有 Last-Modified这个header，于是添加If-Modified-Since这个header，值就是Last-Modified中的值；服务器再次收到这个资源请求，会根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比，如果没有变化，返回304和空的响应体，直接从缓存读取，如果If-Modified-Since的时间小于服务器中这个资源的最后修改时间，说明文件有更新，于是返回新的资源文件和200。
但是 Last-Modified 存在一些弊端：
- 如果本地打开缓存文件，即使没有对文件进行修改，但还是会造成 Last-Modified 被修改，服务端不能命中缓存导致发送相同的资源
- 因为 Last-Modified 只能以秒计时，如果在不可感知的时间内修改完成文件，那么服务端会认为资源还是命中了，不会返回正确的资源
既然根据文件修改时间来决定是否缓存尚有不足，能否可以直接根据文件内容是否修改来决定缓存策略？所以在 HTTP / 1.1 出现了 ETag 和 If-None-Match
2、ETag和If-None-Match
Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，只要资源有变化，Etag就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到request header里的If-None-Match里，服务器只需要比较客户端传来的If-None-Match跟自己服务器上该资源的ETag是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现ETag匹配不上，那么直接以常规GET 200回包形式将新的资源（当然也包括了新的ETag）发给客户端；如果ETag是一致的，则直接返回304知会客户端直接使用本地缓存即可。
3、两者之间对比：
- 首先在精确度上，Etag要优于Last-Modified。
Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。
第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。
第三在优先级上，服务器校验优先考虑Etag
缓存机制
强制缓存优先于协商缓存进行，若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，返回200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回304，继续使用缓存。具体流程图如下：
看到这里，不知道你是否存在这样一个疑问:如果什么缓存策略都没设置，那么浏览器会怎么处理？
对于这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间。
实际场景应用缓存策略
1、频繁变动的资源
Cache-Control: no-cache
对于频繁变动的资源，首先需要使用 Cache-Control:no-cache 使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。
2、不常变化的资源
Cache-Control: max-age=31536000
通常在处理这类资源时，给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年)，这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，从而达到更改引用 URL 的目的，让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。在线提供的类库 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用这个模式。
用户行为对浏览器缓存的影响
所谓用户行为对浏览器缓存的影响，指的就是用户在浏览器如何操作时，会触发怎样的缓存策略。主要有 3 种：
- 打开网页，地址栏输入地址： 查找 disk cache 中是否有匹配。如有则使用；如没有则发送网络请求。
- 普通刷新 (F5)：因为 TAB 并没有关闭，因此 memory cache 是可用的，会被优先使用(如果匹配的话)。其次才是 disk cache。
- 强制刷新 (Ctrl + F5)：浏览器不使用缓存，因此发送的请求头部均带有 Cache-control:no-cache(为了兼容，还带了 Pragma:no-cache),服务器直接返回 200 和最新内容。