Laravel-mix: Slow performance

[jericopulvera]

This is good but it compiles slower than laravel elixir gulp. why?

[JeffreyWay]

When I'm running npm run dev, assets recompile in 20 milliseconds.

[jbreuer95]

@jericopulvera try to do: npm run hmr. it really helps alot.
when i do npm run dev it takes 40 seconds because of the css-loader.

./~/css-loader 45421 ms
./~/postcss-loader
./~/resolve-url-loader
./~/sass-loader?sourceMap
./resources/assets/sass/app.scss

[dluague]

@JeffreyWay have you try compiling bootstrap-sass v4 because I try it and it takes a minute on my end.

[dluague]

Removing "?sourceMap" in sass-loader in webpack.config.js makes my build from 60+s to 3s.

[OwenMelbz]

I'm getting same issues, I branched before trying mix out.

Have 1 branch compiling .scss files in 1123ms via Elixir
Have 1 branch compiling same .scss files in 5224ms via Mix

Removing ?sourceMap didn't do much for me :(

Additionally when using .copy and npm run hot it fails as says the webpack server copy uses newer than the version in Mix.

@JeffreyWay I could share a repo with you if you're interested to see if you can identify the reason?

[jericopulvera]

This slow performance happens to me when I run npm inside my virtual machine.
fixed it long ago by running the command outside the virtual machine.

[OwenMelbz]

I'm not using any form of virutialisation, straight up node from Brew

[JeffreyWay]

The initial compile can be slow, but are you all using npm run watch? That should be significantly faster.

[OwenMelbz]

I had hoped that, however sadly no, bother either hmr or watch modes both compile slowly, that's what my above benchmark was based on :(

Would it be any use for you to see the actual files I can extract them into a repo to check?

[rockymontana]

This is what I get on npm run watch after adding " !important" in one file.

DONE Compiled successfully in 8534ms

Asset Size Chunks Chunk Names
/admin/js/app.js 379 kB 1, 2 [emitted] [big] /admin/js/app
/admin/css/app.css 686 kB 1, 2 [emitted] [big] /admin/js/app
mix-manifest.json 232 bytes [emitted]

And that's faster than it usually is for me. Most of the time I'm at the double.
However, I'm extracting 11 libraries... Could that have anything to do with it?

[JeffreyWay]

I pushed a commit that should speed up compilation a good bit.

f5cb20274c24258dfb5c18741e627cc6235f03a6

[dobromir-hristov]

I have a verison of webpack.config that does NOT have what @JeffreyWay has pushed, still uses the old sass-loader, and version on npm is 0.8.1 (mine also) but on github its 0.8.0 😆

[abinadave]

JeffreyWay Please help.

when i try to run: npm run dev
it seems to be very slow. and no progress

11% building modules 9/14 modules 5 active ...onents\granted\granted-assistance .vue

[abinadave]

@JeffreyWay

Please help, I am Stuck.

when i try to run: npm run dev
it seems to be very slow, 1-2 hrs of waiting.. and theres no progress.

11% building modules 9/14 modules 5 active ...onents\granted\granted-assistance .vue

[rockymontana]

Hello. Here's an update since my last comment and with the newest release of Mix installed.

When I run npm run watch since the last update I loose all my CSS and get some problems with the JavaScript (buttons don't register clicks and stuff so should be something with the JS).

So now I run npm run dev manually before refreshing.

[kiwina]

Just updated last night to the latest version and scss is terribly slow now.
did a bit of testing and anything above 6.3 scss takes forever

[howdu]

Wow that was easy try disabling url processing it fixed the issue for me, back to seconds compared to the painfully slow minutes it was taking before building bootstrap-sass on windows.

If only I'd checked the docs earlier. All my urls are absolute and very rarely change.

mix.sass('resources/assets/app/app.scss', 'public/css')
   .options({
      processCssUrls: false
   });

[osugregor]

Thanks @howdu

My build went from 168445ms to 1292ms

@JeffreyWay, not sure if this information should result in a re-open?

[Okipa]

+1 @howdu. Thanks for your tip, you saved my day !

[alexandrufulop]

I am getting a terrible performance: DONE Compiled successfully in 17711ms :(

Running the latest Homestead 2.0.0 (VM - Virtualbox) with:
npm -v: 4.1.2
node -v: v7.6.0
and "laravel-mix": "^0.8.8",

Any places to look for further faults?

Thanks!

[Okipa]

Did you tried to shutdown url processing as adviced by howdu ?

[alexandrufulop]

UPDATE (Solution): The only way I could make laravel-mix work FAST was like this:
I decided to compile the assets on the host windowz machine and not in the homestead VM as I wanted.
On a Windowz machine, I have the homestead (2.0.0) VM installed in VirtualBox using Vagrant .

Main steps to follow:
1) remove all the node_modules
2) uninstall and reinstall to the latest node.js on the host machine (windowz)
3) check your "npm -v"
4) open a git bash or a cmd in your working directory
5) run: npm install --save
Check your stuff with: npm ls
and also check your package.json
mine looks like this now:

