H5 Cache Mechanism Analysis of Mobile Web Loading Performance Optimization

1. Introduction to H5 cache mechanism

H5, or HTML5, is a new generation of HTML standard, adding many new features. Offline storage (also known as cache mechanism) is one of the most important features. H5 introduces offline storage, which means that web applications can be cached and accessed when there is no Internet connection.

H5 application cache brings three advantages to applications:

• Offline browsing allows users to use apps when they are offline
• Speed: Cached resources load faster
• Reduce server load The browser will only download updated or changed resources from the server.

According to the standards, H5 has a total of 6 cache mechanisms so far, some of which have existed before and some of which have been newly added to H5.

1. Browser caching mechanism
2. Dom Storgage (Web Storage) storage mechanism
3. Web SQL Database storage mechanism
4. Application Cache (AppCache) mechanism
5. Indexed Database (IndexedDB)
6. File System API

Below we first analyze the principles, usage and characteristics of various cache mechanisms; then we look at how to use appropriate cache mechanisms to improve Web loading performance in response to the needs of Android mobile Web performance loading optimization.

2. Analysis of the H5 cache mechanism principle

2.1 Browser Cache Mechanism

The browser cache mechanism refers to the mechanism that controls file cache through fields such as Cache-Control (or Expires) and Last-Modified (or Etag) in the HTTP protocol header. This should be the earliest cache mechanism in the WEB, which is implemented in the HTTP protocol. It is a little different from cache mechanisms such as Dom Storage and AppCache, but they are essentially the same. It can be understood that one is implemented at the protocol layer and the other is implemented at the application layer.

Cache-Control is used to control the effective length of time that files are cached locally. The most common example is the server reply: Cache-Control:max-age=600 means that the file should be cached locally and the effective length is 600 seconds (from the time the request is made). In the next 600 seconds, if there is a request for this resource, the browser will not issue an HTTP request, but will directly use the locally cached file.

Last-Modified is the last update time of the file on the server. The next time you request a file, if the file cache has expired, the browser sends this time to the server through the If-Modified-Since field, and the server compares the timestamp to determine whether the file has been modified. If it has not been modified, the server returns 304 to tell the browser to continue using the cache; if it has been modified, it returns 200 and returns the latest file.

Cache-Control is usually used together with Last-Modified. One is used to control the cache validity period, and the other is used to query the service for updates after the cache expires.

Cache-Control also has a field with the same function: Expires. The value of Expires is an absolute time point, such as: Expires: Thu, 10 Nov 2015 08:45:11 GMT, which means that the cache is valid before this time point.

Expires is a field in the HTTP1.0 standard, and Cache-Control is a new field in the HTTP1.1 standard. They have the same function, both of which control the effective time of the cache. When these two fields appear at the same time, Cache-Control is highly optimized.

Etag is also a field for identifying files, just like Last-Modified. The difference is that the value of Etag is a characteristic string for identifying files. When querying the server whether a file has been updated, the browser sends the characteristic string to the server through the If-None-Match field, and the server matches the file's characteristic string to determine whether the file has been updated. If there is no update, the response packet is 304, and if there is an update, the response packet is 200. Etag and Last-Modified can be used one or both at the same time according to needs. When both are used at the same time, as long as one of the base conditions is met, the file is considered not to have been updated.

There are two special cases:

• When you refresh the page manually (F5), the browser will directly think that the cache has expired (it may not have expired yet), add the field Cache-Control:max-age=0 to the request, and send a packet to the server to query whether there is any file update.
• Force refresh the page (Ctrl+F5), the browser will directly ignore the local cache (even if there is a cache, it will think there is no local cache), add the field: Cache-Control:no-cache (or Pragma:no-cache) in the request, and send a package to the service to pull the file again.

Below are screenshots of different requests and responses for a resource file using the developer tools built into the Google Chrome browser (you can also use other browsers + packet capture tools).

*** Request: 200

Request within the cache validity period: 200 (from cache)

Request after cache expiration: 304 (Not Modified)

Generally, browsers will store cache records and cache files in the local Cache folder. If an Android app uses Webview, the cached file records and file contents will be stored in the data directory of the current app.

Analysis: Cache-Control and Last-Modified are generally used on static resource files on the Web, such as JS, CSS, and some image files. Setting the cache properties of resource files is very meaningful for improving the loading speed of resource files and saving traffic, especially in mobile network environments. But the question is: how to set the effective duration of the cache? If it is set too short, the cache will not be used; if it is set too long, when the resource file is updated, if the browser has cache, it will not be able to retrieve the latest file in time.

Last-Modified requires a query request to the server to know whether the resource file has been updated. Although the server may return 304 to indicate that there is no update, there is still a request process. For mobile networks, this request may be time-consuming. There is a saying called "eliminate 304", which means optimizing 304 requests.

