PWA Deep Dive: Automating Asset Manifests and Offline Service Workers

Over the last few years, the line between native mobile applications and web browsers has almost completely vanished. For many of my clients, launching a full native iOS or Android app is no longer their first choice. The development overhead of maintaining separate Swift and Kotlin codebases, coupled with the friction of app store submission processes, makes Progressive Web Apps (PWAs) a highly appealing alternative.

This is especially true in the digital wallet and micro-banking sectors. Users expect instant interactions, immediate view updates, and most importantly, the ability to view their account histories or run basic wallet operations even when they lose internet connection inside an elevator or on the subway.

Last year, I took over a project where an engineering team tried to build a mobile banking portal on WordPress. The layout was beautiful, but whenever a user transitioned to a weak cell coverage area (like 3G or a crowded transit hub), the app would freeze on a white screen or return a generic "no internet connection" browser page.

In this post-mortem, I will show you how we restructured this mobile dashboard into an offline-first PWA. We will bypass generic plugins and build a custom, automated caching framework from scratch, utilizing advanced Service Worker caching strategies, dynamic manifest generation, and offline event listeners.

Section 1: The Offline-First PWA Architecture

When building a high-performance web app, you cannot approach it like a traditional website. On a standard site, the browser requests assets from the network as the user navigates. If the network is down or slow, the interface lags or fails entirely.

An offline-first architecture changes this relationship. It treats the local disk, not the network, as the primary source of truth for the application's shell.

                                  +------------------------------------+
                                  |         User Interface (PWA)       |
                                  +------------------------------------+
                                                    |
                                      (Fetch requests intercepted)
                                                    v
                                  +------------------------------------+
                                  |           Service Worker           |
                                  +------------------------------------+
                                      /                            \
                        (Cache Hit)  /                              \  (Cache Miss)
                                    v                                v
                     +----------------------+              +----------------------+
                     |     Local Cache      |              |   Network API Endpoint|
                     |  (Static App Shell)  |              |   (Secure Database)  |
                     +----------------------+              +----------------------+

The application shell consists of the minimum HTML, CSS, JavaScript, and image assets required to render the user interface layout. Once a user visits the app for the first time, this shell is stored directly in the browser's Cache Storage. On all subsequent visits, the browser loads these assets instantly from the local cache, completely bypassing the network.

Only the actual transaction data—like account balances, transaction histories, and user profile information—is requested dynamically over the network. If the network request fails, the service worker returns the cached app shell and serves the last-known transaction data from an IndexedDB database, showing the user a clear "offline viewing" status instead of crashing.

Section 2: Building the App Shell from High-Fidelity UI Templates

To build a professional, responsive PWA, you need a highly polished mobile design system. For this project, our design team modeled the dashboard interfaces on the PayApp - Wallet & Banking PWA Mobile Template, which includes pre-built layouts for card balances, transactions, settings, and dynamic sliders.

Converting these high-fidelity design screens into a fast mobile app requires clean, lightweight markup. Instead of using a heavy WordPress theme that loads unnecessary styling libraries, we built the application shell using highly efficient, semantic HTML Templates served from our local service worker cache.

To keep our development speed up, I frequently use code resources from digital artifact hubs like GPLPal to audit and reconstruct base components. By sourcing verified mobile layouts from GPLPal, our dev team was able to prototype the dashboard interfaces in record time, ensuring the final HTML structures were clean and free of unnecessary layout wrappers.

Section 3: The Custom Service Worker Lifecycle and Caching Core

At the core of any PWA is the Service Worker. A service worker is a specialized, event-driven JavaScript file that runs in the background of the browser, completely separate from the main web page thread. It acts as a network proxy, intercepting every fetch request your application makes.

To learn more about how service workers operate, you can read the MDN Service Worker API documentation.

[Service Worker Lifecycle]
  Registration ---> Installation (Caching Shell) ---> Activation (Clearing Old Caches) ---> Fetch Interception

We chose a Cache-First strategy for our static application shell (CSS, JS, fonts, and icons) and a Network-First with local database fallback strategy for our transaction API routes.

Below is the production-grade sw.js service worker file we wrote to handle these caching mechanics:

/**
 * Custom PWA Service Worker for Mobile Wallets
 * Author: WP System Architect
 */

const CACHE_NAME = 'payapp-core-cache-v3';
const API_CACHE_NAME = 'payapp-api-cache-v1';

// Static App Shell assets to cache immediately during installation
const STATIC_ASSETS = [
    '/',
    '/index.html',
    '/assets/css/app-shell.css',
    '/assets/js/app-shell.js',
    '/assets/images/logo.svg',
    '/assets/fonts/inter-latin-400.woff2',
    '/assets/fonts/inter-latin-700.woff2',
    '/manifest.json'
];

