w3c/serviceworker

Service Workers

View on GitHub ↗Jump to charts ↓Open shareable report

Summary Information

Updated 43 minutes ago
Type:Documentation / SpecificationCategory(s):Browsers & ExtensionsDocumentation ToolsWeb Development
Added to GitGenius on September 19th, 2026
Created on February 7th, 2013
Open Issues & Pull Requests: 263 (+0)
GitHub issues: Enabled
Number of forks: 324
Total Stargazers: 3,635 (+0)
Total Subscribers: 200 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 13.0 hours
Mean response time: 416.9 days
90th percentile: 2596.8 days
Tracked items: 258

Most active contributors

Sign in to see contributor activity.

How this project is maintained

54% of open issues come from outside the core team, a mix of external reports and the maintainers' own roadmap. Three people close 84% of everything that gets resolved.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 137
New in 7 days: 0
Closed in 7 days: 1
Avg open age: 2,559 days
Stale 30+ days: 121
Stale 90+ days: 92

Recent activity

Opened in 7 days: 0
Closed in 7 days: 1
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • apr-2017-f2f (21)
  • TPAC2025 (9)
  • apr-2017-f2f-v1 (9)
  • TPAC2026 (8)
  • cache (8)
  • enhancement (8)
  • question (5)
  • decided (4)

Detailed Description

Service workers solve the problem of building reliable offline-capable web applications by providing scriptable primitives that replace the earlier HTML5 Application Cache. They run independently of web pages and can respond to network requests through a cache layer, allowing applications to function without connectivity. The approach uses Promises extensively to enable developers to build layered, URL-friendly applications with fine-grained control over caching and network behavior.

This specification is relevant for browser implementers and web developers building applications that need offline support or advanced network handling. The repository maintains two specification tracks: a nightly living document reflecting the latest requirements and features, and a stable version focused on bug fixes and compatibility without new features. Contributors should engage through GitHub issues for spec development or the public-webapps mailing list for broader discussion. Edits are made to the Bikeshed source file and submitted with corresponding HTML output.

The project operates as a collaborative standards effort with structured issue triage using labels and milestones. Spec updates are tied to resolved issues marked for specification work. The repository accepts pull requests against the master branch and maintains both a cutting-edge nightly specification and a more conservative stable release track to serve different implementer and developer needs.