JavaScript Parse and Execution Cost

JavaScript Is Not Free

Here's something that surprises even senior engineers: a 200KB JavaScript file is far more expensive than a 200KB JPEG. The image gets decoded off the main thread and painted. Done. The JavaScript file goes through a gauntlet that blocks your user from doing anything.

Download it. Parse it. Compile it. Execute it. Every single step happens on the main thread (parsing and compilation can partially happen off-thread, but execution cannot). And every millisecond your main thread is busy, your user is staring at a frozen page.

On a fast MacBook Pro, 200KB of minified JavaScript takes roughly 20ms to parse. On a median Android phone? Closer to 200ms. That's a 10x penalty for the same bytes — and we haven't even started executing yet.

The True Cost of JavaScript

Every JavaScript file your page loads goes through this pipeline before it does anything useful:

Compare this to a 200KB image:

That's why the performance community keeps saying "JavaScript is the most expensive resource." It's not about bandwidth — it's about CPU time on the device that matters most: your user's phone.

The V8 Compilation Pipeline

When JavaScript arrives in V8, it doesn't just run. It goes through a multi-tier compilation system where each tier trades startup speed for execution speed.

Tier 1: Ignition (Interpreter)

Every function starts here. Ignition parses the source code into an AST, then generates compact bytecode. Bytecode is roughly 25-50% the size of equivalent machine code, which matters for memory when you have thousands of functions.

The critical job of Ignition isn't just execution — it's collecting type feedback. Every operation records the types it observes into a FeedbackVector. This data is what the optimizing compilers use later.

Tier 2: Sparkplug (Baseline Compiler)

Sparkplug (V8 9.1+) takes Ignition bytecode and converts it 1:1 to machine code. Zero analysis, zero optimization. It runs roughly 2x faster than interpreted bytecode because it eliminates the interpreter dispatch overhead.

Tier 3: Maglev (Mid-Tier Compiler)

Maglev (V8 11.3+) bridges the gap between Sparkplug and TurboFan. It uses the type feedback from FeedbackVectors and applies basic optimizations like common subexpression elimination and register allocation. Compiles 10-20x faster than TurboFan while producing code that's 50-80% as fast.

Tier 4: TurboFan (Optimizing Compiler)

The crown jewel. TurboFan generates highly optimized machine code using speculative optimization — it literally bets on the types it has observed. If a function always receives integers, TurboFan generates integer-specific machine code that approaches C++ speed. If the bet is wrong (a string shows up where an integer was expected), the code deoptimizes back to Ignition.

Script Evaluation and the Main Thread

Here's where theory meets reality. When the browser encounters a script, it must evaluate it — and that evaluation happens on the main thread. During this time, the page is unresponsive.

Open Chrome DevTools, go to the Performance tab, and record a page load. You'll see blocks labeled "Evaluate Script" in the flame chart. Each one represents a JavaScript file being parsed, compiled, and executed. The wider the block, the longer your users wait.

Main Thread Timeline (simplified):

|-- HTML Parse --|-- Evaluate app.js (150ms) --|-- Evaluate vendor.js (80ms) --|-- Layout --|-- Paint --|
                 ↑                              ↑
                 Main thread blocked             Still blocked
                 User cannot interact            User cannot interact

This is why a single large bundle is so dangerous. A 500KB JavaScript file can block the main thread for 200-500ms on mobile. That's not a theoretical concern — it directly impacts Interaction to Next Paint (INP), which Google uses as a Core Web Vital ranking signal.

Measuring Script Evaluation Cost

Chrome DevTools has a built-in Coverage tool that shows exactly how much of your JavaScript actually executes during page load:

1. Open DevTools → More Tools → Coverage (or press Ctrl+Shift+P and type "Coverage")
2. Click the reload button in the Coverage panel
3. Interact with the page
4. Each file shows a red/green bar: green is code that ran, red is code that was loaded but never executed

In most production applications, 50-70% of loaded JavaScript is unused during the initial page load. That's parse and compile cost you're paying for code that does nothing. Every red byte in the Coverage tool represents wasted main thread time.

Loading Strategies: defer vs async vs module

How you load scripts dramatically affects when they block the main thread.

Default (no attribute)

<script src="app.js"></script>

Parser-blocking. The HTML parser stops, downloads the script, executes it, then resumes parsing. This is the worst option for performance.

async

<script src="analytics.js" async></script>

Downloads in parallel with HTML parsing. Executes as soon as it's downloaded — which means it interrupts parsing at an unpredictable time. The execution order between multiple async scripts is non-deterministic.

Best for: independent scripts that don't depend on DOM state or other scripts (analytics, error tracking).

defer

<script src="app.js" defer></script>

