Kickstarting Your Journey to Progressive Web Apps (Chrome Dev Summit 2017)

Kickstarting Your Journey to Progressive Web Apps (Chrome Dev Summit 2017)

Hello, everyone. It’s almost lunchtime. I hope you enjoy
your day so far. Is it good? AUDIENCE: Woo! EWA GASPEROWICZ: Woo! OK. So you’ve heard a lot today
about Progressive Web Apps, and about the benefits
they bring, and the tech stack they’re using. And probably a
lot of you already tried your hands with
Progressive Web Apps, right? It’s always fun
to try a new tech with your personal
project, a side gig, a demo here and there. But actually, when it
comes to big business– to big commercial
implementations– we sometimes get a little
bit shy in implementing progressive features. And this talk is aimed exactly
at overcoming this shyness. I hope to give you some
ideas and some procedures that you can take back to your
teams, to your organizations, and really kick start
your Progressive Web App journeys over there. Me and my team, we recently went
through a few Progressive Web App migrations. And by migration, I mean
that we were modernizing and implementing progressive
features on existing web sites– the ones that already have
an existing tech stack and an active audience. And even though each
of these projects was slightly different, two
common things that I noticed were that, firstly,
restructuring an existing website is much more difficult
than writing anything from scratch. It can be even overwhelming. So it’s really good to have
some structure and some process you can stick to. And secondly, implementing
progressive features is much more a question
of a right mindset than anything else. Of course, knowing the
ins and outs of technology does help a lot. But you really need to
be in the proper zone to think in a way
your users would think when they’re using your app
to make their experience be delightful. And these are two
things I’m going to talk about today exactly– it’s the process and the
mindset of a Progressive Web App migration. So Progressive Web
Apps, as you know, focus on delivering a delightful
web experience to the users. These are still web
experiences, though. And very often,
organizations already do have some web
presence out there. This means that we, as
developers, we very rarely have the luxury of
starting from a blank page. We rarely can– or
actually should– start from scratch. And with existing web sites
and their complexities, there is no boilerplate. There are no generators,
already-made starter kits that can guide you in the right
direction from the beginning. There is an art to deciding
how to tackle progressiveness in those apps. And in art, you often go
with your gut feeling, right? But as the saying goes,
the best improvisations are the ones that are
well-prepared beforehand. So it’s better to
be well prepared. It’s good to have a
structure to follow– a well-established process
keeps your project on track, helps you enormously in keeping
in touch with your stakeholders without the project, and also
actually sometimes keeps you sane in the ups and
downs of the project. In my case, the process
usually looks as follows. I strongly believe that any
project starts with a coffee, because no coffee
means no productivity. So here we go. The project starts
with a coffee. Of course, I can admit, this
might be a personal preference. So if you have a different thing
to start, go with that one. But anyway, after
you had a coffee or whatever gives
you a kick, you start with the Analyze step. In this step, you look carefully
at your current website and your resources to get
a proper understanding of your starting point. A good analysis also gives you
a very good reference point that you can compare to after
the implementation is done. Next, we rarely have the luxury
of implementing everything at once, because our
resources are limited. So you need to prioritize. And the cool thing about
Progressive Web App tech is that it’s not really
a monolithic technology. It’s a very modular concept. So you can often
pick and choose what to implement and
also in what order. Once the priorities are set,
it’s good to stop for a moment and prepare yourself by
choosing the right tools. It’s important to remember that
you don’t need always to write everything from scratch. You’re not alone. There are tools and
libraries that can help you. So don’t reinvent the wheel– look for your proper tools
before implementation. Then, of course, there’s
time to execute your plan. This is where all
the fun happens. And last but not least– this is a sometimes
overlooked step– measure and evaluate. It gives you both a
nice summary of what you achieved throughout
your project but also a starting point for
the next iteration if one is going to happen. This is a very simple timeline. But talking about it and raising
the our-ness about those steps will make it clear from
the start with your team and stakeholders what the
process should look like. And it will allow you to avoid
some possible misunderstandings in future. So let’s follow it step by step. Step one– analyze. By analyzing your
web site, I mean you should get the quantitative
but also qualitative snapshot of your current situation. We rarely start from
scratch, as I told you, so it is crucial to
understand your standing point before you add new layers
of complexity to your site. And even if you were
actually starting a project from scratch, you
will eventually find yourself iterating
over it over and over again. And each of these
iterations should start with the proper analysis. And a tool that is tremendously
helpful in analyzing a website is, of course, the Lighthouse. If you haven’t tried it
yet– which I doubt– Lighthouse is a Chrome extension
and a command line tool that runs over 100
audits on your site to identify how you can
improve your app’s performance, accessibility, and
overall progressiveness. In recent Chrome, it’s
also integrated directly into the Chrome DevTools, so
you can run an audit directly in Chrome. When you run Lighthouse
on your website, it gives you back a
report and a score that summarizes
different aspects of your website for you. And it does not only
list all the items it’s checked, but also gives
you proposals on how to fix them and links to further resources
in case you want to learn how to actually do that. So just by running
this tool, you can learn a great
deal about how to make your site more progressive. Now, the very small feature
in the Lighthouse report that I’d like to point out
is this Download button. It allows you to save
the generated report to be used for later. I found it very useful
to run the report and save it for later at
the beginning of my project. But also later, periodically, to
observe and enjoy the progress I’m making but also to watch
out for possible regressions throughout the project. So it’s really nice not
to only check your score but actually save it in some
right place to use for later. Once it’s downloaded,
you can actually use the Lighthouse Viewer to
display it in a browser tab again. And from there, you can
also share it and export it to different formats– for example, PDF. And this is very
useful if you want to share your report with your
stakeholders that might not be techie people. They might not understand
how to open the DevTools. And I really encourage
you to do so. Sometimes we tend to stick
to the technical part of our project and not really
communicate all the ins and outs of upcoming migration. We have people that should be
informed on the business side. And Lighthouse Report actually
is a great center point that can guide you through this
discussion with the business people. Of course, Lighthouse gives
you a comprehensive overview of your site. But there are more
tools that you can use. There’s the Network panel in the
Chrome DevTools, the Security panel that can run
audits for you. There’s PageSpeed
Insights, WebPageTest. And most of those
tools actually allow you to save the
traces from your audit and a snapshot of your data so
you can make use of that later. It would be good to
make a habit of saving those audits at each
milestone of your project. Things that you might be
interested in recording are performance, of course, both
load as rendering performance, resource sizes,
numbers of requests, security, and memory usage. All these will inform your
strategy going forward, but also potentially
can allow you to find some low-hanging
fruit, some small improvements, that you can fix easily
without much development effort but that would lead to big gains
and better overall healthiness of your website. OK, so let’s say we made the
proper audit of our site. We know exactly
where we’re standing. Now it’s time to prioritize. So here’s a good message to you. Progressive Web App is not
a monolithic technology. It’s rather a set of concepts,
and they are highly modular. Here you can see a concept
of bringing your app offline, the concept
of notifications, the concept of Credential
Management, and so on. And for most of those items, you
can tackle them independently. And you can tackle
them one at a time and introduce the gains
from each improvement as a progressive
enhancement for your users. You don’t need to
go after all of them immediately, because
then this can be just overwhelming
and too complex on a bigger scale project. You can be really strategic
about your choices and make it all aligned with the
business need of your project, rather than just tick
boxing a set of rules. So how do you decide
where to start? I would say start
at the beginning. Before you start
adding new features, you need to ensure what I
personally call Progressive Web App readiness. I think it is worthwhile
to call it out here, because no amount of
progressive features will solve unresponsive,
cluttered, janky, or unfriendly websites. So before you add new
complexity to your site, you want your site to be
as lean, smooth-working, and optimized as
reasonably possible before you add the
burden of new features. In particular, here’s
where the audit you saved is really handy. Based on your audit outcome,
you might look into the areas like the ones mentioned here. And probably these are
all good old friends. There is nothing new in there. But this moment when
you decide you really want to invest in a
PWA is a great moment to stop for a moment, check
those things out, and fix them if they went off track
throughout the previous lifecycle of your application. The cool thing is
sometimes really small steps can bring
you really big gains. And let me show you an example. Some time ago, I was working
on the [? ?] site. And I was doing exactly that– I was preparing it for some
Progressive Web App features. Here you can see
the network panel from before the
migration happened. What I did here– I just sorted the
assets by size. And just by looking at
the top of that list, it immediately gave me some
targets for optimisation. Here the two biggest
requests made were for YouTube API
and the hero image you see on the homepage. So now what would happen
if you optimized those? As for the hero image, it covers
the full header area, right? So it needs to be as
big as the viewport, but it doesn’t need to
be bigger than that. So I just created a few
versions of that file that are appropriate
for a smaller viewport. I added a few
breakpoints to my CSS and moved these
few lines of code. Bam. I got 21% less image download
on the medium-size page. That’s a huge impact for a
single optimization like this. And this is just by
optimizing a single image. And you can go much
farther than that, right? Second optimization
was about replacing the more complex
or more demanding assets with their
smaller counterparts. So here you can see on
this screen two examples. First one refers to
that sad API file that we were downloading before. These days, it’s not
needed to use the API file for just displaying
the video on the page. You can do it equally
well with I-frame, and the I-frame is a
non-blocking way of getting this video to play on the site. So I could just, bam,
remove it entirely. And I gain 400
kilobytes this way, just by replacing a
single line in my HTML. The second optimization,
similarly, you are using Lodash
library, but we’re using just a few
functions of it. So we could use the Lodash
core instead of full Lodash. This brings us from 24 kilobytes
to 4 kilobytes, which might not be that big gain overall,
but those optimizations do add up over time. So what I’m trying
to say here is that in this moment where you
go for a Progressive Web App, it’s a good moment
to stop for a while and see if this type
of non-optimal behavior appears on your site and fix it. The third example here
is about browser caching. Because once I made sure I’m not
making too big resources being pushed to the user, I
also want to make sure I don’t push things
twice if not necessary. Actually, when I was analyzing
the page in preparation for Service Worker, I
realized that we were doing some silly things on the page. Some assets were versioned
by the version number, and some of them were
actually timestamped– to have the timestamp. So it was inconsistent, but
apart from being inconsistent, it was also pure wrong. Because even if the
asset did not change, with each consecutive build I
would change its URL, right? Either by appending
a new version number or by appending a timestamp. And this means that I’m not
leveraging the normal browser caching that is already
involved in the browsers for a long time. So it was high time
to change that. And if I was not going
for Progressive Web App, I would probably
not go into trouble of investigating all
that and fixing this. Each of these changes
was relatively easy and very quick to implement. But it really brought
a big benefit. And pay attention that
this brought benefit to all of the users, not only
the ones that can actually use the Service Worker
later on down the line after the migration. OK, so let’s say
we are PWA ready. What do we focus on next? Well, the next thing you
need to ensure is the safety. And in our context,
safety means HTTPS. Many new and powerful
web APIs actually take it as a requirement
that you serve your website from a secure origin. Thanks to the HTTPS,
user can trust that the site is
actually you, that there is no fishing happening. There’s no scammer between
you and the site, right? And they know that
nobody is actually listening on the
interaction with your site. The web has a tremendous reach
and is extremely low friction. So you get all kind of users
online, also the ones that are not very tech savvy. So keeping your
users safe is hugely important in the world of PWA. Great. So now we have a decent
page and a secure one. So what do we do next? Well, now is the moment
where you can prioritize based on your business need. For example, if a
really important thing for your business
or organization is user acquisition, maybe
you should focus on perf. Because when user
enters your site, you don’t want to have a
high bounce rate, right? You want to keep
their attention, which means you need to serve
them content quickly. You need to get them
engaged in your site quickly so that they stay, and
they maybe turn into a customer with that visit, right? So then you focus on perf. But maybe your
situation is different. Maybe you are
operating in an area where you get a lot of users on
a 3G connection or even lower. Or maybe your target audience
usually uses London tube, and they don’t get connection
for most of their journey. Then you should really
focus on the offline. You care about user
retention most? That’s where the important
part for your business is? Maybe you should focus
on A2 Home Screen feature and notifications. This way the app will
be integrated better with users’ devices,
and it will be easier to bring them back and turn
them into a returning customer from an occasional one. If you care about
user conversion, well, maybe your
bottleneck is on payments. And maybe if you
try payments API, that’s where you can bring
most value for your business. So as you can see, a lot of
Progressive Web App features are modular, and you
can pick and choose which ones to implement
and in what order. And you should make sure
to always coordinate with your stakeholders to
choose the best line of action for your business and
then iterate as necessary. Whatever you choose, though,
remember to always wrap it in the good user experience. Remember that those
features in technology are not the goal in themselves. Your goal is the delight of the
user that is using your app, right? So it’s very important on how
you implement those features. And we’re going to touch on
that in the implementation section of our process. Now is the time to
choose the right tools. Here I wanted to give a shout
out to the Workbox library. Especially if you implement
offline experience, you sometimes end up writing
a lot of boilerplate. And with Workbox, you can avoid
a lot of that error-prone code to smooth up your
development process. But Workbox is a little
bit more than that. It’s also a set of
generators that help you with the asset management. Remember then when
implementing caching, this can get tricky
really easily, because you need to handle
all the URLs and so on. So you don’t really
want to do it by hand. And then Workbox is
really helping you out. OK, so we have Workbox. We have our priorities set. Well, now it’s time
to implement, right? And this is the hardest part to
give any really generic advice on, because each
project is different. So instead I would
like to share some of the examples of the right UX
patterns and the implementation decisions that you
might find useful when trying to achieve this
happiness and progressive feel of your website. Well, the first rule of thumb
on achieving a good experience is that the user should
always feel in control of what is happening in the app. And janky transitions
from one group to another can successfully
destroy that feeling. Of course, sometimes
we do need to wait for the content from
the network, right? But we know that the
user perception of time is quite elastic, as well,
and we can influence it. So if we can make the
user think that something goes for one second, while it
really loads for three seconds, this is our win. Sometimes just adding
load indicators help. But you can go even further. If the user sees that
something is happening, they can already start
analyzing the page. So instead of blocking
the transition of the page on network, you can
use skeleton screens instead. Here you can see an example
of Progressive Web App for– a
really well-done one. When you type in a listing,
you are taken immediately to the next screen, where just
the outline of the content is presented, and then the
real content is coming in. It gives you as users
an idea of a structure of the page you are
trying to access, and lets you grasp it a bit,
all while the real content is loading. It’s a big improvement for
the user, especially one as impatient as I am usually. Another pattern that enhances
this feeling of being in control is the stable load. First, what do I mean
by unstable load? Well, you probably often
see this in the web today where you load an article
or a piece of content on your mobile device,
and you’re reading it, and it just jumps out
from under your eyes because some additional
content, like an image, loaded at the top of it. It’s especially
annoying if it’s a link, and you just try to tap it,
and it always runs away. So it’s really an anti-pattern. Instead, you can
ensure a stable load. It’s as easy as specifying the
size of your images beforehand and of all the dynamic elements. And this way, you
tell the browser how to lay out the
elements ahead of time so the content is already
in its original position when the new content arrives. This way, you never miss
a link and get frustrated just because of the way
the content is loading. Speaking of loading performance,
this can, of course, be optimized a lot with
Service Worker and caching of the resources locally. And this is a primary reason
why you should consider Service Worker, even if you
don’t expect to get audience that is fully offline. Saving some resources
into cache can make your site
perform much better and be much more
ready able, even if the users don’t
go offline fully for extended periods of time. There is one thing
to consider, though. When you cache
things locally, you need to be mindful
of users’ resources. They do still use some of the
memory on the device, right? Sometimes caching entire site is
simply not viable or possible. Let’s go back to the
Women Techmaker example. I’ll show you on this example
what do I mean by this. Women Techmaker site
is a beautiful site. It’s a rich visual experience. There’s lots of imagery. If I wanted to save all
of this for offline use, it would be very heavy. So maybe I don’t need
all of those images. Maybe I just save the HTML. Well, that’s how the
page would look like. It looks ugly. But also, it’s totally
unusable, right? A user can’t even
navigate through the page because the buttons are gone. So the site is unusable. How do we decide, between
these two extreme points, what do we cache and when? Well, I started to look
at the images on that site by function. The yellow ones, I call
them navigation and action. They’re super important. Without them, the user can’t
really properly use this site. Now, the red ones are
branding and priority. It’s the images that me, as the
developer or business owner, really care about. I use them to create
connection with my audience. They’re very important. They have the priority. Now, the blue ones are the
opposite of the red ones. They’re decorative. It’s nice they’re there. I like them. But if they’re missing, they
don’t really break the site. And now, informative images
are quite interesting, because they look nice, but also
they do convey some meaning. They do convey a message. So they’re like semi-important. Now that I understand the
structure of my images on the page, I can actually
apply different strategies to those. For example, for the
really important ones– the navigational ones– I just inline them with SVG. And I never need to even
care how they’re cached. Because as long as
my HTML is cached, the image is just
there in that SVG form. So that’s done. Now, the red ones– I care about them a lot,
so I pre-cache them. As soon as the Service
Worker is installed, I proactively go
and fetch them so that when user enters
the appropriate subpage, it’s already ready
for them to serve. I reserve those only
for the priority images. Do not overwhelm the cache. Blue ones, I cache at runtime. Which means when user is
moving throughout my site and visiting new
places, I do cache them on best default basis. And I put some limit
on it, as well. So this means that sometimes
the image is present, sometimes it’s missing, but it’s
not breaking the overall look and feel of the site. Now, the informative images
are quite interesting, because here you
can see that I can use the full power of
the Service Worker. Service Worker is
just JavaScript, so you can do all
kinds of magic there. Here what I wanted
to do is I wanted to use an ALT attribute
from the image to generate the image on the fly. I don’t want to store
them, because they might change frequently. But I want to still
convey the message. So in the end, I just return
a generic fallback image for the image itself,
and I render the text as the rest of the image, right? So it’s fully rendered
in the Service Worker, and it’s never using any cache. And I still get
this meaning that I wanted to convey to
the user passed on. So these are four
selective image strategies. And depending on your site,
there might be many more. So you just need
to look carefully at the content of your site
and see what’s best for you. Now, let’s say the user got this
delightful experience from us and is really engaged with that. So we want to keep them
engaged and relaxed and looking at the screen. And when the users
are using that, they usually end up scrolling. And if they scroll long
enough or fast enough, sometimes you get
this scrolling glitch if the list gets
too long, right? So how do we avoid that broken
experience for the user? Well, you can use what we
call virtualized lists. And many of the frameworks
that are in use right now do offer these
type of components. Virtualized list means that
only the items that are actually in this screen are rendered,
and maybe a few before, and at the end. And all the rest is dis-attached
and attached dynamically. This means that you
can scroll pretty fast and never get this blank screen
when the memory is overflowing. As a matter of fact, it was
one of the key techniques that Twitter found
useful when implementing their Progressive Web App
so that the users could be in their Twitter
feed for a long time and not get it broken. Finally, the last UX
pattern I wanted to share is not to interrupt
your users when they’re using your service. If you ask for the
permissions on load, users usually don’t have any
context about what you’re asking them about,
and they really aren’t comfortable making this
decision at that very moment. So it is much better to actually
ask for this type of permission in an appropriate situation. I really like what Twitter did. In Twitter app, when you go
to the Notification tab– so user actually expressed
an interest in notification– they show this
full screen overlay when the user can
sign up for that. So just with this overlay, you
can focus the user’s attention also on the question
being asked. Well, that’s just a short
list of common optimizations you can look into in
looking for the right UX for your Progressive Web App. And by all means, this is
not an exhaustive list. So actually, I’m very
happy to hear your stories and find out about
the good practices you find useful in your
projects later on in the lobby. Finally, everything we
wanted is implemented, and there’s time to
evaluate our work. Remember when I told you to
save some snapshots of the data in the analysis part? Well, now they come in handy. Measuring things at
the end of the project also provides business
justification for next steps. So make sure you, again,
involve your stakeholders in the whole process. You can go again
through the audit and just compare the outcome
with the previous version. And hopefully it will
give you a surge of joy as you see the metrics
improve on your site. However, there is one caveat. Metrics are helpful, but
they’re only metrics. Getting 100% at
Lighthouse feels good. I know it feels good. I’ve been there. And it may also help convince
your boss that you’re the best developer ever. But nothing is better than
really checking the reaction of your users to your website. In evaluating your
changes, you need to pay special
attention to analytics and to the words of your users,
both to track improvements, but also to look out
for possible regressions on the way. Now, we might ask, when is my
web site progressive enough? Is my app already a
Progressive Web App? Or we’re somewhere
in the middle? Is it progressive when
it’s fully offline? Is it progressive when
I checked all the boxes on the Progressive
Web App checklist? Is it when it’s
100% on Lighthouse? Well, remember that all of
these are just representations of the same mental model
and of the same idea of delightful user experience. So maybe it’s not really a
question of how progressive your web app already is. You just can take it
one iteration at a time. Usually, this process
goes round and round, and you can iterate
as many times as you feel you need to
provide the best user experience for your needs. Thank you so much. [MUSIC PLAYING]

Danny Hutson

3 thoughts on “Kickstarting Your Journey to Progressive Web Apps (Chrome Dev Summit 2017)

  1. Good talk but it's very similar to 2016 Google I/O and Progressive Web App Summit. Like, content, case studies, catchphrases, everything, it's all stuff we've seen before which is slightly disappointing. Either way, very good talk in isolation!

Leave a Reply

Your email address will not be published. Required fields are marked *