I’ve been working with the latest version of Sage and noticed that since the migration to webpack 2, the build times have considerably increased. Straight out of the box, the build takes between 13 to 15 seconds.
I tried spending a bit of time researching to see if I could find any improvements to the current configuration, but with no luck.
Are you guys planning on looking into this as well?
FYI, if anyone is interested. I ended up reverting back to webpack1, which in my case only takes up to 3s to compile the bundles and also generates bundles lower in size.
My feeling is that webpack2 is still not stable enough for production. I’ll be happy to switch back to webpack2 once it’s stable.
I’m having the same issue with the Webpack v2 it takes more than 6 seconds to make simple CSS background-color change in base Sage theme. Previous version bundled with Sage 9.0.0-alpha.2 was way faster (about 2s in highly customized theme). I think that it might be related to the configuration and not to the Webpack 2 package itself.
I found various posts on github complainig about the slow compilation times for webpack2. Various solutions as well that I tried, but with no good luck.
At the moment, waiting for full re-build after each change (20 secs every time,…) is a killer in my workflow, and since I don’t have enough time at the moment to profile the current build, it was way easier for me to rollback to v1.
What I ended up doing at the moment is simply refactoring the build config in ES6 and split the build into two folders (v1 and v2) so that I can quickly switch between different systems if anything comes up.
A lot is going on with webpack2 lately and I just feel like it’s not the best time to use this package for production. Will definitely look again into it in a few weeks though as I don’t like the idea of sticking with old libs.
If you are looking to speed up webpack builds I would recommend you to take a look at https://github.com/mxstbr/react-boilerplate where webpack v2 builds are speed up with prebuilt DLL’s. Unfortunatelly I didn’t manage to adapt this to the sage theme.
Could you please share your webpack v1 build? I’ve tried to rollback v2 to v1 but eventually I end up with manually “upgrading” alpha.1 release to the folder structure of alpha.3 but without major webpack modifications.
You can check it out on my fork here:
Give it a go, hope it helps! Let me know if you find any issue and I’ll be happy to have a look and fix it! Cheers!
I found that setting the source maps to
eval brought compliation of SCSS down to a reasonable couple of seconds but PHP page loads are still a maddening 8s or more.
Refer to Webpack documentation for more info
So it is probably not connected with source map generation. For me removing source maps generation is not an option.
Any updates on this case?
@ian Changing #cheap-module-source-map does indeed increase the perfomance
but it isn’t blazing fast.
Reloading JS is far faster than reloading css.
Whats actually very slow is this part:
91% additional asset processing …
EDIT: +1 for @Nicolo_Sacchi and his fork.
@jmarceli This doesn’t remove the source maps generation. Have a look in the Webpack documentation for an explanation of the options for source maps.
@kregenrek I’ve been meaning to install the Gulp build from Sage 8 to compare. Though at around 1-2s for SCSS compilation at this stage of my project I am quite satisfied. What’s killing me is the 6-8s response time for http://localhost:3000. Whereas my http://***.local responds in 200ms.
I switched back webpack 1 (See @Nicolo_Sacchi 's fork). It does increase the perfomance a lot,
but its true the response time of http://localhost:3000 is slow, I agree. Why is that?
I switched back to v1 also. I’m not 100% sure where to track down the slow response on
localhost. Is it BrowserSync, is it NPM, is it Webpack? I’m going to run profiling on Webpack (first attempt failed) to see if that helps. I don’t think it’s a server response issue as
*.local responds well fast. It’s also beer o’clock and I doubt I will problem solve much more beyond finding the beer fridge.
@Nicolo_Sacchi Are you using Trellis or your own server configuration?
I have to agree with everyone else that Sage 9.0.0-alpha.3 with Webpack 2 compiles very slow compared to the Sage 9.0.0 with Webpack 1.
@ian If it helps you: For instance I use my own Server configuration (Debian).
Its pretty fast in my local network now (was testing before from home via vpn).
I’m glad my fork is helping you guys out!
No I’m not a trellis user, I work on valet most of my time since I’ve pretty strict rules for deployments from my clients.
I’ve been using the Sage 8 Gulp on a local homebrew nginx server similar to that on the Trellis VM. And I had no discernible performance issues.
I’ve only used the Webpack 2 (and Nicolo’s v1) with Trellis. I might have a go with the Weback v1&2 on my normal environment and see if the issue with server response time persists. I wonder if it’s something that could be resolved by switching from Virtualbox to Fusion / Parallels. I would use Fusion as I know it has a connector for Vagrant.
@kregenrek I’m getting somewhere. It looks like it’s a DNS issue with the guest OS. I’ve tried a few different things, and I’ve got
localhost:3000 response down from 5000 to ~160ms. Frustration down. Productivity up.
- I’ve switched from VirtualBox to VMWare Fusion
- I’ve disabled IPv6 on my host OS X 10.11
- I’ve changed hostname extension from
.vm (Apple reserves
.local and does some Bonjour and DNS caching juju with it)
- I’ve also found VirtualBox responding adequately with the following settings:
vb.customize ['modifyvm', :id, '--natdnshostresolver1', 'on']
vb.customize ['modifyvm', :id, '--natdnsproxy1', 'on']
vb.customize ['modifyvm', :id, '--nictype1', 'Am79C973']
When I get a cohesive set of steps that work, and have pinned down the issue, I’ll let you know.
So @Nicolo_Sacchi it looks like two issues were getting conflated in this thread. Those of us using Vagrant had real painfully slow server response, in addition to the Webpack 1 vs 2 compilation time issues.
I’m using the latest email@example.com and when I’m working on js files after saving it I can’t see any different behavior.
I have to stop the npm start command and then run it again.
I’m on Windows 10, anyone has been able to resolve it?