Every web page is a negotiation. The browser's rendering engine wants to paint a frame every 16 milliseconds at 60 Hz, or every 8 milliseconds at 120 Hz on capable displays. The ad server, by contrast, wants to run as much JavaScript as it can to track, auction, and render creative content. These two agendas collide on every page that carries advertising, and the collision has a name: the frame budget. The frame budget is the invisible contract between the browser vendor and the ad network, and it is a contract that neither side fully honors. This article looks at who actually controls the render loop, how ad scripts tax it, and what that means for the business of publishing on the open web.

Who Controls the Frame Budget?

Browser vendors set the render loop's cadence. The HTML specification and the associated web platform standards define how the browser schedules rendering work: when a frame is produced, how long tasks are allowed to run before they block the main thread, and how requestAnimationFrame callbacks are batched. These standards are the result of years of work by engineers at organizations like the W3C and WHATWG, and they are implemented consistently across Chrome, Firefox, Safari, and Edge. The frame budget is a fixed resource that every script on the page must share.

Ad servers, however, dictate how that budget is spent. A typical page today loads dozens of third-party scripts: one for the ad network's core tag, another for a measurement partner, another for a viewability tracker, and several more for header bidding partners. Each script runs on the main thread, competes for CPU time, and can push a frame past its deadline. The ad server, not the browser, decides how much of that script runs before the first paint, how much runs after, and how much is deferred to idle time. The browser can only enforce the frame rate; it cannot control what scripts load or how heavy they are.

This structural tension is not an accident. The standards bodies that define the render loop rarely test with real ad loads. They test with synthetic benchmarks and representative pages that may not include the pathological combination of trackers and auction scripts that many publishers actually serve. The specification describes an ideal world where a frame is a clean unit of work. The real world is a messy pile of third-party code that treats the main thread as a shared resource to be exploited, not a budget to be respected.

Neither side fully owns the pipeline. Browser vendors can throttle or deprioritize certain work, but they cannot easily distinguish an essential script from a wasteful one without breaking pages. Ad networks, for their part, are incentivized to maximize revenue per impression, which often means running more scripts, more trackers, and more auction logic. Publishers are caught in the middle: they want fast pages for their users, but they also need ad revenue to survive. The frame budget is the battleground where these competing interests play out.

The Render Loop's Quiet Standard

The render loop is one of the quiet standards of the web. Unlike HTTP or HTML, it is not something most developers think about until a page feels janky. The loop runs continuously, producing frames at the display's refresh rate. On a 60 Hz display, that means a frame every 16.7 milliseconds. On a 120 Hz laptop or phone, the budget shrinks to 8.3 milliseconds. The browser's rendering engine does its best to hit those deadlines, but it can only do so if the main thread is not blocked by long-running JavaScript tasks.

RequestAnimationFrame is the de facto clock for this loop. It is the API that tells the browser, "Run this code before the next paint." It is used by game engines, animation libraries, and some ad creatives to synchronize visual effects with the display. But requestAnimationFrame is also a double-edged sword: if the callback registered with it takes too long, it pushes the entire frame past its deadline, causing dropped frames and visible jank. The browser cannot preempt a running script; it can only wait for the task to finish and then decide whether to skip a frame.

Long tasks are the enemy of the render loop. A long task is any task that runs for more than 50 milliseconds, and the browser uses this threshold to decide when to show a progress indicator or to deprioritize background work. The Long Tasks API lets developers measure these tasks, and Core Web Vitals metrics like Interaction to Next Paint (INP) are designed to capture the user-perceived impact of long tasks. But the standards bodies that define these metrics do not test with the full weight of a production ad stack. They test with representative pages that may not include the worst-case combination of scripts.

Specification alone cannot enforce timing. The browser can only schedule work; it cannot force a third-party script to be efficient. Standards like the Performance Timeline and the Resource Timing API give developers visibility into what is slow, but they do not provide a mechanism to cap the amount of script a page loads. That decision is left to the page's own code, which is often under the control of the ad server, not the publisher or the browser vendor.

Ad Networks' Script Tax

Ad networks impose a script tax on every page they serve. The tax is not a monetary fee; it is the CPU time and network bandwidth consumed by third-party tags. A typical ad stack includes the primary ad network's tag, which loads asynchronously, followed by a cascade of additional scripts for viewability, fraud detection, and attribution. Each script adds a small amount of overhead, but the cumulative effect can be substantial. According to the HTTP Archive's 2023 Web Almanac, the median page on mobile loads around 22 third-party requests, and for news sites that number can exceed 50. The total weight of ad-related JavaScript on a typical news article often exceeds 500 kilobytes, with dozens of separate requests.

