 Hello, everyone. It's almost lunchtime. I hope you enjoy your day so far. Is it good? Okay, so you've heard a lot today about progressive web apps about the benefits they bring and the tech stock 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 kickstart 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 websites the ones that already have an existing tech stack and an active audience and From 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 that 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 a proper zone to think in a way your users would think when they're using your app to make their Their experience really 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 at all 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 websites 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 same 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 you your project on track helps you enormously in Keeping in touch with your stakeholders throughout 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 anyways after you had a coffee or whatever it gives you a kick you start with the Analyzes step in this step you look carefully at your current website and your resources To get the 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 uptake is that it's not really a monolithic technology It's 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 achieve throughout your project But also a starting point for the next iteration if the one is going to happen this is a very simple timeline but Talking about it and raising the awareness about those steps Will make it clear from the start with your team and stakeholders What's the process should look like and it will allow you to avoid some misunderstandings some possible misunderstandings in future So let's follow it step by step step one analyze By analyzing your website, I mean you should get the Quantitative but also qualitative snapshot of your current situation We really 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're actually starting a project from start from scratch You will eventually find yourself iterating over it over and over again and each of these iterations should start with a proper analysis And the 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 a hundred audits on your site to identify how you can improve your app's performance accessibility and well 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 You on your website It gives you back a report and a score that summarizes different aspects of your website for you And this 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 like to point out is this download button It will 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, you know 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 viewer the lighthouse viewer to display it in a 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 if your stakeholders that might not be you know Techie people they might not understand how to open the dev tools and I really encourage you to do so Sometimes we tend to stick to the technical parts of our project and not really communicate all the instant outs of Upcoming migration with 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 dev tools the security panel that can run audits for you there's page speed insights web page test 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 the memory usage such Audit will inform your strategy going forward But also potentially can allow you to find some low-hanging fruit You know 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 Okay, 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 it's not the 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 projects 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 we 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 Junkie or unfriendly website 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 a burden of new features in Particular here 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's nothing new in there, but this moment when you decide you really want to invest in a PWA is great Moments 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 Sometime ago, I was working on the women tech maker org 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 tip of that list It immediately gave me some Some targets for optimization Here the two biggest requests made were for you to pay PI and the hero image you see on the home page So now what 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 few breakpoints to my CSS and with this few lines of code bum I got 21% less Image them download on the medium-sized page. That's a huge impact for 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 smaller counterparts so Here you can see on the screen two examples first one refers to that side API File that we were downloading before these days is not needed to use the API YouTube API file For just displaying the video on the page you can do it equally well with iframe and the iframe is a non-blocking way of getting this video to play on the On the side, so I could just bum remove it entirely and I gained 400 kilobytes this way Just by you know replacing a single line in my HTML The second optimization similarly you were using low-dash library But we're using just a few functions of it so we could use the low-dash core instead of full low-dash This brings us from 24 kilobytes to four kilobytes, which might not be that big game like overall But those optimizations do it up over time so what I try to say here is that In the most this moment where you go for a progressive web app It's a good moment to stop for for a while and see if this type of Non-optimal behavior appears on your side 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 we were doing some silly things on the page some assets were versioned by the Version number and some of them were actually timestamped with the timestamp So it was kind of 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 in building 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 was probably not going to 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 are actually using That can actually use the service worker later on down the line after the migration Okay, so let's say we are PWA ready. What do we focus on the next? Well, the next thing you need to ensure is the safety and in our context safety means HTTPS When the 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 phishing 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 it's 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 the 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 engage 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're operating in a Area where you get a lot of users on a 3g connection or even lower or maybe your target audience Usually use London tube and they don't get connection for most of their journey. Then you should really focus on offline You care about user retention most that's where the kind of important part for your businesses Maybe you should focus on add to home screen feature and the 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 and 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 It's the time to choose the right tools Here I wanted to give a shout to the work box library especially if you implement offline experience you Sometimes end up writing a lot of boilerplate and with work box. You can avoid a lot of that code error prone code and to smooth up your development process But work box is a little bit more than that It's also a set of generators that help you with the asset management management Remember that 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 work box is really helping you out Okay, so we have work box. 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 It's that the user should always feel in control of what is happening in the app and Junking transitions from one view to another it can successfully destroy that feeling of course Sometimes we do need to wait for The content from the network right but if we 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 loads 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 farther 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 housing.com. I really were that well done one when you tap on the listing you 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 an idea you as a user It gives you an idea of a structure of the page you're trying to access and Let's 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 of 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 is 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 in the cache can make your site perform much better and be much more reliable 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 tech maker example I'll show you on this example. What do I mean by this? Women tech maker 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 very heavy So maybe I don't need all of those images. Maybe I just saved the html Well, that's how the page would look like it looks ugly But also it's totally unusable, right? Like users can't even navigate through the page because the 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 the site Now the red ones are branding and priority is the images that me as 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 ever need to even care how they're cached because as long as my html is cached The image is just there in an 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 sub page is already ready for them to serve I reserve those only for the priority images to not overwhelm the 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 a you know bestie fort 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 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 kind of magic there Here what I wanted to do is I wanted to use an alt tag alt attribute from the image to generate the The image on the fly. I don't want to store them because they might change frequently But I wanted to still convey the message So in the end I just returned a generic fallback image for the image itself And I rendered 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 you know 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 It's really engaged with that. So we want to keep them engaged And relaxed and looking at the screen and when the users are using the app 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 this type of components Virtualized list means that only the items that are actually in the screen Are rendered and maybe a few before and at the end And all the rest is this attach and attach dynamically This means that you can scroll pretty fast and never get this, you know, blank screen When the memory is over 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 you know being their tweet 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 user use usually don't have any context about What you're asking them about and they don't really Uh Can make they really are 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 And 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 um can sign up for that So just with this uh with this overlay you can focus their user's attention also on the question being asked Well, that's just a short list of common optimizations You can look into when 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 to 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 step. 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 a hundred of 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 voice of your users Both to track improvements, but also to look out for a possible regressions on the way Now you might ask When is my website 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 hundred 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