Deep understanding of the browser's various refresh rules-related tips

PC Browser Refresh method We commonly have about four kinds:

1. Url+enter or a tag hyperlink click

2. F5 Refresh/ctrl+r Refresh/button Refresh

3. Ctrl+f5 Refresh/ctrl+shift+r Refresh

4. Back Refresh

Wise browsers typically refresh in three ways:

1. Url+enter or a tag hyperlink click

2. Button Refresh

3. Back Refresh

They are different, different browsers, the effect is not the same, with a test page with an IFRAME for example, we test the premise is to allow the page cache, the bottom of our one speak:

PC Browser

1. Url+enter or a tag hyperlink click

If you have ever visited this site, the Refresh method is to extract the data directly from the cache, and the request does not go to the server, assuming that the site has a valid cache set.

As the HTML page under the Chrome browser request, the request parameter with If-none-match (in some cases may also have if-modified-since parameters), the server returned 304, indicating that the request access to the server, and cache verification.

If-Modified-Since: If the requested part is modified after the specified time, the request succeeds and the 304 code is returned without modification, corresponding to the response head last-modified

If-None-Match: If the content does not change returns 304 code, the parameter is the Etag which the server sends previously, compares with the server response Etag to judge whether changes, corresponding response head Etag

And look at the request in the IFRAME.

First, the request in the SRC attribute in the IFRAME does not interfere.

You can see that the request in the IFrame also takes the If-none-match parameter as the external request.

Looking at the request of the picture resource again, we set up the max-age=2628000 to the picture beforehand:

Can see the picture of the request header this time without If-none-match parameters, but with the cache-control:max-age=0, status code is from cache, indicating that this request did not access the server, but directly cache return response.

It turns out: when there is a local cache, but you do not give it to set the expiration date or has expired, the return of this refresh method will take the initiative to access the server to determine whether the cache needs to be updated, and if the expiration date is set and does not expire, then the Refresh method directly from the cache

As above is the Firebug under Firefox, you can see the HTML page request return 304, and the request header with the If-none-match parameter, this is the same as chrome.
And the request in the IFRAME and chrome no difference, the picture because of the direct load from the cache, so Firefox directly does not show.

Summary ":url+enter or a tag hyperlink Click this refresh method Chrome and Firefox are consistent, and the cached resource that is still in the validity period of the request will be returned directly from the cache, otherwise it will bring the if-none-match/ The If-none-match parameter access server determines whether the cache needs to be updated.

2. F5 Refresh/ctrl+r Refresh

First of all, look at the Chrome,chrome this time all the resources are consistent, including the request in the IFrame and previously mentioned max-age of the picture resources.

The image above is a request for an HTML file,

The request was cache-control:max-age=0,

The server will determine whether the cache needs to be updated based on ETag or last-modified, and if no update is required, it will return 304 to tell the browser that its cache is still available and

To slow the duration, return the latest data and new etag/last-modified, and update the browser cache if needed.

And then look at Firefox,

The effect of Firefox and Chrome is consistent for HTML resources and requests for max-age picture resources, but the request for resources in the IFrame is somewhat different, compared to Chrome, where the cache-control:max-age=0 parameters are missing.

3. Ctrl+f5 Refresh

All of the Firefox and Chrome requests are in line, so just look at chrome.

This refresh request does not have the if-modified-since and If-none-match parameters in mode 2, and the Cache-control value becomes: No-cache, and Adds Pragma:no-cache.

The latter two arguments have the same meaning, except that the compatible HTTP version is different.

No-cache the request to force access to the server and verify it, but because this time there was no if-modified-since and If-none-match parameters, the server could not authenticate, so the server directly returned the data and the new last-modified as well as the ETag , Status Code 200OK

4. Back Refresh

Back refresh mainly refers to those who set the page is not cached by the site, Chrome here is more standard, from one of the current page to another page, and then back back, the resources on the page are directly requested cache:

As shown above, the test is done under the Chrome browser.

On the back, Firefox has a different approach:

As pictured above, you'll find a new noun: bfcache.

Full name is Back-forward cache, that is, "round-trip cache", in order to improve the user to use the browser's "back" and "forward" button to speed up the page conversion speed.

This cache not only preserves the page data, but also preserves the DOM and JavaScript state; it actually saves the entire page in memory. In other words, "back" not only means that the html/js/css/interface and other static resources will not be requested again, even JS will not be executed.

Not all of the form bfcache, because I added an IFRAME to the test page, it turns out that the IFRAME will not be cached by Firefox's "roundtrip mechanism", and that it still follows the Url+enter request in the refresh mode.

This point is also clearly stated in the MDN:

If the page is in Bfcache, then opening the page again will not trigger the Load event.

Although it is not a problem to trigger the Load event because the state of the entire page is saved in memory, Firefox provides some new events to illustrate the bfcache behavior more vividly.

Pageshow

The first event is Pageshow, which is triggered when the page is displayed, regardless of whether the page is from Bfcache. In the reload page, Pageshow is triggered after the load event is triggered, and for the page in Bfcache, Pageshow is triggered at the moment when the page state is fully restored. Also note that, although the target of this event is document, its event handlers must be added to window.

In addition to the usual properties, the event object for the Pageshow events also contains a Boolean property named persisted. The value of this property is true if the Bfcache exists in the page, otherwise the value of this property is false.

You can determine whether a page in Bfcache triggers a pageshow event based on persisted.

Pagehide

The Pageshow event corresponds to the Pagehide event, which is triggered when the browser unloads the page and before the Unload event. As with the Pageshow event, Pagehide is triggered on the document, but its event handlers must be added to the Windows object. This event object also contains the persisted property

Summarize

Well, that's all the content of this article, Wise browser details We will be updated later, interested in continue to focus on the cloud habitat community.