What happens when your website isn't available offline?
A news site loses 40% of returning readers when articles fail to load on the subway. A fintech dashboard becomes useless during a commute. PWA app development solves that by turning your website into an installable application that works without internet, sends push notifications, and loads instantly. One codebase replaces two native teams. Over 7 years we have delivered 30+ PWA projects for e-commerce, fintech, and enterprise portals — each with measurable business impact. Contact us for a free PWA readiness assessment — we will audit your current application and estimate the effort.
How does Service Worker manage network requests?
Service Worker — a JavaScript proxy running in a separate thread — intercepts every HTTP request and decides the response source: cache, network, or a mix. Three core strategies solve most real-world scenarios.
| Caching strategy | Typical assets | Offline behavior |
|---|---|---|
| Cache First | JS/CSS with content hash (e.g. main.a1b2c3.js) |
Instant load from cache |
| Network First | API calls for orders, payments | Live data on success, cached fallback on failure |
| Stale While Revalidate | News feeds, search results | Immediate cache, then background update |
Assets with content hashes never change — they can be cached permanently. Stale While Revalidate gives instant response while keeping data fresh within seconds. Google's Workbox automates versioning and cache invalidation; without it a correct Service Worker would require 300+ lines of code. Vite + vite-plugin-pwa generates a production-ready Service Worker from a few lines of config:
import { VitePWA } from 'vite-plugin-pwa';
export default {
plugins: [
VitePWA({
registerType: 'autoUpdate',
includeAssets: ['favicon.ico'],
manifest: { /* name, icons, start_url, display */ },
workbox: {
globPatterns: ['**/*.{js,css,html,ico,png,svg}'],
runtimeCaching: [
{ urlPattern: /^https?:\/\/api\./,
handler: 'NetworkFirst',
options: { cacheName: 'api-cache' }
}
]
}
})
];
};
How is offline mode implemented in practice?
"Works offline" means different things for a news site vs. a CRM. Three typical scenarios:
- Offline reading (news, docs): Service Worker caches pages on first visit — Stale While Revalidate + Background Sync restores queued interactions when connectivity returns.
- Offline editing (notes, tasks): IndexedDB stores local data, Background Sync API queues operations and pushes them automatically even if the browser tab is closed. Limitation: Background Sync is supported only in Chromium (~84% of desktop and mobile users).
- Offline forms: user taps 'Send' without internet — data is preserved in IndexedDB and submitted when the connection is restored. Critical for medical and insurance claim forms.
One commonly underestimated problem: sync conflicts. If user A edits a record offline and user B changes it online, a resolution strategy (last-write-wins, three-way merge, or showing a conflict UI) must be designed upfront. We always address these scenarios during the architecture phase.
Common pitfalls we see in practice: lack of fallback UI (users see a white screen), wrong cache strategy for user-specific data (using Cache First for authenticated API calls), ignoring Service Worker scope (worker placed too deep), and skipping precache validation. Workbox automates cache versioning to avoid expired assets.
How do Web Push notifications work?
Web Push delivers messages through the browser's Push Service (FCM for Chrome/Edge, APNs for Safari). User grants permission → browser subscribes → you receive an endpoint and key → your backend sends a message via the web-push library (Node.js) or equivalent. VAPID keys are generated once, subscriptions stored in a database. iOS (16.4+) supports Web Push only for installed PWAs; Chrome/Firefox/Edge support it without installation. A/B testing send times and content is standard practice — irrelevant notifications cause churn rates above 30%.
Why choose PWA over native applications?
Building and maintaining native iOS and Android apps costs 2–3x more than a single PWA. One codebase, unified business logic, automatic updates — no App Store review delays. PWA lifts conversion by 36% on average (Google aggregated data). Web Push re-engages users at 4x the rate of email when messages are personalized. We have delivered PWA-solutions for high‑traffic e‑commerce platforms (12M monthly sessions) and enterprise fintech dashboards — each project included Core Web Vitals optimisation to pass Google's eligibility criteria. In our experience, PWA engagement metrics are 2–3x higher than mobile web alone, and push notification click-through rates are 7x better than email.
What does turnkey PWA development include?
| Stage | Result | Timeline |
|---|---|---|
| Audit of current application | PWA‑score report, scenario analysis | 1–2 days |
| Design of offline scenarios | Technical documentation, prototype | 2–3 days |
| Service Worker + manifest development | Production code, automated tests | 5–10 days |
| Web Push integration (optional) | Backend endpoint, subscription logic | 3–5 days |
| Testing on real devices | Compatibility report, fixes | 3–5 days |
| Deployment & documentation | Access, instructions, 1‑month warranty | 1–2 days |
Deliverables you receive
- Full source code (Service Worker, manifest, push backend) in your repository.
- Testing guide with Lighthouse audit results and real‑device reports.
- Push notification dashboard or API endpoint for your marketing team.
- Performance monitoring – instruction for checking Core Web Vitals after deployment.
- 1 month of post‑launch support – bug fixes and minor adjustments.
What is App Shell architecture?
App Shell pre‑caches the minimal HTML, CSS and JavaScript needed to render the application chrome on first load. After the shell is cached, subsequent visits render instantly even on slow or offline connections. This technique is paired with dynamic content loading for a native‑like experience.
Process and timeline (from audit to go‑live)
- Audit: Lighthouse PWA score, offline scenario analysis.
- Prioritise valuable offline use cases (based on user behaviour data).
- Configure Service Worker via Workbox, implement manifest.
- Integrate Web Push (if required).
- Test on real devices – Chrome DevTools, Safari Web Inspector, Android Chrome.
- Deploy, hand over documentation, train the team.
Estimated timelines: basic PWA (manifest + Service Worker + static cache) – 1–2 weeks on top of existing application. Add Web Push – 1–2 weeks. Offline editing with IndexedDB and Background Sync – 3–6 weeks depending on data complexity. Cost is calculated individually after a free audit. On average, a PWA project costs 40–60% less than building two native apps – and you save recurring App Store fees. Get in touch for a free consultation – we will assess your project and propose the optimal implementation plan.
Further reading
- MDN Web Docs: Service Worker API
- Wikipedia: Progressive Web Application
- Wikipedia: Service Worker