Each network adds its own tracker. The tracker might be a pixel that fires when the ad is viewed, or a script that collects user interaction data. These trackers are often loaded on every page, even if the user never sees an ad. The result is that a user visiting a publisher's site may be executing code from a dozen or more third-party domains, each with its own performance cost. The ad network's revenue depends on these trackers, so they are not optional from the network's perspective.

The script tax hits mid-tier publishers hardest. Large publishers have the engineering resources to implement lazy loading, defer third-party scripts, and negotiate lighter creative formats. They can also afford to run their own ad server and have more control over which tags are loaded. Mid-tier publishers, by contrast, often rely on a single ad network or a small set of partners, and they lack the leverage to demand changes. They are forced to accept whatever scripts the network serves, even if those scripts degrade the user experience.

Measured slowdowns vary widely. A 2021 study by the ad-tech analytics firm Adalytics found that pages with heavy ad scripts took two to three times longer to become interactive than ad-free versions of the same content. More recent data from Google's Chrome UX Report (CrUX) shows that pages with high third-party script weight tend to have worse Core Web Vitals scores, particularly for Largest Contentful Paint (LCP) and INP. For example, the 2023 Web Almanac reports that sites in the top quartile of third-party script weight have median LCP times that are roughly 1.5 seconds slower than those in the bottom quartile. But the exact impact depends on the device, the network, and the specific combination of scripts. A page that loads quickly on a desktop with a fast connection may be unusable on a mid-range Android phone.

Revenue incentives outweigh render costs. An ad network that reduces its script weight by 20% might see a small improvement in user experience, but it might also see a drop in measured viewability or click-through rates if the trackers are less aggressive. The network's revenue is tied to these metrics, so there is little financial incentive to optimize. The cost of the script tax is borne by the publisher in the form of lower user engagement and by the user in the form of slower page loads.

The Price of a Missed Frame

A missed frame is more than a technical glitch; it is a user experience failure. When a page janks, the user notices. The scroll stutters, the animation freezes, and the page feels unresponsive. This is not a theoretical concern. Research from Google has shown that pages with poor INP scores have lower user engagement, including fewer page views and lower conversion rates. Users are less likely to return to a site that feels slow, even if the content is good.

Core Web Vitals metrics are the industry's attempt to quantify this experience. LCP measures loading performance, INP measures interactivity, and Cumulative Layout Shift (CLS) measures visual stability. These metrics are used by Google in its ranking algorithm, and they are widely adopted by publishers as a benchmark. But the metrics are a proxy, not the full story. A page can have a perfect LCP score and still feel janky if the main thread is constantly blocked by ad scripts. The metrics capture the worst moments, but they do not capture the cumulative drain on the user's patience.

Ad revenue often trumps UX scores. A publisher that removes all ad scripts would likely see a dramatic improvement in Core Web Vitals, but it would also lose its primary source of revenue. The trade-off is real, and most publishers choose revenue. They might optimize the most visible metrics, like LCP, by lazy-loading below-the-fold ads, but they are unlikely to sacrifice ad impressions to improve INP if the revenue loss is significant. The frame budget is a cost of doing business, and publishers treat it as such.

Contractual SLAs rarely mention jank. When a publisher signs a contract with an ad network, the terms are about impressions, fill rates, and revenue share. There is no clause that says, "Your scripts must not block the main thread for more than 50 milliseconds." The network is not legally obligated to care about the frame budget, and the publisher has little recourse if the page is slow. The only leverage the publisher has is the threat of switching to another network, but that is a blunt instrument that may not be practical.

The real cost is lost time on page, not just metrics. A user who encounters jank is more likely to bounce, and a user who bounces is less likely to return. Over time, this erodes the publisher's audience and its ability to monetize. The metrics are a lagging indicator of this erosion, but by the time they show a problem, the damage is already done.

Where the Blame Actually Lies

The blame for the frame budget problem is diffuse. Supply chains for digital advertising include many middlemen: the publisher, the ad network, the supply-side platform (SSP), the demand-side platform (DSP), and the data management platform (DMP). Each participant adds its own scripts and trackers, and each claims that its contribution is minimal. The cumulative effect is a page that is bloated, but no single actor is responsible for the whole.

Header bidding adds auction overhead. Instead of a single ad server deciding which ad to show, header bidding runs an auction in the browser, with multiple demand partners submitting bids in real time. This process requires additional scripts and network requests, and it can significantly increase the time to first ad render. Some publishers have moved to server-side header bidding to reduce the browser overhead, but that shifts the problem to the server, which can introduce latency of its own.

Each participant claims innocence. The ad network says it is just delivering the creative; the SSP says it is just facilitating the auction; the DSP says it is just optimizing the bid. The publisher is the one who ultimately serves the page, but it is often the least technically sophisticated player in the chain. This is a classic tragedy of the commons: everyone benefits from a fast page, but no one is willing to sacrifice their own scripts to achieve it.

