What Is a Service Worker?
A service worker is a script that a browser runs in the background, separate from a web page, acting as a programmable proxy between the site and the network. It enables features that once required a native app: offline access, faster repeat loads through caching, background sync, and push notifications. Because a service worker sits between your site and the internet, it can intercept network requests and serve cached responses, which is the foundation of Progressive Web Apps. It runs only over HTTPS for security.
- What it is
- A background browser script acting as a network proxy
- Enables
- Offline access, caching, background sync, push notifications
- Requires
- HTTPS (except localhost) for security (MDN Web Docs)
- Powers
- Progressive Web Apps (PWAs)
- Lifecycle
- Register, install, activate, then intercepts fetch events
- Limitation
- No direct DOM access; communicates via messages
What a service worker does #
A service worker is a special JavaScript file the browser runs separately from any web page, in the background, even when your site is not open in a visible tab. Its defining power is acting as a programmable proxy: it can intercept the network requests your site makes and decide how to respond, from the network, from a cache it controls, or a mix. That single ability underpins a set of app-like features the web previously lacked. A returning visitor can see content instantly from cache, a site can work with no connection, and a business can send push notifications to re-engage users. Service workers run on their own thread, so they do not block the page's responsiveness, and they cannot directly touch the page's content, communicating instead through messages. They're the engine behind Progressive Web Apps, and they're increasingly relevant to /services/speed-optimization because well-designed caching can make repeat visits dramatically faster without changing anything visitors see on the page itself.
The lifecycle: register, install, activate #
Service workers follow a defined lifecycle that's worth understanding because it explains some of their quirks. First, a page registers the service worker, pointing the browser at its script file. The browser then installs it, a good moment to pre-cache essential files. Next it activates, at which point it can start controlling pages and cleaning up old caches from previous versions. Only after activation does it begin intercepting requests. A subtle point catches many developers: a newly registered service worker often does not control the current page load, it takes over on the next visit, and an updated service worker waits until all old tabs close before activating, unless the code explicitly tells it to take over immediately. This cautious, staged process exists to avoid abruptly changing behavior mid-session. It also means service-worker updates can appear to lag, which is normal. Grasping this lifecycle prevents confusion when changes to a service worker do not seem to take effect right away during /services/web-app-development.
Intercepting requests and caching #
A service worker listens for fetch events and can answer them from a cache before hitting the network.
// sw.js - cache files during install
self.addEventListener('install', event => {
event.waitUntil(
caches.open('v1').then(cache =>
cache.addAll(['/', '/styles.css', '/app.js'])
)
);
});
// answer requests from cache, fall back to network
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(cached => cached || fetch(event.request))
);
});How offline mode works #
The most visible service-worker feature is making a site work without a connection. The mechanism is straightforward once the pieces click. During installation, the service worker stores key files, HTML, CSS, JavaScript, images, in the browser's Cache Storage. Afterward, every network request the page makes passes through the service worker's fetch handler. When the device is offline, instead of the browser showing its error page, the service worker serves the cached copies, so the site still loads and functions. Developers choose caching strategies to balance freshness and reliability: 'cache first' for speed on stable assets, 'network first' for content that changes often, with cache as a fallback. A common touch is a custom offline page shown when a request cannot be served at all. This is why a well-built Progressive Web App feels resilient on a spotty connection. For businesses whose customers are often mobile, field services, transit, rural areas, offline capability can turn a frustrating experience into a dependable one.
Push notifications and background sync #
Beyond offline access, service workers unlock two engagement features that used to require native apps. Push notifications let a site, with the user's permission, deliver messages even when the site is not open, an order update, a reminder, a new-content alert. Because the service worker runs in the background, it can receive a push from a server and display a system notification, then open the relevant page when tapped. Background sync addresses flaky connections: if a user submits something while offline, a form, a comment, an order, the service worker can hold the action and retry automatically once connectivity returns, so nothing is lost. Both features must be used with restraint; aggressive notification prompts annoy visitors and hurt trust, and browsers increasingly limit pushy behavior. Used thoughtfully, though, they let a website re-engage customers and behave reliably in the real world of dropped signals. These capabilities are often the business case that justifies turning a standard site into a Progressive Web App during a /services/website-redesign.
Service workers and Progressive Web Apps #
Service workers are the technical heart of Progressive Web Apps, or PWAs, websites that behave like installed applications. A PWA combines a service worker with a small file called a web app manifest, which describes the app's name, icon, and display settings. Together they let a site be added to a phone's home screen, launch full-screen without browser chrome, work offline, and send notifications, all without an app-store download or install. For a small business, a PWA can be an appealing middle path: much of the feel of a native app at a fraction of the cost, delivered through the same website you already maintain, with no app-store fees or approval delays. It's not right for every project; apps needing deep device integration still call for native development. But for content, booking, ordering, and account-style experiences, a PWA often suffices. If an app-like experience is on your wish list, discussing a PWA during /services/web-app-development is usually worth doing before committing to costlier native builds.
Security and constraints #
Service workers are powerful enough to intercept all of a site's network traffic, so browsers wrap them in strict safeguards. The most important is that they only run over HTTPS, with localhost exempted for development. This prevents an attacker on an insecure connection from injecting a malicious service worker that could hijack requests, a real risk given what these scripts can do. Service workers also cannot access the page's DOM directly; they live in a separate context and exchange messages with pages, which keeps their capabilities contained. They're scoped to a path, so a service worker controls only the part of the site it was registered under. And they can be stopped and restarted by the browser to save resources, meaning they cannot rely on staying alive between events. These constraints exist to keep a genuinely capable technology safe. For any site adopting one, having HTTPS properly in place is a prerequisite and a natural part of broader /services/website-security.
Common pitfalls to watch for #
Service workers reward care and punish carelessness. The most notorious pitfall is caching too aggressively: if a service worker serves stale files, visitors can be stuck seeing an old version of your site long after you've updated it, sometimes needing to clear browser data to escape. Getting the update-and-cache strategy right, versioning caches and cleaning up old ones on activation, is essential. Another trap is the lifecycle surprise, where a new service worker does not take control until existing tabs close, making changes seem not to deploy. Debugging is trickier too, since the worker runs separately from the page. And a broken service worker can, in the worst case, break the site for returning visitors until fixed. None of this makes them dangerous when handled by someone experienced, but it's why a service worker should not be added casually. Ongoing attention through a /services/care-plans arrangement helps ensure caching stays correct as the site changes over time.
When your site benefits from one #
Deciding whether your site needs a service worker comes down to whether its specific superpowers match your customers' needs. The strongest cases are practical: a site used heavily on mobile or in areas with patchy connections, where offline access and fast cached loads genuinely improve the experience; a business that would benefit from re-engaging visitors through push notifications; or a product you want to feel like an installed app without the cost and friction of native development. For those situations, a service worker powering a Progressive Web App can be a smart, cost-effective step, often explored during a /services/website-redesign. For a straightforward brochure or marketing site, though, a service worker adds complexity and caching pitfalls with little upside, so it is usually not worth it. As with most of these technologies, the right question is not whether it is impressive but whether it solves a problem you actually have. When it does, it is powerful; when it does not, a clean, fast standard site serves you better.
FAQ
Do I need a service worker for my website?
Not for a standard site. Regular websites work fine without one. A service worker matters when you want offline access, app-like caching, push notifications, or a Progressive Web App. If those features would genuinely help your customers, say, an ordering app used on the move, it's worth adding; otherwise a normal site is simpler and perfectly capable.
Does a service worker make my site faster?
It can speed up repeat visits significantly by serving cached files instantly instead of re-downloading them. The first visit is not faster, and poor caching can cause stale-content problems, so the benefit depends on careful setup. For returning-visitor performance it's a strong tool, complementing broader speed-optimization work rather than replacing it.
Why does a service worker require HTTPS?
Because it can intercept all of a site's network requests, a service worker is a security-sensitive tool. Requiring HTTPS prevents attackers on insecure connections from injecting a malicious one that could hijack traffic. The only exception is localhost, used during development. In short, the requirement protects both you and your visitors from a serious class of attack.
What is a Progressive Web App?
A Progressive Web App is a website that behaves like an installed app, it can be added to a home screen, launch full-screen, work offline, and send notifications. It combines a service worker with a web app manifest. PWAs deliver much of a native app's feel through your website, without an app-store download, at lower cost.
Can a service worker track me or access my files?
No. A service worker runs in the browser's secure sandbox with no access to your files or system. It can cache the site's own resources and, only with your permission, handle push notifications. It cannot read your disk or spy beyond the site it belongs to. Browser rules strictly limit what it can do.
Why am I still seeing an old version of a site?
A service worker may be serving cached files. If a site cached content too aggressively or its update logic is flawed, returning visitors can see a stale version until the cache refreshes or they clear browser data. It's a common service-worker pitfall, fixed by correcting the caching and versioning strategy, not by anything you did wrong.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?