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 we think localstorage should store some non-critical Ajax data to 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:
The code is as follows |
Copy Code |
CACHE MANIFEST
CACHE: # The list to be cached Style1.css 1.jpg 01.js Http://localhost/applicationcache/02.js Http://localhost/applicationcache/zepto.js
Network: # do not need to cache 4.jpg
Fallback: # After accessing the cache, the alternate access resource, the first is the access source, and the second is the replacement file *.html/offline.html 2.jpg/3.jpg |
First of all, I made a mistake here:
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
The code is as follows |
Copy Code |
\applicationcache 01.js 02.js 1.jpg 2.jpg 3.jpg 4.jpg Demo.appcache Index.html Style1.css Style2.css Web.config 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
The code is as follows |
Copy Code |
Document is loaded from application Cache with manifest Http://localhost/applicationcache/demo.appcache Index.html:1 Application Cache Checking Event Index.html:6 Get Http://localhost/applicationcache/style2.css net::err_failed Index.html:1 Application Cache noupdate Event Index.html:11 Get http://localhost/applicationcache/2.jpg net::err_failed 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:
Recommended 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.
The code is as follows |
Copy Code |
Window.applicationCache.addEventListener ("Updateready", function () { Window.location.reload () }); |
As you can see from the above example, caching is not just a display of defined files, such as the applicationcache/in the previous example will save the index.html as mapped data, and contains demo.appcache files, many times you will encounter a file update line always do not update, 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:
=>
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 manages its own manifest list uniformly, 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.
Summarize
From usability and ease of use, application cache is worth using, but it is best to do the static resources of the cache, really want to implement offline applications will have to spend more effort!