Upgrade to 0.12.1 is causing performance issues while building

[cutemachine]

I just updated my project to use the latest Gatsby version 0.12.1 (0.12.2 has the same prob).

My project has over 180 images. When I do gatsby develop my whole computer becomes very slow. There are over 30 optipng (sometimes pngquant) processes in the process list.

It takes several minutes until I see the first webpack build message in the console:

webpack built af83c42da1ddf7d73ed0 in 402319ms

I have no special setup regarding images in my gatsby-node.js file.

The normal build is also causing the same issue. I would be very grateful for any hints on how to resolve the issue.

[KyleAMathews]

Hmmm that's bad. Image optimization was added for 0.12 (
https://github.com/gatsbyjs/gatsby/releases/tag/v0.12.0) but clearly this
causes problems if you have a lot of images. I can give you more explicit
instructions when I'm near my laptop again but basically you'll want to
modify the default image loader to disable image optimization and just use
a simple file loader.
On Sat, Jul 30, 2016 at 1:23 PM Jo Meenen notifications@github.com wrote:

I just updated my project to use the latest Gatsby version.
The project has over 180 images. When I do gatsby develop my whole
computer becomes very slow. There are over 30 optipng (sometimes pngquant)
processes in the process list.

It takes several minutes until I see the first webpack build message in
the console:

webpack built af83c42da1ddf7d73ed0 in 402319ms

I have no special setup regarding images in my gatsby-node.js file.

The normal build is also causing the same issue. I would be very grateful
for any hints on how to resolve the issue.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#370, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEVhz-XcW-KBgqw9691EvDFTQmtsJKbks5qa7LRgaJpZM4JY4uH
.

[cutemachine]

Thanks Kyle for the quick response. I downgraded to 0.11.7 which works perfectly.

What do you think about moving the image optimization to a pre-build step? Whenever I add an image, I just run a script and add the optimized images to the git repo.

Would be great if you could drop me a line on how to add that default image loader. No rush though. Thanks again for Gatsby :)

[tribou]

I also hit a perf issue with image-webpack-loader and ended up using it only for production builds:

/gatsby-node.js

exports.modifyWebpackConfig = function (config, env) {

  if (env === 'develop') {
    imageLoader = 'url-loader?limit=10000'
  }
  else {
    imageLoader = 'url-loader?limit=10000!image-webpack'
  }

  config.removeLoader('images')
  config.loader('images', {
    test: /\.(jpe?g|png|gif|svg)$/i,
    loader: imageLoader,
  })

  return config
}

However, in the end, I removed it entirely and started running any new images through ImageOptim once manually to make both dev and prod builds much faster. 😉

*edited to match latest gatsby source.

[cutemachine]

Thanks tribou.

I use this in my gatsby-node.js file:

  config.removeLoader('images');
  config.loader('images', {
    test: /\.(jpe?g|png|gif|svg)$/i,
    loaders: [
      'file-loader'
    ],
  })

And optimize my images manually with something like this:

pngquant --force --ext .png */*.png

@KyleAMathews Please, feel free to close the issue. Cheers.

[dardub]

Besides number of images, we're also running into long compile times for larger images. Between the marketing department and designers we're stuck with using large pngs for a current project. :(

[KyleAMathews]

hmmm... looks like this feature was a flop :-) I'll remove it in the next minor breaking release. I'm planning on adding a plugin system (finally) soon so image optimization being added to Webpack would be a great plugin (with the caveat in the README that it's not optimal if you have a lot of images).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed due to inactivity.