Dear all, Thank you all for the incredibly valuable and constructive feedback on the Intent to Deprecate the Background Fetch API.
We have taken all the points raised to heart, especially the concerns from Rick about the UseCounter being potentially misleading, Thomas's mention of key use cases like large AI model downloads, and Jxck's perspective as an actual user of the API. Your points, combined with the new information we've gathered from Barry's HTTP Archive results and Vincent's email, have led us to reassess the API's importance and the potential impact of its removal. Based on this, we have concluded that the Background Fetch API is more critical to the web platform than its current usage metrics initially suggested. Therefore, we are formally withdrawing this Intent to Deprecate the Background Fetch API. We appreciate the thorough discussion and your input on this topic, as the feedback clearly highlighted the value this API provides for a small but critical set of use cases. The API will remain in Chrome, and we will work with the community on its future status. Thank you again, Yoshisato 2025年11月28日(金) 20:48 Barry Pollard <[email protected]>: > If it helps, I ran a query on the HTTP Archive on the > backgroundFetch.fetch string in scripts. This measures *potential usage* > and differs from the blink use counter in ChromeStatus > <https://chromestatus.com/metrics/feature/timeline/popularity/2550> which > only measures *actual use* (i.e. when the use counter was triggered > because that code was run). For a static crawler like the HTTP Archive, the > actual use count is likely rarely triggered. > > This identified 20 scripts, across 36 pages, across 19 sites (including > mozaic.fm) so a bit more coverage than that 1 site found based on use > counters alone. Data here: > > https://docs.google.com/spreadsheets/d/1AlHqD4znlE-BHWht3XhvPt9mMPzslh45V7aPMLFeuxI/edit?gid=737311052#gid=737311052 > I also included the SQL in that results sheet (warning it's VERY costly to > query response bodies like this, which is why we usually depend on the use > counters instead, so take care if rerunning this). > > It's still not massive usage, but a bit more data to go on. It also > includes some sites which are a lot more popular than mozaic.fm (no > offence intended Jxck!) > > Note this is still subject to the other restrictions of HTTP Archive > (mainly that we only crawl the home page and one other page for desktop and > mobile, so a max of 4 pages per site and in many classes more like just 2) > so is still not comprehensive for sites/inner pages we don't crawl, and > also if a service worker is only downloaded and registered on user > interaction. > > I also noticed that the use counter provided above is based on > BackgroundFetchManagerGet which, based on my limited understanding of this > API is not what initiates a background fetch, but is a status check of an > already triggered background fetch. I'm not sure if every app that uses > background fetch calls backgroundFetch.get. > > When you look at the usage counter of Fetch it's still small but about 5 > times that usage: > > - BackgroundFetchManagerGet > <https://chromestatus.com/metrics/feature/timeline/popularity/2550> > - ~0.000010% page loads > - BackgroundFetchManagerFetch > <https://chromestatus.com/metrics/feature/timeline/popularity/2549> - > ~0.000050% of page loads > > Hope that all helps you all make your decision and let me know if you've > any other questions on the HTTP Archive side. > > Barry > On Thursday, November 27, 2025 at 3:30:05 PM UTC [email protected] > wrote: > >> I am the owner of the website mozaic.fm, which is the only one that >> appears on that Status page. >> >> That page is my podcast program, and at that time, I turned the podcast >> page into an app by adopting the "PWA Narrative" and using its added >> features. I periodically fetched RSS using periodic background fetch, >> displayed badge with the badging API if new episodes are available, and >> downloaded episode MP3s using background fetch so they could be listened to >> offline. >> >> However, I implemented it quite a while ago, and since many people >> listening my program on Spotify or Apple's podcast apps, I honestly had >> forgotten about this feature myself. >> >> At TPAC 2025, I spoke directly with yoshisato, and he asked me, "Would >> you mind if this feature were removed ?". >> >> I told him that if removing this feature would benefit the web, and if I >> were the only one blocker in worldwide, I wouldn't oppose it. >> >> However, the risks associated with not removing this feature are largely >> unknown. It's also unclear whether similar risks exist for other PWA >> features. PWA has incorporated ambitious capabilities, and I was in a >> position to try them. The Web values compatibility, but it should >> prioritize user safety even more. If security risks or similar issues were >> found, I would understand removing it. However, if the message is simply >> that “features with few users may be removed,” then adopting new features >> early becomes a risky act. >> >> Were they also hoping to remove other PWA features if they had few users? >> Wouldn’t that imply that the very concept of "PWA" itself has failed? >> >> If the reason was “too few users relative to the maintenance cost,” are >> there any efforts being made to increase the number of users? At least for >> Background Fetch, I don’t think there have been any updates or advocacy for >> a long time. >> >> I believe PWA was a campaign strongly promoted by Google. Has Google >> already lost interest in PWA? Do they no longer have the budget or >> resources to advocate for the features they introduced? If that is the >> case, what has become of that narrative now? >> >> We developers are strongly encouraged to try new features every time a >> new campaign appears: Layered APIs, Houdini, Web Packaging etc etc. >> However, browser vendors do not signal when those campaigns have >> effectively ended. Even when teams are re-orged, people are laid off, or >> resources are redirected to another campaign, we keep waiting for updates. >> >> If there were either a serious explanation of why this feature should be >> removed on its own by security reason, or a clear indication that Google >> has shifted its overall policy regarding the PWA campaign, I believe we >> could have a more constructive discussion. >> >> >> Best, >> Jxck >> 2025年11月27日木曜日 5:31:04 UTC+9 [email protected]: >> >>> I'm a bit worried that the UseCounter may be misleading. While the >>> UseCounter is low, it's still about 2x the level we call "trivial" >>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.mqfkui78vo5z>. >>> We've seen situations in the past where rare activities (eg. some specific >>> aspect of payments or account creation) were nonetheless really critical to >>> some sites. Our content does a pretty good job of explaining why this API >>> is sometimes essential, and coincidentally just yesterday I had recommended >>> it to someone who was complaining that the web lacked this important >>> facility. Is Thomas correct that really you can't rely on being able to >>> just use a SW for long-running background download tasks? Our compat >>> principles >>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.x5bhg5grhfeo> >>> cover >>> this sort of case pretty clearly IMHO: >>> >>> A change which can be trivially accounted for (such as by replacing a >>> webkit-prefixed API name with the non-prefixed version) is generally >>> considered to be lower risk than one which requires more effort. At the >>> extreme end, a breaking change which takes away a capability (no matter how >>> minor) which cannot be achieved by any other mechanism is generally >>> considered high risk. >>> >>> To move forward I guess what I'd like to see is some feedback from >>> developers who are actually using the Background Fetch API. Do they agree >>> it's unimportant and they can replace it with something else? Or do some of >>> them at least feel like the capabilities of their application would be >>> significantly reduced without this API? Can we look at the HTTP Archive >>> hit <https://mozaic.fm/> (which only tracks API use on page load by the >>> way), some UKM UseCounters, and/or the ~100 hits in GitHub >>> <https://github.com/search?q=%22.backgroundFetch.fetch%28%22+language%3AJavaScript+&type=code> >>> to >>> see if we can get any sentiment from web developers? >>> >>> Thanks, >>> Rick >>> >>> >>> On Wed, Nov 26, 2025 at 11:21 AM Alex Russell <[email protected]> >>> wrote: >>> >>>> This capability was developed in conjunction with media app developers. >>>> Have we heard from them? I'd also like to understand Jake Archibald's >>>> perspective. >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Wednesday, November 26, 2025 at 6:38:03 AM UTC-8 Mike Taylor wrote: >>>> >>> Is this a request to deprecate for some number of milestones then remove >>>>> (if so, what is the proposed plan?), or just a straight removal? Could you >>>>> clarify? Thanks. >>>>> On 11/24/25 10:40 p.m., Chromestatus wrote: >>>>> >>>>> *Contact emails* >>>>> [email protected] >>>>> >>>>> *Explainer* >>>>> *No information provided* >>>>> >>>>> *Specification* >>>>> https://wicg.github.io/background-fetch >>>>> >>>>> *Summary* >>>>> Deprecates the Background Fetch API, which allows web applications to >>>>> download large files in the background, even if the user navigates away >>>>> from the page or closes the browser. Despite being available in Chrome >>>>> since version 74, the Background Fetch API has not seen wide adoption by >>>>> the developer community, with usage remaining consistently low, at less >>>>> than 0.00002% of page loads as of November 2025. Given the low adoption >>>>> rate and the significant engineering effort required to maintain the API >>>>> and address ongoing security issues, it is being deprecated. Developers >>>>> are >>>>> encouraged to explore alternative solutions for managing large file >>>>> downloads. >>>>> >>>>> *Blink component* >>>>> Blink>ServiceWorker >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22> >>>>> >>>>> *Web Feature ID* >>>>> background-fetch <https://webstatus.dev/features/background-fetch> >>>>> >>>>> *Motivation* >>>>> The Background Fetch API has been available in Chrome since version >>>>> 74. However, it has not seen wide adoption. Usage metrics show that the >>>>> feature is used in less than 0.00002% of page loads as of November 2025. >>>>> Given the low usage, the ongoing engineering effort to maintain the >>>>> Background Fetch API and address security issues is no longer justifiable. >>>>> For developers who need to provide users with the ability to download >>>>> large >>>>> files, there are several alternatives: - For simple file downloads, >>>>> developers can provide a standard download link. - For more advanced use >>>>> cases, such as providing offline access to large files, developers can use >>>>> the Fetch API within a Service Worker to download and cache the necessary >>>>> resources. This approach provides developers with greater control over the >>>>> user experience. >>>>> >>>>> *Initial public proposal* >>>>> *No information provided* >>>>> >>>>> *TAG review* >>>>> *No information provided* >>>>> >>>>> *TAG review status* >>>>> Not applicable >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> The interoperability risk of removing the Background Fetch API is low. >>>>> The API has not been implemented by Firefox or Safari, and there have been >>>>> no signals from either to indicate that they intend to do so. As a result, >>>>> removing this API from Chrome will not cause interoperability issues, as >>>>> it >>>>> is not a feature that is part of the interoperable web platform. The >>>>> compatibility risk is also minimal. Usage of the Background Fetch API has >>>>> remained consistently low, at less than 0.00002% of page loads as of >>>>> November 2025. Because of this extremely low usage, the number of websites >>>>> that will be affected by this removal is very small. >>>>> >>>>> *Gecko*: No signal ( >>>>> https://github.com/mozilla/standards-positions/issues/30) >>>>> >>>>> *WebKit*: No signal ( >>>>> https://github.com/WebKit/standards-positions/issues/149) >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> *Other signals*: TAG: >>>>> https://github.com/w3ctag/design-reviews/issues/279 >>>>> >>>>> *Ergonomics* >>>>> The Background Fetch API is tightly coupled with the Service Worker >>>>> API. It is accessed through the backgroundFetch property of a >>>>> ServiceWorkerRegistration object. Developers using this API would also >>>>> likely use the Fetch API to create the Request objects for the download >>>>> and >>>>> the Cache API to store the downloaded responses. The API is designed to be >>>>> asynchronous and to operate in the background. The main fetch() method >>>>> returns a Promise, and the download process is managed by the browser, off >>>>> the main thread. This design avoids blocking the main thread and is >>>>> intended to improve performance and battery life for large downloads >>>>> compared to keeping a service worker alive for a long-running fetch. >>>>> Therefore, the API's usage does not inherently pose a performance risk >>>>> that >>>>> would make it difficult for Chrome to maintain good performance. The >>>>> deprecation is due to low adoption and high maintenance cost, not because >>>>> of ergonomic or performance issues in its design. >>>>> >>>>> *Activation* >>>>> This change is a deprecation and removal of an existing API. The >>>>> primary risk is the impact on developers who are currently using the >>>>> Background Fetch API. However, the "activation" risk for this removal is >>>>> minimal. The API has seen extremely low adoption since its introduction in >>>>> Chrome 74, with usage below 0.00002% of page loads. This indicates that >>>>> very few developers will be required to take action. >>>>> >>>>> *Security* >>>>> The removal of the Background Fetch API reduces the overall attack >>>>> surface of the browser and mitigates existing security issues associated >>>>> with maintaining the feature. >>>>> >>>>> *WebView application risks* >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> *No information provided* >>>>> >>>>> >>>>> *Debuggability* >>>>> *No information provided* >>>>> >>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>> No >>>>> >>>>> *Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> No >>>>> >>>>> >>>>> *Flag name on about://flags* >>>>> *No information provided* >>>>> >>>>> *Finch feature name* >>>>> BackgroundFetch >>>>> >>>>> *Rollout plan* >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://crbug.com/460293588 >>>>> >>>>> *Estimated milestones* >>>>> Shipping on desktop 146 >>>>> Shipping on Android 146 >>>>> Shipping on WebView 146 >>>>> >>>>> *Anticipated spec changes* >>>>> >>>>> Open questions about a feature may be a source of future web compat or >>>>> interop issues. Please list open issues (e.g. links to known github issues >>>>> in the project for the feature specification) whose resolution may >>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>> of >>>>> the API in a non-backward-compatible way). >>>>> *No information provided* >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://chromestatus.com/feature/5074579353632768?gate=6606728540061696 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com>. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6925253c.050a0220.107b62.0899.GAE%40google.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6925253c.050a0220.107b62.0899.GAE%40google.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- >>>> >>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> >>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0787a736-c17f-497b-979c-eb50355086b9n%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0787a736-c17f-497b-979c-eb50355086b9n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6VWC0wBkUm-%3Dk4uK20YfWR-Pq%3Dv5iKDFK3jMp0uVMRxRA%40mail.gmail.com.
