When should you use a PWA? – Progressive Web App Training

When should you use a PWA? – Progressive Web App Training

SAM DUTTON: OK. Let’s take it back,
right back to the 1820s. And this is Babbage’s
difference engine. It was designed to tabulate
polynomial functions, such as logarithms. One machine, one app,
hand-built, hard-coded. To get a new app, you
had to get Babbage to design a new machine. And well, as it happened,
wait nearly two centuries for someone to
actually build it. Now move forward 150 years
and software looked like this. Big programs needed 10
or more floppy disks. Compact disks, and later
DVDs, were a revolution. The MapPoint app,
for example, could be bought from a bookstore. This had pan and zoom,
and it completely changed trip planning. Web-based maps at the time
couldn’t do anything like that. Well, let’s move
forward a few years. Google Maps happened. And this worked on any
computer, not just one that you’d spent 30
minutes installing on. Google Maps showed that the
web’s distribution model can really work. However, on mobile, well,
we’ve seen something different. Now, raise your hand
if you use Google Maps on the web on desktop. But what about on mobile? Do you open a browser to
use Google Maps on a phone? I’d guess not many of you. So the hardest problem with
software is distribution. And anyone who’s ever worked
in IT will understand this. So how does this
play out on mobile? Well, it’s true that
users spend most of their time in native apps. Re-engagement features
keep users in apps. Notifications bring users back,
even when the app is closed. And home screen icons
maintain visibility. But usage is highly
concentrated. It’s a winner take
all situation. App developers often spend
more for distribution than they actually earn back. So if the native ecosystem
isn’t going so well, why hasn’t the web been
even more disruptive? Well, here’s one way to think
of the differences between web and native– the capability access. Native apps have the ability
to start up fast and reliably. They can work offline and use
push, sync, sensors, and so on. Now, the web has been perceived
as safer and more respectful of privacy, but it doesn’t
have those native features. If we add another
access, reach, you can see where the web succeeds. Google data shows that
mobile users visit around 100 sites per month. This is the power of URLs. They meet one-off needs. But what if the web could
meet those user expectations? This is what Progressive Web
Apps represent, PWA for short. Web apps are finally
able to earn their place on the home screen and
in the notification tray. And they don’t have
to give up on reach. So what was missing
from the web? Well, first, we needed
reliability and performance on par with native apps. Next, we needed to be in
the notification tray. And lastly, for
trustworthy apps, we needed to be on
the home screen. So now let’s talk
about performance. We all time is money. And this data shows just how
badly bounce rate increases with load time. Other studies show that after
just 3 seconds, 40% of users will abandon a website. 40%. But what if you didn’t need to
traverse the network every time for every asset? What if you could intelligently
cache assets locally reliably? Well, that’s what
service workers do. Service workers enable
you to implement caching with the cache
API, not just by hoping to rely on browser caching. This means that after
the first visit, sites and apps can
be reliably fast. Well, that’s huge. But what about the first visit? The AMP Project from
the Google search team was built to address
the web obesity epidemic and provides reliably fast
web components for first load. These AMP components can
be much faster to load, and less data hungry
than non-AMP content. Well, what if you
could combine the two, fast first load with reliable
performance subsequently? Well, we can do
that by combining AMP and service worker. This is where AMP meets PWA. So do you want to try
out progressive web apps? Well, there are great tools
built into the Chrome DevTools. For PWA developers,
Google engineers have created Lighthouse. This reports on how
well your site or app is doing in terms of
performance, security, accessibility, SEO,
and PWA features. You also get command
line tools you can build into your workflow
and production processes. So to sum up, PWAs are
reliable, fast, and engaging. We’ve been really excited
to see incredible momentum across the globe. Here’s a sample of folks
shipping or actively working on PWAs and new web APIs. With these early
adopters, we’ve seen that every site has their own
way of investing in mobile web, and starting down the path
towards progressive web apps. So now it’s your turn. Thanks for watching.


  1. I'm wondering how does creating a pwa help with jank free scrolling. Does this mean that as a developer I wouldn't have to try to make the interactions (such as scrolling) more seemless because that's just something that pwa will do for me (that would be great but I still want to know how it would do that)? Perhaps I didn't catch something or I'll learn more as I move ahead. Great lesson, btw

  2. I am so deep in lit-firebase-redux. damn close. The largest custom web component is user-account-everything. Jammed user: drawer, page, and functions together. so I am able to template a Framework + User, then focus on custom page elements for each domain.

  3. I'm not convinced that mixing pwa and amp is always a good idea. Unless first load time is really really important than yes, otherwise your users should be fine waiting a few seconds for the first load. Also, dynamic es6 module import would be a huge performance win for pwa.

  4. I appreciate you making videos about PWAs because I really want that technology to move into gear.
    …But, idk, I'm utterly disappointed by this video :/ You just vaguely spoke about PWA features/benefits but that did not answer the question from the video title. Also I have never heard about those "amp" components you were talking about and I have absolutely no clue what you were trying to say with that…

  5. Please note the studies About app usage are from 2015. More current numbers would be great and the vertical of those top 3 apps – I'd bet Messaging, social media and Maybe the browser?

  6. A very vague info indeed, the same is elsewhere. I can offer way more on business cases when a PWA should be used, because we started working on PWA like approach even before the term itself was born (we called it Mobile Front as a Service). A ver 1.0 of our platform called Mobsted.com was already up and running when the rest of world woke up :::))) Right now we at v 3.0…… So, ridding off the lyrics – we divide our customers, hence use cases, into several groups:

    The FIRST group is the best fit for going PWA – useful apps, but not a daily life changer – examples are insurance company, car dealer's or an apartment's customer service app – people don't go our of their way to get these, but will agree to install it as long as it is quick to get, takes no space and needs no registration. The best case we have is 10X install rates for PWA vs the equal content native app of the same business.

    The SECOND group by "best to worst fit" are – apps with little utility, which are difficult to get into smartphones – best example here are e-commerce oriented mobile apps – PWA has the smarts to overcome the "non-installation wall", if done right, and can deliver some value to end users.

    The THIRD group by the "best to worst" fit – apps which users can be made to install, but PWA saves costs in making and support. Examples here are internal business processes apps, like field data collection, equipment reviews, etc. Employees can be made to install anything, however PWA provides great flexibility and much lower costs of ownership for as many apps as business needs.

    The FORTH group – apps which people will instal in a native form anyways. Examples here are mobile banking, social etc. The only value from PWA vs native here is cost savings, which is often not such an important consideration as security and fuller access to hardware for clients like banks.

    I am also deliberately avoiding a block of apps banned from app stores, which are by definition a perfect PWA fit. Also, I can not provide opinion on games, which take a huge share in both app stores, but are out of our platform's scope and there are issues for offline mode there, too.

  7. Hi, can you please link to the studies/articles that you refer at at 3:17? To have a reference of the data in which we are basing our PWA/performance work. Thanks!

Leave a Reply

Your email address will not be published.