Progressive web app structure

Now we know the theory behind PWAs, let's look at the recommended structure of an actual app. We will start with analyzing the js13kPWA application, why it is built that way, and what benefits it brings.


渲染网站主要有两种方法 - 在服务器上或在客户端上。它们都有其优点和缺点,你可以适当地混合使用这两种方法

  • Server-side rendering (SSR) means a website is rendered on the server, so it offers quicker first load, but navigating between pages requires downloading everything every single time. It works great across browsers and has lots of tools available to help with the development process, but it suffers in terms of loading speed and therefore general perceived performance — loading every single page requires a new round trip to the server.
  • Client-side rendering (CSR) allows the website to be updated in the browser almost instantly when navigating to different pages, but requires more of an initial download hit and extra rendering on the client at the beginning. The website is slower on an initial visit, but much faster on subsequent visits.

Mixing SSR with CSR can lead to the best results — you can render a website on the server, cache its contents, and then update the rendering on the client-side as and when needed. The first page load is quick because of the SSR, and the navigation between pages is smooth because the client can re-render the page with only the parts that have changed.

PWA可以使用您喜欢的任何方法构建,但有些方法会更适合。最流行的方法是“app shell”概念,它完全按照上述方式混合SSR和CSR,此外还遵循“离线优先”方法,我们将在后续文章中详细解释并在我们的示例应用程序中使用。还有一种涉及Streams API的新方法,我们将简要提及。

App shell

App shell意图尽快加载最小的用户界面,然后缓存它,以便在后续访问时可以离线使用,然后加载应用程序的所有内容。这样,下次有人从设备访问应用程序时,UI立即从缓存加载,并从服务器请求新内容(如果它已在缓存中不可用)。


我们可以通过service worker控制从服务器请求的内容以及从缓存中检索的内容,这将在下一篇文章中详细解释 - 现在让我们关注结构本身。


This architecture allows a website to benefit the most from all the PWA features — it caches the app shell and manages the dynamic content in a way that greatly improves the performance. In addition to the basic shell, you can add other features such as add to home screen or push notifications, safe in the knowledge that the app will still work OK if they are not supported by the user's browser — this is the beauty of progressive enhancement.

The website feels like a native app with instant interaction and solid performance while keeping all the benefits of the web.

Being linkable, progressive and responsive by design

It's important to remember the PWA advantages and keep them in mind when designing the application. The app shell approach allows websites to be:

  • Linkable: Even though it behaves like a native app, it is still a website — you can click on the links within the page and send a URL to someone if you want to share it.
  • Progressive: Start with the "good, old basic website” and progressively add new features while remembering to detect if they are available in the browser and gracefully handle any errors that crop up if support is not available. For example, an offline mode with the help of service workers is just an extra trait that makes the website experience better, but it's still perfectly usable without it.
  • Responsive: Responsive web design also applies to progressive web apps, as both are mainly for mobile devices. There are so many varied devices with browsers — it's important to prepare your website so it works on different screen sizes, viewports or pixel densities, using technologies like viewport meta tag, CSS media queries, Flexbox, and CSS Grid.

Different concept: streams

An entirely different approach to server- or client-side Rendering can be achieved with the Streams API. With a little help from service workers, streams can greatly improve the way we parse content.

The app shell model requires all the resources to be available before the website can start rendering. It's different with HTML, as the browser is actually streaming the data already and you can see when the elements are loaded and rendered on the website. To have the JavaScript "operational", however, it has to be downloaded in its entirety.

The Streams API allows developers to have direct access to data streaming from the server — if you want to perform an operation on the data (for example, adding a filter to a video), you no longer need to wait for all of it to be downloaded and converted to a blob (or whatever) — you can start right away. It provides fine-grained control — the stream can be started, chained with another stream, cancelled, checked for errors, and more.

In theory, streaming is a better model, but it's also more complex, and at the time of writing (March 2018) the Streams API is still a work-in-progress and not yet fully available in any of the major browsers. When it is available, it will be the fastest way of serving the content — the benefits are going to be huge in terms of performance.

For working examples and more information, see the Streams API documentation.

Structure of our example application

The js13kPWA website structure is quite simple: it consists of a single HTML file (index.html) with basic CSS styling (style.css), and a few images, scripts, and fonts. The folder structure looks like this:

Folder structure of js13kPWA.


From the HTML point of view, the app shell is everything outside the content section:

<!DOCTYPE html>
<html lang="en">
	<meta charset="utf-8">
	<title>js13kGames A-Frame entries</title>
	<meta name="description" content="A list of A-Frame entries submitted to the js13kGames 2017 competition, used as an example for the MDN articles about Progressive Web Apps.">
	<meta name="author" content="end3r">
	<meta name="theme-color" content="#B12A34">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<meta property="og:image" content="icons/icon-512.png">
	<link rel="shortcut icon" href="favicon.ico">
	<link rel="stylesheet" href="style.css">
	<link rel="manifest" href="js13kpwa.webmanifest">
	<script src="data/games.js" defer></script>
	<script src="app.js" defer></script>
	<p><a class="logo" href=""><img src="img/js13kgames.png" alt="js13kGames"></a></p>
	<h1>js13kGames A-Frame entries</h1>
	<p class="description">List of games submitted to the <a href="">A-Frame category</a> in the <a href="">js13kGames 2017</a> competition. You can <a href="">fork js13kPWA on GitHub</a> to check its source code.</p>
	<button id="notifications">Request dummy notifications</button>
	<section id="content">
		// Content inserted in here
	<p>© js13kGames 2012-2018, created and maintained by <a href="">Andrzej Mazur</a> from <a href="">Enclave Games</a>.</p>

