We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
随着互联网的发展,前端页面变的越来越复杂,越来越多的事情,被拿到前端来处理。这就导致 HTML 页面会被加载大量的资源 包括 JS,CSS 以及图片等。
本文从 HTTP 缓存的角度,来谈谈如何优化页面资源加载性能。
在谈 HTTP 缓存之前,让我们先来聊聊 HTTP 协议,HTTP 作为一个非常重要的协议,它的发展却驻足不前,翻开的它的历史,它竟然只有三个版本:
然而 HTTP 协议只是 TCP/IP 协议族的一小部分,为了了解客户端和服务器是如何通信的,就必须了解 TCP/IP 协议族.
TCP/IP 协议族进行了分层,从上到下依次是,应用层,传输层,网络层,数据链路层。 HTTP 协议属于应用层,TCP 协议属于传输层。
HTTP 协议是建立在 TCP 协议基础上,让我们来简单描述一下,浏览器与服务器如何使用 HTTP 协议进行通信的:
浏览器和服务器通信发送的数据块是 HTTP 报文。HTTP 报文由起始行,首部和主体三部分组成。 HTTP 报文一般分为请求报文和响应报文。请求报文的起始行由方法,URI 和 HTTP 版本组成。响应报文的起始行由状态码,原因短语组成。它们的首部都有首部字段和值组成。主体是需要发送和返回的数据。首部和主体之间用 CRLF 空行分割。
如何利用好 HTTP 缓存的关键在于响应和请求的首部字段。
因为每个浏览器都实现了 HTTP 缓存,所以无需设置请求的首部字段,目前所要做的就是,确保每个服务器响应都提供正确的 HTTP 首部,以指导浏览器何时可以缓存资源以及可以缓存多久。
ETag 为我们提供一种验证资源是否被修改的方法,举例,浏览器首次请求资源,服务器返回一个带 ETag 首部的响应,大约过了一小时后,浏览器再次发起同样的请求,此时浏览器自动将 ETag 的值作为 If-None-Match 首部的值,发送给服务器,当服务器使用该值,检查响应的资源是否被修改,如果未修改,则返回 304 Not Modified 响应。注意这里我们并未下载资源,节约时间和宽带资源。
Cache-Control 可以设置的值有: no-cache 或 no-store, public 或 private, max-age。
no-cache 或 no-store no-cache 表示必须先与服务器确认返回的资源是否被修改,然后才能确认是否使用缓存资源来满足后续相同的请求。因此,如果存在 ETag,no-cache 会发起往返通信来验证缓存的资源,如果资源未被更改,可以避免下载。
no-store 禁止浏览器和所有中继缓存(例如代理缓存服务器)存储返回的响应资源。
public 或 private
public 表示允许浏览器和任何中继缓存缓存响应资源 private 只允许浏览器缓存响应资源
max-age
max-age 指定从当前请求开始,允许获取的响应资源被重用的最长时间 例如:max-age=120 表示响应可以再缓存和重用 120 秒
配置 Cache-Control 的策略 如下图
我们可以根据自己实际的业务和不同的资源制定不同的缓存策略:
在定义缓存策略时, 有一些准则是可以参考的:
nginx 服务器中配置 ETag 和 Cache-Control
server { listen 80; server_name get-set.cn; root /data/hjzheng/build/; charset utf-8; etag on; # 启用 ETag try_files $uri =404; location ~* (.+)\.html { add_header Cache-Control no-cache; } location ~* (.+)\.js { add_header Cache-Control private; expires 1y; # 设置 max-age } location ~* (.+)\.css { add_header Cache-Control public; expires 1y; } location ~* (.+)\.(jpg|png|gif|eot|svg|ttf|woff) { add_header Cache-Control public; expires 31d; } }
注意, 本文主要讲述 Cache-Control 中值在 response 中设置的作用,在 Request 中含义略有不同:
常见服务器配置 nginx配置location总结及rewrite规则写法
The text was updated successfully, but these errors were encountered:
No branches or pull requests
随着互联网的发展,前端页面变的越来越复杂,越来越多的事情,被拿到前端来处理。这就导致 HTML 页面会被加载大量的资源 包括 JS,CSS 以及图片等。
本文从 HTTP 缓存的角度,来谈谈如何优化页面资源加载性能。
HTTP协议
在谈 HTTP 缓存之前,让我们先来聊聊 HTTP 协议,HTTP 作为一个非常重要的协议,它的发展却驻足不前,翻开的它的历史,它竟然只有三个版本:
然而 HTTP 协议只是 TCP/IP 协议族的一小部分,为了了解客户端和服务器是如何通信的,就必须了解 TCP/IP 协议族.
TCP/IP 协议族进行了分层,从上到下依次是,应用层,传输层,网络层,数据链路层。 HTTP 协议属于应用层,TCP 协议属于传输层。
HTTP 协议是建立在 TCP 协议基础上,让我们来简单描述一下,浏览器与服务器如何使用 HTTP 协议进行通信的:
浏览器和服务器通信发送的数据块是 HTTP 报文。HTTP 报文由起始行,首部和主体三部分组成。
HTTP 报文一般分为请求报文和响应报文。请求报文的起始行由方法,URI 和 HTTP 版本组成。响应报文的起始行由状态码,原因短语组成。它们的首部都有首部字段和值组成。主体是需要发送和返回的数据。首部和主体之间用 CRLF 空行分割。
配置响应首部字段
如何利用好 HTTP 缓存的关键在于响应和请求的首部字段。
因为每个浏览器都实现了 HTTP 缓存,所以无需设置请求的首部字段,目前所要做的就是,确保每个服务器响应都提供正确的 HTTP 首部,以指导浏览器何时可以缓存资源以及可以缓存多久。
使用 ETag 验证缓存的资源是否被修改
ETag 为我们提供一种验证资源是否被修改的方法,举例,浏览器首次请求资源,服务器返回一个带 ETag 首部的响应,大约过了一小时后,浏览器再次发起同样的请求,此时浏览器自动将 ETag 的值作为 If-None-Match 首部的值,发送给服务器,当服务器使用该值,检查响应的资源是否被修改,如果未修改,则返回 304 Not Modified 响应。注意这里我们并未下载资源,节约时间和宽带资源。
使用 Cache-Control 指导浏览器如何缓存资源
Cache-Control 可以设置的值有: no-cache 或 no-store, public 或 private, max-age。
no-cache 或 no-store
no-cache 表示必须先与服务器确认返回的资源是否被修改,然后才能确认是否使用缓存资源来满足后续相同的请求。因此,如果存在 ETag,no-cache 会发起往返通信来验证缓存的资源,如果资源未被更改,可以避免下载。
no-store 禁止浏览器和所有中继缓存(例如代理缓存服务器)存储返回的响应资源。
public 或 private
public 表示允许浏览器和任何中继缓存缓存响应资源
private 只允许浏览器缓存响应资源
max-age
max-age 指定从当前请求开始,允许获取的响应资源被重用的最长时间 例如:max-age=120 表示响应可以再缓存和重用 120 秒
配置 Cache-Control 的策略
如下图
我们可以根据自己实际的业务和不同的资源制定不同的缓存策略:
总结
在定义缓存策略时, 有一些准则是可以参考的:
配置 nginx
nginx 服务器中配置 ETag 和 Cache-Control
其他
注意, 本文主要讲述 Cache-Control 中值在 response 中设置的作用,在 Request 中含义略有不同:
资料
常见服务器配置
nginx配置location总结及rewrite规则写法
The text was updated successfully, but these errors were encountered: