Optimizing Network Interception in Manifest V3: Inside the Architecture of an Asynchronous Blocklist Extension

Muhammad Aleem Naveed — Wed, 08 Jul 2026 00:52:41 +0000

As Google Chrome completes the transition from Manifest V2 to Manifest V3, Chrome extension development has fundamentally changed. Persistent background pages have been replaced with event-driven service workers, and the synchronous webRequest API has largely given way to the declarative declarativeNetRequest API.

These changes require more than simple API replacements—they demand a different architectural approach.

While building SaveYourself, a productivity-focused Chrome extension that blocks distracting websites, intercepts network requests, and enforces focus sessions, I had to redesign the extension around Manifest V3's constraints while maintaining responsiveness and keeping resource usage low.

This article explains some of the engineering decisions behind that architecture.

1. Designing for Ephemeral Background Service Workers

Under Manifest V2, background scripts remained active for the lifetime of the browser session. This allowed developers to keep state in memory, but it also meant extensions continuously consumed system resources.

Manifest V3 replaces this model with event-driven service workers.

A service worker starts only when an event occurs and is automatically terminated when it becomes idle. Any variables stored in memory disappear once the worker shuts down.

Because of this, SaveYourself treats the background process as a stateless execution environment. Persistent information—such as whether a focus session is active—is stored using chrome.storage.local and retrieved whenever the service worker wakes up.

// background.js

chrome.runtime.onInstalled.addListener(async () => {
  await chrome.storage.local.set({
    extensionActive: false,
    lockedDomains: []
  });
});

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.action === "START_LOCK") {
    handleSessionLock(message.duration).then(sendResponse);
    return true;
  }
});

This approach ensures the extension behaves consistently across service worker restarts without relying on long-lived in-memory state.

2. Network Filtering with declarativeNetRequest

One of the most significant Manifest V3 changes is the removal of the blocking version of chrome.webRequest.

Instead of allowing JavaScript to inspect every outgoing request, Chrome now encourages extensions to define filtering behavior declaratively using the declarativeNetRequest API.

Rather than evaluating each request in JavaScript, SaveYourself converts the user's blocked websites into dynamic rules that Chromium applies internally. This allows network requests to be filtered directly by the browser engine, reducing extension overhead and improving privacy.

async function updateSystemBlocklist(domainList) {
  const newRules = domainList.map((domain, index) => ({
    id: index + 1,
    priority: 1,
    action: {
      type: "block"
    },
    condition: {
      urlFilter: `*://*.${domain}/*`,
      resourceTypes: [
        "main_frame",
        "sub_frame",
        "xmlhttprequest"
      ]
    }
  }));

  const oldRules =
    await chrome.declarativeNetRequest.getDynamicRules();

  await chrome.declarativeNetRequest.updateDynamicRules({
    removeRuleIds: oldRules.map(rule => rule.id),
    addRules: newRules
  });
}

By delegating request filtering to Chromium itself, the extension avoids unnecessary JavaScript execution while still supporting dynamic, user-defined blocking rules.

3. Enforcing Focus Sessions Without Continuous Polling

One of SaveYourself's primary goals is preventing users from modifying settings during an active focus session.

Rather than keeping a persistent monitoring loop running, the extension uses browser-provided APIs to maintain lock state efficiently.

When a focus session begins:

The session's expiration time is stored in chrome.storage.local.
The popup interface checks that value whenever it opens.
Background logic validates whether configuration changes are allowed.
Scheduled browser alarms trigger events when the session ends.

This event-driven design eliminates the need for continuous polling while ensuring lock enforcement remains reliable across browser restarts and service worker lifecycles.

Lessons Learned from Building for Manifest V3

Manifest V3 encourages developers to build extensions that are event-driven, resource-efficient, and privacy-conscious.

Some of the most important architectural lessons from building SaveYourself include:

Treat service workers as stateless execution environments.
Persist important state using Chrome's storage APIs.
Use declarativeNetRequest whenever browser-level filtering is appropriate.
Prefer browser events and alarms over continuous polling.
Design around asynchronous execution instead of persistent runtime state.

Although Manifest V3 introduces new constraints, those constraints also encourage cleaner architectures that rely more heavily on browser-native capabilities.

For SaveYourself, embracing these patterns resulted in an extension that remains responsive while minimizing resource usage and staying within Chrome's modern security model.

If you're interested in the implementation details, you can explore the source code on GitHub or install the extension directly from the Chrome Web Store.

DEV Community: Muhammad Aleem Naveed

Optimizing Network Interception in Manifest V3: Inside the Architecture of an Asynchronous Blocklist Extension

1. Designing for Ephemeral Background Service Workers

2. Network Filtering with declarativeNetRequest

3. Enforcing Focus Sessions Without Continuous Polling

Lessons Learned from Building for Manifest V3