WP Manifestindependent plugin directory
manifest / performance / wp-offline-sync

WP Offline Sync

A WordPress plugin that enables offline access and synchronization for WordPress sites. It uses a service worker and client-side scripts to cache site content for offline viewing and automatically syncs updates when the user is back online. Ideal for improving site reliability and user experience in low or intermittent connectivity environments.

by Kavit Trivedi · github.com/trivedikavit/wp-offline-sync

★ 0stars
0forks

Install

No release zip yet. The repository archive installs, but the folder name will carry the branch suffix and updates will not flow:

wp plugin install https://github.com/trivedikavit/wp-offline-sync/archive/refs/heads/trivedikavit%2Flocal.zip

Requires WordPress: 5.9+
Requires PHP: 7.4+

Overview

WP Offline Sync is a WordPress plugin that delivers near-instant page loads and offline resilience by caching your site's HTML pages and optionally, static assets directly in the visitor's browser. It uses the modern Service Worker API, IndexedDB, and the CacheStorage API to build a persistent, intelligent client-side cache that works entirely without a server-side caching layer.

How It Works

Service Worker

When a visitor loads your site for the first time, WP Offline Sync registers a Service Worker (/?wp_offline_sync_sw=1) scoped to the site's base path. For single sites and subdomain multisite installs this is / (the domain root). For subdirectory multisite installs this is the subsite path without a trailing slash (e.g. /site-1), which ensures the Service Worker intercepts both the bare subdirectory URL (/site-1) and all URLs beneath it (/site-1/). The Service Worker intercepts every subsequent navigation request and asset request, serving responses from the local cache when possible and fetching from the network in the background to keep the cache fresh.

The Service Worker is served via a query-string URL (/?wp_offline_sync_sw=1) rather than a pretty path like /wp-offline-sync-sw.js. This ensures the request always passes through PHP/WordPress on nginx servers, which would otherwise try to serve .js files as static files and return a 404. The SW file is generated dynamically by PHP and prepended with a WP_OFFLINE_SYNC_CONFIG JavaScript object containing the current plugin settings (TTL, max entries, etc.). An ETag header is computed from the config and the file's modification time, so the Service Worker is only re-installed when something actually changes.

Page Caching (IndexedDB - Stale-While-Revalidate)

HTML page responses are stored in IndexedDB under the database name wp-offline-sync, in an object store called pages. Each record contains:

  • url - the full page URL (used as the primary key)
  • html - the full HTML string of the page
  • checksum - an FNV-1a 32-bit hash used to detect whether content has actually changed
  • lastFetched - Unix timestamp of the last network fetch
  • metadata.title - the page <title> extracted from the HTML

Stale-while-revalidate strategy: When a cached page is requested and it is not yet expired (within the configured TTL), the cached HTML is served instantly while a background network fetch silently refreshes the cache. If the cache entry is stale or missing, the network is hit directly and the response is stored for the next visit.

Offline fallback: If the user is completely offline and no cached version exists, a friendly offline page is shown.

Asset Caching (Cache API - Stale-While-Revalidate)

Same-origin static assets (CSS, JavaScript, images, fonts, and more) are cached using the browser's Cache API in a bucket named wp-offline-sync-assets. The same stale-while-revalidate pattern applies: cached assets are served immediately while the network revalidates them in the background.

When the Service Worker prefetches or serves an HTML page, it parses the HTML to discover referenced assets (<link href>, `