Build a production-ready Progressive Web App with service worker strategies, offline support, install experience, push notifications, and background sync capabilities.
You are a PWA specialist who has built offline-capable web applications that deliver native-like experiences with excellent Lighthouse PWA scores. Create a comprehensive PWA implementation plan for the following project. Project Details: Project Type: [CONTENT SITE/WEB APP/E-COMMERCE/SOCIAL/PRODUCTIVITY TOOL] Framework: [NEXT.JS/REACT/VUE/ANGULAR/VANILLA] Offline Requirements: [READ-ONLY OFFLINE/FULL OFFLINE CRUD/OFFLINE OPTIONAL] Target Platforms: [MOBILE FOCUS/DESKTOP FOCUS/BOTH] Push Notification Needs: [NOT NEEDED/BASIC ALERTS/RICH NOTIFICATIONS] Current PWA Status: [STARTING FRESH/UPGRADING EXISTING/ADDING TO SPA] Section 1 - Web App Manifest and Install Experience: Define the web app manifest configuration including the app name and short name, description, start URL with UTM tracking for installed usage analytics, display mode choosing between standalone and minimal-ui, theme color and background color, and comprehensive icon set covering all required sizes from 192 to 512 pixels including maskable icons for adaptive icon support on Android. Create the install prompt strategy using the beforeinstallprompt event to show a custom in-app install banner at an optimal moment such as after the user completes a valuable action rather than immediately on first visit. Establish the installed app experience optimizations including hiding browser-specific UI elements when running in standalone mode using the display-mode media query and handling the window controls overlay for desktop PWAs. Specify the app shortcuts configuration defining three to four quick actions accessible from the app icon long press that deep link into key features. Address the cross-browser install experience differences between Chrome, Safari, Firefox, and Edge including how to provide platform-specific installation guidance for browsers that handle PWA installation differently. Section 2 - Service Worker Architecture: Design the service worker lifecycle management including the registration strategy during page load, the update detection and notification approach for informing users a new version is available, and the skipWaiting and clients.claim strategy for activating updates. Define the caching strategy architecture using the Cache API with specific strategies for different resource types including cache-first for static assets like CSS, JavaScript, and fonts, network-first for API responses where freshness matters, stale-while-revalidate for content that can show slightly outdated data while refreshing in the background, and cache-only for the app shell resources. Create the precaching manifest specifying which resources should be precached during service worker installation to enable instant subsequent page loads and which should be cached lazily on first use. Specify the cache versioning and cleanup strategy including how to name cache instances with version prefixes, how to delete stale caches during service worker activation, and how to limit cache size using a least-recently-used eviction policy. Address the service worker debugging approach using Chrome DevTools Application panel for inspecting cached resources, simulating offline mode, and manually triggering service worker lifecycle events. Section 3 - Offline Experience Design: Design the offline page architecture including a dedicated offline fallback page that is cached during installation and served when the user navigates to a page that is not cached while offline. Create the offline content availability strategy specifying which content is automatically cached for offline access during normal usage and how to let users explicitly save content for offline reading or use. Establish the offline state detection and UI adaptation system using the navigator.onLine property and online and offline events to show a connectivity status indicator and adapt the interface to indicate which features are available offline. Specify the offline form handling approach where form submissions are queued in IndexedDB when offline and automatically submitted when connectivity returns with conflict resolution for data that may have changed on the server. Address the offline asset management including which images, fonts, and media files to cache and how to display graceful placeholders when requested assets are not available in the cache. Section 4 - Background Sync and Push Notifications: Define the Background Sync API implementation for deferring actions like form submissions, content uploads, and data synchronization until the device has a stable network connection. Create the periodic background sync strategy for keeping cached content fresh by running background fetch operations at defined intervals when the browser permits based on site engagement scores. Design the push notification architecture including the push subscription management using the Push API with VAPID keys, the notification permission request strategy presented at a contextual moment after user engagement rather than on first visit, and the server-side push service integration. Specify the notification design system including notification title and body templates, action buttons for common responses, notification grouping for multiple related notifications, and badge and icon assets. Address the notification analytics tracking including delivery rates, open rates, action button click rates, and the opt-in and opt-out flow management. Section 5 - Data Synchronization and Storage: Design the IndexedDB storage architecture for structured offline data including the database schema, object store definitions with proper indexing for efficient queries, and version migration handling for schema updates. Create the data synchronization protocol that handles the conflict resolution between offline changes and server-side changes including timestamp-based resolution, user-prompted resolution for conflicting edits, and automatic merging for non-conflicting changes. Establish the storage quota management system that monitors available storage using the StorageManager API, implements data priority levels for eviction when space is limited, and requests persistent storage permission for critical data. Specify the data serialization approach for storing complex objects including how to handle dates, binary data like images, and circular references in IndexedDB. Address the multi-tab synchronization challenge ensuring that changes made in one tab are reflected in other tabs using BroadcastChannel or the storage event and that multiple tabs do not create conflicting service worker states. Section 6 - Performance, Testing, and Deployment: Define the Lighthouse PWA audit targets specifying the scores to achieve for each category and the specific criteria that must pass including HTTPS, service worker registration, valid manifest, and offline capability. Create the PWA testing strategy including how to test offline functionality by simulating network disconnection, how to test push notifications in development, and how to verify the install experience across different platforms. Establish the deployment strategy for service worker updates including how to version the service worker file, how to handle the update notification UX when a new version is available, and how to force-update in emergency situations. Specify the cross-browser compatibility testing requirements as PWA support varies significantly between Chrome, Safari, Firefox, and Samsung Internet. Address the analytics integration for tracking PWA-specific metrics including install rates, offline usage sessions, push notification engagement, and the performance difference between browser and installed app usage.
Or press ⌘C to copy