Packet capture shows that for requests with the if-Modified-Since field, if the server responds with a 304 packet and the response contains the Cache-Control:max-age or Expires field, the cache validity period of the file will be updated, that is, the cache of the file will be valid again. If a request is made again after the 304 response, the cached file will be used directly, and the server will no longer be queried to see if the file has been updated, unless the new cache time expires again.

In addition, Cache-Control and Last-Modified are mechanisms of the browser kernel, which are generally implemented in a standard way and cannot be changed or set. Taking QQ Browser X5 as an example, Cache-Control and Last-Modified cache cannot be disabled. The cache capacity is 12MB, regardless of HOST, and expired cache will be cleared first. If none of them have expired, the earliest cache or the one that expires the soonest or has the largest file size should be cleared first; expired cache may still be valid, and clearing the cache will cause the resource files to be re-pulled.

In addition, browsers, such as X5, do not verify the contents of cached files when using them, which makes it possible for the contents of cached files to be modified.

The analysis found that the browser's cache mechanism is not a very perfect cache mechanism. The best cache mechanism should be like this:

1. The cache file is not updated. Use the cache as much as possible without interacting with the server.
2. When the cache file is updated, the new file can be used as soon as possible;
3. The cached files should maintain integrity and modified cached files should not be used;
4. The cache capacity must be configurable or controllable, and cache files cannot be cleared due to storage space limitations or expiration. Taking X5 as an example, items 1 and 2 cannot be met at the same time, and items 3 and 4 cannot be met at the same time.

In actual applications, in order to solve the problem of difficult to set Cache-Control cache duration and to "eliminate 304", the Web front-end adopts the following method:

1. Add the version number or file MD5 value string to the resource file name to be cached, such as common.d5d02a02.js, common.v1.js, and set Cache-Control:max-age=31536000, which is one year. Within one year, if the resource file is cached locally, the cache will be used, and there will be no 304 response packets.
2. If the resource file is modified, the file content is updated and the resource file name is modified, such as common.v2.js, and the HTML page will also reference the new resource file name.

In this way, the purpose of using the cached file when it is not updated and using the latest file when it is updated is achieved. This is the purpose of using the cached file when it is not updated. This is the purpose of using the cached file when it is ...

2.2 Dom Storage Storage Mechanism

DOM storage is a general term for a set of storage-related features first introduced in the Web Applications 1.0 specification. It has now been separated and developed into an independent W3C Web Storage specification. DOM storage is designed to provide a larger storage capacity, safer, and more convenient storage method, which can replace the traditional method of storing some information that does not need to be known to the server in cookies.

The above paragraph is the official description of the Dom Storage storage mechanism. It seems that the Dom Storage mechanism is similar to Cookies, but has some advantages.

Dom Storage is provided by storing string Key/Value pairs, and provides 5MB (may be different for different browsers, divided by HOST) of storage space (Cookies are only 4KB). In addition, the data stored in Dom Storage is local, unlike Cookies, which will be sent to the server every time a page is requested.

DOM Storage is divided into sessionStorage and localStorage. The usage of localStorage object and sessionStorage object is basically the same, the difference between them is the scope of application. sessionStorage is used to store data related to the page, and it cannot be used after the page is closed. LocalStorage is persistent and can be used even after the page is closed.

Dom Storage provides the following storage interfaces:

 interface Storage {
 readonly attribute unsigned long length;
 [IndexGetter] DOMString key(in unsigned long index);
 [NameGetter] DOMString getItem(in DOMString key);
 [NameSetter] void setItem(in DOMString key, in DOMString data);
 [NameDeleter] void removeItem(in DOMString key);
 void clear();
 };

sessionStorage is a global object that maintains storage space that is valid during a page session. The page session period lasts as long as the browser is open. The page session also persists when the page is reloaded or restored. Each time a new page is opened in a new tab or window, a new session is initialized.

 < script   type = "text/javascript" >  
 // When the page is refreshed, restore the previously entered content from sessionStorage
 window.onload = function (){
    if (window.sessionStorage) {
        var name = window .sessionStorage.getItem("name");
        if (name != "" || name != null){
            document.getElementById("name") .value = name ;
 }
 }
 }; 
 
 // Save the data to the sessionStorage object
 function saveToStorage() {
    if (window.sessionStorage) {
        var name = document .getElementById("name").value;
        window.sessionStorage.setItem("name", name);
 window.location.href = "session_storage.html" ;
 }
 }
 </ script >   
 
 < form   action = "./session_storage.html" >  
 < input   type = "text"   name = "name"   id = "name" />  
 < input   type = "button"   value = "Save"   onclick = "saveToStorage()" />  
 </ form >

