AEM and PWA: Offline Content Delivery with Service Workers

AEM sites increasingly serve people who expect fast, app-like experiences across phones, tablets and laptops. A progressive web app (PWA) adds an installable front end, responsive interactions and resilient content delivery, while Adobe Experience Manager remains responsible for authoring, workflow, personalisation and asset governance.

Service workers provide the technical bridge between those two layers. They run independently of the browser page, intercept network requests and decide whether a response should come from a local cache, the network or a fallback experience. With the right strategy, an AEM-powered PWA can continue displaying useful content when a connection is slow, intermittent or unavailable.

This matters in Australia, where a user may move between reliable fibre in Melbourne, a crowded Sydney train platform and patchy coverage on a regional road. A well-designed offline mode should not pretend that every page is current. It should clearly distinguish cached information from newly synchronised content while preserving the essential journey.

How AEM And Service Workers Fit Together

AEM supplies structured content, rendered pages, GraphQL responses, images and client-side assets. Content authors work in familiar environments, while the PWA consumes published output through APIs or carefully designed HTML endpoints. The service worker sits in the browser and manages requests after the application has been loaded once.

This separation is important because a service worker should not become a second content management system. AEM remains the source of truth, and the browser stores a controlled subset of published material. The front end can cache an application shell—navigation, styles, JavaScript and offline artwork—then request content as needed. Frequently used articles, product details or forms can receive a longer offline life if the business case supports it.

AEM Dispatcher and a CDN still matter. They reduce origin load and improve network performance before the browser cache is involved. Cache headers, URL versioning and invalidation rules must align across AEM, Dispatcher, the CDN and the service worker. If each layer applies different freshness assumptions, users can receive a mixture of current navigation and obsolete page content.

Designing A Useful Offline Content Model

Offline delivery starts with content priorities rather than caching every response. A retailer might cache store hours, product specifications and previously viewed items. A tourism organisation could preserve attraction details and emergency contacts for travellers with unreliable reception. A financial service may allow access to general guidance while refusing to store sensitive account data on a shared device.

A practical model commonly uses three tiers. The application shell can use a cache-first approach because it needs to open immediately. Stable assets such as logos and fonts can use a cache-first or stale-while-revalidate strategy. Dynamic AEM content usually benefits from network-first delivery, with a clearly labelled cached response when the request fails. This prevents old prices, availability or campaign messages from appearing indistinguishable from live information.

Structured content makes those decisions easier. AEM components can expose metadata such as publication time, expiry time, content type and offline eligibility. The PWA can then cache an article but reject an expired promotion. When importing large content sets into AEM, teams can also use CSV and XLS imports to establish consistent fields and identifiers that support predictable synchronisation.

Service Worker Caching Patterns

The service worker lifecycle has several stages: installation, activation, request interception and background updates. During installation, the worker can pre-cache essential shell resources. During activation, it should remove obsolete cache versions and take control carefully, since immediately replacing an active worker can change behaviour while a user is completing a transaction.

Cache names should include an application or release version, but versioning alone is not an invalidation strategy. A new deployment needs a process for identifying changed content and assets. Hashed JavaScript and CSS filenames help with static files, while API responses may require time-to-live values, ETags or explicit revision identifiers from AEM. The browser should never be forced to guess whether a page has changed.

Different request types deserve different strategies. A navigation request may try the network first and fall back to an offline document. Images can use stale-while-revalidate to display quickly and refresh quietly. A POST request should never be replayed automatically without a deliberate queueing design, especially where it could create duplicate orders or payments. Background Sync can help retry safe operations, but the server still needs idempotency keys and clear conflict handling.

Offline pages should communicate status plainly. “Saved on Tuesday at 3:15 pm” is more useful than a generic loading indicator. Users should be able to refresh when connected, remove stored data and understand which actions require a network connection. This is especially relevant on shared family devices or workplace tablets.

Performance, Security And Australian Requirements

The PWA should be tested against realistic Australian conditions rather than an ideal office connection. Simulate a slow 4G connection, a tunnel commute, a regional network drop and a device with limited storage. Measure first load, repeat load, cache hit rate, time to usable content and the size of the offline bundle. Large AEM assets, uncompressed images and unnecessary personalisation requests can quickly undermine the benefit of local caching.

Security deserves equal attention. Service workers require HTTPS, and their scope must be restricted to the application paths they actually control. Avoid putting access tokens, payment details, health information or unnecessary personal data into Cache Storage or IndexedDB. Apply a strict Content Security Policy, review third-party scripts and clear local data when a user signs out. A cached response can remain available after the server session has ended, so logout behaviour must include client-side storage cleanup.

Australian organisations should account for the Privacy Act 1988 and the Australian Privacy Principles when deciding what information is retained offline. A consent banner does not automatically justify storing identifiable browsing or customer data on a device. Retention periods, access controls, breach response and cross-border data flows should be documented, particularly when CDN, analytics or cloud services process information outside Australia.

Accessibility must remain part of the offline design. Australian government and enterprise projects frequently align with WCAG expectations, and the offline experience should preserve keyboard access, readable contrast, focus management and meaningful status messages. A cached shell that loads quickly but hides an unavailable form behind an inaccessible error state is not a resilient experience.

Connecting Offline Delivery To AEM Operations

AEM teams need an operational agreement covering publishing, cache invalidation, release sequencing and rollback. When an author activates a page, the change may pass through AEM publish, Dispatcher, a CDN and then a user’s local cache. Each layer needs an observable path. Logs and dashboards should show whether content was served by the origin, edge cache or service worker, while respecting privacy requirements.

Preview and author environments should not accidentally register the production service worker. A common safeguard is to enable offline functionality only on approved publish domains and to use separate cache names for development, staging and production. Automated tests can verify that a release installs cleanly, removes outdated assets and displays the correct fallback when AEM is unreachable.

AEM’s content fragments and headless delivery options can support a clean API-driven architecture, but offline synchronisation still needs boundaries. Define which endpoints are cacheable, how pagination works, how deleted content is removed and what happens when a fragment changes while a device is offline. For mobile applications and PWAs, these AEM caching strategies provide useful context for aligning browser storage with broader delivery layers.

Analytics should record offline events locally and send them later only when consent and data-minimisation rules permit. Duplicate events are possible after retries, so event identifiers and server-side deduplication are valuable. Teams should monitor cache misses, failed synchronisation, stale-content displays and storage quota errors instead of relying solely on page views.

For an AEM project, begin with one high-value offline journey rather than attempting to make the whole site available without a connection. Map its content dependencies, classify data by sensitivity and freshness, then implement a small service worker with explicit caching rules. Test it across metropolitan and regional network conditions, validate privacy and accessibility controls, and measure whether users can complete the intended task. A focused pilot can then guide wider rollout across the content estate.