Angular-cli: add webpack-dev-server gzip support

Created on 9 Sep 2016  路  8Comments  路  Source: angular/angular-cli

By default config,Use ng serve -prod ,The bundle file too big.

Before

image
image

After

image
image

Need Change

I think this issue is important,Others maybe think the quality of this project is poor.
File addon/ng2/tasks/serve-webpack.ts need add gzip support;
In line 58 Insert ,compress:true

3 (nice to have)

Most helpful comment

In production i used other webserver.
I mean when developers use ng server -prod,server should be gzip.
Developers can predict the production environment.
Otherwise, why use ng server with prod,just need build then publish to production.
Most seed project prod mode default open gzip锛孖nclude old angular-cli version.

All 8 comments

@xpyanchong I am curious what your reason for needing gzip in a dev server since it is not the serve you would use in production.

In production i used other webserver.
I mean when developers use ng server -prod,server should be gzip.
Developers can predict the production environment.
Otherwise, why use ng server with prod,just need build then publish to production.
Most seed project prod mode default open gzip锛孖nclude old angular-cli version.

True, I was just about to ask how can I serve a gzipped bundle to prod. I have tried adding ,compress:true (it's line 44 now and under /node_modules/angular-cli/tasks/serve-webpack.js) and it worked but I would want to know how can I pre configure it...? Is it possible? I thought it should be gzipped by default, won't it?

I think this is more than a nice to have, especially considering how simple a change it is. I am often on slow connections with a remote angular-cli and it makes a tremendous difference.

Doesn't this defeat the purpose of a dev environment? Plus also, it is not recommended to use ng serve with --prod node because these files are being transferred and stored in memory. Consider the hashing we put in file names and how that new a problem with an in-memory fs.

I agree that ng serve --prod doesn't make a lot of sense but in my opinion having the source code and build environment on a remote machine with SSH and view the web frontend from another devices does make a lot of sense. Think testing on tablets etc.

In my current app, patching serve-webpack-js to enable gzip compression decreases load times by factor 2-3.

Thanks for the commit. However, I believe combining it with --prod isn't the best solution. First we already concluded that ng serve --prod isn't really a major use case and secondly one spends most of the time in development mode and there major performance gains can be observed by using compression -- in a remote browser scenario.

I opt for making this a user configurable setting in angular-cli.json.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_This action has been performed automatically by a bot._

Was this page helpful?
0 / 5 - 0 ratings