Slow autoreload

Is there a way to speed up Strapi when auto reloading? Strapi takes about 4-8 seconds each time I modify a controller.

I have pm2 starting strap by launching npm develop in a processes.json script.

What strapi version do you use? I noticed with outdated versions have longer restarts.

v3.0.1 → ~6-8seconds (thats an older project that I forgot to update and it has the old node_modules/cache folder)

v3.2.4 → ~1.5seconds (another project that I keep up-to-date)

How I’ve fixed reloads on that older version:

Delete cache/build/modules:
rm -rf .cache build node_modules

Reinstall all the packages
yarn install

Build the admin:
yarn build --clean

See the result for v3.0.1, it now has the same reload speed as v3.2.4

I did create the project using an old 3.0.0 alpha version. I’ve upgraded to 3.2.5 but was still getting long reloading times.

I tried following your instructions. I did the rm command and yarn install. Those went through fine. But when I did
yarn build --clean

I got this

yarn run v1.22.4
$ strapi build --clean
Building your admin UI with development configuration ...

● Webpack █████████████████████████ building (22%) 103/137 modules 34 active

Error: Module not found: Error: Can't resolve '../../plugins/strapi-plugin-content-manager/admin/src' in '/Users/komocode2/Documents/Workspace/carrie-strapi/.cache/admin/src'
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/strapi-admin/index.js:70:23
    at finalCallback (/Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compiler.js:257:39)
    at onCompiled (/Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compiler.js:265:20)
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compiler.js:670:21
    at eval (eval at create (/Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:28:1)
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compilation.js:1173:13
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compilation.js:1096:25
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compilation.js:1017:13
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2830:7
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2830:7
    at done (/Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2863:11)
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2818:7
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/webpack/lib/Compilation.js:1017:13
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2830:7
    at /Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2830:7
    at done (/Users/komocode2/Documents/Workspace/carrie-strapi/node_modules/neo-async/async.js:2863:11)
error Command failed with exit code 1.
info Visit for documentation about this command.

Seems that .cache folder still exists. Or the argument “–clean” tries to delete the cache folder but it doesn’t exist. Can you check? If it exists then delete it. And try to run strapi with: yarn develop. As it will build the .cache folder anyway.

purge your package-lock.json, yarn.lock, node_modules, build, and .cache then reinstall the node_modules and rerun the build. You have some old cached package somewhere. probably 75% of the time I see this, it’s related to the use of npm which is quite a bit slower than yarn (for installs and builds, it’s quite inefficient in node module resolutions)

I’ve deleted node_module, build, .cache, and yarn.lock. I’ve run strapi build --clean then yarn develop.

I’m getting:
Launched in │ 4672 ms

Is this how long it usually takes? I’m on a MacBook Pro 2018 15" with a speedy flash drive.

Screen Shot 2020-10-28 at 9.33.01 PM

Do you have nvm installed? Can you make a test and try with another node version? As I see you are on v14.9.0 and I’m curious if node version is affecting your performance.

I’m using v12.18.4 and it launches in 1.5seconds~

This also largely depends on:

  • your database
  • number of models
  • complexity of models

A personal project I have has roughly 95-ish models that can get pretty complicated on relations and takes about 20-30 seconds to load properly. During the boot up Strapi checks the database to ensure its not missing any tables or columns, and double checks that every route has a permissions entry.

Using 12.19.0, still getting about 5 seconds.

Screen Shot 2020-10-29 at 1.15.32 PM

It’s a fairly new project, I only have 1 simple model.

Since it’s still a fairly new project, I’ll try recreating the project and transition over the data.

I have a speed issue with all my strapi projects. In the following project, I have just one model now with AWS RDS postgresql db. Any idea how to improve the speed?

1 Like

Have you tried to switch to a local db to see what’s the difference in launch time?

Thank you, I tried with local db. the launch time went down to 5000ms, which is still painful but seems a big improvement. What happens at the launch in the background with the db?

It verifies if all the tables, columns, configs exist.

Is it possible to turn it off temporarily? For example, when I am developing an endpoint functionality without bothering with the data models.

You can try setting the autoMigration to false under options (see: Configurations - Strapi Developer Documentation )

But that may only disable our specific migrations for certain upgrades/field changes.

I just migrated my project’s strapi from 3.0.6 to 3.6.8 and I did remove package-lock.json and node-modules before running npm i again and then npm run build --clean.
Yet, my autoreload time got much slower! It has nothing to do with number of modules nor cloud/local databases or whatsoever. Everything is the same except the migration additions and modifications!
When I reset my code back to before the migration commit, it gets much faster!

Any update for this slow autoreload?