{
  "private": true,
  "scripts": {
    "dev": "cross-env NODE_ENV=development webpack --progress --hide-modules",
    "watch": "cross-env NODE_ENV=development webpack --watch --watch-poll --progress --hide-modules",
    "hot": "cross-env NODE_ENV=development webpack-dev-server --inline --hot",
    "production": "cross-env NODE_ENV=production webpack --progress --hide-modules"
  },
  "devDependencies": {
    "axios": "^0.15.3",
    "cross-env": "^3.2.4",
    "jquery": "^3.1.1",
    "laravel-mix": "^0.8.8",
    "lodash": "^4.17.4",
    "node-sass": "^4.5.0",
    "vue": "^2.1.10"
  },
  "dependencies": {
    "bootstrap-sass": "^3.3.7",
    "bootstrap-social": "^5.1.1",
    "font-awesome": "^4.7.0",
    "jquery": "^3.1.1",
    "toastr": "^2.1.2"
  }
}

6) npm run watch

Everything works fine and fast now!

[firescript]

thanks @howdu 👊

[xitude]

+1 to @howdu. Fixed my lock up.

[ghost]

+1 @howdu. Thanks man. You made my day!

[ivanvermeyen]

After upgrading from Elixir to Mix I also had very slow performance at the first compile and when watching for changes... I do have many SCSS files... Setting processCssUrls: false as @howdu said brought the compile time from 16922ms to 4795ms 👍

Big thanks to @JeffreyWay for bringing us Mix (and so many other goodies)! #respect !

[KerryJones]

+1 @howdu -- it went from ~2 minutes to 5 seconds or so.

[rodrigogoncalves]

I also had to use solution by @howdu to get Mix to work in my Homebrew box (Windows host), but I think it would be better if we could get to the actual root of the issue and solve it.

Perhaps this has to do with the usage of virtualization. I see many people with the same virtualized setup as mine having this issue, while others that are running it in the native OS are not.

[OwenMelbz]

@rodrigogoncalves sadly not true :D We've got several native macOS machines of different spec with latest updates, and still had the issue.

[ivanvermeyen]

@rodrigogoncalves

It would be great if the problem can be solved, in case we do need/want to process the images... I was actually considering this, because I would like to enable browsercaching...

I'm running macOS sierra with Laravel Valet. PHP and MySQL etc. is all installed via Homebrew. So I'm not using any VM.

$ node -v
v7.10.0

$ npm -v
4.2.0

[rodrigogoncalves]

Should this ticket be closed?

[ruchern-chong]

@JeffreyWay Issue seemed to have been resolved. @rodrigogoncalves Just ping him.

[rodrigogoncalves]

@ruchern, what I mean was: "Should this ticket _really_ be closed, or should it be open, since the issue is still not solved?"

[ivanvermeyen]

I think the issue is resolved in the 1.0 beta, at least when I tried it. But that wasn't versioning yet etc., so I'm waiting till the 1.0 release to use this feature. 👍

[benyanke]

Is there an option (or could there be @JeffreyWay ) where the URLs can be cached for a certain amount of time?

We're using some google fonts, and while of course we want to keep up with the latest version, it's pointless bandwidth and time to fetch those and recompile every time we make a change. It could certainly could be cached fr 12 or 24 hours with no major consequence when running npm run dev - and of course no cache on npm run prod.

[darthchudi]

@howdu thanks a lot!

[rderks88]

By turning of compress in mix.options (running "npm run production") I got a 50% build decrease with a 3% increase in resulting js size. No idea what the big downside is in this case. Any ideas? Take a look at the output differences below. For anyone interested in code-copy-pasting:

mix.options({ uglify: { compress: false }, });

50% reduced compilation time

DONE Compiled successfully in 47394ms 14:39:31

                            Asset     Size  Chunks                    Chunk Names
       /js/chunkCourse.5f77bddf5501b2e821c3.js  84.3 kB      16  [emitted]         /js/chunkCourse
    /js/chunkChallenge.438a9c95017023973658.js  1.55 MB       0  [emitted]  [big]  /js/chunkChallenge
     /js/chunkDeadline.246920bf2d4aae8a0d50.js   251 kB       2  [emitted]  [big]  /js/chunkDeadline
         /js/bootstrap.7aa2a30468327f12f3b8.js   497 kB       3  [emitted]  [big]  /js/bootstrap
         /js/chunkHome.c0940edefa388334c74e.js   148 kB       4  [emitted]         /js/chunkHome
    /js/chunkDiscovery.c93cd081a10f3f9940ab.js   149 kB       5  [emitted]         /js/chunkDiscovery
    .....................................................................................................
             /css/app.df79f54f06796ccbed33.css   113 kB       3  [emitted]         /js/bootstrap
             /css/pdf.df79f54f06796ccbed33.css  2.59 kB       3  [emitted]         /js/bootstrap
                             mix-manifest.json  2.21 kB          [emitted]

