# Why Code Removal May Be Preferable to Scheduling for Performance Remediation

DevFeed: [Why Code Removal May Be Preferable to Scheduling for Performance Remediation](<https://devfeed.tech/articles/the-wicked-reason-removing-code-beats-better-scheduling-26567.md>)

Original publisher: [Read original article](<https://infrequently.org/2026/08/notes-on-performance-remediation-strategies/>)

Author: Alex Russell

Published: 2026-08-19T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [ordering](<https://devfeed.tech/topics/ordering.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [ordering](<https://devfeed.tech/tags/ordering.md>), [performance](<https://devfeed.tech/tags/performance.md>), [webdev](<https://devfeed.tech/tags/webdev.md>)

## AI overview

An opinion article arguing that removing code can be a more reliable performance-remediation strategy than reordering or deferring work. It says both approaches require understanding page behavior, while scheduling changes can increase validation, coordination, bandwidth, and main-thread performance risks.

## Source excerpt

My colleague Marko Ilić has published an insightful piece on how to schedule work on the critical path, and I recommend reading it before proceeding here. Contents Elimination vs. Scheduling: An Organisational Perspective What's Good for the Goose... "Preloading" as Scheduling Scheduling Is For Closers General-Purpose Advice ...and welcome back. As you likely anticipated, Marko's beautifully presented post kicked off healthy discussions around the office. Since we almost always see eye-to-eye, it seemed interesting to surface some of that discussion here. With his permission, what follows are expanded versions of some points I posed in reply. Elimination vs. Scheduling: An Organisational Perspective There's no daylight between our positions on code reduction: sending and running less is always ideal. Where we differ, perhaps, is the priority teams should assign to scheduling vs. code removal in their performance remediation efforts. Contra Marko, I posit that reordering can almost never be assumed to be cheaper or easier. While it may be hard to remove code, my view is that it is generally not harder than re-ordering in most codebases. Why? The primary cost of both code removal and scheduling interventions is the investment to deeply understand page behaviour. This presents a narrative challenge to the proposition that scheduling is an easier fix, as both approaches share the largest cost. At the team level, the consequences of restructuring are harder to reason about than direct removal, reducing potential upside and increasing validation costs. Bytes that are only deferred still contend for bandwidth, potentially delaying above-the-fold resources in ways that only become visible in the tail of the connection quality curve. Worse, late-fetched JS resources generate heavy "thuds" when residual allocations from background compilation arrive on the main thread. These stalls show up in INP data, but can be maddening to track down due to their stochastic relationship wi