HTML5 Application Caching Application cache

Source: Internet
Author: User

What is Application Cache

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

The three advantages of the application cache are:

① Offline Browsing

② Boost page load speed

③ Reduce server pressure

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

Offline Storage Technology

HTML5 puts forward two major offline storage technologies: Localstorage and Application Cache, each with application scenarios, and traditional offline storage technology as a cookie.

After practice we think that localstorage should store some non-critical AJAX data, do the icing on the cake;

The application cache is still the icing on the cake for storing static resources;

A cookie can only hold a small field (4096 bytes); Therefore, it is not possible to store big data, which is one of the differences between cookies and the caching technology mentioned above, because HTTP is stateless and the server needs an identity string to differentiate whether the request originates from the same server. This task is done by the cookie, which is passed between the server and the browser each time to verify the user's permissions.

So the application cache scenario is different, so the use is inconsistent.

Application Cache Introduction

The use of the application cache is done in two ways:

① server side needs to maintain a manifest checklist

Only one simple setting is required on the ② browser

<HTML  manifest= "Demo.appcache">   

Take an example to illustrate:

Cache manifestcache:# requires a cached list Style1.css1. Jpg01. Jshttp://localhost/applicationcache/02.jshttp: ///localhost/applicationcache/zepto.jsnetwork:# do not need to cache 4. jpgfallback:# Access Cache fails after alternate access to the resource, the first one is the access source , and the second one is the replacement file *.html/offline.html2.jpg/3.jpg       

First I reported 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, which is "text/cache-manifest". Must be configured on the Web server, different servers are not the same

\applicationcache. js. js            1. jpg    2. jpg    3. jpg 4. jpg Demo.appcache index.html style1.css style2.css Web. config zepto.js     

This way it can be applied offline, even if the network is disconnected, the files can still be accessed

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

The manifest file can be divided into three parts: Cache manifest-Files listed under this heading will be cached after the first download-Files listed under this heading require a connection to the server and are not cached fallback- The files listed under this heading provide a fallback page when the page is inaccessible (for example, 404 pages)

, HTML5 defines a few incidents, but we generally do not actively use JS to operate what, in most cases, we rely entirely on the browser processing.

Size limit

Application cache Size limit uniform at 5M, I'm doing a test here:

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

With manifest http://localhost/applicationcache/demo.appcacheindex.html:1 application Cache Checking Eventindex.html:6 GET http://localhost/applicationcache/style2.css net::err_failedindex.html:1  Application Cache noupdate eventindex.html:11 GET http://localhost/applicationcache/2.jpg Net::err_ Failedindex.html:12 GET http://localhost/applicationcache/3.jpg net::err_failed    

As shown, Style2 is no longer cached, what does this cause?

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

Recommend application Cache, store public resources, and do not store business resources

Some questions

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

function() {    window.location.reload ()});

As can be known from the above example, the cache is not just a file that shows the definition, such as the applicationcache/in the previous example The default is to save Index.html as the map of the 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 change can be updated.

For example, we make a change to the code here:

<HTML  manifest= "Demo.appcache">+<manifest= "Demo1.appcache" >        

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 list of manifest, It means a page configured Common.js,b page also configured Common.js, meaning is a page update, b page manifest do not change, b page is still read the old version of the file, this has some 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 a static resource cache, the real need to implement offline applications will have to spend more effort!

Reference: http://www.w3school.com.cn/html5/html_5_app_cache.asp

Please point out any errors or deficiencies in the text.

HTML5 Application Caching Application cache

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.