Pro Yearly is on sale from $80 to $50! »

A year with progressive web apps! #webinale

A year with progressive web apps! #webinale

About a year ago, we started using Progressive Web Apps (PWAs). The idea behind PWA was to replace native mobile apps. In this talk, I will show you what is possible to build with PWA, what kind of limitations exist, and what we learned in our journey. Along the way, you will see where progressive web apps can be a good fit for your own projects.

29db221e8a59b06c9180725ec8ac1e75?s=128

Antonio Peric-Mazar

June 04, 2019
Tweet

Transcript

  1. A year with progressive web apps! Antonio Perić-Mažar, Locastic 06.04.2019.,

    #webinale
  2. Antonio Perić-Mažar CEO @ Locastic Co-Founder @ Tinel Meetup Co-Founder

    @ Blockada antonio@locastic.com @antonioperic
  3. Locastic • We help clients create amazing web and mobile

    apps (since 2011) • mobile development • web development • UX/UI • Training and Consulting • Shift Conference, Symfony Croatia • www.locastic.com t: @locastic
  4. Stop call progressive web apps trendy!

  5. Our world today

  6. MOBILE

  7. UX

  8. MOBILE.UX.

  9. None
  10. None
  11. None
  12. https://www.morevisibility.com/blogs/analytics/setting-up-and-reporting-on-site-speed-in-google-analytics.html October 2016

  13. None
  14. Mobile web (UX) is broken!!!

  15. None
  16. And trust me… you will never had enough cheese

  17. “I don't care how many kick-ass Visio architecture diagrams you

    have; as far as the user is concerned, the UI is the application. I know UI US HARD, but you have to build an impressive UI if you want to be taken seriously. Give your UI the high priority it deserves.” Jeff Atwood, Coding Horror blog
  18. “I don't care how many kick-ass Visio architecture diagrams you

    have; as far as the user is concerned, the UI is the application. I know UI US HARD, but you have to build an impressive UI if you want to be taken seriously. Give your UI the high priority it deserves.” Jeff Atwood, Coding Horror blog
  19. None
  20. Capebility Reach

  21. “A Progressive Web App uses modern web capabilities to deliver

    an app-like user experience.”
  22. “A Progressive Web App uses modern web capabilities to deliver

    an app-like user experience.”
  23. PWA is: • Progressive - Works for every user, regardless

    of browser choice because it's built with progressive enhancement as a core tenet. • Responsive - Fits any form factor: desktop, mobile, tablet, or whatever is next. • Connectivity independent - Enhanced with service workers to work offline or on low-quality networks. • App-like - Feels like an app, because the app shell model separates the application functionality from application content . • Fresh - Always up-to-date thanks to the service worker update process.
  24. PWA is: • Safe - Served via HTTPS to prevent

    snooping and to ensure content hasn't been tampered with. • Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search engines to find it. • Re-engageable - Makes re-engagement easy through features like push notifications. • Installable - Allows users to add apps they find most useful to their home screen without the hassle of an app store. • Linkable - Easily share the application via URL, does not require complex installation.
  25. None
  26. Fast Integrated Reliable Engaging 4 things to focus on

  27. Fast Integrated Reliable Engaging

  28. Fast • No junky scrolling • No slow load performance

    • Measure and improve all the time • Bad connection (or no connection) is not excuse
  29. 53% of users abandon sites that take longer than 3

    seconds to load
  30. https://cloudfour.com/thinks/ios-doesnt-support-progressive-web-apps-so-what/

  31. None
  32. App shell model • Reliable performance that is consistently fast

    • Native-like interactions • Economical use of data
  33. Fast Integrated Reliable Engaging

  34. Integrated • User should not reach browser to reach your

    app • They should be able to interact same as with any other app on their device • They expect to have all possibilities as other apps • Users should be able to start app from their home screen
  35. https://www.mobigyaan.com/android-8-0-oreo-vs-ios-11-which-is-better

  36. https://techcrunch.com/2017/08/25/majority-of-u-s-consumers-still-download-zero-apps-per-month-says-comscore/

  37. https://techcrunch.com/2017/08/25/majority-of-u-s-consumers-still-download-zero-apps-per-month-says-comscore/

  38. https://www.technology.org/2017/07/28/progressive-web-apps-vs-native-which-is-better-for-your-business/

  39. 80% users intentionally moved apps to their home screen

  40. Broken experience • Required user interaction • Where it will

    start? • Would it work offline? https://medium.com/@saigeleslie/how-to-create-a-progressive-web-app-with-react-in-5-mins-or-less-3aae3fe98902
  41. Web manifest • Simple JSON file • Tell browsers about

    your app and how it should behave once app is ‘installed’ • Having manifest is required to show add to home screen pop-up • Works for desktop and mobile apps (chrome) • https://manifest-validator.appspot.com/ • https://app-manifest.firebaseapp.com/
  42. { "background_color":"#ffffff", "display":"standalone", "icons":[ … ], "name":"Twitter", "short_name":"Twitter", "start_url":"/", "theme_color":"#ffffff",

    “scope":"/" } <link rel="manifest" href="/manifest.json"> You can add it now to 
 your app
  43. None
  44. https://ponyfoo.com/articles/progressive-app-serviceworker

  45. 40% higher interaction rate from Home screen

  46. Web Payment API!

  47. 66% of purchases on mobile are on the mobile web

  48. 1/3 of purchases on Web are via mobile That means

    the UX 
 is BROKEN!
  49. Checkout forms today: • Manual • Tedious • Slow •

    N-taps http://www.alyssatucker.com/improving-hollars-ios-checkout-process/
  50. Autofill - step forward • Autocomplete attributes • 30% faster

    • Automatic • Simple • Slow • n-taps http://www.alyssatucker.com/improving-hollars-ios-checkout-process/
  51. Web Payment API!

  52. None
  53. None
  54. None
  55. Web Payment API! • Automatic • Simple • Fast •

    1-tap • Supportes payment gatway,
 or some applications payment 
 (Google Pay) https://paymentrequest.show/images/pr-woocommerce.gif
  56. More APIs • Media Session • Media Capture API •

    Casting support • Web bluetooth • Web Share
  57. More APIs • Media Session • Media Capture API •

    Casting support • Web bluetooth • Web Share
  58. Remember users expect to be able to interact with your

    app in the same way that they do all of the other apps on their device
  59. Fast Integrated Reliable Engaging

  60. Reliable Reliability means, never showing the Downsaur

  61. None
  62. Reliable • The quality of a network connection can be

    affected by a number of factors such as: • Poor coverage of a provider. • Extreme weather conditions. • Power outages. • Users travelling into “dead zones” such as buildings that block their network connections. • Travelling on a train and going through a tunnel. • Internet connection is managed by a third party and time boxed when it will be active or inactive like in an airport or hotel. • Cultural practises that require limited or no internet access at specific times or days.
  63. Reliable • We need instant loading offline • 60% of

    mobile connection is 2G • Fast Application is UX • 14 sec to load average website on 4g • 19 sec to load average website on 3G
  64. Service Workers

  65. Service Workers

  66. Service Workers Service Workers

  67. Service Workers • Rich offline experiences • Background syncs •

    Push notifications • …
  68. Service Workers • Script that browser runs in background, separated

    from web page • It is Javascript worker, so it cannot access to DOM directly • Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled.
  69. Service Workers • It's terminated when not in use, and

    restarted when it's next needed, so you cannot rely on global state within a service worker's onfetch and onmessage handlers. • Service workers make extensive use of promises • Service worker is for second load
  70. Service Workers lifecycle

  71. Register a Service Worker if ('serviceWorker' in navigator) { window.addEventListener('load',

    function() { navigator.serviceWorker.register('/sw.js').then(function(registration) { // Registration was successful console.log('ServiceWorker registration successful with scope: ', registration.scope); }, function(err) { // registration failed :( console.log('ServiceWorker registration failed: ', err); }); }); }
  72. None
  73. Service workers Events • On install - as a dependency

    • On install - not as a dependency • On activate • On user interaction • On network response • Stale-while-revalidate • On push message • On background-sync
  74. On install - as a dependency

  75. On install - as a dependency self.addEventListener('install', function(event) { event.waitUntil(

    caches.open('mysite-static-v3').then(function(cache) { return cache.addAll([ '/css/whatever-v3.css', '/css/imgs/sprites-v6.png', '/css/fonts/whatever-v8.woff', '/js/all-min-v4.js' // etc ]); }) ); });
  76. On install - not as a dependency

  77. Update Service Worker • Update your service worker JavaScript file.

    When the user navigates to your site, the browser tries to redownload the script file that defined the service worker in the background. If there is even a byte's difference in the service worker file compared to what it currently has, it considers it new. • Your new service worker will be started and the install event will be fired. • At this point the old service worker is still controlling the current pages so the new service worker will enter a waiting state. • When the currently open pages of your site are closed, the old service worker will be killed and the new service worker will take control. • Once your new service worker takes control, its activate event will be fired.
  78. On activate

  79. Update Service Worker • self.skipWaiting() • Skips waiting for refresh

    to start using new SW
  80. On User Interaction

  81. On Network response

  82. State-while-revalidate

  83. On Background Sync

  84. SW: Serving suggestions - responding to requests • Cache only

    • Network only • Cache, falling back to network • Cache & network race • Network falling back to cache • Cache then network • Generic fallback
  85. Cache only

  86. Network only

  87. Cache, falling back to network

  88. Cache & network race

  89. Network, falling back to Cache

  90. Cache, than Network

  91. Generic fallback

  92. None
  93. None
  94. None
  95. Reliable conclusion • Think how you design for the success,

    failure and instability of a network connection • Data may be expensive, so be considerate to the user • Make sure performance is part of your design process and UX • Try to provide offline by default if your app doesn't require much data • Inform users of their current state and of changes in states • https://serviceworke.rs/ - different examples
  96. https://serviceworke.rs/ - different examples

  97. Your goal is to provide a good experience that lessens

    the impact of changes in connectivity
  98. Fast Integrated Reliable Engaging

  99. Engaging • Charming and Attractive • Shift way how we

    think in patterns and designs from web patterns to some native patterns • Push notifications (browser doesn’t need to be opened) • Push Notification API
  100. Engaging

  101. What makes good notification Push. Push. Back upon now. (Courtesy

    Enrique Iglesias)
  102. What makes good notification • Timely - I feel I

    need and it matters now • Precise - specific info, what happens • Personal - make it personal
  103. What makes good notification

  104. https://www.slideshare.net/SeulgiChoi4/pwa-push-notification

  105. https://www.slideshare.net/SeulgiChoi4/pwa-push-notification

  106. None
  107. Push Notifications { "body": "Did you make a $1,000,000 purchase

    at Dr. Evil...", "icon": "images/ccard.png", "vibrate": [200, 100, 200, 100, 200, 100, 400], "tag": "request", "actions": [ { "action": "yes", "title": "Yes", "icon": "images/yes.png" }, { "action": "no", "title": "No", "icon": "images/no.png" } ] }
  108. 43% agrees to an app’s request to allow push notifications

  109. None
  110. Tools!

  111. Lighthouse

  112. None
  113. http://mobilehtml5.org/ http://mobilehtml5.org/ts/ http://mobilehtml5.org/tests/ http://mobilehtml5.org/tests/ te http://mobilehtml5.org/tests/ t http://mobilehtml5.org/tests/

  114. Some show case!

  115. 65% increase in page per session 75% increase in Tweets

    sent
 20% decrease in bounce rate Twitter Lite
  116. 76% higher conversation across browsers 4x higher interaction rate from

    Add to screen Increased usage of native apps also Alibaba
  117. 80%+ conversation 54% smaller than Android app 120% smaller than

    iOS app BookMyShow
  118. Cut load times from 11.91 to 4.69 seconds 90% smaller

    than Native Android App https://medium.com/@addyosmani/a-tinder-progressive-web-app-performance- case-study-78919d98ece0 Tinder
  119. Myths about PWA!

  120. PWAs are only for offline apps

  121. PWAs are a mobile thing

  122. None
  123. PWAs are a Google-only thing

  124. None
  125. PWAs are not ready yet

  126. None
  127. None
  128. None
  129. None
  130. https://pwa.rocks/

  131. None
  132. None
  133. Don’t be driven with hype, choose the best fit for

    your project
  134. It is not about PWA vs Native apps, it is

    about Users
  135. Thank you!

  136. antonio@locastic.com @antonioperic www.locastic.com Questions?