browser choice. • Responsive - Fit any form factor: desktop, mobile, tablet, or forms yet to emerge. • Connectivity independent - Service workers allow work offline, or on low quality networks. • App-like - Feel like an app to the user with app-style interactions and navigation. • Fresh - Always up-to-date thanks to the service worker update process. Overview
and ensure content hasn’t been tampered with. • Re-engageable - Make re-engagement easy through features like push notifications. • Installable - Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store. • Linkable - Easily shared via a URL and do not require complex installation. • One code-base (web app) Overview
Apple Store) • It is not possible to add a video, description, photos, and star ratings • 3D/HD games, high graphics-oriented apps – performance problems • New native device features might not be available immediately (examples: fingerprint scanner, FaceID) Problems
from browsers • 82% increase „conversion rate” on iOS • 2x more visited sites per session per user • 74% increase time spent per page per session Flipkart • 3x increase time spent on the site • 40% increase re-engagement rate • 70% increase conversion through „Add to Homescreen” button • 3x less data consumption
go offline while browsing, continue browse when they come back online • 150% increase time for people who add its PWA to the home screen Tinder • Cut load times from 11.91 seconds to 4.69 seconds • 90% smaller than native Android app Uber • 50k gzipped app load 3 seconds on 2G networks
are responsive on tablets & mobile devices • The start URL (at least) loads while offline • Metadata provided for Add to Home screen • First load fast even on 3G • Site works cross-browser • Page transitions don't feel like they block on the network • Each page has a URL https://developers.google.com/web/progressive-web-apps/checklist
resources - use the Cache API (part of Service Worker), for all other data - use IndexedDB. • Web Storage (e.g LocalStorage) is synchronous, has no Web Worker support and is size-limited (only strings). Async LS have been kicked around in the past, current focus is on getting IndexedDB 2.0 in a good state. • Cookies have their uses but are synchronous, lack Web Worker support and are size-limited.
and Opera: Your storage is per origin (rather than per API) until the browser quota is reached. Manage by Quota Management API. • Firefox: no limits (prompts after 50MB) • Mobile Safari: 50MB max. • Desktop Safari: unlimited (prompts after 5MB) • IE10+: 250MB max (prompts at 10MB.) • Edge: for volume size 8- 32GB = 500MB, >32GB = 4% of volume size https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c https://love2dev.com/blog/what-is-the-service-worker-cache-storage-limit/
separately (separate daemon instance) from the main browser thread in the background, intercepting network requests, caching resources, and providing a base for multiple APIs including push notifications, background sync, and caching.
blocking (it's designed to be fully asynchronous) synchronous XHR and localStorage cannot be used in a service worker. • The service worker can't access the DOM directly. To communicate with the page, the service worker uses the postMessage(). • You cannot rely on a global state persisting between events. If there is information that you need to persist and reuse across restarts, you can use IndexedDB databases. • This is not related to the standard browser Cache-Control mechanism.