When the browser is accidentally refreshed, some temporary data should be saved and restored. The sessionStorage object is most useful in handling this situation. For example, restore the data we have filled in the form.

Copy the above code to the session_storage.html page (you can also download it directly from the attachment), open it with different pages or windows of Google Chrome browser, enter different text in the input box, click "Save", and then refresh them respectively. Each page or window displays the content entered in the current page, and they do not affect each other. If you close the page and reopen it, the content you entered last time will be gone.

The interface and usage of Local Storage are the same as Session Storage, the only difference is that the data saved in Local Storage is persistent. When the current PAGE is closed (after the Page Session ends), the saved data still exists. When the PAGE is reopened, the last saved data can be obtained. In addition, Local Storage is global. If two PAGEs are opened at the same time, they will share a copy of the stored data. If the data is modified in one PAGE, it can be perceived in the other PAGE.

 < script >  
 // Another way to directly reference the key through localStorage is equivalent to:
  //localStorage.getItem("pageLoadCount");
  //localStorage.setItem("pageLoadCount", value);
  if (!localStorage.pageLoadCount)
 localStorage.pageLoadCount = 0 ;
 localStorage.pageLoadCount = parseInt (localStorage.pageLoadCount) + 1;
     document.getElementById('count') .textContent = localStorage .pageLoadCount;
 </ script >   
 
 < p >  
 You have viewed this page
 < span   id = "count" > an untold number of </ span >  
 time(s).
 </ p >

Copy the above code to the local_storage.html page and open it with a browser. The value of pageLoadCount is 1. Close the page and reopen it. The value of pageLoadCount is 2. This is because the last value has been saved.

Use two pages to open local_storage.html at the same time and refresh them alternately. It is found that the two pages share the same pageLoadCount.

Analysis: Dom Storage provides a more flexible data storage method for the Web, with larger storage space (relative to Cookies), simpler usage, and convenient for storing some temporary data on the server or locally.

From the interface provided by DomStorage, DomStorage is suitable for storing relatively simple data. If you want to store structured data, you may need to use JASON to convert the object to be stored into a JASON string. It is not suitable for storing complex data or data that requires a large storage space, nor is it suitable for storing static files.

In the Android embedded Webview, you need to enable Dom Storage through the Webview settings interface.

 WebView myWebView = (WebView) findViewById(R.id.webview);
 WebSettings webSettings = myWebView.getSettings();
 webSettings.setDomStorageEnabled( true );

To use Android as an analogy, the Web's Dom Storage mechanism is similar to Android's SharedPreference mechanism.

2.3 Web SQL Database Storage Mechanism

H5 also provides a SQL-based database storage mechanism for storing structured data suitable for the database. According to official standard documents, the Web SQL Database storage mechanism is no longer recommended and will no longer be maintained in the future. Instead, AppCache and IndexedDB are recommended.

Currently, most mainstream browsers (click here to view browser support) still support the Web SQL Database storage mechanism. The Web SQL Database storage mechanism provides a set of APIs for Web Apps to create, store, and query databases.

The following is a simple example to demonstrate the use of Web SQL Database.

 <script>
 if (window.openDatabase){
 //Open the database, if it doesn't exist, create it  
      var db = openDatabase( 'mydb' , '1.0' , 'Test DB' , 2 * 1024 ); 
 
 //Through the transaction, create a table and add two records  
      db.transaction(function (tx) {
           tx.executeSql( 'CREATE TABLE IF NOT EXISTS LOGS (id unique, log)' );
           tx.executeSql( 'INSERT INTO LOGS (id, log) VALUES (1, "foobar")' );
           tx.executeSql( 'INSERT INTO LOGS (id, log) VALUES (2, "logmsg")' );
 }); 
 
 //Query all records in the table and display them  
     db.transaction(function (tx) {
         tx.executeSql( 'SELECT * FROM LOGS' , [], function (tx, results) {
             var len = results.rows.length, i;
             msg = "<p>Found rows: " + len + "</p>" ;
 for (i= 0 ; i<len; i++){
                 msg += "<p>" + results.rows.item(i).log + "</p>" ;
 }
             document.querySelector( '#status' ).innerHTML = msg;
 }, null );
 });
 } 
 
 </script> 
 
 <div id= "status" name= "status" >Status Message</div>

Copy the above code into sql_database.html and open it with a browser to see the following content.

The official recommendation is that browsers should set certain limits on the database storage space for each host when implementing it. The recommended default quota is 5MB (per host). When the upper limit is reached, you can apply for more storage space. In addition, the SQL Database implementation of mainstream browsers is based on SQLite.

Analysis: The main advantage of SQL Database is that it can store complex data and fully utilize the advantages of the database to easily add, delete, modify, and query data. Due to the complexity of SQL syntax, it is more troublesome to use. SQL Database is also not very suitable for caching static files.

