Shulou(Shulou.com)06/01 Report--

This article mainly shows you "how to implement application caching in HTML5", which is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to implement application caching in HTML5".

Why use Application Cache technology?

Before HTML5, we need to access the network to access, there is no doubt that the website has repeatedly requested the server, resulting in slower speed. For PC users, the network is relatively stable, and the loading speed will not be much worse. But what about the mobile? The mobile end depends on the wireless signal, the signal tower, the position is not fixed, affected by the nearby buildings and so on. A series of lead to the instability of the network, we can not change users, nor can we give up the slower users of the network.

Also, in the field of hybrid app, built-in webview is often used to load html pages, which can still cause the above problems if the network speed is too slow.

Offline storage technology

In the actual development, we mainly use Application Cache and LocalStorage technology, which come from HTML5 technology.

(1) Application Cache: usually used for caching static resources (static pages).

(2) LocalStorage: commonly used for AJAX request caching to store non-critical AJAX data.

Let me repeat in a paragraph why you use Application Cache technology:

When some elements of the page are unchanged, you can use Application Cache technology to cache them offline. Every time you access these cached elements, you no longer need to request the server. When something changes frequently, let them request the server every time.

HTML5 Application Cache characteristics

HTML5 introduces application caching, which means that web applications can be cached and accessed when there is no Internet connection.

Application caching brings three advantages to applications:

(1) offline browsing: users can access and use it when they are not involved in the network

(2) Speed improvement: cached resources load faster

(3) reduce requests to the server: browsers will download only updated or changed resources from the server.

Start using Application Cache

Roles involved: servers and html files

What needs to be done on the server side

Manage and maintain manifest.appcache files, check if there are inaccessible files in the manifest list, and update them in a timely manner to avoid losses.

Manifest file (W3C recommends that the file extension is .appcache)

A manifest file is a simple text file that tells the browser what is cached (and what is not cached).

The manifest file can be divided into three parts:

CACHE MANIFEST-the files listed under this heading will be cached after the first download

NETWORK-the files listed under this heading require a connection to the server and will not be cached

FALLBACK-the file listed under this heading specifies the fallback page (such as 404 page) if the page is inaccessible.

Let's sort it out and introduce it one by one.

1. CACHE MANIFEST (it is necessary)

CACHE MANIFEST/reset.css/logo.gif/hx.js

The manifest file lists three resources: a CSS file, a GIF image, and a JavaScript file. When the manifest file is loaded, the browser downloads the three files from the root directory of the website. Then, whenever the user is disconnected from the Internet, these resources are still available.

Note: make sure the path is correct according to the actual directory of the file on the server.

Summary: the resources listed in CACHE MANIFEST are files that need to be cached locally (files to be cached)

II. NETWORK

NETWORK:nav.html

The NETWORK section states that the file "nav.html" is never cached and is not available offline.

NETWORK:*

You can also use the asterisk "*" to indicate that all other resources / files require an Internet connection.

Note: do not put the home page index into the NETWORK to prohibit caching, otherwise plug-ins can not be used.

Summary: the resources listed in NETWORD are dynamic resource files that need to be requested each time (files that are not cached)

III. FALLBACK

FALLBACK:/index/ / 404.html

The FALLBACK section states that if an Internet connection cannot be established, replace all files in the / index/ directory with "404.html".

Note: the first URI is a resource and the second is a backup.

Summary: the resources listed in FALLBACK are displayed using the latter replacement if a file cannot be connected to the Internet or if access fails. (friendly backup page)

Complete manifest file:

CACHE MANIFEST# Files that need to be cached2014.6.5/reset.css/logo.gif/hx.jsNETWORK:#Files that do not need caching2014.6.5nav.htmlFALLBACK:#Files to be replaced2014.6.5/index/ / 404.html

Note: # represents a comment line, but a seemingly simple comment line is very useful. Why do you say that, because the cache of the application is updated when its manifest file changes. If you edit a picture or modify a JavaScript function, these changes will not be re-cached. Updating the date and version number, timestamp, or MD5 code in the comment line is a way to get the browser to re-cache the file.

What html needs to do

You only need to import the manifest.appcache file:

Application Cache Life destruction rules

(1) if the user clears the browser's cache, the Application Cache local cache will be destroyed.

(2) when the manifest file is modified, because the applied cache will be updated when its manifest file is changed. If you edit a picture or modify a JavaScript function, these changes will not be re-cached and the Application Cache local cache will be destroyed.

(3) the application cache is updated by the program

Go deep into the manifest.appcache file

First of all, the first reminder is, do not put the index home page to prohibit caching, although put into the NETWORK does not work, this is a specification, but also a rule, please follow.

HTTP-related cache header domains and https cache page restrictions will be ignored by manifest, so it will not expire until the user agent updates the page, that is, even HTTPS can work offline.

The capacity limit of application cache varies from browser to browser, which is almost 5MB.

When a resource is cached, the browser directly requests this absolute path to also access the resource in the cache.

