A CommonJS service takes several seconds to start serving traffic, and the time is spent in top-level code of required modules — parsing config, building lookup tables — before the server ever starts listening. Why does require() put that cost exactly there, and how would you restructure the modules?

## Why the cost lands where it lands CommonJS loading is synchronous and run-to-completion. `require('./x')` evaluates x.js's body from top to bottom, and only when the last statement has finished does it return the value in `module.exports`. There is no interleaving, no yielding, no partial load. If x.js itself requires y.js at its top, that nested call runs y.js to completion first, so loading walks the graph depth-first. The consequence for a service is direct: the top level of every module reachable from your entry file is a single, serial, blocking startup phase that runs before your own first statement. A module that does ```js // tariffs.js const raw = fs.readFileSync('./tariffs.json', 'utf8'); const table = buildIndex(JSON.parse(raw)); module.exports = { table }; ``` charges that read and parse to whoever requires it, whether or not they will ever consult a tariff. Multiply by a dependency tree and you get the symptom in the question. ## The diagnosis Before restructuring, confirm the shape. Log a timestamp as the first statement of the entry file and again immediately before the server starts, and instrument suspicious module bodies with a duration log at their top and bottom. Because loading is serial, a simple per-module elapsed time attributes the cost precisely — there is no concurrency to confuse the accounting. Sorting those numbers usually shows one or two offenders rather than diffuse slowness. ## Restructuring: bodies declare, functions do The design rule that follows is that a module body should *declare* things and an exported function should *do* things. ```js // registry.js — nothing expensive happens while require() runs let table = null; function buildTable(rows) { const t = new Map(); for (const row of rows) t.set(row.id, row); return t; } module.exports = { init(rows) { table = buildTable(rows); }, lookup(id) { if (table === null) throw new Error('registry not initialised'); return table.get(id); }, }; ``` This buys several things beyond a faster require. The application now controls *when* initialisation happens, so it can start cheap listeners first, or run several independent initialisations concurrently instead of serially. It controls *what happens on failure*: a throw inside `init()` carries application context and can be retried or degraded, whereas a throw at module top level unwinds out of a `require` call in the middle of the dependency graph with far less context. And initialisation can be asynchronous, which a module body genuinely cannot express in CommonJS — this is exactly why so many modules that need I/O expose an async `connect()` or `start()` rather than doing it at load. ## Lazy requiring The second lever is that `require` is an ordinary function call, so it can live inside the function that needs the module: ```js function renderReport(data) { const heavy = require('./chart-renderer'); // loaded on first report, not at startup return heavy.render(data); } ``` This moves a module's entire load cost off the startup path for features that are rarely or never exercised. It is a real technique, and it is also a trade-off worth naming out loud in an interview: the cost and any load-time failure now appear during a request rather than at startup, which is worse for fail-fast behaviour and can surprise operators. Use it for genuinely optional subsystems — a CLI subcommand, an export format, a debug tool — not as a blanket policy. ## Side effects at load are the deeper problem Slow startup is the visible symptom; the structural problem is that load-time side effects create implicit ordering. A module that opens a connection, registers a global handler, or mutates shared state at its top level makes its behaviour depend on *when it happens to be required*, which is a function of import order across the whole tree. That is hard to reason about, hard to test (importing the module in a test suite performs the side effect), and hard to change safely — reordering two requires can alter behaviour. Pushing side effects into explicit calls makes the ordering visible in the application's own code. ## What to say in an interview Lead with the mechanism — synchronous run-to-completion evaluation charges module top-level work to the requiring call — then give the restructuring rule, then name the trade-offs: explicit init costs a little ceremony and requires discipline about "not initialised" states; lazy requiring trades startup time for first-use latency and later failure detection. Mentioning testability and failure-reporting benefits shows you are treating it as a design property rather than a performance trick.