In the Android embedded Webview, you need to enable SQL Database through the Webview settings interface and set the storage path of the database file.

 WebView myWebView = (WebView) findViewById(R.id.webview);
 WebSettings webSettings = myWebView.getSettings();
 webSettings.setDatabaseEnabled( true );
 final String dbPath = getApplicationContext().getDir( "db" , Context.MODE_PRIVATE).getPath();
 webSettings.setDatabasePath(dbPath);

The Android system also uses a large number of databases to store data, such as contacts, short messages, etc. The database format is also SQLite. Android also provides an API to operate SQLite. The Web SQL Database storage mechanism provides this native function to Web Apps by providing a set of APIs and using the browser to implement it.

#p#

2.4 Application Cache Mechanism

Application Cache (AppCache for short) seems to be a cache mechanism developed to support offline use of Web Apps. Its cache mechanism is similar to the browser's cache (Cache-Control and Last-Modified) mechanism, both of which cache files in units, and the files have a certain update mechanism. However, AppCache is a supplement to the browser's cache mechanism, not a replacement.

Let's first take an official example from W3C to explain the usage and function of the AppCache mechanism.

 WebView myWebView = (WebView) findViewById(R.id.webview);
 WebSettings webSettings = myWebView.getSettings();
 webSettings.setDatabaseEnabled( true );
 final String dbPath = getApplicationContext().getDir( "db" , Context.MODE_PRIVATE).getPath();
 webSettings.setDatabasePath(dbPath);

The above HTML document references an external JS file and a GIF image file, and references a file ending with appcache through the manifest attribute in its HTML header.

We open this HTML link in Google Chrome browser, JS functions normally and the image is displayed normally. Disable the network, close the browser and reopen the link, and we find that JS works normally and the image is displayed normally. Of course, it may also be the browser cache that plays a role. We can disable the network and try again after the browser cache of the file expires, and we find that the HTML page is also normal.

Through the tools that come with the Google Chrome browser, we can view the cached AppCache (divided by HOST).

The cache in the screenshot above is the AppCache of the HTML page we just opened. From the screenshot, we can see that the HTML page and the JS and GIF image files referenced by the HTML are all cached; in addition, the appcache file referenced by the manifest attribute in the HTML header is also cached.

There are two key points in the principle of AppCache: manifest attributes and manifest files.

HTML references the manifest file through the manifest attribute in the header. The manifest file, which is the file ending with appcache above, is a normal file that lists the files that need to be cached.

The manifest file in the screenshot above is the manifest file referenced by the HTML code. The file is relatively simple. The first line is the keyword, and the second and third lines are the file paths to be cached (relative paths). This is just the simplest manifest file. A complete manifest file also includes other keywords and content. The HTML that references the manifest file and the files to be cached listed in the manifest file will eventually be cached by the browser.

A complete manifest file includes three sections, similar to the sections in the ini configuration file in Windows, but without the square brackets.

1. CACHE MANIFEST - Files listed under this header will be cached after they are downloaded for the first time
2. NETWORK - Files listed under this header require a connection to the server, and will never be cached
3. FALLBACK - Files listed under this header specifies fallback pages if a page is inaccessible

A complete manifest file, such as:

 CACHE MANIFEST
 # 2012-02-21 v1.0.0​​​​  
 /theme.css
 /logo.gif
 /main.js 
 
 NETWORK:
 login.asp 
 
 FALLBACK:
 /html/ /offline.html

In general, when a browser first loads an HTML file, it parses the manifest attribute, reads the manifest file, gets the list of files to be cached under Section: CACHE MANIFEST, and then caches the files.

Are AppCache's cache files stored separately from the browser's cache files, or are they the same? They should be separate, because AppCache also has a local space limit of 5MB (per host).

AppCache also has an update mechanism after it is loaded and generated. If the cached files need to be updated, the manifest file needs to be updated. Because the browser will not only use the cache by default when loading the next time, but will also check whether the manifest file has been modified (byte by byte) in the background. If there is a modification, the manifest file will be retrieved again, and the file list under Section: CACHE MANIFEST will be checked for updates. The check and update of manifest files and cache files also comply with the browser cache mechanism.

If the user manually clears the AppCache cache, the browser will regenerate the cache the next time it loads, which can also be considered a cache update. In addition, Web App can also use code to implement cache updates.

Analysis: AppCache seems to be a good caching method. In addition to caching static resource files, it is also suitable for building Web offline apps. In actual use, there are some things that need to be paid attention to, and some of them can be said to be "pitfalls".

