The main pitfalls when using cache in HTML5 applications
Application cache, also known as AppCache, is today one of the hottest topics for web developers. AppCache allows your site visitors to download the site when they are offline. You can even save parts of your site, such as images, style sheets or web fonts in the cache on the user's computer. This can help load your site faster, thereby reducing the load on your server.
To use AppCache, a description file is created with the extension “appcache”, for example, manifest.appcache. In this file you can list all the files that should be cached. To enable this feature on your website, you need to include a link to this description file on your webpage in the html element as follows:
Here is an example description file:
')
In addition to the benefits, AppCache has several basic pitfalls that should be avoided in order to prevent the destruction of user experience and the disruption of your application.
If you include the description file itself in the application cache description, it will loop, and it will be almost impossible to tell the site that there is a new cache file, and that it needs to load and use the new description file instead of the old one. Therefore, always be careful not to make the following mistake:
This is a very common mistake when working with AppCache for the first time. NETWORK can come to the rescue in the description file. The NETWORK section of the description file indicates the resources for which the web application needs access to the network.
The addresses listed under the NETWORK flag usually fall into the “white list”, that is, the files listed here are always downloaded from the server if there is an Internet connection. For example, the following code snippet ensures that resource load requests contained in the subtree / api / are always downloaded from the network, not from the cache.
The description file must always be submitted according to the correct type of the text / cache-manifest environment. If the environment type is not set, then AppCache will not work.
It always needs to be configured in your working server’s .htaccess. This item is mentioned in most tutorials that teach how to use AppCache, but is often overlooked by many developers when they transfer web applications from the development server to the production server.
Enter the following into your Apache .htaccess file:
If you upload your app to Google App Engine, you can complete the same task by adding the following part of the code to your app.yaml file:
Avoid violation of the entire description as a result of the wrong location of the file.
If one of the files specified in the description file is not found or cannot be loaded, then the entire description file is lost. This is the oddity of AppCache behavior and should be remembered.
For example:
If you delete logo.gif, AppCache will not be able to find the deleted image file, and as a result, nothing from the description file will be executed.
Immediately after the description file is saved by the browser, the files will be downloaded from the cache description file, even if the user is connected to the Internet. This feature helps to increase the speed of loading your site and helps reduce the load on the server.
As you already know from the previous paragraph, the data is loaded from AppCache, even if the user is online, and the changes you made to the files on your website or server will not take effect until you update the description file.
You should always update the description file after updating the site, otherwise your user will never see the changes, and will only see previously cached data. You can change the version number or data in the comments to your description file to force the user's browser to download the new version of the description file. For example, if the previous description file you used before making changes to the site looked like this:
It can be changed as in the next block of code so that the user's browser can download a new copy of the description file.
Notice that the line that begins with # is a comment line and is not executed.
Although the description file may contain links to resources that need to be cached from other domains, it should always be sent to the browser from the same source as the host page. Otherwise, the description file will not load. For example, this is the correct description file:
Here we have specified the content that will be stored in the user's browser cache, the link to which is provided from another domain, which is good.
Another important thing to remember is that the linked URLs that you specify in the description file are associated with the description file, and not with the document in which you link to the description file. If you make a mistake that the description and the link will not be located along the same path, the resources will not be loaded, and in turn, the description file will not be loaded.
If the structure of your application looks like this:
Then your description file should look like this:
You can programmatically check whether your application uses an updated version of the cache description by testing window.applicationCache.status. Here is a sample code:
By running the above code on the site, you can find out when an update will be available to describe AppCache. Please note that UPDATEREADY is a defined state. You can even use the swapCache () method in the onUpdateReady () function to replace the old description file with a new one:
AppCache is a useful technology, but, as we see, you need to be careful when using it in your projects. Developers should carefully select what should be included in the description file. Ideally, the description file should include static content, such as style sheets, scripts, fonts, and images. In this case, decide what to include in your description file, you can only. Appcache is a double-edged sword, so use it carefully!
To use AppCache, a description file is created with the extension “appcache”, for example, manifest.appcache. In this file you can list all the files that should be cached. To enable this feature on your website, you need to include a link to this description file on your webpage in the html element as follows:
<html lang="en" manifest="manifest.appcache"> Here is an example description file:
')
CACHE MANIFEST # 23-01-2015 v0.1 /style.css /logo.gif /script.js NETWORK: * FALLBACK: /server/ /fallback.html In addition to the benefits, AppCache has several basic pitfalls that should be avoided in order to prevent the destruction of user experience and the disruption of your application.
Never include a description file in the description file list.
If you include the description file itself in the application cache description, it will loop, and it will be almost impossible to tell the site that there is a new cache file, and that it needs to load and use the new description file instead of the old one. Therefore, always be careful not to make the following mistake:
CACHE MANIFEST # 23-01-2015 v0.1 manifest.appcache page2.css Do not load uncached resources on a cached page.
This is a very common mistake when working with AppCache for the first time. NETWORK can come to the rescue in the description file. The NETWORK section of the description file indicates the resources for which the web application needs access to the network.
The addresses listed under the NETWORK flag usually fall into the “white list”, that is, the files listed here are always downloaded from the server if there is an Internet connection. For example, the following code snippet ensures that resource load requests contained in the subtree / api / are always downloaded from the network, not from the cache.
NETWORK: /api Always set the description of the application type in your server’s .htaccess
The description file must always be submitted according to the correct type of the text / cache-manifest environment. If the environment type is not set, then AppCache will not work.
It always needs to be configured in your working server’s .htaccess. This item is mentioned in most tutorials that teach how to use AppCache, but is often overlooked by many developers when they transfer web applications from the development server to the production server.
Enter the following into your Apache .htaccess file:
AddType text/cache-manifest .appcache If you upload your app to Google App Engine, you can complete the same task by adding the following part of the code to your app.yaml file:
- url: /public_html/(.*\.appcache) static_files: public_html/\1 mime_type: text/cache-manifest upload: public_html/(.*\.appcache) Avoid violation of the entire description as a result of the wrong location of the file.
If one of the files specified in the description file is not found or cannot be loaded, then the entire description file is lost. This is the oddity of AppCache behavior and should be remembered.
For example:
CACHE MANIFEST # 23-01-2015 v0.1 /style.css /logo.gif /script.js If you delete logo.gif, AppCache will not be able to find the deleted image file, and as a result, nothing from the description file will be executed.
Do not forget that data is loaded from AppCache even when connected
Immediately after the description file is saved by the browser, the files will be downloaded from the cache description file, even if the user is connected to the Internet. This feature helps to increase the speed of loading your site and helps reduce the load on the server.
Changes on the server will not take effect until the description file is updated.
As you already know from the previous paragraph, the data is loaded from AppCache, even if the user is online, and the changes you made to the files on your website or server will not take effect until you update the description file.
You should always update the description file after updating the site, otherwise your user will never see the changes, and will only see previously cached data. You can change the version number or data in the comments to your description file to force the user's browser to download the new version of the description file. For example, if the previous description file you used before making changes to the site looked like this:
CACHE MANIFEST # 23-01-2015 v0.1 It can be changed as in the next block of code so that the user's browser can download a new copy of the description file.
CACHE MANIFEST # 23-01-2015 v0.2 Notice that the line that begins with # is a comment line and is not executed.
The description file must be from the same source as the host.
Although the description file may contain links to resources that need to be cached from other domains, it should always be sent to the browser from the same source as the host page. Otherwise, the description file will not load. For example, this is the correct description file:
CACHE MANIFEST # 23-01-2015 v0.2 https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.3/jquery.js Here we have specified the content that will be stored in the user's browser cache, the link to which is provided from another domain, which is good.
Linked URLs are linked to the description URL
Another important thing to remember is that the linked URLs that you specify in the description file are associated with the description file, and not with the document in which you link to the description file. If you make a mistake that the description and the link will not be located along the same path, the resources will not be loaded, and in turn, the description file will not be loaded.
If the structure of your application looks like this:
css/style.css js/main.js img.jpg index.html manifest.appcache Then your description file should look like this:
CACHE MANIFEST # 23-01-2015 v0.2 css/style.css js/main.js img.jpg Check the description status programmatically.
You can programmatically check whether your application uses an updated version of the cache description by testing window.applicationCache.status. Here is a sample code:
function onUpdateReady() { alert('found new version!'); } window.applicationCache.addEventListener('updateready', onUpdateReady); if (window.applicationCache.status === window.applicationCache.UPDATEREADY) { onUpdateReady(); } By running the above code on the site, you can find out when an update will be available to describe AppCache. Please note that UPDATEREADY is a defined state. You can even use the swapCache () method in the onUpdateReady () function to replace the old description file with a new one:
window.applicationCache.swapCache(); Conclusion
AppCache is a useful technology, but, as we see, you need to be careful when using it in your projects. Developers should carefully select what should be included in the description file. Ideally, the description file should include static content, such as style sheets, scripts, fonts, and images. In this case, decide what to include in your description file, you can only. Appcache is a double-edged sword, so use it carefully!
Useful Paysto solutions for Habr readers:
→ Get paid by credit card right now. Without a site, PI and LLC.
→ Accept payments from companies via the Internet. Without a site, PI and LLC.
→ Acceptance of payments from companies for your site. With document circulation and exchange of originals.
→ Automation of sales and service transactions with legal entities. Without intermediary in the calculations.
→ Accept payments from companies via the Internet. Without a site, PI and LLC.
→ Acceptance of payments from companies for your site. With document circulation and exchange of originals.
→ Automation of sales and service transactions with legal entities. Without intermediary in the calculations.
Source: https://habr.com/ru/post/254619/
All Articles