// Install Event: Cache all critical app shell assets
self.addEventListener('install', (event) => {
    event.waitUntil(
        caches.open(CACHE_NAME)
            .then((cache) => {
                console.log('[Service Worker] Pre-caching static app shell assets...');
                return cache.addAll(STATIC_ASSETS);
            })
            .then(() => {
                // Force the waiting service worker to become the active service worker
                return self.skipWaiting();
            })
    );
});

// Activate Event: Clear out older cache versions to free up disk space
self.addEventListener('activate', (event) => {
    event.waitUntil(
        caches.keys().then((cacheNames) => {
            return Promise.all(
                cacheNames.map((cache) => {
                    if (cache !== CACHE_NAME && cache !== API_CACHE_NAME) {
                        console.log('[Service Worker] Cleaning up deprecated cache:', cache);
                        return caches.delete(cache);
                    }
                })
            );
        }).then(() => {
            // Claim all open browser windows immediately
            return self.clients.claim();
        })
    );
});

// Fetch Event: Intercept network requests and apply caching strategies
self.addEventListener('fetch', (event) => {
    const request = event.request;
    const url = new URL(request.url);

    // 1. Transactional API Request Handling (Network-First, Cache Fallback)
    if (url.pathname.startsWith('/wp-json/payapp/v1/')) {
        event.respondWith(
            fetch(request)
                .then((response) => {
                    // Clone the response to write it to our local API cache
                    const responseClone = response.clone();
                    caches.open(API_CACHE_NAME).then((cache) => {
                        cache.put(request, responseClone);
                    });
                    return response;
                })
                .catch(() => {
                    // Network failed, attempt to return the last-known cached transaction data
                    return caches.match(request).then((cachedResponse) => {
                        if (cachedResponse) {
                            return cachedResponse;
                        }
                        // Return a fallback JSON response indicating the offline status
                        return new Response(JSON.stringify({
                            status: 'offline',
                            message: 'Network connection lost. Showing cached data.'
                        }), {
                            headers: { 'Content-Type': 'application/json' }
                        });
                    });
                })
        );
        return;
    }

    // 2. Static Asset Handling (Cache-First, Network Fallback)
    event.respondWith(
        caches.match(request)
            .then((cachedResponse) => {
                if (cachedResponse) {
                    return cachedResponse;
                }

                // If asset is not in cache, request it over the network
                return fetch(request).then((networkResponse) => {
                    // Only cache valid standard GET requests
                    if (!networkResponse || networkResponse.status !== 200 || networkResponse.type !== 'basic') {
                        return networkResponse;
                    }

                    const responseToCache = networkResponse.clone();
                    caches.open(CACHE_NAME).then((cache) => {
                        cache.put(request, responseToCache);
                    });

                    return networkResponse;
                });
            })
    );
});

Section 4: Generating Manifest Files Dynamically in WordPress

A web app needs a manifest.json file for browsers to recognize it as a PWA. This file tells the mobile operating system how to display the app when installed on a user's device, including setting the theme colors, background colors, custom icons, and start URL.

Hardcoding a manifest file is not ideal if you need to update theme settings, change splash screens, or modify paths dynamically. To keep things flexible, we built a custom PHP class inside our active WordPress theme to generate the manifest file dynamically based on our system parameters:

 'PayApp',
            'name'             => 'PayApp Mobile Wallet & Banking App',
            'description'      => 'Secure, high-velocity digital mobile banking portal.',
            'icons'            => [
                [
                    'src'   => esc_url( get_theme_file_uri( '/assets/images/icon-192x192.png' ) ),
                    'type'  => 'image/png',
                    'sizes' => '192x192',
                    'purpose' => 'any maskable'
                ],
                [
                    'src'   => esc_url( get_theme_file_uri( '/assets/images/icon-512x512.png' ) ),
                    'type'  => 'image/png',
                    'sizes' => '512x512',
                    'purpose' => 'any'
                ]
            ],
            'start_url'        => '/',
            'background_color' => '#0052cc', // Custom banking brand theme color
            'theme_color'      => '#ffffff',
            'display'          => 'standalone',
            'orientation'      => 'portrait',
            'prefer_related_applications' => false
        ];

    echo json_encode( $manifest_data, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT );
    exit;
}

}
new PayApp_PWA_Manifest_Generator();

After adding this class to your functions.php or dynamic core utility plugins, make sure to visit Settings > Permalinks in your WordPress dashboard and click "Save Changes". This flushes the database rewrite rules so WordPress can route the dynamic manifest path correctly.

Section 5: Handling Offline Connection Changes Smoothly

An offline-first PWA should keep the user informed about their connection status. If a user tries to transfer funds or update their profile while offline, we want to intercept the action, save it locally, and notify them that their update is pending synchronization.

                              +---------------------------+
                              |   On-Screen Status Banner |
                              +---------------------------+
                                            ^
                         (Network Change)   |   (Network Restore)
                                            v
+------------------------+      +-------------------------+      +------------------------+
|  User loses cellular  | ---> |   Trigger Offline Event | ---> |  Queue request in      |
|  connectivity          |      |   Update UI theme state |      |  IndexedDB cache       |
+------------------------+      +-------------------------+      +------------------------+