1. To update a cached file, you need to update the manifest file that contains it, even if it is just adding a space. A common method is to modify the version number in the manifest file comment. For example: # 2012-02-21 v1.0.0
2. The browser uses the cached file first, and then updates the cached file by checking whether the manifest file has been updated. In this way, the cached file may not use the latest version.
3. During the cache update process, if one file fails to update, the entire update will fail.
4. The manifest and the HTML that references it must be on the same host.
5. A list of files in the manifest file. If it is a relative path, it is the relative path to the manifest file.
6. The manifest may also be updated incorrectly, causing the cache file to fail to update.
7. Resources that are not cached cannot be loaded in cached HTML, even if there is network. For example: http://appcache-demo.s3-website-us-east-1.amazonaws.com/without-network/
8. The manifest file itself cannot be cached, and the update of the manifest file uses the browser cache mechanism. Therefore, the cache time of the Cache-Control of the manifest file cannot be set too long.

In addition, according to official documents, AppCache is no longer recommended and will no longer be supported by the standard. Currently, mainstream browsers still support AppCache, but it is not certain whether this will happen in the future.

In the Android embedded Webview, you need to enable AppCache through the Webview settings interface, set the storage path of the cache file, and also set the cache space size.

 WebView myWebView = (WebView) findViewById(R.id.webview);
 WebSettings webSettings = myWebView.getSettings();
 webSettings.setAppCacheEnabled( true );
 final String cachePath = getApplicationContext().getDir( "cache" , Context.MODE_PRIVATE).getPath();
 webSettings.setAppCachePath(cachePath);
 webSettings.setAppCacheMaxSize( 5 * 1024 * 1024 );

2.5 Indexed Database

IndexedDB is also a database storage mechanism, but it is different from the no longer supported Web SQL Database. IndexedDB is not a traditional relational database and can be classified as a NoSQL database. IndexedDB is similar to the key-value storage method of Dom Storage, but it is more powerful and has a larger storage space.

IndexedDB stores data in the form of key-value. Key is required and must be unique; Key can be defined by yourself or automatically generated by the system. Value is also required, but Value is very flexible and can be any type of object. Generally, Value is accessed through Key.

IndexedDB provides a set of APIs for storing, retrieving, and traversing data. These APIs are asynchronous, and the results of the operations are returned in callbacks.

