Home  >  Article  >  Web Front-end  >  Detailed explanation of the knowledge points of HTML5 application cache Application Cache

Detailed explanation of the knowledge points of HTML5 application cache Application Cache

巴扎黑
巴扎黑Original
2017-05-01 14:48:181412browse

What is Application Cache

HTML5 introduces application caching technology, which means that web applications can be cached and used without a network. By creating a cache manifest file, offline applications can be easily created.

The three advantages brought by Application Cache are:

① Offline browsing

② Improve page loading speed

③ Reduce server pressure

Moreover, all major browsers support Application Cache. Even if they do not support it, it will not have any impact on the program

Offline storage technology

HTML5 proposes two major offline storage technologies: localstorage and Application Cache, both of which have their own application scenarios; the traditional offline storage technology is Cookie.

After practice, our task localstorage should store some non-critical ajax data to make the icing on the cake;

Application Cache is used to store static resources, which is still the icing on the cake;

Cookies can only save a small piece of text (4096 bytes); so they cannot store big data. This is one of the differences between cookies and the above-mentioned caching technology. Because HTTP is stateless, the server needs to distinguish whether the request originates from the same server. , an identification string is required, and this task is completed by cookies. This text will be passed between the server and the browser every time to verify the user's permissions.

Therefore, the application scenarios of Application Cache are different, so the usage is also inconsistent.

Introduction to Application Cache

The use of Application Cache requires two aspects of work:

① The server needs to maintain a manifest list

② Only a simple setting is required on the browser


To illustrate with an example:

CACHE MANIFEST

CACHE:
# 需要缓存的列表
style1.css
1.jpg
01.js

http://localhost/applicationcache/02.js


http://localhost/applicationcache/zepto.js

NETWORK:
# 不需要缓存的
4.jpg

FALLBACK:
# 访问缓存失败后,备用访问的资源,第一个是访问源,第二个是替换文件*.html /offline.html
2.jpg/3.jpg

First of all, I reported an error here:

 Application Cache Error event: Manifest fetch failed (404)

The reason for this error is: the manifest file needs to be configured with the correct MIME-type, that is, "text/cache-manifest". It must be configured on the web server, different servers are different

\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

In this way, you can apply it offline. Even if the Internet is disconnected at this time, those files can still be accessed

There is one thing worth noting here. For example, if /index.html is not included here, it will cache "applicationcache/". In fact, this is index.html

manifest 文件可分为三个部分:
CACHE MANIFEST - 在此标题下列出的文件将在首次下载后进行缓存
NETWORK - 在此标题下列出的文件需要与服务器的连接,且不会被缓存
FALLBACK - 在此标题下列出的文件规定当页面无法访问时的回退页面(比如 404 页面)

As shown in the figure, HTML5 defines several event points, but we generally do not actively use js to operate. In most cases, we completely rely on the browser's processing.

Size limit

The size limit of Application Cache is unified at 5M. Let me do a test here:

As shown, the two css files still exceed 5M at this time

Document was 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 can no longer be cached. What problems will this cause?

For example, channel A maintains its own Application Cache, and channel B also maintains its own. At this time, if the usage of channel A reaches a peak, all caches of channel B will become invalid, so:

  建议Application Cache,存储公共资源,不要存储业务资源

some problems

In terms of the update mechanism, when the manifest is updated for the first time, because the page loading has already started or even completed and the cache update has not yet been completed, the browser will still use expired resources; when the Application Cache is updated, the browser will not use the new ones this time. Resources will only be used the second time. At this time, the window.reload event is executed in the update event.

window.applicationCache.addEventListener("updateready", function(){
    window.location.reload()
});

From the above example, we can know that the cache is not just the display definition file. For example, applicationcache/ in the above example will save index.html as mapped data by default, and include the demo.appcache file. Many times, a file update will be encountered. It is always not updated online. At this time, you can update it by just making some modifications in the manifest configuration file.

For example, let’s make a change to this code:


=>

If you do not update demo.appcache at this time, the cache will not be updated. The reason is that index.html is cached and the original manifest list is still detected

Each page manages its own manifest list in a unified manner, which means that page a is configured with common.js, and page b is also configured with common.js. This means that after page a is updated, if the manifest of page b does not change, page b still reads For old version files, this makes sense but is also wasteful and requires public pages for processing.

Summarize

From the perspective of availability and ease of use, Application Cache is worth using, but it is best to cache static resources. It takes more effort to truly implement offline applications!

The above is the detailed content of Detailed explanation of the knowledge points of HTML5 application cache Application Cache. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn