React-pdf: Generating PDF takes +30 minutes on production server, but 15 seconds on local dev

[ghost]

OS:
Dev: Windows 10 using WSL (Ubuntu 18.04)
Production: CentOS 7

Using latest Chrome.

Edge, downloads within about 30 seconds.

Can't test on IE and Firefox due to this issue:

https://github.com/diegomura/react-pdf/issues/339

React-pdf version:
alpha.18

Description:
Testing the app on the production server. There is one report that I print that is about 8 pages covered in tables with borders, and even rows with gray background. Doesn't seem too intense.

On my local dev machine. it takes about 15 seconds to generate the report.

On the production server, it takes well over 30 minutes to generate the same minutes. Any suggestion on what could be causing this and how to resolve it?

[diegomura]

Hard to tell 🧐
Maybe obvious question, are you using the same react-pdf version?

[ghost]

Hi, yes, it is the same on both.

[diegomura]

Im totally blind on this one. With that little info I cannot say why is this happening. And probably neither replicate it on my side. I recommend you to debug react-pdf in production (if you can) to see where on the whole rendering process is this happening.

A good starting point would be here. Each line of the Document render method triggers a specific rendering phase. You can check which one is taking so long, and then dig inside that one until you reach the cause of the problem

[ghost]

A good starting point would be here. Each line of the Document render method triggers a specific rendering phase. You can check which one is taking so long, and then dig inside that one until you reach the cause of the problem

Would this also be a good starting point for digging into IE11 and Firefox issues I am having (https://github.com/diegomura/react-pdf/issues/339)? I'll start digging into that as well as I need to get them resolved this week.

[ghost]

OK, think I figured out what the issue is and it is with UglifyJSPlugin. On the production server I changed this to 'development' in my webpack.config.js:

new webpack.DefinePlugin({'process.env.NODE_ENV': JSON.stringify('development')}),

Still had the issue with it basically timing out out and saying "DevTools has disconnected".

Then disabled the new UglifyJSPlugin and now it is working.

Changed this back and it still works, but gives errors about it being a production build with no dead code elimination being applied.

new webpack.DefinePlugin({'process.env.NODE_ENV': JSON.stringify('production')}),

Thoughts on what might be going on?

Heading to SO and https://github.com/webpack-contrib/uglifyjs-webpack-plugin to see what is up.

[diegomura]

Wow. That's crazy.
No idea what may going on there, but I would recommend to use terser instead of UglifyJS. Is it UglifyJS that is unmaintained? Not sure, but some people even reported that with terser they had a performance boost on layouting with Yoga.

[ghost]

Ok, I will give terser a shot. Yeah, it is unmainted.

Going to close since this doesn't appear to be a @react-pdf/renderer issue.

[ghost]

To add to this, after spending a part of yesterday and most of today updating all of my dependencies (primarily Webpack and Babel) and working out the kinks (deprecated plugins like CommonsChunkPlugin, Uglify, and extract-text-webpack-plugin primarily), I have my project back up and running. Tested a production build using terser instead of UglifyJS. Production builds are work properly now.

To override the default use of UglifyJs in Webpack 4 production builds, you do the following:

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  //...
  optimization: {
    minimizer: [new TerserPlugin()]
  }
};