Here is the helper script we wrote to monitor the browser's connectivity status and display an interactive notice when the device loses connection:

/**
 * PWA Connectivity Sync Engine
 * Author: WP System Architect
 */

class ConnectivityEngine {
    constructor() {
        this.isOnline = navigator.onLine;
        this.offlineQueue = [];
        this.init();
    }

    init() {
        // Register browser-level connectivity event listeners
        window.addEventListener('online', () => this.handleNetworkRestored());
        window.addEventListener('offline', () => this.handleNetworkLost());

        // Initial connection check
        if (!this.isOnline) {
            this.applyOfflineStyles();
        }
    }

    handleNetworkLost() {
        this.isOnline = false;
        this.applyOfflineStyles();
        this.showNetworkNotice('Connection lost. You are now browsing in offline mode.');
    }

    handleNetworkRestored() {
        this.isOnline = true;
        this.removeOfflineStyles();
        this.showNetworkNotice('Connection restored! Synchronizing your wallet records...', true);
        this.processPendingQueue();
    }

    applyOfflineStyles() {
        document.body.classList.add('pwa-offline-mode');
        // Apply an overlay indicator to signify restricted actions
        const overlay = document.createElement('div');
        overlay.id = 'pwa-offline-banner';
        overlay.innerHTML = `
            <div class="banner-inner" style="background:#cc0000; color:#fff; padding:10px; text-align:center; font-weight:bold;">
                Offline Mode Active - Data Displayed is Cached
            </div>
        `;
        document.body.insertBefore(overlay, document.body.firstChild);
    }

    removeOfflineStyles() {
        document.body.classList.remove('pwa-offline-mode');
        const banner = document.getElementById('pwa-offline-banner');
        if (banner) {
            banner.remove();
        }
    }

    showNetworkNotice(text, isTemporary = false) {
        console.log(`[PWA Notify] ${text}`);
        // Render a toast notification in the user interface
        const toast = document.createElement('div');
        toast.className = 'pwa-toast-notification';
        toast.innerText = text;
        toast.style.cssText = 'position:fixed; bottom:20px; left:50%; transform:translateX(-50%); background:#333; color:#fff; padding:12px 24px; border-radius:30px; z-index:9999; box-shadow:0 4px 10px rgba(0,0,0,0.3);';

        document.body.appendChild(toast);

        if (isTemporary) {
            setTimeout(() => {
                toast.style.transition = 'opacity 0.5s ease';
                toast.style.opacity = '0';
                setTimeout(() => toast.remove(), 500);
            }, 3000);
        }
    }

    /**
     * Process cached operations stored during connection loss
     */
    processPendingQueue() {
        if (this.offlineQueue.length === 0) return;

        console.log(`[PWA Sync] Processing ${this.offlineQueue.length} pending operations...`);
        // Loop through the queued actions and post them to our database APIs
        while (this.offlineQueue.length > 0) {
            const pendingAction = this.offlineQueue.shift();
            this.sendPayload(pendingAction.endpoint, pendingAction.payload);
        }
    }

    sendPayload(endpoint, payload) {
        fetch(endpoint, {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify(payload)
        })
        .then(response => response.json())
        .then(data => console.log('[PWA Sync] Sync successful:', data))
        .catch(err => console.error('[PWA Sync] Sync execution failed, returning to queue:', err));
    }
}

// Instantiate the engine on page load
document.addEventListener('DOMContentLoaded', () => {
    window.AppConnectivity = new ConnectivityEngine();
});

Section 6: Building Offline User Engagement Options

When your app detects a complete connection loss, you should keep users engaged while they wait for their signal to return.

Instead of showing a blank error screen or letting them navigate away to another app, you can offer lightweight, offline-friendly tools or games. To provide this kind of experience on our dashboard, we cached some ready to use HTML5 games for website folders. Because these games are built with clean JavaScript and HTML5 Canvas, we can cache them directly in our service worker static assets array.

When a user is offline, our application displays an option to play a quick game. This runs completely locally in the browser, keeping the user engaged without placing any extra load on your primary transaction processing database.

Section 7: Post-Mortem Benchmark Metrics and Performance Audit

After rebuilding our mobile app shell, implementing the dynamic manifest generator, and configuring our service worker caching strategies, we ran a series of performance audits.

Below is a comparison of our performance metrics before and after the PWA optimization process:

Moving to an offline-first architecture requires a shift in how you plan your layouts and database queries. By separating your presentation layer from your dynamic API data, configuring a reliable service worker, and building custom asset pipelines, you can deliver a native-app-like experience in the browser.

Avoid relying on bloated plugins to manage your PWA configurations. Take control of your service worker's caching lifecycle, keep your app shell lightweight, and write custom integration scripts. This ensures your mobile application remains fast, secure, and accessible to your users under all network conditions.