Progressive Web App questions

A couple weeks ago, I received a polite inquiry from Colin van Eenige asking if I would help him with a graduation project by answering some questions about Progressive Web Apps. We exchanged a few emails. I answered his questions. And I promptly forgot about it.

That is until I saw Jeremy Keith had thought to publish his answers to similar questions from Colin. I enjoyed reading Jeremy’s answers so much that I’m stealing the idea. Here are Colin’s questions and my responses.

Hmm… this is a broad question. It starts with making sure that we design things in a way that we know is going to be performant. We avoid excess and make sure we do as much as we can with CSS and SVG instead of images.

At some point, we start working on using service workers and ensuring that assets are cached so they load quickly. And then we use WebPageTest to test our work and iterate on our work to make it faster.

It depends on what they have to do and what they are trying to accomplish. I realize that is a wishy washy answer, but it is the right answer. Let’s look at two scenarios:

Scenario 1: The company is a health startup targeting affluent customers. They need access to HealthKit on iOS for their product to work. And they need to show user engagement in their product to get their next round of funding.

In that case, while they may eventually want to do something on the web, they should absolutely start with a native app because they need native to get access to HealthKit. Plus, the metric that they’ve been told that their potential sources of funding care about is engagement, not reach, and engagement is a metric that native apps tend to do better with.

Scenario 2: A medium-size company is thinking about creating an app. They’ve got a broad customer base that spans a lot of different platforms. In addition to the functionality of the app, one of their main motivations is to be able to say that “they have an app.” But they aren’t going to be able to build an app for every platform their customers use.

In this case, it probably makes sense to build a PWA either in addition to the native app or possibly as a starting point that then would let the organization experiment with the app before creating a native version.

Those are just two hypothetical scenarios. Each organization and their goals are different.

I just looked back at what I wrote, and I don’t specifically talk about the difficulties of optimizing for performance. I find performance work to be fun work so I would have been surprised to hear me refer to it as difficult. Most of the challenges for performance are usually found in organizational priorities, not in the challenges of the work itself.

What I did talk about was how difficult it was to measure the before and after of PWAs. I still find this to be a challenge due to the nature of the way browsers cache information and the fact that my most commonly used tools (e.g., WebPageTest) haven’t been updated to report if something is coming from the service worker or not.

As far as what I’m looking for, ideally we’d have less than a second for time to glass on a mobile network. That’s really hard to pull off because of network latency so the realistic goal is 2 seconds. But I still strive for <1 second.

I think it is a combination of things. PWAs are best practices for web development. So it is a bit of a vision, but it is also what we should be doing by default anyways.

The nice thing is that the incentives that browsers provide and their interest in continuing to raise the bar on what it means to be a PWA gives people inside organizations the tools they need to argue the case for performance.

Honestly, I haven’t looked. We did it for our own site so that we could show off what we’ve learned and do it in the best way possible.

Also, our statistics are skewed heavily by the fact that the vast majority of people who come to our site are here to read articles that we’ve written.

For example, the most popular page on our site last year was the article I wrote about autofill. It was read a little over 50,000 times last year. The bounce rate for that page was 90%.

I don’t consider that a problem. I’m not particularly worried about converting someone from reading our site into a customer. Instead, I’m hopeful that over time if we are sharing what we learn and helping the community, that eventually, perhaps someone will contact us because of the goodwill we’ve engendered.

All of this is to say that I don’t think of our site as a good test case of the promises of PWAs. I think that published stats from the Google case studies are much more interesting.

Originally, I was skeptical about PWAs because I felt like it was a buzzword surrounding technology that people should be using anyways. But then I was speaking on a panel and happened to mention progressive web apps, why I thought they made sense, and watched the audience get excited about it.

I then realized that the incentives for PWAs and simply the idea of encapsulating the technology into a digestible idea made a difference.

Shortly thereafter, I was talking to a potential client about PWAs, and he asked me to send him some articles to read about them. I looked around and realized all of the articles were written for developers, not for business people. So I decided to write for them and for designers.

Adding it to the site as something we offer seemed like a no brainer for two reasons:

1. I believe PWAs represent better user experiences and are the way we should be building the web. Our site and our company has always been about pushing what is best for the web.
2. I also believe that a lot of companies are going to want PWAs in the future so I want to be ready for them.

I hope this helps!