Lazy parsing & preparsing

Why engines delay work

A modern page often ships thousands of functions, but only a fraction run before the first screen is useful. If the engine fully parsed and compiled every body immediately, startup would spend CPU time and memory on menus, settings panels, validators, and feature code the user may never open.

This lesson builds on function expressions, closures, and loading performance. It also connects to the engine path from Meet the engines, the parser work in Parsing & ASTs, the variable facts in Scope analysis, and the startup trade-offs in Startup performance.

A full parse builds the representation a compiler can use for a function body. In V8, that feeds Ignition's bytecode compiler. A preparse is still a real syntax pass, but it records less: enough to know the function is valid, where it ends, and which scope facts matter later.

The visible program below defines four functions. Startup calls only startApp(). That means the settings panel and the click handler body are useful code, but not startup code.

1function startApp() {2  registerClickHandler();3  return showShell();4}5 6function registerClickHandler() {7  return function onClick() {8    return openSettingsPanel();9  };10}11 12function showShell() {13  return "shell ready";14}15 16function openSettingsPanel() {17  return "settings ready";18}19 20console.log(startApp());

Line by line: line 1 defines the startup function; line 6 defines a helper that returns a future click handler; line 12 defines a small helper that is called now; line 16 defines a settings feature; line 20 calls only the startup path. Lazy parsing is the reason line 16 does not have to pay full parser cost during the first load.

V8's 2019 article Blazingly fast parsing, part 2: lazy parsing explains why the preparser cannot simply count braces. JavaScript grammar is too complex; it must parse syntax enough to find the real function end and enforce early errors. The saving is that it avoids building the full AST and bytecode-ready structures for bodies that are not needed yet.

The preparser also records just enough about inner functions for later scope analysis: declarations, references to outer variables, function boundaries, and data that lets the full parser resume without starting nested preparsing from scratch. That connects directly to closures: if an inner function references an outer variable, the engine must remember that fact before deciding where variables live.

1function startApp() {Run2  registerClickHandler();3  return showShell();4}5 6function registerClickHandler() {7  return function onClick() {8    return openSettingsPanel();9  };10}11 12function showShell() {13  return "shell ready";14}15 16function openSettingsPanel() {17  return "settings ready";18}19 20console.log(startApp());

Older lazy parsing could become non-linear for deeply nested code: an outer function was preparsed, then later fully parsed, and inner functions could be preparsed again along the way. V8's 2019 work stores inner-function preparse data so a later full parse of the outer body can skip inner bodies that still are not called.

1function outerRoute() {Run2  function readTitle() {3    return "Dashboard";4  }5 6  function renderChart() {7    return "Chart";8  }9 10  return readTitle();11}12 13console.log(outerRoute());

The key phrase is skip inner bodies, not ignore them. The engine already knows where readTitle and renderChart begin and end, and it knows the scope facts it must preserve. When readTitle() is called, that inner function gets its own full parse. Its sibling can keep waiting.

A function wrapped in parentheses, such as (function () { ... })(), is often an IIFE: an immediately-invoked function expression. V8 calls the recognizable parser signal a PIFE, a possibly-invoked function expression, because the parser notices the likely call pattern early and can eagerly parse and compile that body.

1(function bootPife() {2  console.log("pife boot");3})();4 5function bootNormal() {6  console.log("normal boot");7}8 9bootNormal();

In V8's 2019 post, the original parenthesized pattern is joined by a Chrome 57-era recognition of common UglifyJS output such as a leading !function or a comma-separated ,function after a PIFE. The old optimize-js package used static heuristics to add these hints. That helped older V8 versions much more than it helps modern V8, because parser speed and inner-function skipping improved. As of September 2026, treat PIFE wrapping as a measured startup hint, not a formatting rule.

Lazy parsing is a trade-off. A function that is defined but never called avoids full parse work. A function that is called immediately can pay twice: first the lightweight preparse, then the full parse on demand. V8's function-event log makes that structure visible without relying on invented flags.

1function uncalledCold() { return 41; }2function calledHot() { return 42; }3console.log(calledHot());

Node 22.23.1 (V8 12.4)
flags used: --log-function-events, --logfile, --no-logfile-per-isolate
uncalledCold: preparse-resolution; no full-parse; no first-execution
calledHot: preparse-resolution -> full-parse -> parse-function -> first-execution
pifeNow: full-parse at load; no parse-function event
normalNow: preparse-resolution -> full-parse -> parse-function -> first-execution

The tests spawn child Node processes with --log-function-events, --logfile, and --no-logfile-per-isolate, after verifying those flags with node --v8-options. They delete NODE_TEST_* environment variables and remove the generated log directory after parsing it.

V8's 2025 post Giving V8 a Heads-Up says Chrome 136 ships file-based explicit compile hints. The exact magic comment is //# allFunctionsCalledOnLoad, placed at the top of a JavaScript file. It tells V8 that all functions in that file are expected to be called during page load, so eager compilation may save on-demand stalls and duplicate parsing.

1//# allFunctionsCalledOnLoad2function hydrateHeader() {3  return "header";4}5 6function attachSearch() {7  return "search";8}9 10console.log(hydrateHeader() + " + " + attachSearch());

For a real website, start in Chrome DevTools' Performance panel and record a reload. Search the main thread for Compile Script and Compile Code events, then connect those events to the bundle and the route that caused them. For controlled experiments, V8's function-event log is useful, but always check available flags in the runtime you are testing.

1# Browser trace: open DevTools > Performance and record reload.2# Look for V8 "Compile Script" and "Compile Code" events.3 4node --v8-options | grep -E -- "--(lazy|log-function-events|logfile)"5node --log-function-events --no-logfile-per-isolate --logfile=v8.log app.js

Code caching is a separate repeat-visit mechanism. The V8 posts on code caching for developers and improved code caching explain that Chrome can serialize bytecode for unchanged scripts and later deserialize it. That can reduce parse and compile time on hot visits, but it does not make a first visit or changed source free.

The playground below parses the visible source with acorn, extracts a real function tree, and runs a teaching model over it. The counters are deliberately simple parse-work units, not V8 timings, but the relationships are the ones you just saw: lazy preparsing, eager PIFEs, duplicate work for immediately-called ordinary functions, and whole-file compile hints.

1function startApp() {2  registerClickHandler();3  return showShell();4}5 6function registerClickHandler() {7  return function onClick() {8    return openSettingsPanel();9  };10}11 12function showShell() {13  return "shell ready";14}15 16function openSettingsPanel() {17  return "settings ready";18}19 20console.log(startApp());

Production choices

In production, the biggest win is usually shipping less startup code: split optional features, avoid pulling admin tools into the public route, and keep large libraries behind the interaction that needs them. Lazy parsing helps once source text is already present; it does not replace code splitting or byte budgets.

1. Measure startup compile events on a throttled profile.
2. Identify functions that are called during load versus later interactions.
3. Prefer moving optional code out of the initial bundle when possible.
4. Use PIFE shape or file-level compile hints only for profiled core startup code.
5. Retest memory and interaction timing after making code more eager.

Common misconceptions

Key takeaways

• V8 lazy-parses ordinary function bodies because most functions shipped to a page are not called during startup.
• The preparser still checks syntax and early errors and records scope facts; it does not ignore the body.
• Calling a lazy function immediately creates duplicate work: preparse first, full parse on first call.
• PIFEs and file-level compile hints move selected code toward eager parsing, which helps only when profiling says the code is load-critical.
• Code caching helps repeat visits; it is separate from first-load lazy parsing decisions.

Next: Scope analysis & variable allocation, where those preparser facts become decisions about where variables live.