No single actor controls the full path. The browser vendor controls the render loop, but it cannot control what scripts are loaded. The ad network controls the scripts, but it cannot control the browser's scheduling. The publisher controls the page, but it cannot control the ad network's code. This fragmentation makes it difficult to assign responsibility and even more difficult to fix the problem. The blame game stalls meaningful fixes, as each party waits for another to act.

Practical Fixes for the Mess

Despite the structural problems, there are practical steps that publishers and ad networks can take to improve the frame budget. One approach is to set an explicit frame budget in the ad code itself. This means measuring the time spent in ad-related scripts and setting a limit, say 30 milliseconds per frame, and ensuring that the total does not exceed that limit. This requires a shift in mindset: instead of treating the main thread as an unlimited resource, treat it as a finite budget that must be managed. However, this approach is not universal; it depends on the publisher's ability to instrument their ad stack and enforce the budget across all third-party scripts.

Consider time-boxed script execution. The browser provides the setTimeout and requestIdleCallback APIs to defer work, but these are often misused. A more robust approach is to use the scheduler.postTask API, which is now available in some browsers, to prioritize tasks and prevent long-running scripts from blocking the main thread. This is a relatively new API, but it is designed for exactly this purpose. However, its adoption depends on the publisher's development stack and the browsers their audience uses; it may not be feasible for all publishers.

Lazy-load non-critical ad components. Ads that are below the fold do not need to load immediately. By deferring their load until the user scrolls near them, the initial page load is lighter, and the frame budget is less strained. This technique is already used by many publishers, but it is not universal. There is a trade-off: lazy loading can reduce viewability if the ad is not loaded in time, so publishers need to balance the performance benefit against the revenue risk. The specific implementation will vary based on the publisher's ad stack and the ad formats they use.

Negotiate lighter creative formats. Rich media ads with heavy animation and video are the worst offenders for jank. Publishers can push back on these formats, either by setting a maximum file size or by requiring that ads use the IntersectionObserver API to pause when off-screen. Some ad networks offer lighter formats, such as simple banner ads, which have a much smaller footprint. The publisher has some leverage here, but it is limited by the network's willingness to comply. This is not a one-size-fits-all solution; it depends on the publisher's relationship with their ad partners and the value of the impressions.

Measure per-vendor render impact. The Performance API can attribute long tasks to specific scripts, and this data can be used to identify which vendors are the biggest offenders. Publishers can then use this data to negotiate with those vendors or to switch to lighter alternatives. The measurement itself is not difficult, but it requires a commitment to monitoring and a willingness to act on the results. For publishers with limited engineering resources, this may be a significant undertaking, but it is a necessary step for understanding the true cost of each ad partner.

Who Owns the Next Move?

The next move in this standoff is uncertain. Browser vendors could take a more aggressive stance and throttle heavy frames or block scripts that exceed a certain budget. There is precedent for this: Chrome has already implemented intervention for abusive notifications, and it could do the same for performance. But such interventions are risky. They could break legitimate pages and would likely face pushback from the ad industry, which would argue that the browser is overstepping its role.

Antitrust fears slow action. Browser vendors, especially Google, are under scrutiny from regulators for their dominance in both search and advertising. If Google were to use its browser to disadvantage certain ad networks, it would invite legal challenges. This creates a chilling effect: even if a technical intervention is clearly in the best interest of users, the legal risk may be too high. The result is that browsers are likely to continue to provide tools and metrics, but not to enforce a strict frame budget.

Ad tech giants control the purse strings. The largest ad networks, including Google and Meta, have the resources to optimize their own scripts, and they do so to some extent. But they also have a dominant market position, which gives them little incentive to change the status quo. The cost of the frame budget is spread across the industry, so no single player feels the pain enough to act unilaterally.

Publishers lack leverage to demand change. A mid-tier publisher cannot afford to alienate its ad network, and a large publisher may have the resources to optimize, but even they are constrained by the need to maximize revenue. The only real leverage publishers have is the threat of moving to a subscription or membership model, but that is a radical change that most are not willing to make.

Standards may evolve, but money shapes reality. The web platform will continue to evolve, and new APIs will provide more control over the render loop. But the fundamental tension between the browser's desire for a smooth frame rate and the ad industry's desire for more script will remain. The frame budget is not a technical problem that can be solved with a new API; it is an economic problem that reflects the value we place on speed versus the value we place on free content. As long as advertising pays for the web, the ad server will set the frame budget, and the browser will have to live with it.

So, what can a publisher do today? Start by measuring the render impact of each ad vendor on your site. Use the Performance API to identify which scripts are causing long tasks, and share that data with your ad partners. If a vendor consistently degrades your Core Web Vitals, consider switching to a lighter alternative or negotiating a lighter creative format. The frame budget is not a fixed constraint; it is a resource that can be managed with the right data and the right conversations. The next move is yours.