The following code demonstrates the basic functions of opening (creating) a DB in IndexedDB, creating a storage object (which can be understood as a "table" with relational data), and accessing and traversing data.

 <script type= "text/javascript" > 
 
 var db; 
 
 window.indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB; 
 
 //Does the browser support IndexedDB?  
 if (window.indexedDB) {
 //Open the database, if it does not exist, create it  
   var openRequest = window.indexedDB.open( "people_db" , 1 ); 
 
 //Callback when DB version is set or upgraded  
   openRequest.onupgradeneeded = function(e) {
       console.log( "Upgrading..." ); 
 
       var thisDB = e.target.result;
 if (!thisDB.objectStoreNames.contains( "people" )) {
           console.log( "Create Object Store: people." ); 
 
 //Create a storage object, similar to a table in a relational database  
           thisDB.createObjectStore( "people" , { autoIncrement: true }); 
 
 //Create storage objects and indexes  
 //var objectStore = thisDB.createObjectStore("people",{ autoIncrement:true });  
 // //first arg is name of index, second is the path (col);  
 //objectStore.createIndex("name","name", {unique:false});  
 //objectStore.createIndex("email","email", {unique:true});  
 }
 } 
 
 //DB successfully opened callback  
 openRequest.onsuccess = function(e) {
    console.log( "Success!" ); 
 
 //Save the global database object, which will be used later  
 db = e.target.result; 
 
 //Bind button click event  
     document.querySelector( "#addButton" ).addEventListener( "click" , addPerson, false ); 
 
    document.querySelector( "#getButton" ).addEventListener( "click" , getPerson, false ); 
 
    document.querySelector( "#getAllButton" ).addEventListener( "click" , getPeople, false ); 
 
    document.querySelector( "#getByName" ).addEventListener( "click" , getPeopleByNameIndex1, false );
 } 
 
 //DB open failure callback  
  openRequest.onerror = function(e) {
 console.log( "Error" );
 console.dir(e);
 } 
 
 } else {
    alert( 'Sorry! Your browser doesn\'t support the IndexedDB.' );
 } 
 
 //Add a record  
 function addPerson(e) {
    var name = document.querySelector( "#name" ).value;
    var email = document.querySelector( "#email" ).value; 
 
    console.log( "About to add " +name+ "/" +email); 
 
    var transaction = db.transaction([ "people" ], "readwrite" );
 var store = transaction.objectStore( "people" ); 
 
 //Define a person  
 var person = {
 name:name,
 email:email,
 created: new Date()
 } 
 
 //Perform the add  
   var request = store.add(person);
 //var request = store.put(person, 2);   
 
   request.onerror = function(e) {
       console.log( "Error" ,e.target.error.name);
 //some type of error handler  
 } 
 
   request.onsuccess = function(e) {
      console.log( "Woot! Did it." );
 }
 } 
 
 //Query records by KEY  
 function getPerson(e) {
    var key = document.querySelector( "#key" ).value;
 if (key === "" || isNaN(key)) return ; 
 
    var transaction = db.transaction([ "people" ], "readonly" );
    var store = transaction.objectStore( "people" ); 
 
    var request = store.get(Number(key)); 
 
    request.onsuccess = function(e) {
        var result = e.target.result;
 console.dir(result);
 if (result) {
           var s = "<p><h2>Key " +key+ "</h2></p>" ;
 for (var field in result) {
               s+= field+ "=" +result[field]+ "<br/>" ;
 }
           document.querySelector( "#status" ).innerHTML = s;
 } else {
            document.querySelector( "#status" ).innerHTML = "<h2>No match!</h2>" ;
 }
 }
 } 
 
 //Get all records  
 function getPeople(e) { 
 
 var s = "" ; 
 
     db.transaction([ "people" ], "readonly" ).objectStore( "people" ).openCursor().onsuccess = function(e) {
        var cursor = e.target.result;
 if (cursor) {
            s += "<p><h2>Key " +cursor.key+ "</h2></p>" ;
 for (var field in cursor.value) {
                s+= field+ "=" +cursor.value[field]+ "<br/>" ;
 }
 s+= "</p>" ;
            cursor.continue ();
 }
         document.querySelector( "#status2" ).innerHTML = s;
 }
 } 
 
 //Query records by index  
 function getPeopleByNameIndex(e)
 {
    var name = document.querySelector( "#name1" ).value; 
 
    var transaction = db.transaction([ "people" ], "readonly" );
    var store = transaction.objectStore( "people" );
    var index = store.index( "name" ); 
 
 //name is some value  
    var request = index.get(name); 
 
    request.onsuccess = function(e) {
       var result = e.target.result;
 if (result) {
           var s = "<p><h2>Name " +name+ "</h2><p>" ;
 for (var field in result) {
               s+= field+ "=" +result[field]+ "<br/>" ;
 }
 s+= "</p>" ;
 } else {
        document.querySelector( "#status3" ).innerHTML = "<h2>No match!</h2>" ;
 }
 }
 } 
 
 //Query records by index  
 function getPeopleByNameIndex1(e)
 {
 var s = "" ; 
 
    var name = document.querySelector( "#name1" ).value; 
 
    var transaction = db.transaction([ "people" ], "readonly" );
    var store = transaction.objectStore( "people" );
    var index = store.index( "name" ); 
 
 //name is some value  
    index.openCursor().onsuccess = function(e) {
        var cursor = e.target.result;
 if (cursor) {
            s += "<p><h2>Key " +cursor.key+ "</h2></p>" ;
 for (var field in cursor.value) {
                s+= field+ "=" +cursor.value[field]+ "<br/>" ;
 }
 s+= "</p>" ;
            cursor.continue ();
 }
         document.querySelector( "#status3" ).innerHTML = s;
 }
 } 
 
 </script> 
 
 <p>Add data<br/>
 <input type= "text" id= "name" placeholder= "Name" ><br/>
 <input type= "email" id= "email" placeholder= "Email" ><br/>
 <button id= "addButton" >Add Data</button>
 </p> 
 
 <p>Query data based on Key<br/>
 <input type= "text" id= "key" placeholder= "Key" ><br/>
 <button id= "getButton" >Get Data</button>
 </p>
 <div id= "status" name= "status" ></div> 
 
 <p>Get all data<br/>
 <button id= "getAllButton" >Get EveryOne</button>
 </p>
 <div id= "status2" name= "status2" ></div> 
 
 <p>Query data based on index: Name<br/>
    <input type= "text" id= "name1" placeholder= "Name" ><br/>
    <button id= "getByName" >Get ByName</button>
 </p>
 <div id= "status3" name= "status3" ></div>

Copy the above code to indexed_db.html and open it with Google Chrome browser to add and query data. In Chrome's developer tools, you can view the created DB, storage objects (which can be understood as tables), and the data added to the table.

IndexedDB has a very powerful function, which is index. It can generate an index for any attribute in a Value object, and then quickly query the Value object based on the index.

To generate an index or support index query data, you need to call the interface to generate the index of the attribute when you generate the storage object. You can create indexes for multiple different attributes of the object at the same time. For example, the following code generates indexes for both the name and email attributes.

 var objectStore = thisDB.createObjectStore( "people" ,{ autoIncrement: true });
 //first arg is name of index, second is the path (col);  
 objectStore.createIndex( "name" , "name" , {unique: false });
 objectStore.createIndex( "email" , "email" , {unique: true });