Long compilation time

DONE Compiled successfully in 103691ms 14:41:41

                            Asset     Size  Chunks                    Chunk Names
       /js/chunkCourse.5f77bddf5501b2e821c3.js  79.5 kB      16  [emitted]         /js/chunkCourse
    /js/chunkChallenge.438a9c95017023973658.js  1.52 MB       0  [emitted]  [big]  /js/chunkChallenge
     /js/chunkDeadline.246920bf2d4aae8a0d50.js   244 kB       2  [emitted]         /js/chunkDeadline
         /js/bootstrap.7aa2a30468327f12f3b8.js   449 kB       3  [emitted]  [big]  /js/bootstrap
         /js/chunkHome.c0940edefa388334c74e.js   143 kB       4  [emitted]         /js/chunkHome
    /js/chunkDiscovery.c93cd081a10f3f9940ab.js   144 kB       5  [emitted]         /js/chunkDiscovery
    .....................................................................................................
             /css/app.df79f54f06796ccbed33.css   113 kB       3  [emitted]         /js/bootstrap
             /css/pdf.df79f54f06796ccbed33.css  2.59 kB       3  [emitted]         /js/bootstrap
                             mix-manifest.json  2.21 kB          [emitted]

[ruchern-chong]

Technically your file are so small in size that the compression ratio is not high.

[dominiquevilain]

Fresh Laravel install here. Just made an npm install and tried to npm run dev with the sample files. Using the latest homestead (installed a fresh one yesterday).
Compile time is around 17 seconds… Same with other npm scripts, compile time is huge.
With Howdu's workaround, gets down to around 10 seconds…Still very long.
Can’t imagine what will happen when resources will grow up in my app :/

[ruchern-chong]

@dominiquevilain not to worry. How often do you want to compile your assets? Even on development, you are going to use the water anyway. Watch will compile for the first time and subsequently only makes delta compilations.

[dominiquevilain]

@ruchern Watch task isn’t recompiling anything at all… Just added a property to the exampleComponent provided with the fresh install of Laravel, tried to use it somewhere in the component. The watch task ignores it when i save. Worth to mention that at the end of the npm install, i've got a warning about the impossibility to install fsevent on the linux used by homestead. So fsevent is not installed. I will try with a native OSX configuration instead of the homestead VM.

[dominiquevilain]

Back to MacOS instead of Homestead. Everything is fast… And the Watch script works!

[SignetPlanet]

@dominiquevilain , I have the same issue running a vagrant homestead Laravel box on a windows 10 host machine. I've removed all the other imports (like bootstrap) and with just maybe 200 lines of scss in all at this point. "npm run dev" takes around 15 seconds (with urls disabled) and "npm run watch" does not detect any changes to anything. It looks like it has something to do with the vagrant sharing the drive with windows and how homestead has configured a few things that don't play well with window hosts. I tried going back to my old tried and tested method of using using node-sass, concat, postcss and nodemon.js for watching and building the css and watching works as it should and it takes just a fraction of a second. I didn't have this issue with a previous project but to be honest I don't think this is the laravel-mix change but changes made to the homestead Laravel project.

[legshooter]

Win10, running locally, and none of the solutions worked for me (including @howdu's).

Compiling always takes 15-20 seconds. sass() and less() being the problematic ones. Super frustrating.

[exfriend]

@legshooter check if you have any .scss imports from node_modules and see if you can import .min.css instead. Might seem obvoius but still.

[legshooter]

@exfriend only Bootstrap. Thanks though.

Update:

I was up to ~54 seconds for npm run prod.

But now my whole setup is Mix-ed, and after dropping some heavy dependencies and moving from Less to Sass, it's down to ~33 seconds.

npm run dev is at ~13 seconds, and npm run watch's incremental builds are done almost momentarily, so coupled with Browsersync I finally got to the desired improved development experience.

[SlyDave]

This might help some having problem with getting their syntax correct with how to set uglify options as a bunch of the examples above do not work (produce errors about how compress isn't a valid option)

mix.js('resources/js/app.js', 'public/js')
   .sass('resources/sass/app.scss', 'public/css')
   .sass('resources/sass/admin.scss', 'public/css')
    .options({
        processCssUrls: false,
        uglify: {
            parallel: 8, // Use multithreading for the processing
            uglifyOptions: {
                mangle: true,
                compress: false, // The slow bit
            }
        }
    })

[ashikjs]

Wow that was easy try disabling url processing it fixed the issue for me, back to seconds compared to the painfully slow minutes it was taking before building bootstrap-sass on windows.

If only I'd checked the docs earlier. All my urls are absolute and very rarely change.

mix.sass('resources/assets/app/app.scss', 'public/css')
   .options({
      processCssUrls: false
   });

@howdu You save my day :)