Make a site with multiple pages offline

Asked

Viewed 1,256 times

6

Assuming I have a site with multiple pages - for example a blog - I want to put an option for those who visit it to have access to it without internet.

Since not every device has constant internet access, and not everywhere there is this possibility, it would allow the user to read a text while in one of these situations.

However, based on this there are some implications:

  • There is a solution that requires less of the user? Instructing him to open the browser menu and save the page - option not available in some mobile browsers - would not be a good idea.
  • It is possible to make this an option for the user? I don’t want my site to make someone else’s internet usage franchise pop up as soon as I open it by loading all the articles from the site;
  • It is possible that the user select what he wants to save? For example, an article, or even a set of articles, which he was interested in reading;
  • Images and videos in the posts can be saved?
  • 1

    in theory it depends on the client’s browser... but setting the page headers to full cache with these headers.. remembering that you have to remove any dynamical content from the page, such as analitics and others..

  • Look at my comments for @Abriel-gartz’s reply.

2 answers

3


In HTML5 there is the api Application Cache, which is exactly to manipulate the cache to have an application that works in offline mode. Read, which can be installed in the user’s browser.

This is an API that allows you to add a manifest file that will control the cache of your application. But it is too extensive to explain in detail here how it works and how to use.

Besides the official specification i’ll leave some recommendation links for study:

You can create an IFRAME with the manifest, thus installing your application by placing on a button, you can also add the manifest only after the person performs an action on the page, like clicking on an installation button, adding the manifest and saving it in a cookie so that when reloaded it is added the manifest automatically when already installed.

As for the selective cache of files, what you should do is a dynamic manifest, so that certain options that your user choose you will modify the manifest so that it caches the desired files. However this will cause you to reload all files from the manifest, so use carefully.

There are other more excuses to manipulate the application cahce system, but if you intend to use install and remove videos I recommend using IFRAME with unique manifest (in the case of Firefox each will request authorization for installation the first time, which is described in the specification but other browsers do not yet respect).

  • It does not meet points 2, 3 and part of 4: it is not a choice of the user, it downloads everything in the manifest and does not download videos (at least not in what I have seen). I was interested in the @Brenozan response because it seems that with the help of server code, these points can be met.

  • Ah, I remembered another problem with Application Cache: it was created for one-page sites, not sites with many pages: a blog can have hundreds. Imagine the size of manifest.appcache!

  • It can also be used on multiple pages, just all of them have reference to the same manifest and in the manifest include the URL of all the pages you want to cache, otherwise you can cache the entry page and use the cache header-control so that subsequent pages remain accessible offline, use some tool that scans your directories to generate the manifest automatically. Yes if you want to cache a large application, it will store a lot of information in the client and will hinder your control between online/offline. There is no magic solution.

  • 1

    Have you seen those questions the author himself answers? That was going to be one of them, but you’re almost getting to my answer. Actually I was looking for someone who had done it in a more organized way, but apparently nobody did. Put only the main page and a FALLBACK in the manifesto and save the texts and images in the IndexedDB: you suggested to me the same trick I’m already using.

  • Well, I tried to answer your question in the best possible way I know and I still went after some sources so you could read about it, in your question did not explain that you wanted an alternative to HTML5 Application Cache, I even gave suggestions on how to solve specific problems that you presented, which are not foreseen by the Application Cache, in fact it was not made for dynamic websites and applications, hence its name, but I did my best to clarify the question.

  • I’m not really looking for an alternative, but someone who had a better application of it instead of yadda yadda "put the pages in the manifest and tag the <html>". I propose an edition of yours or create a response from scratch?

Show 1 more comment

2

Use the Application Cache, introduced in HTML5, would be the first idea to be thought out.
On a site with one or two pages this works well and without harming the user experience: there are few files to download, there are not many choices to be made and no reasons to worry about bandwidth spending.

But sites with multiple pages using it generates some problems: high traffic, many pages in the manifest, among others. But we can take advantage that they are usually generated by some program or script using some database data: instead of storing with the generated HTML we use and store the data.

HTML5 has introduced several forms of data storage: basically every browser that supports Application Cache will also support at least Websql or Indexeddb (source). With this we can store the data of the site - be it text, images or video - when the user asks and works with them independent of an internet connection.

Using the option FALLBACK Application Cache all pages that are not in the manifest will be redirected to what you specify. So, only redirect all pages to one where they will be processed by an MVC library: few files in the manifest are enough.

In case you are reading this in the future we already see that the Application Cache is being surpassed by other technologies, at the moment the Serviceworkers: instead of you setting up a page, with a script on it that will generate the rest, you use a Sharedworker to do so. This seems simple, but there are big changes: being controlled by Javascript, without the need to use <iframe>s; the option to disable it if you want; the ability to use the connection when it is available and when not using another data source.

  • +1 did not know the Serviceworker. Very interesting.

  • When I wrote this answer I said that one surpasses the other, actually only in this use since the Application Cache works well for what was done, just not for large applications. At least in the future we won’t need those tricks.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.