Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

docker build for nodejs 22.11.0 is considerably (3 minutes) slower than 21.3.0

Here is my docker file:

```dockerfile

FROM node:21.3.0
RUN apt-get -y update && apt-get -y upgrade && apt-get install -y ffmpeg && apt-get clean
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true
RUN apt-get update && apt-get install gnupg wget -y && \
wget --quiet --output-document=- https://dl-ssl.google.com/linux/linux_signing_key.pub | gpg --dearmor > /etc/apt/trusted.gpg.d/google-archive.gpg && \
sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \
apt-get update && \
apt-get install google-chrome-stable -y --no-install-recommends && \
rm -rf /var/lib/apt/lists/*
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
ENV CHROME_PATH "/usr/bin/google-chrome"
CMD ["yarn", "run", "serve"]
```
 
This builds pretty fast (3 minutes) but if you switch the node version to 22.11.0, it adds 3 minutes to the build (even after caching).
 
The difference in time occurs int the gcr.io/kaniko-project/executor:latest stage
0 2 330
2 REPLIES 2

Hi @uriv,

Welcome to the Google Cloud community!

The lengthy build time you observed with v22.11.0 compared with the older version may have a few contributing factors such as the difference of the base image size of both versions, and increase in delay caused by the version upgrade.

For the base image size, the one for v22.11.0 could be quite larger and have additional layers than v21.3.0. This may demand for longer download and setup times. To compare sizes of both images, you can check this page for more info. You can also consider testing things out with v22.11.0-slim while adding other required packages manually to observe if there’s any improvement.

When updating to v22.11.0, there’s a possibility that dependencies may require recompilation and existing packages may need respective updates (new dependencies can be verified by inspecting a “yarn.lock” file). This can contribute to lengthy build time in docker.

Also, does this increased build time remain constant during the next tests? You could also try exploring the use of “npm ci” in your dockerfile, compare it with “yarn install” then see if (1) it’s applicable to your use case and (2) it yields any speed improvements.

Even if caching was performed, it might be the case that the addition of new dependencies or heavier components had caused changes on “package.json” or “yarn.lock”, which makes it ineffective.

If the issue persists, I’d also recommend filing an issue in the official GitHub issue tracker for docker-node so that the development team of Node.js for Docker may conduct further analysis on these packages.

I hope this helps!

@KyleMari I'm attaching the logs of the stage that is the issue; ` gcr.io/kaniko-project/executor:latest`

the deploy stage lasts the same which implies this isn't a docker image download time issue

https://gist.github.com/uriva/9a966aac24bc16bc718ce4f91723b89c

https://gist.github.com/uriva/f71404ed26e5feb58d61f95ad37a1f94

In both cases this is not the first time the build runs, so you see the layers are cached, so this is not a docker build issue either iiuc.