The Layers of Website Blocking
Every time you visit a website, the request passes through multiple layers between your browser and the server. A website blocker can intercept the request at any of these layers. The layer at which blocking happens determines the blocker's capabilities, performance impact, and privacy implications.
At the highest level - the application layer - browser extensions like FocusGuard intercept requests before they leave Chrome. At the network layer, DNS filters resolve domain names to different IP addresses or refuse to resolve them entirely. At the system layer, the hosts file maps domain names to localhost, preventing the request from reaching the real server. And at the hardware layer, routers can filter traffic based on DNS queries or IP addresses.
Understanding these layers helps you choose the right blocking approach for your specific needs. A Chrome extension gives you per-site time limits and focus sessions, but only works in Chrome. DNS blocking works across your entire network but can't distinguish between a quick YouTube check and a focused work session on the same domain.
How Chrome Extensions Block Sites
Chrome extensions are the most popular type of website blocker because they offer the best combination of power, flexibility, and user experience. But how do they actually prevent a site from loading?
In older versions of Chrome, extensions used the webRequest API, which allowed them to observe and modify network requests in real time. An extension could watch every request your browser made, check it against a block list, and cancel the request if it matched a blocked domain. While this was extremely flexible, it had two significant drawbacks: it required the extension to read every request (a privacy concern), and Chrome couldn't optimize performance because requests had to wait for the extension to respond.
Modern Chrome extensions use the declarativeNetRequest API (introduced with Manifest V3), which solves both problems. Instead of actively watching and intercepting every request, the extension declares a set of rules to Chrome in advance. Chrome then enforces those rules natively, without the extension having to process each request. This is faster, more private, and uses less memory.
The declarativeNetRequest API
The declarativeNetRequest API is the foundation of every modern Chrome site blocker, including FocusGuard. Here's how it works at a technical level:
When you add a site to your block list in FocusGuard, the extension creates a rule in Chrome's internal rule registry. Each rule specifies a domain pattern (like *.youtube.com or *.facebook.com) and an action (block the request or redirect it). Chrome compiles these rules into an efficient matching structure that can check every outgoing request against the rule set in microseconds.
When you navigate to a blocked domain, Chrome's network stack intercepts the request before it's even sent. It checks the URL against the registered rules, finds a match, and either blocks the request entirely or redirects it to a custom page (in FocusGuard's case, the calm summary redirect). The request never reaches the server, and the only resource cost is a simple pattern match - far more efficient than the old approach of running JavaScript code on every request.
FocusGuard uses dynamic rules that can be modified at runtime. When you start a focus session, it dynamically adds rules to block all distracting sites for the session duration, then removes them when the session ends. This runtime flexibility is what makes FocusGuard's combination of scheduled blocks, time limits, and focus sessions possible within a single, lightweight extension.
How DNS Blocking Works
DNS (Domain Name System) blocking operates at a completely different layer from browser extensions. Before your browser can load a website, it must first resolve the domain name (like youtube.com) to an IP address (like 142.250.80.46). DNS filtering intercepts this resolution step.
A DNS-based blocker - whether it's a service like OpenDNS or NextDNS, or a local tool like Pi-hole - maintains a list of blocked domains. When any device on your network tries to resolve a blocked domain, the DNS server returns either a null response (refusing to resolve) or a false IP address (pointing to a block page). The browser then can't connect to the real site because it doesn't know the real IP address.
DNS blocking has one critical advantage over extension-based blocking: it works on every device on your network. Phones, tablets, smart TVs, game consoles - everything that uses your network's DNS configuration is affected. This makes it ideal for household-wide enforcement or for people who browse across multiple devices.
The tradeoff is granularity. DNS blocking can't distinguish between a request from Chrome and a request from a system update service. It can't implement per-site time limits because it doesn't track session duration. And many modern DNS blockers use DNS-over-HTTPS or DNS-over-TLS, which can bypass traditional DNS filtering if the client is configured to use an encrypted DNS resolver directly.
How Hosts File Blocking Works
Long before browser extensions existed, the hosts file was the original website blocker. Every operating system has a local text file that maps domain names to IP addresses. On Windows it's at C:\Windows\System32\drivers\etc\hosts, and on macOS and Linux it's at /etc/hosts.
When you add a line like 127.0.0.1 www.youtube.com to your hosts file, you're telling your operating system that YouTube's IP address is 127.0.0.1 (localhost). When you try to visit YouTube, your browser asks the OS for the IP address, the OS checks the hosts file first (before DNS), finds the entry, and returns 127.0.0.1. The browser then tries to connect to your own computer instead of YouTube's servers, which fails - resulting in a connection error or a "can't reach this page" message.
Hosts file blocking is extremely fast (no DNS lookup needed), works across all browsers, and requires no additional software. But it's also purely manual - you add entries by editing a text file with administrator privileges. There's no scheduling, no time limits, no graceful redirect page, and no easy way to temporarily disable a block. It's best used as a permanent, rock-solid block for a small number of domains, often as a complement to an extension-based blocker.
How Router-Level Blocking Works
Router-level blocking is an extension of DNS blocking that operates at the hardware level. Instead of configuring DNS on each individual device, you configure your router to use a specific DNS resolver (like OpenDNS or NextDNS) that filters domains at the network gateway.
Every device on your network inherits the router's DNS configuration by default. This means a single configuration change can block websites on every phone, laptop, tablet, and smart TV in your home - without installing anything on any of them. It's the most comprehensive blocking method available for a home network.
Router-level blocking is also the hardest to bypass from within the network. An individual can override the DNS settings on their device, but most users won't bother. For parents, this makes router-level blocking a powerful tool for household internet management.
The limitations are significant, however. Router-level DNS blocking can't implement time limits, can't show custom block pages (it usually shows a generic "this site can't be reached" error), and can be bypassed by encrypted DNS resolvers. It also doesn't distinguish between users - every member of the household gets the same block rules.
How Proxy-Based Blocking Works
A less common but technically interesting approach is proxy-based blocking. Instead of intercepting requests at the browser or DNS level, a proxy server sits between all your devices and the internet. Every request passes through the proxy, which can inspect the full URL (not just the domain), the content of the page, and even the SSL certificate.
Proxy servers can implement far more sophisticated blocking than DNS or extension-based methods. A proxy can block specific pages within a site while allowing others, block content based on keywords or categories, inspect HTTPS traffic (with certificate installation), and log all browsing activity.
Tools like Squid, Charles Proxy, and mitmproxy support this level of filtering. The tradeoff is significant setup complexity, performance overhead (every request is decrypted and re-encrypted), and privacy concerns (the proxy sees all your traffic). For most personal use cases, proxy-based blocking is overkill - it's primarily used in enterprise environments where centralized browsing control is required.
Comparison: Which Method Should You Use?
Each blocking method has its ideal use case. Here's a practical guide to choosing the right approach:
Chrome extensions (FocusGuard) - Best for individual desktop users who want per-site time limits, scheduled blocking, focus sessions, and time tracking. The most feature-rich and user-friendly option, but limited to Chrome.
DNS filtering (NextDNS, OpenDNS, Pi-hole) - Best for household-wide blocking or if you browse across multiple devices. Effective against mobile browsing on Safari or Chrome for iOS. No per-site time limits or focus sessions.
Hosts file - Best for a small number of permanent, rock-solid, cross-browser blocks. Zero performance overhead and works on every browser. Requires manual editing and offers no flexibility.
Router-level blocking - Best for parents managing household internet or tech-savvy users who want a single configuration point. Comprehensive but inflexible, with no time limits or custom redirects.
For most people, the practical answer is a Chrome extension for their primary work device combined with a DNS filter on the home network for phones and other devices. FocusGuard handles the desktop side, while a free service like NextDNS covers the rest of your devices.
FocusGuard's Technical Approach
FocusGuard uses the declarativeNetRequest API exclusively, making it a Manifest V3 extension that's fast, private, and future-proof. All block rules are stored locally in Chrome's storage - they're never sent to any server. The extension itself weighs under 80 KB and has minimal impact on browser performance.
Time tracking in FocusGuard uses a different mechanism from blocking. The extension monitors tab activation events to determine which tab is currently active. It tracks the time each site has been in the active tab, subtracting any time you spend in a different tab or application. This active-tab-only tracking ensures accurate usage data that reflects actual attention, not passive tab count.
When a time limit is reached, FocusGuard dynamically updates its rule set to add a block rule for that specific domain. The rule is enforced by Chrome's native network stack, providing the same performance and reliability as any other declarativeNetRequest rule. When the usage resets at midnight (or whenever you configure the reset time), FocusGuard removes the rule, restoring access.
Schedule-based blocking works similarly. FocusGuard maintains a schedule in local storage and periodically checks whether the current time falls within a blocked period for each domain. When it does, it adds the block rule. When it doesn't, it removes it. This periodic synchronization means the block rules are always aligned with your schedule, even if you leave the browser open for days at a time.
All of this happens silently, without any server communication, and without requiring you to create an account. Your block list, your time limits, your focus session history, and your usage data all stay on your machine. FocusGuard has no access to your browsing activity - it only sees what you explicitly configure in the block list.