HTML5 games and app caches and version updates

Overview

Browser cache can be said to be a double-edged sword, on the one hand can greatly accelerate user access speed, save bandwidth; On the other hand, when the version is updated, the cache is a headache, the browser may use the cache rather than the latest published resources. Resources include JS script, CSS, image resources and so on.

When using HTML5 to develop an app or game, the ideal state should be: the first time the user accesses, downloads and caches the resource, if the server version is not updated, continues to use the cached resource without re-downloading, or if the server version has an update, download the updated resource and enter the app/game.

HTTP if-modified-since header can easily check whether the file is updated, we only need to support If-modified-since header in the server configuration. Nginx is turned on by default, and Apache needs to be configured manually. Without the updated file, the server returns 304, but the file contents are not transferred, so the request is returned very quickly, there is an updated file, 200 is returned, and the file contents are transferred.

In fact, for JS script, CSS, text, JSON and other files can be downloaded using XMLHttpRequest, most browsers will automatically make if-modified-since judgments, so this part of the version of the update and cache is usually no problem, and for the picture resources, XMLHttpRequest can not load cross-domain pictures, and can only load Base64 format pictures, will make the picture size greatly increased. Of course, you can also consider using XHR2, or other XHR enhancements, but compatibility is not particularly good. Normally we use the image element of HTML5, which sets the src attribute to download the picture resource, but uses the cached resource directly.

So the question is, how to ensure that the image resource cache and version updates are not a problem? (I use the test browser including PC-side Chrome/firefox/safari, mobile safari/chrome/browser/qq Browser, the rest of the platform untested, this article gives the scenario in the remaining browsers still need to test validation.) ）

Scenario 1: Directly change the access address of a picture resource

A simple but very effective way to change the access address of the updated image directly after each version update. You can add parameters after accessing the address, or you can change the file name according to the MD5 value of the files, and recommend changing the file name directly. Need to do is to write scripts to automatically calculate the MD5 value, change the file name, in the js/html and other files to access the address also need to automatically search and replace, one click Release, done.

Disadvantages: Some JS scripts may have stitching generated file access address, such as a special effect sequence frame, access to the address of "assets/effect_{0}.png". Format (index), which can be cumbersome to replace, requires special consideration. (I modified the String.prototype.format here)

Scenario 2. Using HTML5 's Applicationcache

Applicationcache I also introduced in the previous blog post, the version of the update we only need to correspond to the manifest file version number and cache list, the browser will automatically update the file according to the manifest file list, always ensure that the user access to the latest resources. Write scripts automatically generate manifest files, one-click Release, Done.

Deficiencies: If the picture resource is large, we do not want users to download all the images before entering the app/game, there are many picture resources can be entered after loading on demand. Then this part of the on-demand image will be included in the network list, or for a simple direct set network: *. The problem is that the network segment in the HTML5 specification is never cached, and when the user accesses it again, loading the picture resource on demand needs to be downloaded again. So if there is a picture resource loaded on demand, the applicationcache effect is much worse.

In the actual test, the browser/qq browser for the network segment of the resources did not follow the specification, but also cache, even if the user exits again access, on-demand will also use the cached picture, loading speed quickly. So the Applicationcache scheme is perfect for both browsers. The safari/chrome does not cache the network segment resource.

Scenario 3: Configure the expire time of the picture resource on the server

The third idea is to control the expire time of the picture resource when the server returns the request, most browsers request to download the file from the server after the file expire time (browser/qq browser exception, after testing even after expire still use cached pictures. ）。 Our app/game still uses the browser's normal cache instead of the Applicationcache, the test found expire after the browser requests the download file support If-modified-since, so long as always mark the picture resource as expired , the browser can automatically check if the image needs to be updated. This scheme is simple to set up, but very effective.

For example Nginx settings:

Location ~* \. (jpg|jpeg|png|  -1; }

The disadvantage: The effect in Safari/chrome is very good, but this scheme is not feasible for browsers with strong partial caching mechanisms (/QQ browsers, etc.).

Summary

The above plan is I in the endless groping in summed up, but generally speaking, the cache and version update problem, and did not find a perfect universal solution, browser implementation and support HTML5 degree varies greatly, or need to choose according to the platform of the release. If you have a better solution, welcome to exchange and share!

HTML5 games and app caches and version updates