Downloads in parallel with HTML parsing. Executes after HTML parsing is complete, but before the DOMContentLoaded event. Multiple defer scripts execute in document order.

Best for: most application scripts. You get parallel downloading without blocking the parser.

type="module"

<script type="module" src="app.js"></script>

Deferred by default (behaves like defer). Also enables ES module syntax (import/export). Module scripts are never parser-blocking.

modulepreload

<link rel="modulepreload" href="/modules/utils.js">

Here's a trick most developers miss. When you use ES modules, the browser discovers dependencies only as it parses each module. Module A imports Module B, which imports Module C — that's a waterfall of three sequential network requests. modulepreload lets you tell the browser about these dependencies upfront so it can fetch them in parallel.

<link rel="modulepreload" href="/modules/app.js">
<link rel="modulepreload" href="/modules/utils.js">
<link rel="modulepreload" href="/modules/api.js">
<script type="module" src="/modules/app.js"></script>

Without modulepreload, the browser discovers utils.js and api.js only after downloading and parsing app.js. With it, all three start downloading immediately.

Code Splitting: Ship Less, Parse Less

The most effective way to reduce JavaScript cost is to not send it in the first place. Code splitting breaks your application into chunks that load on demand.

Route-based splitting

Every modern bundler supports this. Instead of one giant app.js, you get a chunk per route:

Before: app.js (500KB)
After:  shared.js (80KB) + home.js (60KB) + dashboard.js (120KB) + settings.js (90KB)

The user visiting the home page downloads 140KB instead of 500KB. That's a 72% reduction in parse cost on the initial load.

Component-based splitting

For heavy components that aren't needed immediately:

import dynamic from 'next/dynamic'

const CodeEditor = dynamic(() => import('./CodeEditor'), {
  loading: () => <EditorSkeleton />,
})

const ChartDashboard = dynamic(() => import('./ChartDashboard'), {
  loading: () => <ChartSkeleton />,
})

The code editor and chart library only download when the user navigates to a view that needs them. The loading skeleton keeps the layout stable (preventing CLS) while the chunk loads.

The import() boundary

Every import() call creates a split point. The bundler generates a separate chunk that's loaded on demand:

button.addEventListener('click', async () => {
  const { openModal } = await import('./heavy-modal.js')
  openModal()
})

Until the user clicks that button, heavy-modal.js doesn't download, parse, or execute. Zero cost.

Measuring the Real Cost

Theory is nice, but you need to measure your actual application. Here are the tools that matter:

Chrome DevTools Performance Panel

Record a page load, then look for:

• Evaluate Script blocks in the flame chart — each is a file being parsed + compiled + executed
• Parse and Compile sub-tasks within those blocks
• Long Tasks (any task over 50ms) — these directly degrade INP

Coverage Tool

As mentioned above, the Coverage panel shows unused JavaScript per file. Sort by "Unused Bytes" to find your biggest offenders.

Lighthouse / PageSpeed Insights

The "Reduce unused JavaScript" audit flags files where more than 20KB is unused. It estimates the potential savings in milliseconds.

Bundle Analyzer

npx next build && npx @next/bundle-analyzer

This generates a visual treemap of your bundles, showing exactly which libraries consume the most space. A 150KB charting library imported for a single page is an obvious candidate for code splitting.

Reducing Parse Cost in Practice

Beyond code splitting, there are concrete techniques to reduce the parse burden:

1. Tree shaking

Modern bundlers eliminate unused exports. But tree shaking only works with ES modules (import/export), not CommonJS (require). Ensure your dependencies ship ESM builds.

// Tree-shakeable — bundler can drop unused exports
import { debounce } from 'lodash-es'

// NOT tree-shakeable — the entire lodash library is included
const { debounce } = require('lodash')

2. Avoid polyfills you don't need

Many applications ship polyfills for features already supported by their target browsers. Check your browserslist config and audit your polyfill bundle.

3. Compress aggressively

Brotli compression reduces JavaScript files 15-20% more than gzip. If your CDN supports Brotli (most do), enable it. A 200KB file compressed to 50KB with Brotli means 50KB to download and 200KB to parse — the parse cost doesn't change, but you save network time.

4. Defer non-critical scripts

Third-party scripts (analytics, chat widgets, A/B testing) should never block the initial render. Load them with async, or better yet, load them after the page becomes interactive:

if (typeof requestIdleCallback !== 'undefined') {
  requestIdleCallback(() => {
    const script = document.createElement('script')
    script.src = 'https://analytics.example.com/tracker.js'
    document.body.appendChild(script)
  })
}

This waits until the browser's main thread is idle before loading the analytics script. Your users get a fast initial experience, and the analytics load when there's nothing more important to do.

Common Mistakes

Key Rules

Quiz: Putting It All Together