Cache the page that contains the manifest list, so in fact, even if we do not display the page containing manifest in the manifest cache list, this page will be cached.

Every time the website is updated, the server should check and update the manifest.appcache file to avoid loss.

Even if the manifest property is not set for other pages in the site, the requested resource is accessed from the cache if it is in the cache.

If the manifest file, or one of the files listed internally, does not download properly, the entire update process will fail and the browser will continue to use the old cache.

In fact, it is not necessary to explicitly list the pages to which Application Cache is linked, by default, any page that contains the manifest attribute of the html element will be cached, these automatically cached pages are called main entries, and the files listed in the list are called detailed entries. If some files need to be accessed online, you can create a "whitelist". Like the entries under NETWORK, these files are often called network entries, and each time you connect to a network, you request the server.

The first line CACHE MANIFEST is in a fixed format and must be written on the first line, with NETWORK and FALLBACK as optional.

Resources in FALLBACK must be of the same origin as the manifest file.

The html that references manifest must have the same origin as the manifest file and be in the same domain.

When the manifest file changes, the resource request itself triggers the update

Comments not only play the role of non-execution, which has been explained in detail above, which can be version number, timestamp, MD5 code, and so on.

The cache part of the manifest file cannot use wildcards and must be specified manually. There are no automation tools.

In the process of development, when interacting with WCF through ajax, the data is often loaded successfully for the first time or several times, and then failed.

Because of the enabled web offline caching mechanism, each time ajax loads data, it is read from the local cache file, using ajax's get mode. Because of the get mode cache, the data is not re-requested from the server, resulting in data loading failure.

After changing to ajax post mode, the data is never cache, so every time you refresh the website, you will request data from service.

Error report: Application Cache Error event: Manifest fetch failed

Solution:

The manifest file needs to be configured with the correct MIME-type, namely "text/cache-manifest".

ContentType = text/cache-manifest for manifest, with a recommended .appcache extension

And must be configured on the web server, different server configuration methods are different.

The page is offline and ajax is updated.

First of all, you can modify the manifest file to update this page, but as the article content page is offline, it will be stored locally, if you are a chapter, then the content page of this article will be saved, if you visit it with the same url, no matter whether the data in your article is updated or not, this offline page will not be updated (unless you update the manifest file). So, all your dynamic data have to be obtained by ajax, just like the client, the offline page should be an empty shell without data, and then use ajax to pull the data to fill the empty shell. Then note that the request address of ajax should be written to the network of manifest.

Updates to offline pages (long tail problem)

The website has been updated, how to update the user's local offline page?

As many articles said, first online your file, and then modify the page introduced in the cache.manifest file can, for example, modify the comments, modify, if you visit the page, you will first go to verify manifest updates, if there is an update, refresh the page again, the page will be updated.

Long tail problem (very important):

As mentioned earlier, if your manifest file is updated and you visit the page, you need to refresh the page before the updated page can be loaded by load, so there is a problem. If your back-end data, that is, the data for the js ajax interface has changed, your corresponding js has also been modified. Then when you modify the launch of manifest, the first time you open the page, the page will appear bug. Just swipe the page again and you'll be fine. So, this first visit to bug is something we don't want to see.

And you can't know when the user will visit your page again, so once your page is offline using manifest, just like the client, there will be a long tail problem. Fortunately, manifest has some js interfaces, so you can judge that load updates the file.

The cache.status property returns the current offline application status

UNCACHED (value 0): offline application is not enabled

IDLE (value 1): offline applications are enabled, but locally cached resources are up-to-date and not marked as obsolete

CHECKING (numeric 2): the status of the current update cache is "checking"

DOWNLOADING (value 3): the status of the current update cache is "downloading resources"

UPDATEREADY (value 4): the status of the current update cache is "update complete"

OBSOLETE (value 5): offline applications are enabled, but cache resources are marked as obsolete

What happens if the file exceeds the cache size of 5m.

For example, Channel A maintains its own Application Cache,B channel as well as its own. At this time, if the use of Channel A reaches a peak, it will lead to the invalidation of all caches in Channel B.

Therefore, it is recommended that Application Cache store public resources, not business resources!

As far as the update mechanism is concerned, 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 been completed, the browser will still use the expired resources; when the Application Cache is updated, the new resources will not be used this time, and the second time will be used. The window.reload event is executed in the update event at this time.

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

As you can see from the above example, the cache is not only the file that displays the definition, such as applicationcache/ in the example above, the data whose index.html is mapped is saved by default, and the demo.appcache file is included. Very often, you will encounter a file update that is not always updated online. At this time, you can update it by making some changes in the manifest configuration file.

Make a code change:

= >

At this time, if the A.appcache is not updated, the cache will not be updated because the index.html is cached and the original manifest list is still detected.

Each page manages its own manifest list, which means that page an is configured with common.js,b and common.js, which means that page an is updated

If the manifest of the b page is not changed, the b page still reads the old version of the file, which is reasonable but also wasteful and needs to be dealt with on the public page.

These are all the contents of the article "how to implement application caching in HTML5". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.