After the index is generated, you can query the data based on the index.

 function getPeopleByNameIndex(e)
 {
 var name = document.querySelector( "#name1" ).value; 
 
 var transaction = db.transaction([ "people" ], "readonly" );
 var store = transaction.objectStore( "people" );
 var index = store.index( "name" ); 
 
 //name is some value  
 var request = index.get(name);
 request.onsuccess = function(e) {
    var result = e.target.result;
 if (result) {
        var s = "<p><h2>Name " +name+ "</h2><p>" ;
 for (var field in result) {
            s+= field+ "=" +result[field]+ "<br/>" ;
 }
 s+= "</p>" ;
 } else {
        document.querySelector( "#status3" ).innerHTML = "<h2>No match!</h2>" ;
 }
 }
 }

Analysis: IndexedDB is a flexible and powerful data storage mechanism that combines the advantages of Dom Storage and Web SQL Database. It is used to store large blocks or complex data, provides larger storage space, and is relatively simple to use. It can be used as a substitute for Web SQL Database. It is not very suitable for caching static files.

1. Objects are accessed in a key-value manner. They can be any type of value or object, including binary.
2. You can generate indexes for any attributes of an object to facilitate querying.
3. Larger storage space, the default recommended 250MB (per HOST), which is much larger than the 5MB of Dom Storage.
4. Data operations are performed through the database's transaction mechanism to ensure data consistency.
5. Asynchronous API calls avoid waiting and affecting the experience.

Android started to add support for IndexedDB in 4.4. Just turn on the switch to allow JS execution.

 function getPeopleByNameIndex(e)
 {
 var name = document.querySelector( "#name1" ).value; 
 
 var transaction = db.transaction([ "people" ], "readonly" );
 var store = transaction.objectStore( "people" );
 var index = store.index( "name" ); 
 
 //name is some value  
 var request = index.get(name);
 request.onsuccess = function(e) {
    var result = e.target.result;
 if (result) {
        var s = "<p><h2>Name " +name+ "</h2><p>" ;
 for (var field in result) {
            s+= field+ "=" +result[field]+ "<br/>" ;
 }
 s+= "</p>" ;
 } else {
        document.querySelector( "#status3" ).innerHTML = "<h2>No match!</h2>" ;
 }
 }
 }

#p#

2.6 File System API

The File System API is a new storage mechanism added to H5. It provides a virtual file system for Web Apps, just like Native Apps access the local file system. Due to security considerations, this virtual file system has certain limitations. Web Apps can create, read, write, delete, and traverse files (folders) in the virtual file system.

The File System API is also an optional caching mechanism, just like the previous SQLDatabase, IndexedDB, and AppCache. The File System API has some specific advantages of its own:

1. It can meet the storage requirements of large binary blobs.
2. You can improve performance by preloading resource files.
3. The file can be edited directly.

The browser provides two types of storage space for the virtual file system: temporary and persistent. Temporary storage space is automatically allocated by the browser, but may be reclaimed by the browser; persistent storage space requires explicit application, and the browser will give the user a prompt when applying, requiring the user to confirm. Persistent storage space is managed by the WebApp itself, and the browser will not recycle or clear the content. The size of persistent storage space is managed by quotas. When applying for the first time, an initial quota will be allocated, and you need to apply again when the quota is used up.

The virtual file system runs in a sandbox. The virtual file systems of different WebApps are isolated from each other, and the virtual file system is also isolated from the local file system.

