Lazy parsing & preparsing

Why engines put off work

A web page often sends the browser thousands of functions. Only a few of them run while the page first loads. The rest wait for a click, a menu, or a settings panel. Some never run at all.

The program that runs JavaScript is called an engine. Chrome and Node.js both use an engine called V8. Before an engine can run a function, it does two jobs:

• It parses the function: it reads the text and builds a tree that describes the code. That tree is called an AST, short for abstract syntax tree.
• It compiles the function: it turns the tree into bytecode, a list of simple steps the engine can run.

Both jobs take time and memory. If the engine did them for every function at load, it would waste work on code that nobody calls yet.

The rules of JavaScript, called the ECMAScript specification, say what a program must do. They don't say when the engine parses each function. This lesson shows what V8 does. It uses V8's own articles and real logs from Node.js. The engines in Firefox and Safari may choose differently, but your program prints the same result in every engine.

This lesson builds on function expressions, closures, and loading performance. It also links to these lessons:

• Meet the engines, for the steps an engine takes.
• Parsing & ASTs, for how the parser builds its tree.
• Scope analysis, for where variables are stored.
• Startup performance, for making pages start faster.

A full parse reads every part of a function body and builds its whole tree. V8 then hands that tree to its bytecode compiler, which is called Ignition.

A preparse is a lighter read. It still checks the grammar of the whole body, but it keeps only a few facts:

• that the function has no syntax errors,
• where the function ends,
• which variables from outside the function it uses.

Parsing and compiling are two different jobs. Parsing turns text into a tree. Compiling turns that tree into bytecode. V8 usually does both on a function's first call, but they are still two separate steps.

1function openSettings() {2  return "settings opened";3}4 5console.log("home ready");

Line 1 creates a function called openSettings. Nothing ever calls it. Line 5 prints home ready, so that is the only output. JavaScript promises that output in every engine.

The output can't tell you whether the engine preparsed, fully parsed, or compiled openSettings. Those steps happen inside the engine, where your code can't see them.

The table below names four engine words that are easy to mix up. Read each row as: the word, what it means, and why it matters.

The next program creates four functions at the top level, and one more function inside one of them. At startup, line 20 calls only startApp(). The settings panel and the click handler are useful later, but startup doesn't need them.

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());

In plain words, line by line:

1. Line 1 creates startApp, the function that startup runs.
2. Line 6 creates registerClickHandler. It returns a new function, onClick, for a later click.
3. Line 12 creates showShell, a small helper that startup calls.
4. Line 16 creates openSettingsPanel. Only a click would call it.
5. Line 20 calls startApp(). This is the only call at the top level of the file.

With V8's normal settings, the function on line 16 gets no full parse and no compile during the first load. It gets only the quick check.

V8 explained its preparser in a 2019 article, Blazingly fast parsing, part 2: lazy parsing. One point in it: the preparser can't just count curly braces to find where a function ends. JavaScript's grammar is too complex for that. For example, a brace can sit inside a string. So the preparser really reads the syntax. What it saves is the work of building the full tree and the bytecode.

The preparser also writes down a few facts about the functions inside each body:

• which variables each inner function creates,
• which outer variables each inner function uses,
• where each inner function starts and ends.

These facts matter for closures. A closure is a function that keeps using variables from the function around it. If an inner function uses an outer variable, the engine must know that before it decides where to store the variable. The saved facts also let a later full parse start faster, as the next section shows.

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());

A nested function is a function written inside another function. Older V8 versions did extra work with nested functions:

1. At load, V8 preparsed the outer function, and the inner functions inside it.
2. Later, a call made V8 fully parse the outer function.
3. During that full parse, V8 preparsed the inner functions all over again.

With many levels of nesting, this repeated work grew very fast. Since 2019, V8 saves the facts about inner functions from the first preparse. A later full parse of the outer function reads those facts and skips the inner bodies that still aren't 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 idea: V8 skips the inner bodies, but it doesn't forget them. It already knows where readTitle and renderChart start and end, and which variables they use. When line 10 calls readTitle(), that inner function gets its own full parse. renderChart is never called, so it keeps waiting.

A function written as a value, like the right side of const f = function () {}, is a function expression. Wrap one in round brackets and call it right away, like (function () { ... })(), and you get an IIFE: an immediately invoked function expression. Invoked means called.

