|
|
|
@ -5,7 +5,7 @@ Besides server-side caching that we have described in the previous sections, Web
|
|
|
|
|
also exploit client-side caching to save the time for generating and transmitting the same page content. |
|
|
|
|
|
|
|
|
|
To use client-side caching, you may configure [[yii\filters\HttpCache]] as a filter for controller |
|
|
|
|
actions whose rendering result may be cached on the client side. [[yii\filters\HttpCache|HttpCache]] |
|
|
|
|
actions whose rendering result may be cached on the client-side. [[yii\filters\HttpCache|HttpCache]] |
|
|
|
|
only works for `GET` and `HEAD` requests. It can handle three kinds of cache-related HTTP headers for these requests: |
|
|
|
|
|
|
|
|
|
* [[yii\filters\HttpCache::lastModified|Last-Modified]] |
|
|
|
@ -52,14 +52,14 @@ The above code states that HTTP caching should be enabled for the `index` action
|
|
|
|
|
generate a `Last-Modified` HTTP header based on the last update time of posts. When a browser visits |
|
|
|
|
the `index` page for the first time, the page will be generated on the server and sent to the browser; |
|
|
|
|
If the browser visits the same page again and there is no post being modified during the period, |
|
|
|
|
the server will not re-generate the page, and the browser will use the cached version on the client side. |
|
|
|
|
the server will not re-generate the page, and the browser will use the cached version on the client-side. |
|
|
|
|
As a result, server-side rendering and page content transmission are both skipped. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## `ETag` Header <span id="etag"></span> |
|
|
|
|
|
|
|
|
|
The "Entity Tag" (or `ETag` for short) header use a hash to represent the content of a page. If the page |
|
|
|
|
is changed, the hash will be changed as well. By comparing the hash kept on the client side with the hash |
|
|
|
|
is changed, the hash will be changed as well. By comparing the hash kept on the client-side with the hash |
|
|
|
|
generated on the server-side, the cache may determine whether the page has been changed and should be re-transmitted. |
|
|
|
|
|
|
|
|
|
You may configure the [[yii\filters\HttpCache::etagSeed]] property to enable sending the `ETag` header. |
|
|
|
@ -97,7 +97,7 @@ The above code states that HTTP caching should be enabled for the `view` action
|
|
|
|
|
generate an `ETag` HTTP header based on the title and content of the requested post. When a browser visits |
|
|
|
|
the `view` page for the first time, the page will be generated on the server and sent to the browser; |
|
|
|
|
If the browser visits the same page again and there is no change to the title and content of the post, |
|
|
|
|
the server will not re-generate the page, and the browser will use the cached version on the client side. |
|
|
|
|
the server will not re-generate the page, and the browser will use the cached version on the client-side. |
|
|
|
|
As a result, server-side rendering and page content transmission are both skipped. |
|
|
|
|
|
|
|
|
|
ETags allow more complex and/or more precise caching strategies than `Last-Modified` headers. |
|
|
|
|