The <head> section contains some basic info like title, description and links to CSS, web manifest, games content JS file, and app.js — that's where our JavaScript application is initialized. The <body> is split into the <header> (containing linked image), <main> page (with title, description and place for a content), and <footer> (copy and links).

The app's only job is to list all the A-Frame entries from the js13kGames 2017 competition. As you can see it is a very ordinary, one page website — the point is to have something simple so we can focus on the implementation of the actual PWA features.


The CSS is also as plain as possible: it uses @font-face to load and use a custom font, and it applies some simple styling of the HTML elements. The overall approach is to have the design look good on both mobile (with a responsive web design approach) and desktop devices.

The main app JavaScript

The app.js file does a few things we will look into closely in the next articles. First of all it generates the content based on this template:

var template = "<article>\n\
    <img src='data/img/SLUG.jpg' alt='NAME'>\n\
    <h3>#POS. NAME</h3>\n\
    <li><span>Author:</span> <strong>AUTHOR</strong></li>\n\
    <li><span>Twitter:</span> <a href=''>@TWITTER</a></li>\n\
    <li><span>Website:</span> <a href='http://WEBSITE/'>WEBSITE</a></li>\n\
    <li><span>GitHub:</span> <a href='https://GITHUB'>GITHUB</a></li>\n\
    <li><span>More:</span> <a href=''></a></li>\n\
var content = '';
for(var i=0; i<games.length; i++) {
    var entry = template.replace(/POS/g,(i+1))
    entry = entry.replace('<a href=\'http:///\'></a>','-');
    content += entry;
document.getElementById('content').innerHTML = content;

Next, it registers a service worker:

if('serviceWorker' in navigator) {

The next code block requests permission for notifications when a button is clicked:

var button = document.getElementById("notifications");
button.addEventListener('click', function(e) {
    Notification.requestPermission().then(function(result) {
        if(result === 'granted') {

The last block creates notifications that display a randomly-selected item from the games list:

function randomNotification() {
    var randomItem = Math.floor(Math.random()*games.length);
    var notifTitle = games[randomItem].name;
    var notifBody = 'Created by '+games[randomItem].author+'.';
    var notifImg = 'data/img/'+games[randomItem].slug+'.jpg';
    var options = {
        body: notifBody,
        icon: notifImg
    var notif = new Notification(notifTitle, options);
    setTimeout(randomNotification, 30000);

The service worker

The last file we will quickly look at is the service worker: sw.js — it first imports data from the games.js file:


Next, it creates a list of all the files to be cached, both from the app shell and the content:

var cacheName = 'js13kPWA-v1';
var appShellFiles = [
var gamesImages = [];
for(var i=0; i<games.length; i++) {
var contentToCache = appShellFiles.concat(gamesImages);

The next block installs the service worker, which then actually caches all the files contained in the above list:

self.addEventListener('install', function(e) {
  console.log('[Service Worker] Install');
  e.waitUntil( {
      console.log('[Service Worker] Caching all: app shell and content');
      return cache.addAll(contentToCache);

Last of all, the service worker fetches content from the cache if it is available there, providing offline functionality:

self.addEventListener('fetch', function(e) {
    caches.match(e.request).then(function(r) {
      console.log('[Service Worker] Fetching resource: '+e.request.url);
      return r || fetch(e.request).then(function(response) {
        return {
          console.log('[Service Worker] Caching new resource: '+e.request.url);
          cache.put(e.request, response.clone());
          return response;

The JavaScript data

The games data is present in the data folder in a form of a JavaScript object (games.js):

var games = [
        slug: 'lost-in-cyberspace',
        name: 'Lost in Cyberspace',
        author: 'Zosia and Bartek',
        twitter: 'bartaz',
        website: '',
        github: ''
        slug: 'vernissage',
        name: 'Vernissage',
        author: 'Platane',
        twitter: 'platane_',
        website: '',
        github: ''
// ...
        slug: 'emma-3d',
        name: 'Emma-3D',
        author: 'Prateek Roushan',
        twitter: '',
        website: '',
        github: ''

Every entry has its own image in the data/img folder. This is our content, loaded into the content section with JavaScript.

Next up

In the next article we will look in more detail at how the app shell and the content are cached for offline use with the help from the service worker.


此页面的贡献者: mdnwebdocs-bot, chrisdavidmills, eightHundreds
最后编辑者: mdnwebdocs-bot,