Responsive, adaptive and progressive: building impressive websites

Over the last few years, web application technologies and frameworks have evolved at a fast pace. Each development seems to get a marketing term that, by coincidence, ends in …ive. So let's coin another one! In this article, I'll explain the basic concepts behind these approaches and how they can help you build an impressive web application.

Responsive Web Design

It all started around late 2010, if I remember correctly, with the idea of a web page that renders properly at different screen resolutions. This became known as Responsive Web Design (RWD). Elements resize to fit the screen and give the reader a good user experience, using fluid, proportion-based grids, flexible images and CSS3 media queries. If you're not focusing on RWD yet, you've missed the boat—but be brave, take a leap and jump aboard.

I'm serious: Google started to boost search rankings based on RWD compatibility in April 2015. Besides improving your UI and UX, it can help your SEO. At the time of this 2018 post, most internet users are on mobile devices, so I wouldn't take this lightly.

Try resizing your browser and see how my website renders and behaves differently as the window changes.

Getting nervous? Don't worry. Later on, I'll give you some starting points and frameworks to try, along with ways to combine these technologies.

Adaptive Web Design

You've probably also heard of Adaptive Web Design (AWD). Articles often describe it as similar to RWD, and the two terms are frequently mixed up. AWD was first coined in early 2011. The main difference is that AWD uses different templates: one optimized for mobile devices and another for desktop browsers. This lets you load different assets (JavaScript, CSS and images) and use a simpler DOM structure on mobile to improve loading speed. Although AWD can still be useful in some scenarios, I think it's slowly becoming obsolete because of the developments I'll explain next.

Progressive Web Apps

If you're working on web applications and following development news, you've probably heard of Progressive Web Apps (PWAs). As of this 2018 post, Google Chrome has fully supported them since April. PWAs enhance existing web technology, so they don't require separate bundling or distribution. You publish a PWA just as you would any other web page. That means you can start applying these enhancements without too much impact on compatibility with older browsers that don't support PWAs yet.

So what makes a PWA a PWA?

• Progressive: Works for every user, regardless of browser choice.
• Responsive: Fits any screen and resolution (desktop, tablet, mobile, …).
• Connectivity-independent: Service workers allow offline use and help on low-quality networks.
• App-like: Feels like an app, with app-style interactions and navigation.
• Fresh: Stays up to date thanks to service worker processes.
• Safe: Served over HTTPS to ensure the content hasn't been tampered with. HTTPS is a technical requirement for service workers.
• Discoverable: Identifiable as an application through W3C manifests and service worker registration scope, allowing search engines to find it.
• Re-engageable: Makes re-engagement easy through features such as push notifications.
• Installable: Lets users keep useful apps on their home screen without the hassle of an app store.
• Linkable: Easily shared through a URL, with no complex installation required.

How I made my own website impressive

Now you're probably thinking, “How do I get an impressive website?” I've used responsive web design for almost five years. I started with a WordPress backend, then migrated to the static site engine Hexo.js, which had a port of my WordPress theme available. Although my site was responsive, performance wasn't great: it ran on a cheap server with a cheap database and received a lot of traffic. If you've used WordPress, you probably know that caching can involve quite a few plugins and settings. Let me introduce you to static site generators.

Static site generators

A static site generator creates HTML pages that you upload to a web server. When someone visits a page, there's no server-side computation or database query needed. That can mean fast performance and lower hosting costs, even with high traffic. Another nice benefit is that most static site generators let you write content in Markdown. It's easy to learn and lets you produce formatted content quickly, without writing HTML or relying on a WYSIWYG editor that might mess with your markup.

So how do you manage versions of your website and blog?

That is a question I get very often, and the answer is very simple. Git!

Here are a few popular static site generators that come to mind:

• Hexo.js: A Node.js-based engine with many plugins available, including tools for creating a PWA.
• Gatsby: A blazing-fast static site generator for React.
• Jekyll: A Ruby-powered static site engine. GitHub Pages uses Jekyll, so you can deploy your site through GitHub for free—with a custom domain name and all.
• Hugo: Built around Google’s Go programming language, it’s blazing fast.

I'm happy to update this list based on your comments. I'm looking forward to your contributions and findings.

How to find areas for improvement

First, there's Google PageSpeed, which gives you insights into page loading speed and areas for improvement. With the Chrome extension described here, you can run it through the developer tools.

1. Open Chrome Developer Tools by selecting the Chrome menu at the top-right of the browser window, then selecting Tools -> Developer tools.
2. In the Chrome Developer Tools pane, click the PageSpeed tab to switch to the PageSpeed Insights panel.
3. Navigate to a web page in Chrome and click the red ANALYZE button to run PageSpeed Insights.

There's also Google Lighthouse, another plugin that checks your website against PWA standards.

As you can see, my website still has room for performance improvements. Most issues can be resolved in the theme or are related to its third-party plugins. Try running both tools on my site, then on your own to see where you can improve. There will probably be some quick wins, while other issues may take more time. In the next sections, I'll explain a few of the topics these tools highlight.

Caching policies

By returning HTTP cache headers from your web server, you can define where and for how long your content may be cached. You can control whether the browser or a private cache server is allowed to cache it, and for how long. This reduces requests to your web server, letting it handle more traffic. It also improves the user experience: readers don't have to download the same image, JavaScript or CSS file again, so pages respond faster.

You can define caching policies for static assets in your web server configuration.

location ~* \.(?:manifest|appcache|html?|xml|json)$ {
  expires -1;
  # access_log logs/static.log; # I don't usually include a static log
}
 
# Feed
location ~* \.(?:rss|atom)$ {
  expires 1h;
  add_header Cache-Control "public";
}
 
# Media: images, icons, video, audio, HTC
location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
  expires 1M;
  access_log off;
  add_header Cache-Control "public";
}
 
# CSS and Javascript
location ~* \.(?:css|js)$ {
  expires 1y;
  access_log off;
  add_header Cache-Control "public";
}

Application manifests

The manifest.json file belongs in the root of your website. It contains information browsers use when you pin your web application to the home screen, for example. Below is a small example of a manifest.json file. In Hexo, I used the hexo-pwa plugin to generate it from values in my Hexo configuration.

{
  "name": "Marco Franssen blog",
  "short_name": "Marco F blog",
  "description": "Blog by Marco Franssen, covering software development!",
  "theme_color": "#006bde",
  "background_color": "#ffffff",
  "display": "standalone",
  "icons": [{
    "src": "images/icons/icon-72x72.png",
    "sizes": "72x72",
    "type": "image/png"
  },
  ...
  ]
}

Once you've defined the file, reference it in the head section of your pages.

<link rel="manifest" href="/manifest.json" />

Service workers

I also generated my service worker using the hexo-pwa plugin. A service worker is JavaScript that the browser uses to run tasks in the background. One typical task is downloading content ahead of time, so it's already available from the local browser cache when a user visits it. This can even let readers view some blog posts offline when their connection is poor. I configured the hexo-pwa plugin to download the following pages by default.

• /
• /about/
• /git-recipes/
• The first five blog posts

I also configured it to download the Google Analytics script only when there's network connectivity, serve JavaScript, CSS and images from the cache first, and try the network first for my homepage. That way, readers get the latest content when I publish a new post.

A popular tool for creating modern web applications is webpack, which also has plugins for PWAs. For a starting point on creating a service worker, see the webpack PWA documentation.

Wrap-up: an impressive web application

I could probably keep writing for a few more hours, but it's time for you to try these approaches yourself. If time allows, I might write more detailed articles exploring some of these topics. As always, don't hesitate to ask questions in the comments.

Now quickly go build your own impressive web application!