HTML5 Application Caching Application cache detailed

What is Application Cache

HTML5 introduces application caching technology, meaning that Web applications can be cached and used without a network, creating a cache manifest file that makes it easy to create offline applications.

The three advantages that application cache brings are:

① Offline Browsing

② Lifting page Load speed

③ lowers Server pressure

and the main browser to support application Cache, even if not supported will not affect the program

Offline Storage Technology

HTML5 puts forward two kinds of off-line storage technology: Localstorage and Application Cache, both of which have the application scene, and the traditional offline storage technology as cookies.

After practice our task Localstorage should store some non-critical Ajax data, do the icing on the cake;

Application cache is used to store static resources, and is still the thing to do icing on the cake;

Cookies can only hold a small field (4096 bytes), so it is not possible to store large data, which is one of the differences between cookies and the caching technique mentioned above, because HTTP is stateless and the server needs an identity string to distinguish whether the request originated from the same server. This task is the cookie complete, this text each time between the server and the browser pass, to verify the user's permissions.

So the application cache application scenario is not the same, so the use is not consistent.

Application Cache Introduction

The use of application cache should be done in two aspects:

① server side needs to maintain a manifest list

The ② browser only needs a simple setting

Take an example to illustrate:

1. CACHE MANIFEST
3. CACHE:
4. # The list to be cached
5. Style1.css
6. 1.jpg
7. 01.js
9. Http://localhost/applicationcache/02.js
12. Http://localhost/applicationcache/zepto.js
14. Network:
15. # do not need to cache
16. 4.jpg
18. Fallback:
19. # After accessing the cache, the alternate access resource, the first is the access source, and the second is the replacement file *.html/offline.html
20. 2.jpg/3.jpg

First of all, I made a mistake here:

1. Application Cache Error event:manifest fetch failed (404)

The reason for this error is that the manifest file needs to be configured with the correct mime-type, that is, "text/cache-manifest". Must be configured on a Web server, different servers

1. Applicationcache
2. 01.js
3. 02.js
4. 1.jpg
5. 2.jpg
6. 3.jpg
7. 4.jpg
8. Demo.appcache
9. Index.html
10. Style1.css
11. Style2.css
12. Web.config
13. Zepto.js

This can be applied offline, this time even if the network is broken, those files can still access

Here is one thing to note, for example, here without/index.html he will "applicationcache/" cache, in fact this is index.html

The

manifest file can be divided into three sections:
Cache MANIFEST-Files listed under this heading will be cached after the first download
Network-Files listed under this heading need to be connected to the server and will not be cached
Fallback-the documents listed under this heading provide a fallback page (such as 404 pages) When the page is inaccessible

As shown in the figure, HTML5 defines a few event points, but we generally do not take the initiative to use JS to operate what, in most cases, we completely rely on the browser processing.

Size limit

Application cache Size limit Unified in 5M, I do a test here:

As shown, two CSS files are still over 5M this time

1. Document is loaded from application Cache with manifest Http://localhost/applicationcache/demo.appcache
2. Index.html:1 Application Cache Checking Event
3. Index.html:6 Get Http://localhost/applicationcache/style2.css net::err_failed
4. Index.html:1 Application Cache noupdate Event
5. Index.html:11 Get http://localhost/applicationcache/2.jpg net::err_failed
6. Index.html:12 Get http://localhost/applicationcache/3.jpg net::err_failed

As shown, Style2 is no longer cached, what is the problem?

For example, my channel a maintained its own application Cache,b channel also maintained its own, this time a channel if the use reached a peak, will cause all the cache B channel failure, so:

recommends application Cache, store public resources, do not store business resources

Some questions

By the update mechanism, when the manifest is first updated, the cache update is not complete, because the page load is already started or even completed, and the browser still uses expired resources; The browser is not using the new resource when the application cache is updated, and the second time it will not be used. The Window.reload event is executed at this time in the update event.

1. Window.applicationCache.addEventListener ("Updateready", function () {
2. Window.location.reload ()
3. });

As you can see from the example above, caching is not just a display of defined files, such as the applicationcache/in the previous example will be the default save index.html for the mapping of data, and contains demo.appcache files, many times you will encounter a file update line is always not updated, this time casually in the manifest configuration file to do a little modification can be updated.

For example, we'll make a change in the code here:

2. =>

This time, if you do not do Demo.appcache update, the cache will not be updated, because index.html is cached, the detection is still the original manifest list

Each page unified management of their own manifest list, A page is configured COMMON.JS,B page also configured Common.js, meaning is a page update, b page manifest not change, b page is still read the old version of the file, this has a certain reason but also have a certain waste, need public page to do processing.

Summary

from usability and ease of use, application cache is worth using, but it is best to do static resource caching, and it will take more effort to implement offline applications.