V8 looks for one sign that a function will run right away: a round bracket ( just before the word function. V8 calls a function with that sign a PIFE, a possibly invoked function expression. It says "possibly" because the parser sees the bracket before it knows whether a call follows. For a PIFE, V8 skips the preparse. It fully parses and compiles the function at load.

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

Line 1 wraps bootPife in round brackets, and line 3 calls it straight away. Line 5 creates bootNormal the plain way, and line 9 calls it. The program prints pife boot, then normal boot.

V8's 2019 article also mentions two more shapes. Around Chrome 57, V8 learned to spot the shapes that the UglifyJS minifier writes. A minifier is a tool that shrinks code before you ship it. The two shapes are:

• a !function at the start of a line,
• a ,function after a comma that follows an earlier PIFE.

An old package called optimize-js added these brackets for you. It guessed which functions would run at startup. That helped older V8 versions a lot. It helps modern V8 much less, because the parser got faster and no longer preparses inner functions twice. Add PIFE brackets only when a measurement shows that they help.

Lazy parsing is a trade. A function that is never called saves its full parse. But a function that runs right away can pay twice: first the preparse at load, then the full parse on its first call. That second read is called a reparse.

V8 can write a log of these events. Below is the small program that the lesson tests run, and then a summary of what the log said.

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

Line 1 creates uncalledCold, which nothing calls. Line 2 creates calledHot. Line 3 calls calledHot() and prints 42.

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

How to read the summary, line by line:

1. Line 1 names the Node.js version and its V8 version.
2. Line 2 lists the flags the tests used. A flag is an option you add to the node command.
3. Line 3: uncalledCold got only a preparse. It got no full parse, and it never ran.
4. Line 4: calledHot got a preparse first. When line 3 called it, the log shows a full-parse and a parse-function event. That is the reparse. Then the function ran for the first time.
5. Line 5: pifeNow comes from a second small program, where it is a PIFE. It got its full parse at load and no reparse.
6. Line 6: normalNow, a plain function in that same program, was read twice, like calledHot.

The tests run Node.js with three flags:

• --log-function-events turns the log on.
• --logfile names the file to write.
• --no-logfile-per-isolate keeps the file name exactly as written.

Before that, the tests run node --v8-options to check that these flags exist. They also remove the NODE_TEST_* environment variables, and they delete the log folder when they finish.

This log is proof for one V8 version only. Chrome and Node.js both use V8. Firefox and Safari use other engines, with different tools and different event names.

In 2025, V8 wrote a post called Giving V8 a Heads-Up. It says Chrome 136 added explicit compile hints for whole files. A compile hint is a special comment that tells V8 what to do. The exact comment is //# allFunctionsCalledOnLoad, and it goes at the top of a JavaScript file.

The comment tells V8: "Every function in this file runs while the page loads." So V8 compiles them all at load. That can avoid a pause on each first call, and it avoids reading each function twice.

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

Line 1 is the hint. Lines 2 and 6 create two functions. Line 10 calls both of them and prints header + search. Every function in this file really runs at load, so the hint fits.

To measure a real website, use Chrome DevTools. Open the Performance panel and record a page reload. Then search the main thread for two kinds of events:

• Compile Script: V8 parses and compiles a whole script.
• Compile Code: V8 compiles one function, often on its first call.

Match each event to the file and the page that caused it. For small tests on your own computer, V8's function-event log works well too. Always check that a flag exists in the version you test.

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

Lines 1 and 2 are notes for the browser. Line 4 lists V8's flags and keeps only the lines about lazy parsing, the function-event log, and the log file. Line 5 runs app.js with the function-event log turned on, and writes the log to v8.log.

Code caching is a different idea, for repeat visits. V8's posts on code caching for developers and improved code caching explain it. Chrome can save the bytecode of a script that hasn't changed, and load it again on the next visit. That cuts parse and compile time on repeat visits. A first visit, or a changed file, still pays the full cost.

The playground below reads the code on the left with acorn, a JavaScript parser written in JavaScript. It finds every function and every call. Then it counts the work with a simple model. Each function costs one unit per line of code it has. These units are made up for teaching; they are not V8 times.

Pick a strategy to compare:

• Lazy default: preparse plain functions, fully parse PIFEs at load, and fully parse the others when they are first called.
• Eager all: fully parse every function at load.
• File hint: act as if the file starts with the compile hint.

The model only follows direct calls by name, like startApp(). It can't predict method calls, callbacks chosen while the code runs, code-cache hits, or the extra speed-ups a real engine adds later. Use it to compare strategies. To study a real app, record a real trace.

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());

Choices for real websites

In a real product, the biggest win is usually to send less code at startup:

• Split optional features into separate files.
• Keep admin tools out of the public pages.
• Load large libraries only when the user needs them.

Lazy parsing helps only after the code has arrived in the browser. It doesn't replace splitting your code or keeping your files small.

1button.addEventListener("click", async () => {2  const { openEditor } = await import("./editor.js");3  openEditor();4});

Line 1 waits for a click on a button. Line 2 uses import(), called a dynamic import. It downloads and runs a separate file, editor.js, only at that moment. Line 3 opens the editor. You can't run this example here, because it needs a real button on the page and a separate editor.js file.

A safe order of work:

1. Measure compile events at startup, with the CPU slowed down in DevTools.
2. List which functions run at load, and which run later, after a click or another action.
3. Move optional code out of the first file you send, when you can.
4. Use PIFE brackets or the file hint only for startup code you have measured.
5. After making code compile earlier, measure memory and click response again.

Common misconceptions

The table below compares lazy parsing with three ideas that sound alike. Read each row as: the idea, what it delays or reuses, and the point to remember.

Key takeaways

• Most functions a page sends don't run at startup, so V8 gives plain functions only a quick check, a preparse, at load.
• The preparse still checks the syntax, finds early errors, and notes which outer variables a function uses.
• A function that is preparsed and then called right away is read twice: a preparse at load, then a full parse on its first call.
• PIFE brackets and the compile hint for a whole file make V8 fully parse code at load. Use them only when a measurement shows the code runs at load.
• Code caching helps repeat visits. It is a separate idea from what V8 parses on a first load.

Next: Scope analysis & variable allocation. There, the facts the preparser saved help the engine decide where each variable is stored.