larlet-fr-david-cache/cache/6123a07505f79305c1a46f13131917af/index.md

title: Building an offline page for theguardian.com
url: https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom
hash_url: 6123a07505f79305c1a46f13131917af

<p>You’re on a train to work and you open up the Guardian app on your phone. A tunnel surrounds you, but the app still works in very much the same way as it usually would—despite your lack of internet connection, you still get the full experience, only the content shown will be stale. If you tried the same for a website, however, it wouldn’t load at all:<br/></p>
<figure itemprop="associatedMedia image" itemscope="" itemtype="http://schema.org/ImageObject" data-component="image" class="element element-image img--portrait  fig--narrow-caption fig--has-shares " data-media-id="6ba3b0c53e0ccb83176c865ef193161a3e1562e8" id="img-2">
<a href="#img-2" class="article__img-container js-gallerythumbs" data-link-name="Launch Article Lightbox" data-is-ajax="">
 <span class="inline-expand-image inline-icon centered-icon rounded-icon article__fullscreen modern-visible">
<svg viewbox="0 0 22 22">
<path d="M3.4 20.2L9 14.5 7.5 13l-5.7 5.6L1 14H0v7.5l.5.5H8v-1l-4.6-.8M18.7 1.9L13 7.6 14.4 9l5.7-5.7.5 4.7h1.2V.6l-.5-.5H14v1.2l4.7.6"/>
</svg> </span> </a>

<figcaption class="caption caption--img caption caption--img" itemprop="description">
Chrome for Android’s offline page Illustration: Oliver Ash
</figcaption>
</figure>
<p>Chrome eases the pain of being offline with its hidden game (press space bar on desktop, tap the dinosaur on mobile). But we can do better.</p>
<p><a href="https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md" data-link-name="in body link" data-component="in-body-link" class=" u-underline">Service workers</a> allow website authors to intercept all network requests to their websites, which means we can provide rich offline experiences, just like native apps. At the Guardian, we recently released a custom offline experience of our own. When users are offline they will see a Guardian branded page with a simple offline message and, for fun, a crossword to play while they wait for a connection. This blog post is about how we built it, but first, here’s how you can try it out for yourself.</p>
<h2>Try it out</h2>
<p>You must be running a browser that supports the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API" data-link-name="in body link" data-component="in-body-link" class=" u-underline">Service Worker</a> and <a href="https://developer.mozilla.org/en/docs/Web/API/Fetch_API" data-link-name="in body link" data-component="in-body-link" class=" u-underline">fetch</a> <a href="https://en.wikipedia.org/wiki/Application_programming_interface" data-link-name="in body link" data-component="in-body-link" class=" u-underline">API</a>s. At the time of writing only Chrome (mobile and desktop) supports both of APIs, but support is coming in Firefox very soon (currently in the nightly build), and <a href="https://jakearchibald.github.io/isserviceworkerready/" data-link-name="in body link" data-component="in-body-link" class=" u-underline">all browsers except Safari have shown enthusiasm</a>. Furthermore, service workers can only be registered for websites served over <a href="https://en.wikipedia.org/wiki/HTTPS" data-link-name="in body link" data-component="in-body-link" class=" u-underline">HTTPS</a>, which theguardian.com has started to move towards. Thus, we can only offer the offline experience for HTTPS sections of the website. For the time being, we have chosen the <a href="https://www.theguardian.com/info/developer-blog" data-link-name="in body link" data-component="in-body-link" class=" u-underline">developer blog</a> as our testing ground. So, if you’re reading this on <a href="https://www.theguardian.com/info/developer-blog" data-link-name="in body link" data-component="in-body-link" class=" u-underline">our developer blog</a> section of the website, you’re in luck.</p>
<p>Once you’ve visited a page on our <a href="https://www.theguardian.com/info/developer-blog" data-link-name="in body link" data-component="in-body-link" class=" u-underline">developer blog</a> in a supported browser, you’re all set. Disconnect your device from the internet and refresh. If you are unable to try it out for yourself, <a href="https://twitter.com/jaffathecake/status/657207009335508992" data-link-name="in body link" data-component="in-body-link" class=" u-underline">take a look at this demo video</a>.</p>
<h2>How it works</h2>
<p>We can instruct browsers to register our service worker as soon as the user arrives on the page with some simple JavaScript. Support for service workers is currently sparse, so we need to use feature detection to avoid any errors.<br/></p>
<figure class="element element-code">
<pre class="prettyprint"><code class="language-javascript">if (navigator.serviceWorker) {
    navigator.serviceWorker.register('/service-worker.js');
}</code></pre>
</figure>
<p>As part of the service worker’s install event, we can use the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Cache" data-link-name="in body link" data-component="in-body-link" class=" u-underline">new cache API</a> to cache the various moving parts of our website, such as <a href="https://en.wikipedia.org/wiki/HTML" data-link-name="in body link" data-component="in-body-link" class=" u-underline">HTML</a>, <a href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets" data-link-name="in body link" data-component="in-body-link" class=" u-underline">CSS</a>, and <a href="https://en.wikipedia.org/wiki/JavaScript" data-link-name="in body link" data-component="in-body-link" class=" u-underline">JavaScript</a>:</p>
<figure class="element element-code">
<pre class="prettyprint"><code class="language-javascript">var staticCacheName = 'static';
var version = 1;

function updateCache() {
    return caches.open(staticCacheName + version)
        .then(function (cache) {
            return cache.addAll([
                '/offline-page.html',
                '/assets/css/main.css',
                '/assets/js/main.js'
            ]);
        });
};