The File System API provides a set of file and folder operation interfaces, with synchronous and asynchronous versions to meet different usage scenarios. The following example demonstrates simple functions and usage through a file creation, reading, and writing example.

 <script type= "text/javascript" > 
 
 window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem; 
 
 //Request storage space for temporary files  
 if (window.requestFileSystem) {
     window.requestFileSystem(window.TEMPORARY, 5 * 1024 * 1024 , initFS, errorHandler);
 } else {
  alert( 'Sorry! Your browser doesn\'t support the FileSystem API' );
 } 
 
 //Request successful callback  
 function initFS(fs){ 
 
 //Open the log.txt file in the root directory, and create it if it does not exist.  
 //fs is the file system object that was successfully returned, fs.root represents the root directory  
  fs.root.getFile( 'log.txt' , {create: true }, function(fileEntry) { 
 
 //fileEntry is a file object returned, representing the opened file   
 
 //Write specified content to the file  
 writeFile(fileEntry); 
 
 //Read the written content and display it on the page  
 readFile(fileEntry); 
 
 }, errorHandler);
 } 
 
 //Read the file content  
 function readFile(fileEntry)
 {
    console.log( 'readFile' ); 
 
 // Get a File object representing the file,  
 // then use FileReader to read its contents.  
   fileEntry.file(function(file) { 
 
     console.log( 'createReader' ); 
 
      var reader = new FileReader(); 
 
      reader.onloadend = function(e) { 
 
        console.log( 'onloadend' ); 
 
        var txtArea = document.createElement( 'textarea' );
        txtArea.value = this .result;
        document.body.appendChild(txtArea);
 }; 
 
      reader.readAsText(file);
 }, errorHandler);
 } 
 
 //Write specified content to the file  
 function writeFile(fileEntry)
 {
    console.log( 'writeFile' ); 
 
 // Create a FileWriter object for our FileEntry (log.txt).  
    fileEntry.createWriter(function(fileWriter) { 
 
      console.log( 'createWriter' ); 
 
      fileWriter.onwriteend = function(e) {
        console.log( 'Write completed' );
 }; 
 
        fileWriter.onerror = function(e) {
          console.log( 'Write failed: ' + e.toString());
 }; 
 
 // Create a new Blob and write it to log.txt.  
        var blob = new Blob([ 'Hello, World!' ], {type: 'text/plain' }); 
 
        fileWriter.write(blob); 
 
 }, errorHandler);
 } 
 
 function errorHandler(err){
 var msg = 'An error occured: ' + err;
 console.log(msg);
 }; 
 
 </script>

Copy the above code into the filesystemmapi.html file and open it with Google Chrome (now only supports the File System API, Chrome 43+, Opera 32+, and Chrome for Android 46+). Since Google Chrome disables the File System API function in local HTML files, add the "—allow-file-access-from-files" command line parameter when starting Chrome.

In the screenshot above, the left is the result of HTML running, and the right is the web file system seen in the Chrome developer tools. Basically, the data of several cache mechanisms of H5 can be seen in this developer tool, which is very convenient.

Analysis: The File System API brings file system functions to Web Apps, and the functions of Native file system are implemented accordingly in Web Apps. Any scenario where data needs to be managed through files or data management through file systems is more suitable.

Up to now, the File System API is not supported by the Android system.

3. Optimization of mobile web loading performance (cache)

After analyzing the various caching mechanisms provided by H5, we return to the mobile (for Android, which may also be suitable for iOS). Now Android Apps (including mobile Q and WX) mostly embedded components of Webview (system Webview or QQ browser X5 components), and load some H5 operation activity pages or information pages by embedded Webview. This can give full play to the advantages of the Web front-end: rapid development, release, and flexible up and down. However, Webview also has some problems that cannot be ignored. The more prominent one is that it loads relatively slowly and consumes relatively more traffic.

By debugging and catching some H5 pages, it is found that each time an H5 page is loaded, there will be more requests. In addition to the requests of the HTML main URL itself, the JS, CSS, font files, and pictures referenced externally by HTML are all independent HTTP requests, and each request is serialized (maybe there is connection multiplexing). With so many requests being serialized, coupled with the browser's parsing and rendering time, the overall loading time of the web becomes longer; the more requested files, the more traffic it consumes. We can use the above mentioned caching mechanisms to help us optimize the loading performance of the web.

Conclusion: Combined with the comparison of various cache mechanisms, static files, such as JS, CSS, fonts, pictures, etc., are suitable for cache through the browser cache mechanism. Caching files can greatly improve the loading speed of the web and save traffic. However, there are some shortcomings: the cached files need to be loaded only after they are loaded; the storage space of the browser cache is limited, and the cache may be cleared; the cached files are not verified. To solve these shortcomings, you can refer to the offline package of QQ, which effectively solves these shortcomings.

Data obtained by the Web locally or on the server can be cached through Dom Storage and IndexedDB. It also reduces interaction with Server to a certain extent, improves loading speed, and saves traffic.

Of course, the performance optimization of the web also includes choosing the appropriate image size to avoid blockage caused by JS and CSS, etc. This requires colleagues on the front-end of the web to optimize according to some specifications and some debugging tools.

For more information, please follow our WeChat ID: weixinBugly or search for our WeChat ID: weixinBugly.

Tencent Bugly

Bugly is an outsourced version of Tencent's internal product quality monitoring platform. It supports two mainstream platforms: iOS and Android. Its main function is to monitor and report crashes and stutters on the user side after the app is released, so that developers can understand the quality of the app for a short time and modify them in time. Currently, all products within Tencent are using them to monitor the crash of online products.

Tencent’s internal team has been polished for 4 years. Currently, all Tencent’s internal products are in use, basically covering the mobile devices and network environment in the Chinese market, and the reliability is guaranteed. Using Bugly, you have used the same quality as mobile QQ, QQ space, and mobile phone manager.