perf: remove zopfli to speed up webpack #10288
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR removes zopfli compression, speeding up webpack compilation in production by ~7.5x (6m36s -> 0m53s).
Analysis
I did some profiling of the command:
RAILS_ENV=production bundle exec rails assets:precompile
after some digging, I found I could debug webpack using:
So I took a trace. I think the screenshot speaks for itself:
Benchmark
My benchmark is the following:
rm -fr tmp/ RAILS_ENV=production bundle exec rails assets:precompile
Then I use the
time
command to time it.Without the fix, this takes 6m36.437s in real time on my Dell XPS 13. With the fix, it takes 0m52.958s (~7.5x improvement).
Explanation
Zopfli outputs a very compact gzip format, but it's slow. Removing it speeds things up considerably.
Even though nginx's default gzip output may be less efficient than zopfli, I don't think it's reasonable to force every instance admin to run this command which takes a very long time. Maybe some admins aren't even using gzip – maybe they're using Brotli. They can also configure the gzip options in nginx, or run zopfli themselves.
As a future improvement, I don't think generating
.gz
files is even strictly necessary. Given this config, nginx should serve gzipped content no matter what – it's just that we don't necessarily control the gzip output.