self.addEventListener('install', function (event) {
    event.waitUntil(updateCache());
});</code></pre>
</figure>
<p>Once install has completed, the service worker can listen to and control the fetch event, giving us full control over all future network requests incurred by the website.</p>
<figure class="element element-code">
<pre class="prettyprint"><code class="language-javascript">self.addEventListener('fetch', function (event) {
    event.respondWith(fetch(event.request));
});</code></pre>
</figure>
<p>To give you some idea of the flexibility we have here, we could construct our own response programmatically:</p>
<figure class="element element-code">
<pre class="prettyprint"><code class="language-javascript">self.addEventListener('fetch', function (event) {
    var response = new Response('&lt;h1&gt;Hello, World!&lt;/h1&gt;',
        { headers: { 'Content-Type': 'text/html' } });
    event.respondWith(response);
});</code></pre>
</figure>
<p>Or, we could respond with something from the cache if we can find a match for the given request, falling back to the network:</p>
<figure class="element element-code">
<pre class="prettyprint"><code class="language-javascript">self.addEventListener('fetch', function (event) {
    event.respondWith(
        caches.match(event.request)
            .then(function (response) {
                return response || fetch(event.request);
            })
    );
});</code></pre>
</figure>
<p>So how do we use all of this to provide an offline experience?</p>
<p>Firstly, the HTML and resources needed for the offline page are cached by the service worker upon installation. Included in this cache is the <a href="https://facebook.github.io/react/" data-link-name="in body link" data-component="in-body-link" class=" u-underline">React</a> <a href="https://github.com/guardian/frontend/tree/dca4d6fbfddd608bed0d628b63f5da763be09c79/static/src/javascripts/es6/projects/common/modules/crosswords" data-link-name="in body link" data-component="in-body-link" class=" u-underline">application</a> we have developed for <a href="http://www.theguardian.com/crosswords" data-link-name="in body link" data-component="in-body-link" class=" u-underline">our crossword pages</a>. Thereafter we intercept all network requests to a web page on theguardian.com, including requests for subresources on those pages. The logic for handling these requests goes something like:</p>
<ol>
<li>If we detect the incoming request is a navigation to one of our HTML pages, we always want to serve the most up-to-date content, so we attempt to make the request over the network to the server.</li>
<ol>
<li>When we get a response from the server, we can respond with that directly.</li>
<li>If the network request throws an error (i.e. failed because the user is offline), we catch this and instead respond with the cached HTML for the offline page.</li>
</ol>
<li>Else, if we detect the request is anything other than HTML, we will lookup the request in the cache.</li>
<ol>
<li>If a cached match is found, we can respond with that directly.</li>
<li>Else, we will attempt to make the request over the network to the server.</li>
</ol>
</ol>
<p>The resulting code, which uses the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Cache" data-link-name="in body link" data-component="in-body-link" class=" u-underline">new cache API</a> (as part of the Service Worker API) and <a href="https://developer.mozilla.org/en/docs/Web/API/Fetch_API" data-link-name="in body link" data-component="in-body-link" class=" u-underline">fetch</a> (for making network requests), is as follows:</p>
<figure class="element element-code">
<pre class="prettyprint"><code class="language-javascript">var doesRequestAcceptHtml = function (request) {
    return request.headers.get('Accept')
        .split(',')
        .some(function (type) { return type === 'text/html'; });
};

self.addEventListener('fetch', function (event) {
    var request = event.request;
    if (doesRequestAcceptHtml(request)) {
        // HTML pages fallback to offline page
        event.respondWith(
            fetch(request)
                .catch(function () {
                    return caches.match('/offline-page.html');
                })
        );
    } else {
        // Default fetch behaviour
        // Cache first for all other requests
        event.respondWith(
            caches.match(request)
                .then(function (response) {
                    return response || fetch(request);
                })
        );
    }
});</code></pre>
</figure>
<p>That’s it! All the code for <a href="https://github.com/guardian/frontend" data-link-name="in body link" data-component="in-body-link" class=" u-underline">theguardian.com is open source on GitHub</a>, so you can view the <a href="https://github.com/guardian/frontend/blob/43c73e57aa9a00dc3555baa51c5d975b0e6b2b66/applications/app/templates/serviceWorker.scala.js" data-link-name="in body link" data-component="in-body-link" class=" u-underline">full version of our service worker script there</a>, or in production at <a href="https://www.theguardian.com/service-worker.js" data-link-name="in body link" data-component="in-body-link" class=" u-underline">https://www.theguardian.com/service-worker.js</a>.</p>
<p>We have good reasons to be excited about these new browser technologies, because they can be used to give websites the same rich offline experiences we have in native apps today. In the future when theguardian.com has completed migration to HTTPS, the offline page will increase in significance and we can make further improvements to the offline experience. Imagine opening theguardian.com on your internet-less commute to work to find content personalised for you, downloaded and cached by the browser ahead of your visit. There is no friction involved in the installation step—unlike native apps which require users to have app store accounts for installation, all that’s needed on the web is to visit the website in question. Service workers can also help improve website load times, as the shell of a website can be cached reliably, just like in native apps.</p>
<p>If you’re interested in learning more about service workers and what’s possible, Matt Gaunt, who is a Developer Advocate for Chrome, has written an <a href="http://www.html5rocks.com/en/tutorials/service-worker/introduction/" data-link-name="in body link" data-component="in-body-link" class=" u-underline">introduction to Service Worker</a> which goes into more detail.</p>