flow: Development Mode Performance Regression 14.x vs 19

I was able to reproduce and can confirm the issue. The frontend build time in v19 has increased 3.5x - 4x compared to that in v14.5.

webpack-dev-server startup time when running a default Flow project generated from https://start.vaadin.com:

Vaadin version	Win 10 Pro	WSL2	MacOS 10.14
14.4.9	3.0 sec (100%)	2.5 sec (100%)	3.1 sec (100%)
16.0.4	9.4 sec (316%)	5.7 sec (228%)	7.0 sec (228%)
17.0.11	7.8 sec (265%)	5.7 sec (227%)	6.9 sec (226%)
18.0.7	8.5 sec (288%)	6.1 sec (245%)	7.5 sec (243%)
19.0.0	12.3 sec (416%)	8.5 sec (340%)	11.3 sec (369%)

Projects: v14.zip, v16.zip, v17.zip, v18.zip, v19.zip.

Why it was not detected by an automatic regression test nor noticed by one of Vaadin developers is another question, but let’s focus at fixing the build time regression here. I could speculate, without having done a proper research, that the time increase could be due to (i) adding TypeScript compilation in V15 and (ii) adding Service Worker generation in V19. These are assumptions which need validation.

In Flow apps both TypeScript and Service Worker support bring little value, and the build time increase would be hard to justify if it is indeed due to adding these 2 features.

@haijian-vaadin Thanks! Haven’t noticed the other PR. Looks like my laptop got a little bit faster (20 vs 13 sec) with nothing else open, but still way behind v14 for me.

Same applications as last time, just changed the pom version to 14.5.3 and 19.0.6:

V14.4.9 2021-04-26 14:19:04.746 INFO 13669 — [ task-2] dev-webpack : Started webpack-dev-server. Time: 5934ms 2021-04-26 14:19:33.087 INFO 13880 — [ task-2] dev-webpack : Started webpack-dev-server. Time: 4865ms 2021-04-26 14:19:58.715 INFO 14089 — [ task-2] dev-webpack : Started webpack-dev-server. Time: 4958ms

V14.5.3 2021-04-26 14:26:49.007 INFO 14755 — [ task-2] dev-webpack : Started webpack-dev-server. Time: 5386ms 2021-04-26 14:27:15.730 INFO 14972 — [ task-2] dev-webpack : Started webpack-dev-server. Time: 5252ms 2021-04-26 14:27:38.519 INFO 15180 — [ task-2] dev-webpack : Started webpack-dev-server. Time: 5085ms

v19.0.3 2021-04-26 14:12:21.345 INFO 11717 — [onPool-worker-5] com.vaadin.flow.server.DevModeHandler : Started webpack-dev-server. Time: 14928ms 2021-04-26 14:13:00.762 INFO 11988 — [onPool-worker-3] com.vaadin.flow.server.DevModeHandler : Started webpack-dev-server. Time: 13966ms 2021-04-26 14:13:47.400 INFO 12217 — [onPool-worker-3] com.vaadin.flow.server.DevModeHandler : Started webpack-dev-server. Time: 13799ms

v19.0.6 2021-04-26 14:16:30.634 INFO 12882 — [onPool-worker-3] com.vaadin.flow.server.DevModeHandler : Started webpack-dev-server. Time: 11803ms 2021-04-26 14:17:24.555 INFO 13169 — [onPool-worker-3] com.vaadin.flow.server.DevModeHandler : Started webpack-dev-server. Time: 10705ms 2021-04-26 14:18:01.193 INFO 13390 — [onPool-worker-3] com.vaadin.flow.server.DevModeHandler : Started webpack-dev-server. Time: 11021ms

I researched for the performance improvement ideas using the https://github.com/stephencookdev/speed-measure-webpack-plugin when running node node_modules/webpack/bin/webpack.js --mode=development.

The starting numbers

 SMP  ⏱  
General output time took 8.43 secs

 SMP  ⏱  Plugins
InjectManifest took 6.38 secs
CompressionPlugin took 0.384 secs
StatsPlugin took 0.136 secs
WebpackManifestPlugin took 0.134 secs
HtmlWebpackPlugin took 0.006 secs
ApplicationThemePlugin took 0.005 secs

 SMP  ⏱  Loaders
ts-loader took 4.9 secs
  module count = 7
modules with no loaders took 3.4 secs
  module count = 694
lit-css-loader, and 
extract-loader, and 
css-loader, and 
@vaadin/theme-loader took 0.451 secs
  module count = 4
html-webpack-plugin took 0.015 secs
  module count = 1

Improvements

Recommend: using {transpileOnly: true} option for ts-loader

Gives the best gain by far from the rest. In combination with fork-ts-checker-webpack-plugin for error checking:

Before:

InjectManifest took 6.38 secs
...
ts-loader took 4.9 secs
  module count = 7

After:

InjectManifest took 2.29 secs
ForkTsCheckerWebpackPlugin took 0.004 secs
...
ts-loader took 0.601 secs
  module count = 7

Note: InjectManifest plugin time also decreases.

Recommend: removing flow-frontend/**.ts from TypeScript compilation

We currently ship both source + compiled .js + .d.ts files in target/flow-frontend modules, and the *.ts sources are actually picked up for compilation because we have resolve: { extensions: ['.ts', '.js'] } set in the generated webpack config. I tried simply swapping for ['.js', '.ts']. This brings TypeScript module count down and improves ts-loader time even more.

Before:

ts-loader took 0.601 secs
  module count = 7

After:

ts-loader took 0.183 secs
  module count = 3

The .ts-first extensions configuration is the one recommended in webpack docs, however. We should consider removing the source .ts files from the target/flow-frontend as a way of doing this optimisation.

Maybe: removing resolve.modules entries

Webpack docs recommend keeping those at minimum. We currently have

  resolve: {
    modules: [
      'node_modules',
      flowFrontendFolder,
      ...projectStaticAssetsFolders,
    ],
   }

Removing the latter two was relatively easy in V20 Flow project from the starter for me. The flowFrontendFolder entry was only necessary for the generated theme files, where we could replace it with the existing Frontend/ directory alias, and the ...projectStaticAssetsFolders was never used.

The impact of this is harder to measure with together other improvements applied, does not yield much to my eye. However, with default ts-loader setup, this seems to reduce total time for ~10%:

Before:

General output time took 8.43 secs

After:

General output time took 7.61 secs

Maybe: skipping InjectManifest plugin

In V20, the frontend build generates the service worker, whereas in V14 the service worker is served from Java runtime. Let us see how much it costs for frontend build time, and try skipping InjectManifest plugin:

Before:

General output time took 8.43 secs
...
ts-loader took 4.9 secs
  module count = 7
modules with no loaders took 3.4 secs
  module count = 694

After:

General output time took 6.36 secs
...
ts-loader took 3.3 secs
  module count = 6
modules with no loaders took 3.21 secs
  module count = 602

Again these numbers are taken without ts-loader improvements applied. With transpileOnly: true option for ts-loader, the impact was hardly noticeable for me.

@knoobie thanks for sharing, good to see that it helps with the performance, we may need to do another round of performance tuning since the difference is still significant compare with v14.