I have a multi-page website. I want to make two of those pages available offline, using the HTML5 manifest. However, I want the online counterparts to be used instead of the local cached version when possible. Currently, the cached versions are being loaded even when the network is available.
Add this to the header:
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
If you want certain pages to always load from the server when on-line, the implication is that they are in some way more up-to-date?
If that's the case, you need to ensure that your site's off-line cache recognises that these elements have changed, and thus update them instead. I guess the only way is to force this refresh by ensuring that when the relevant elements are updated on the server, so is your off-line cache manifest file.
(You can of course use the NETWORK directive in your cache manifest to compel the user agent to always go to the server for certain resources but then as you imply, you won't have these pages available when off-line).
So you don't have to necessarily invalidate the cache file, but you do need to ensure that it triggers an update and cache-swap.
The solution I found was to ensure that the pages I cache in the manifest do not contain any dynamically generated content. When online, my JavaScript code performs an Ajax request to fetch the dynamically generated content. The JavaScript detects when the browser is offline and will refuse to perform the Ajax requests, essentially shifting into offline-only mode.
Related
We are using a "manifest.appcache" file to control the application cache on our site. A part of the application should be accessible offline, which means that some of the pages have the reference on the manifest in the html-tag, others don't.
Is there any way to check if the cache is empty (from all pages)?
Example
Page A is available online only, so no manifest is referenced. Page B is available online and offline, so the manifest is referenced. Now we want to check on page A (online only) if page B is already cached (the cache is not empty).
There is no way to check if the cache is empty or if there is an page in the cache (with application cache).
If you really need to do it, there are two solutions you can use:
You can use cookies to track the sites that are loaded in the cache. This opens new problems: What if the user clears the cookies and not the application cache?
The more cleaner solution is to use IndexedDB or the HTML5 FileSystem to save the content and just cache wrappers for that content. You can cache the wrappers to the beginning and then you can handle the content with the APIs i mentioned (i used this one). This way you can simply check whether a page is in the cache or not.
Sorry for answering my own question, but i hope this saves some time.
I listed static resources (CSS and javascript files) referenced by the HTML in the explicit cache section of the cache manifest, as a modern mobile web app usually does. But it is surprising to find in chrome that these static resources are downloaded twice for the first time accessing the web app when there is not any local cache yet, since the cache is used to minimize bandwidth. I think the reasons that they are downloaded twice is that they are referenced in the cache manifest and in the HTML.
Why doesn't the browser share the resource if it is referenced in both places? Is it conforming to the HTML5 standard or a bug in chrome?
I have seen this behavior consistently across nearly every browser (Chrome, IE, and Firefox) when using a cache manifest. As far as I can tell, the resources are indeed downloaded twice because they are referred to in both the cache manifest and the html/css. The initial load is for loading the page itself, and the second load is for loading the appcache.
Now, even if a second request needs to be performed to load the appcache, the resource should be served from the regular browser cache since the original request probably loaded it into the browser cache. However, all browsers seem to treat appcache loads differently than regular browsing activity and bypass the cache.
As far as HTML5 specs go, the spec suggests that browsers can implement a mechanism to use the existing download, but it is optional:
Fetch the resource, from the origin of the URL manifest URL, with the synchronous flag set and the manual redirect flag set. If this is an upgrade attempt, then use the newest application cache in cache group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and so forth) with respect to that cache. User agents may also have other caches in place that are also honored.
If the resource in question is already being downloaded for other reasons then the existing download process can sometimes be used for the purposes of this step, as defined by the fetching algorithm.
An example of a resource that might already be being downloaded is a large image on a Web page that is being seen for the first time. The image would get downloaded to satisfy the img element on the page, as well as being listed in the cache manifest. According to the rules for fetching that image only need be downloaded once, and it can be used both for the cache and for the rendered Web page.
source
I don't understand the point of the HTML5 AppCache. We already have a normal cache. If you visit a website the first time it'll already cache all the assets. What extra value does the AppCache provide? Is it just a list of files so that the browser knows what assets to download, even if they're not referenced by the HTML right now? Does the browser make sure that the caching is "all-or-nothing", i.e. does it ensure that everything referenced by the manifest is cached, or nothing at all?
I think the point you're missing is that AppCache is specifically designed to allow web apps (and web sites) to be made available offline, though the same speed benefits which the normal browser cache provides, when the user is online, are also provided by AppCache.
The key difference with the browser cache is that you can specify all the assets the browser should cache in a manifest file (conceivably your entire site) whereas the browser cache will only store the pages (and associated assets) you have actually visited.
I'm no expert on the AppCache, but I do know it is not without its problems. There's a really good article here from a chap who used AppCache to allow parts of his mobile site to be available offline. It includes some rationale on their decision to use it and a number of gotchas they encountered in doing so.
This HTML5 Rocks article on the subject also has some good information.
AppCache actually uses the browser cache in support of its operation. It is the browser equivalent of downloading an app to run locally.
The first time a user visits the page, the resources of that page will be loaded from the server and stored in the normal cache. If the page specifies an appcache manifest, the browser will download the manifest and fetch all the resources in there (even if they do not appear on the page that embedded the manifest). These are then stored in appcache.
The second time a user visits the page, the browser will check its appcache. If an entry exists for that URL, it will load the page from appcache instead of from the server, based on the rules specified in the manifest (the manifest can mark some resources explicitly as fetched from the network).
After the browser loads the page from appcache, it will contact the server to see if there is an updated manifest. If the manifest is updated, it will fetch the resources from the manifest. These fetches are done using normal browser cache rules, so some of these resources may actually end up being fetched from the regular browser cache instead of from the server (this allows you to do differential updates when using appcache to develop offline apps). The new version of the appcache is kept separate from the old version. After the new version is fetched the user keeps interacting with the resources from the old version until they refresh the main page, after which the new version is loaded and the old is discarded.
Another important point is that appcache has different rules for when resources are discarded. Appcache basically never discards the latest set of resources, and caches them as a whole. To prevent abuse it enforces storage limits (sometimes as little as 5 MB) of how big a site's cache can be. By contrast, the browser cache has no per-site limits, but will discard individual resources from a site if the global cache limits are reached.
The important feature of HTML 5 application cache is it makes available the web application offline. Which is not given by normal browser cache.
In addition to this application cache will provide
Speed - since the entire contents of the specified page will be cached to browser so it will provide a better speed than browser cache
Reduce Server Load - There is no need of a post back all the time, since all the contents are there in cache, till there is any changes in the Manifest file
Cache manifest :- The cache manifest file is the heart of HTML5 application cache. We can specify what are the pages need not be cached, what should not, and even we can reuse this one as a error handling technique, for that we can specify a custom error page in the FALLBACK section to show if the user request a content that requires network connectivity
For a basic understanding on Application cache you can See this tutorial
I am a little slow to the HTML5 caching, I have just some simple questions though.
1) How long is data in a caching manifest cached?
2) If I update the data, how can I make sure the client checks for a newer version when it is available, or is this already done?
3) Also, is this completely useless for a non-0mobile environment or can it speed up load times on a desktop?
<html lang="en" manifest="offline.manifest">
offline.manifest
CACHE MANIFEST
index.html
style.css
image.jpg
image-med.jpg
image-small.jpg
notre-dame.jpg
1) As long as the user cares to cache it. The only way to completely get rid of the cache is to go into the browser settings and explicitly remove it.
2) If you update the manifest file, the client will download new versions of all the files. This download is still governed by 'old' HTTP caching rules, so set headers appropriately, also make sure you send a 'no-cache' header on the manifest file itself. The rules from HTML5 Boilerplate are probably a good place to start.
3) Remember desktops can lose connectivity too. Also, having files in application cache means they are always served locally so, providing you're sensible about what you put in it, the application cache can reduce bandwidth and latency. What I mean by sensible is: if most visitors only see a couple of pages of your site and you update the manifest of your entire site every week, then they could end up using more bandwidth if you're forcing them to cache a load of static files for pages they never look at.
To really cut down on bandwidth and latency in your HTML5 website of the future: use the application cache for all your assets and a static framework; use something like mustache to render all your content from JSON; send that JSON over Web Sockets instead of HTTP, saving you ~800 bytes and a two way network handshake per request; cache data with Local Storage to save you fetching it again, and manage navigation with the History API.
1) How long is data in a caching manifest cached?
Once an application is cached, it remains cached until one of the following happens:
The user clears the browser's cache
The manifest file is modified
The application cache is programatically updated
2) If I update the data, how can I make sure the client checks for a newer version when it is available, or is this already done?
you can specify witch files not to cache (NETWORK:)
If you want to update your cached files, you should modify something in the manifest file, the best way is to put comment in the file and change it when you want the browser to update the cache
3) Also, is this completely useless for a non-mobile environment or can it speed up load times on a desktop?
Yes it is useful, cause the internet can cut on all devices
I have a few questions regarding HTML5 offline storage, which I could not figure out.
Where exactly these files are stored in the Windows? I could not find here:
C:\Documents and Settings[User Name]\Application Data\Mozilla\Firefox\Profiles\
Is there any expiration time, after that browser deletes these files automatically? Or do the files remain forever?
What if I change the contents of the page, is there anyway to refresh the refresh the data which is stored offline?
Thanks.
I found them in %AppData%/Profiles/<currentprofilename>.default/OfflineCache. I'm using Windows 7.
This depends on the expires headers your web server sends for the files in question. It is recommended you set the expires header to one week, but it is up to you, you can make it never expire. Note that the manifest file itself should be set to never be cached.
In order to refresh the data you must actually change the manifest file. It is recommended that somewhere in the manifest file you put a comment with the version number, then update it every time you change any of your other files.
Edit: I had answered these questions thinking you meant offline application cache, not local storage.
Well, for the sake of accuracy, it should be mentioned that although localStorage was indeed part of the HTML5 specification, it was split into its own after getting slightly over-complicated to be include alongside with the rest of HTML5.
It really depends on your browser, but it should be found on your AppData folder, in /profiles//OfflineCache. (for Windoes 7).
There is generally NO expiration date for localStorage, it can remain forever unless specifically removed by the website.
Javascript changes the localStorage data, (assuming you don't touch the actual file), in which case, the website you are using (or writing) needs to be smart enough to refresh the localStorage along with the page's content.