and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? Easy to launch Nice load screens Work offline (kind of) Can consume space BUT …
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? Simple Searchable Sharable Adaptable
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? PWA = Web + App Normal website +
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? • A built in browser proxy • JavaScript based • Bonus of push notifications • Cache assets on start up • Use cache when no network • Error handle when no cache and no network • And more…..
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? • Even in challenging network conditions • Standard page load timings important • As well as usability timings • 60fps rendering • No Jank • Responsive touch inputs
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA?
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? TLS is a ranking index in it’s own right But TLS opens access to: • Service workers • Push notification API • H2 for performance • Other API’s • Web Background sync • Payment API
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA? • Adaptive is also OK • Applies to Tablets as well as mobile • Viewport <meta> tags • Correct sized content (think images) • Big enough buttons • Manual checks still useful
and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Section 1: What is a PWA?
• Cache the file • Compress the file • Consider renaming the images • Limit the number of images (2-5) • Cache those images • Optimise the images Section 3: Optimising App startup
images • Size * • Resize for device types • Resize for screen estate • Format • The basics (e.g. no png’s) • Browser specific formats • Quality • Baseline a good start • Intelligent automated solutions * See also responsive images Section 3: Optimising App startup
• Minify • Think about your approach… • Initial performance – think about the critical path • In-app performance & cacheability – big bang Section 3: Optimising App startup
App startup Critical Path Faster rendering Smaller payload Improved app start-up time Only used once Maintenance overhead Monolith Reusable Increased offload Easy to maintain Can delay render Sending more bytes
App startup Index.html ~ line 132 <!-- Bootstrap core JavaScript ================================================== --> <!-- Placed at the end of the document so the pages load faster --> <script src="js/jquery-3.2.1.slim.min.js"></script> <script src="js/vendor/popper.min.js"></script> <script src="js/bootstrap.min.js"></script> </body> </html>
App startup Index.html ~ line 132 <!-- Bootstrap core JavaScript ================================================== --> <!-- Placed at the end of the document so the pages load faster --> <script src="js/jquery-3.2.1.slim.min.js" async></script> <script src="js/vendor/popper.min.js" defer></script> <script src="js/bootstrap.min.js" async></script> </body> </html>
within the App H2 rendering best practice • Critical content from single domain • Defer non-critical content • Server push • Preload 3rd party content * * resource hints
user experience SPOF <!-- Google Tag Manager --> <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-N5T323S');</script> <!-- End Google Tag Manager -->
user experience 3rd Party best practice • Self host if possible • JS – async & defer where possible • Resource hints (preload & preconnect) • Measure performance • Measure impact • Impose SLA’s
user experience • Google Analytics • https://garl.ink/offline-analytics • Collect & store offline • Replay when network available • We built a basic mPulse collector • Code Demo • Will be released • You can build your own!
user experience What if we could know what type of connection or the user’s preference? • Act differently for desktop/mobile • Desktop more likely to be on a fixed (unmetered/fast) connection • Detect if user has Chrome Data Saver enabled • Intercept requests and rewrite them • Use the Network API to discover the type of connection • Currently Draft…
user experience pwabuilder-sw.js self.addEventListener('install', function(event) { if(navigator.connection && navigator.connection.type !== false) { //Network API data available if(navigator.connection.type == "ethernet" || "wifi" || "wimax") { //Fast, likely unmentered... preload all the things event.waituntil(preLoad()); } else { //Cellular or unable to detect... just give basic offline support event.waituntil(minimalPreLoad()); } } else { //Network API data not supported event.waitUntil(preLoad()); } });
user experience Response • Respond in under 50ms • Don’t block the user, make sure response is within 100ms • Provide feedback for anything else Source: https://developers.google.com/web/fundamentals/performance/rail
user experience Animation • Do nothing where you can, do the minimum where you can’t • Use the 100ms response to pre-calculate expensive work • Target 10ms/frame, 6ms to render • Consider all types • visual animation • scrolling • dragging Source: https://developers.google.com/web/fundamentals/performance/rail
user experience Idle • Use to complete deferred work • Keep work blocks <50ms to avoid blocking user input • User takes priority Source: https://developers.google.com/web/fundamentals/performance/rail
user experience Load Test in conditions that match your users • 4G doesn’t always mean 4G • Focus on critical rendering path • 5s doesn’t mean everything • Source: https://developers.google.com/web/fundamentals/performance/rail
user experience Measuring RAIL in Dev Tools • Throttle your CPU • Throttle the network • View main thread activity • View main thread activities in a table to sort • Analyze frames per second (FPS) • Monitor CPU usage, JS heap size, DOM nodes, layouts per second, and more • Visualize network requests • Capture screenshots • View interactions • Find scroll performance issues • View paint events Source: https://developers.google.com/web/fundamentals/performance/rail
mgooding1981
drumnistnakano
champ
syoshie
kkamegawa
twada
maruto
shingo_kawahara
scalar
lycorptech_jp
sat
nishiuma
miichan
ufuk
kevinliebholz
mclloyd
aki_iinuma
sugarenia
marcelosomers
tammyeverts
jeffersonlam
bermonpainter
chrislema
samanthasiow
sergeychernyshev
