Foundation-sites: Foundation Template Build Time

[phifa]

is awfully long. Why? Babel? Webpack? My setup is on a SSD, but in larger project the watcher needs up to a minute to transpile and reload the browser. IMHO build time should be <1s to work fast. Performance is one of the USPs of Foundation and being able to quickly develop a prototype. So, what's stopping this? Would like to hear everybody thoughts on this.

[marcoValkyriweb]

Have you tried using yarn? My project compiles in under ten seconds, though admittedly I do clean up a lot of unnecessary modules (that aren't used in my project). Using yarn start, a change reflects/compiles in 1.1s and browsersync refreshes instantly. This is on a i7 4720HQ.

Using npm, it's 3.2s

[DanielRuf]

Which node modules do you use in your build setup?

[phifa]

@marcoValkyriweb I am not using yarn. I am literally just using the default setup @DanielRuf and adding a little bit of scss and javascript and it slows down a lot. The build time for production is not what concerns me, more the watch time. HTML changes are detected fast, but JS and SCSS just takes a long time.

[DanielRuf]

Isn't gulp used by default? Did you try a clean webpack setup? In my experience an incremental webpack build was much faster.

[marcoValkyriweb]

@phifa my JS and SCSS changes are within half a second of saving (as in change detected to start the compile), npm is also quite fast though.

To use yarn:
first install global: https://yarnpkg.com/lang/en/docs/install/
in the project root/directory where you run npm start, run yarn once (only for project specific set-up)
Then use yarn start for development and yarn build for production.

https://www.sitepoint.com/yarn-vs-npm/
https://blog.oharagroup.net/npm-v5-3-0-vs-yarn-0-27-5-speed-c9d3be07b557

Changing SCSS:

[11:50:41] Starting 'sass'...
[Browsersync] 1 file changed (app.css)
[11:50:42] Finished 'sass' after 1.31 s

For the following code, including adding the file to my app.scss:

.footer-container {
    background-color: $gray-footer;
    color: white;

    h3 {
        color: white;
    }
    a {
        color: white;
    }
    p {
        margin-bottom: unset;
    }
    svg {
        color: $secondary-blue;
    }
    background: { //added this one to add more specifics
        color: red;
        repeat: unset;
    }
}

[CGTS]

I was running into ~30s compile times after every save. I had over 300 pages and a lot of partials but it still seemed excessive.

I ended up adding the following to my gulp pages task

function pages() {
  return gulp.src('src/pages/**/*.{html,hbs,handlebars}', { since: gulp.lastRun(pages) })

My page now compiles in about a second or so. The only issue is when you make a change to a partial you will also need to go to the page it is being imported into and save that page as well. It's irritating but the increase in speed is worth it.

[DanielRuf]

Like I wrote, Gulp is probably the issue imo.

[phifa]

Will Gulp even be needed in the future? @kball @IamManchanda @rafibomb? If the next release of Foundation only uses Webpack, I'm happy to ignore it and wait.

[colin-marshall]

@phifa please try making the following changes in your package.json and do a before/after comparison to see if you get any speed improvments:

"babel-loader": "^7.1.2",
"gulp-sass": "^3.1.0",
"webpack": "^3.1.0",
"webpack-stream": "^4.0.0",

Bumping gulp-sass went from 5s to 3s on a fresh clone of the foundation-zurb-template. Curious to see how much gain there is on larger projects and if it also applies to JS with webpack.

[colin-marshall]

Also, in FoundationPress we recently had a user switch the JS watch to use webpack's native watcher function instead of gulp and we saw a performance increase.

https://github.com/olefredrik/FoundationPress/pull/1169

Maybe this is something we should look into doing for Foundation to get some performance increase in the short term while we're still using gulp.

[phifa]

@colin-marshall I changed the lines you suggested. I got a little speed improvement for my scss files. Not significant though. But I don't think scss is the problem.

@CGTS I don't think the html files (partials, layouts, templates) are the problem. The transpile time for the html files is under 1 second.

The Javascript Webpack watching is the main issue. I am working on different projects. I have just started one where I only added two jquery libraries (fancybox and mmenu) and my transpile time is already around 5s (Windows 10, SSD).

@colin-marshall Why are we still using Gulp? I like the idea of completely moving to Webpack, less dependencies = less things that can cause trouble.

[DanielRuf]

Mh, what are your node and npm version?

[phifa]

@DanielRuf

Node.js 8.9.2 (x64)
npm 5.5.1

[phifa]

I am working on a bigger project now, this is how long it takes for JS to transpile:

[10:58:40] Starting 'javascript'...
[10:58:54] Version: webpack 2.7.0
 Asset     Size  Chunks                    Chunk Names
app.js  2.83 MB       0  [emitted]  [big]  app

[10:58:55] Finished 'javascript' after 15 s

[DanielRuf]

Webpack 2.7 is quite old. There is webpack 3 and 4 (beta).
Also 2.8 MB is quite much. Is this the production or dev mode?

[phifa]

@DanielRuf yeah I tried @colin-marshall's suggestion on another project, now I also updated this project to webpack 3.10.0, not changing much. I agree, it is a big file, it includes a few libs. Why does Webpack always have to transpile all files, even the libs in node_modules? I am making minor changes in my app.js and still it builds everything from scratch.

[11:23:03] Starting 'javascript'...
[11:23:16] Version: webpack 3.10.0
 Asset     Size  Chunks                    Chunk Names
app.js  2.83 MB       0  [emitted]  [big]  app

[11:23:16] Finished 'javascript' after 12 s
[11:23:16] Starting '<anonymous>'...
[Browsersync] Reloading Browsers...

[brettsmason]

@phifa I've not been part of this discussion so apologies if anything I say has been covered...
Have you tried excluding node_modules in your Webpack rules? Here's an example of what I mean.

[DanielRuf]

@phifa I've not been part of this discussion so apologies if anything I say has been covered...
Have you tried excluding node_modules in your Webpack rules? Here's an example of what I mean.

This should be normally the case with most default rules for the js loaders. Without this webpack checks the whole node_modules directory.

[colin-marshall]

If we switched everything to webpack, would we have to use sass-loader? If so, it sounds like that will introduce its own set of performance issues.

https://github.com/webpack-contrib/sass-loader/issues/296

[colin-marshall]

@conorbarclay if you have time, could you please look into switching the JS watch task here and on the Foundation Zurb Template? Thanks!

[Geddo]

same for me. The building process with standard "foundation watch" needs apx. 35-40seconds (standard foundation JS + ONE small JS with some scrolling events). Way too long while developing JS-Scripts IMHO
i7@4Ghz, SSD (no M.2 :-() Win10

[colin-marshall]

@Geddo is this on the first time building after running foundation watch and rebuilding, or just when it rebuilds?

[DanielRuf]

I have completely switched a project to webpack. I will test the performance, analyze the build time and share the example setup.

[phifa]

@DanielRuf so you took out gulp? anything else you had to take out?

[DanielRuf]

@DanielRuf so you took out gulp? anything else you had to take out?

Yes, we completely removed gulp from one of our test setups and migrated to webpack ("webpack": "^3.10.0").

[DanielRuf]

[10:48:44] Starting 'default'...
[10:48:44] Starting 'build'...
[10:48:44] Starting 'clean'...
[10:48:44] Finished 'clean' after 4.73 ms
[10:48:44] Starting 'sass'...
[10:48:44] Starting 'javascript'...
[10:48:44] Starting 'images'...
[10:48:44] Starting 'icons'...
[10:48:44] Starting 'copy'...
[10:48:46] Finished 'images' after 2.51 s
[10:48:53] Version: webpack 2.7.0
...
[10:48:53] Finished 'sass' after 9.14 s
[10:48:53] Finished 'javascript' after 9.15 s
[10:48:53] Finished 'copy' after 9.21 s
[10:48:53] Finished 'icons' after 9.65 s
[10:48:53] Finished 'build' after 9.66 s
[10:48:53] Starting 'watch'...

pure webpack (3.10.0):

webpack --config webpack.dev.js

Webpack is watching the files…

Hash: 5651d35fb68e4f1d932b
Version: webpack 3.10.0
Time: 4568ms

And this is the dev mode.

The same config with the production mode takes around 7-8 seconds (large project)

webpack --config webpack.dev.js -p

Webpack is watching the files…

Hash: 60ee65cda7fbff64e425
Version: webpack 3.10.0
Time: 8277ms

webpack --config webpack.dev.js --progress --profile
 10% building modules 1/1 modules 0 active                                    
Webpack is watching the files…

2922ms building modules
p 3ms sealing 
0ms optimizing 
0ms basic module optimization 
2ms module optimization 
0ms advanced module optimization 
1ms basic chunk optimization 
0ms chunk optimization 
2ms advanced chunk optimization 
0ms module and chunk tree optimization 
0ms chunk modules optimization 
0ms advanced chunk modules optimization 
0ms module reviving 
0ms module order optimization 
1ms module id optimization 
1ms chunk reviving 
0ms chunk order optimization 
2ms chunk id optimization 
10ms hashing
0ms module assets processing 
18ms chunk assets processing
1ms additional chunk assets processing 
0ms recording 
1ms additional asset processing 
578ms chunk asset optimization
1134ms asset optimization
35ms emitting
Hash: 5651d35fb68e4f1d932b
Version: webpack 3.10.0
Time: 4724ms

webpack --config webpack.dev.js -p --progress --profile
 10% building modules 1/1 modules 0 active                                         
Webpack is watching the files…

4731ms building modules                                                               
2ms sealing 
0ms optimizing 
0ms basic module optimization 
2ms module optimization 
0ms advanced module optimization 
0ms basic chunk optimization 
0ms chunk optimization 
2ms advanced chunk optimization 
0ms module and chunk tree optimization 
0ms chunk modules optimization 
0ms advanced chunk modules optimization 
1ms module reviving 
0ms module order optimization 
0ms module id optimization 
1ms chunk reviving 
0ms chunk order optimization 
2ms chunk id optimization 
12ms hashing
0ms module assets processing 
17ms chunk assets processing
1ms additional chunk assets processing 
0ms recording 
1706ms additional asset processing
674ms chunk asset optimization
1053ms asset optimization
28ms emitting
Hash: 60ee65cda7fbff64e425
Version: webpack 3.10.0
Time: 8247ms

Not sure if Gulp provides any profiling.

npm --version && node --version
5.5.1
v8.9.0

[DanielRuf]

So ~7s Sass in Gulp vs ~2-3s with webpack (node-sass / sass-loader). Also webpack (3) does incremental builds which is typically faster. And webpack 4 is faster than webpack 3. Especially with newer npm and Node.js versions.

[DanielRuf]

But this was just a very rough first webpack 3 migration in a very short time as we had issues with gulp on our CI servers.

[colin-marshall]

@DanielRuf that's great! I would like to see some of the other people in this issue that were having slow build times test out your setup.

[DanielRuf]

default webpack 2.7.0

webpack --config webpack.dev.js

Webpack is watching the files…
Hash: 2608b23d793040aea4f5
Version: webpack 2.7.0
Time: 4765ms

webpack --config webpack.dev.js -p

Webpack is watching the files…

Hash: cb99192c3a7c0acb8ee8
Version: webpack 2.7.0
Time: 8160ms

webpack --config webpack.dev.js --progress --profile
 10% building modules 1/1 modules 0 active                                         
Webpack is watching the files…

2663ms building modules                                                               
1ms sealing 
1ms optimizing 
0ms basic module optimization 
3ms module optimization 
1ms advanced module optimization 
0ms basic chunk optimization 
0ms chunk optimization 
2ms advanced chunk optimization 
0ms module and chunk tree optimization 
1ms module reviving 
0ms module order optimization 
1ms module id optimization 
0ms chunk reviving 
0ms chunk order optimization 
2ms chunk id optimization 
11ms hashing
0ms module assets processing 
21ms chunk assets processing
1ms additional chunk assets processing 
0ms recording 
0ms additional asset processing 
595ms chunk asset optimization
1025ms asset optimization
33ms emitting
Hash: 2608b23d793040aea4f5
Version: webpack 2.7.0
Time: 4371ms

webpack --config webpack.dev.js -p --progress --profile
 10% building modules 1/1 modules 0 active                                         
Webpack is watching the files…

4713ms building modules                                                               
2ms sealing 
0ms optimizing 
0ms basic module optimization 
3ms module optimization 
0ms advanced module optimization 
0ms basic chunk optimization 
0ms chunk optimization 
2ms advanced chunk optimization 
0ms module and chunk tree optimization 
1ms module reviving 
0ms module order optimization 
0ms module id optimization 
1ms chunk reviving 
0ms chunk order optimization 
1ms chunk id optimization 
10ms hashing
0ms module assets processing 
21ms chunk assets processing
1ms additional chunk assets processing 
1ms recording 
1736ms additional asset processing
684ms chunk asset optimization
1079ms asset optimization
27ms emitting
Hash: cb99192c3a7c0acb8ee8
Version: webpack 2.7.0
Time: 8296ms

[phifa]

I dont get it. So is it worth it removing gulp completely? Should we consider this for the foundation template?

[DanielRuf]

I dont get it. So is it worth it removing gulp completely? Should we consider this for the foundation template?

It is on my todo list. And also a switch to PostCSS in the (far) future maybe.

[DanielRuf]

We plan to fully move to webpack in an upcoming release, probably 7.

[phifa]

„i don’t get it“
:) By that i mean, do you see good speed improvements with only webpack? in other words, would you consider gulp to be the thing that slows everything down?

[DanielRuf]

By that i mean, do you see good speed improvements with only webpack? in other words, would you consider gulp to be the thing that slows everything down?

Yes, definitely.

[DanielRuf]

Just to clarify this: gulp has its own ecosystem. For example instead of directly using node-sass it uses gulp-sass which runs node-sass. Directly using it + switching to webpack 4 and PostCSS brings a huge performance improvement.

[phifa]

@danielruf nice! How can I test it out? Do you have a prototype setup for foundation template to play with?

[DanielRuf]

@phifa I'll share an improved webpack config very soon. This were the results of an internal project which I've migrated to a full webpack setup which has some more things like a custom webpack plugin written by me (webpack port of a svg sprite plugin for gulp and Grunt).

[phifa]

@DanielRuf excited to test this out!

[DanielRuf]

Will take a bit longer as I focus on the other issues at the moment, updated dependencies and a clean, working testsuite.

The pure webpack build is still on my todo and has a high prio.

[DanielRuf]

You can follow the thread at https://github.com/zurb/foundation-sites/issues/11044

Should we keep the issue here open?
Do we need more metrics?

[DanielRuf]

Closing as we can not reproduce such slow builds with latest build dependencies.

[rafibomb]

What @DanielRuf is proposing, removing Gulp and using Webpack's task runner is the right way forward. It will improve the project in many ways but not in SCSS compiling time (for now): https://github.com/webpack-contrib/sass-loader/issues/296#issuecomment-288464857