Lesson 65 of 80

Dynamic import() and Code-Splitting

Q: Walk through how you'd use dynamic import() to avoid shipping a heavy library to users who never touch the feature that needs it — and how that's actually enforced under the hood.

A strong answer covers: import() is called at runtime and returns a promise, unlike static import which resolves before any code runs; A concrete trigger point (a click handler, a route change) that calls import() lazily; The bundler turns the dynamically imported module into a separate chunk, fetched only when that code path runs; Module results are cached — repeated import() calls to the same specifier don't re-fetch.

A static import runs at load time, whether you need the module yet or not. import() runs on demand, returns a promise, and is the mechanism every bundler's code-splitting is built on.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Dynamic import() and Code-Splitting

What interviewers actually ask about this, and what a strong answer has to cover.

Walk through how you'd use dynamic import() to avoid shipping a heavy library to users who never touch the feature that needs it — and how that's actually enforced under the hood.

A strong answer covers

import() is called at runtime and returns a promise, unlike static import which resolves before any code runs
A concrete trigger point (a click handler, a route change) that calls import() lazily
The bundler turns the dynamically imported module into a separate chunk, fetched only when that code path runs
Module results are cached — repeated import() calls to the same specifier don't re-fetch

Likely follow-ups

If two different components both dynamically import the same module, does the network request happen twice? Why or why not?
Is import() a bundler feature or a real part of the JavaScript language? What would happen with no bundler at all?
How is this different from module federation — are they the same thing?

Practice these with the AI interviewer →

The plain-language idea

A regular import Chart from "chart.js" at the top of a file is static — it has to be resolved before any of the module's code runs, so Chart ships in the initial bundle whether the user ever opens the chart screen or not. import(), the function form, is different: it's a call you make at runtime, wherever you like, and it returns a promise that resolves to the module. Nothing gets fetched until that call actually happens.

That one difference is the entire mechanism behind "code-splitting." Bundlers like webpack, Vite, and Next.js's own compiler see a dynamic import() and automatically carve the imported module into its own chunk, loaded lazily instead of bundled up front.

See it in a real thing: loading a heavy module on demand

async function openChartPanel() {
  const button = document.querySelector("#show-chart");
  button.disabled = true;
  button.textContent = "Loading…";

  const { renderChart } = await import("./chart-renderer.js");

  renderChart(document.querySelector("#chart-container"));
  button.disabled = false;
}

document.querySelector("#show-chart").addEventListener("click", openChartPanel);

chart-renderer.js — and whatever heavy charting library it pulls in — never gets fetched or parsed until someone actually clicks the button. If they never click it, that code never costs the user anything. Compare that to a static import { renderChart } from "./chart-renderer.js" at the top of the file: it would load on every page visit, whether the chart is ever shown or not.

import() also accepts an expression, not just a string literal — import(./locales/$.js) — which is how apps lazily load one of many possible modules (a locale, a route, a plugin) based on something only known at runtime.

What people usually miss

Watch out

A dynamic import doesn't re-fetch on every call. The module registry caches by resolved specifier — call import("./chart-renderer.js") from ten different places and the network request happens once; every call after the first resolves instantly from the cache.
The chunk boundary is decided by the bundler, not the language. import() is a real ECMAScript feature that works in browsers with no bundler at all — but the "separate file, loaded on demand" behavior you associate with code-splitting is a bundler convention layered on top, not something the spec guarantees.
"Module federation" is a step beyond this, not a synonym for it. Dynamic import() loads code that was already known about at build time, just deferred. Module federation (a webpack/Vite concept) goes further — loading a module from a separate build, owned by a separate team or deploy, that your app didn't even know about when it was compiled. This lesson covers the language feature; federation is an architecture built on top of it.

The genealogy: promises, one more time

import() is just another promise-returning function — the same .then()/await handling you'd use for a fetch call works here unchanged. If promises already make sense, there's nothing new to learn about how to consume a dynamic import, only when reaching for one pays off.