Lesson 13 of 30

Docker Basics for Frontend Developers

Q: Why is Docker's build slow for this project, and how would you speed it up?

A strong answer covers: Docker caches each Dockerfile instruction as a layer, invalidating it (and everything after) when its inputs change; Copy package.json/lockfile and run install BEFORE copying the rest of the source, so dependency installs are cached independently of source changes; Multi-stage builds keep the final production image small by discarding the build toolchain.

Not a virtual machine — a way to package an app with everything it needs to run, so 'works on my machine' stops being a real category of bug.

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.

Question 1 of 2

A Dockerfile copies the entire source tree, then runs pnpm install. Every build re-runs the slow install step, even for a one-line CSS change. Why?

Docker doesn't support caching build steps at allCopying the whole source tree before installing invalidates the cache for every layer after it, including install, on any file changepnpm install always re-runs on every build regardless of Dockerfile structure

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 Docker Basics for Frontend Developers

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

Why is Docker's build slow for this project, and how would you speed it up?

A strong answer covers

Docker caches each Dockerfile instruction as a layer, invalidating it (and everything after) when its inputs change
Copy package.json/lockfile and run install BEFORE copying the rest of the source, so dependency installs are cached independently of source changes
Multi-stage builds keep the final production image small by discarding the build toolchain

Likely follow-ups

What's the practical difference between a container and a virtual machine?
Why does 'works on my machine' become less of a real problem with containerized deployment?
What would a multi-stage Dockerfile for a frontend app's build and serve steps look like?

Practice these with the AI interviewer →

The plain-language idea

A container packages your app's code together with its exact runtime environment — the Node version, installed dependencies, OS-level libraries — into one portable unit. Unlike a full virtual machine, containers share the host machine's OS kernel, which makes them dramatically lighter and faster to start.

FROM node:20-alpine
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile
COPY . .
RUN pnpm build
CMD ["pnpm", "start"]

Each line is a layer. Docker caches layers — if package.json hasn't changed since the last build, the pnpm install layer is reused from cache instead of re-run, which is exactly why COPY package.json happens before COPY . .: dependency installs (slow, changes rarely) get cached independently from source code (fast, changes constantly).

Docker: the same bytes, everywhere it runsStep 1 of 3

Dockerfile: FROM node:20; COPY .; RUN npm install; CMD npm start — a recipe for building an image.

What people usually miss

Watch out

Layer order is a real, common performance mistake. Copying the whole source tree before installing dependencies means any code change invalidates the cached install layer too — every build re-runs a slow pnpm install, even for a one-line CSS tweak.
A container is not a VM. No separate guest OS kernel, no full hardware virtualization — that's exactly why containers start in milliseconds-to-seconds instead of the minutes a VM boot takes, and why they're so much lighter on resources.
Multi-stage builds keep production images small — a build stage with the full toolchain (compilers, dev dependencies) produces the built output, and a separate final stage copies only that output into a minimal runtime image, discarding everything else.

Why this matters in interviews

Frontend roles increasingly touch containerized deployment, and "why is our Docker build so slow" is a genuinely common real question — correctly diagnosing it as a layer-caching/ordering issue is a concrete, practical signal beyond just knowing docker run exists.