Re: brotli compressed js files (es5 vs es6)
112 views
Skip to first unread message
Alexey Ivanov
Aug 27, 2019, 8:03:43 PM8/27/19
to Denys Mikhalenko, Brotli
You may want to provide the files themselves so that people can run experiments on them. Without looking at the files I would suppose that they have different entropy levels (given that es6 is much more terse it is expected.)
Also you may want to provide flags/scripts you are using to compress these files so that we can look at common mistakes like using small windows or lower compression settings.
As for the brotli benefits for ES5 browsers -- brotli is way faster at decompression (though with bigger windows it will likely use more memory on the device) so it will give some speedup.
PS. You can also try libdeflate -- it is not as slow as zopfli but gives a decent compression ratios.
PPS. We've described some of the pre-compression tricks in a blog post some time ago: https://blogs.dropbox.com/tech/2017/04/deploying-brotli-for-static-content/
--
t: @SaveTheRbtz
> On Aug 27, 2019, at 11:57 AM, Denys Mikhalenko <denys.mikhal...@gmail.com> wrote:
>
> Hi everyone,
>
> We're trying to implement differential serving of es5 transpiled (for older browsers) and es6 (for modern ones) javascript bundles and we realized that brotli compressed bundles are almost identical in terms of compressed size.
> While uncompressed es5 is ~200kb bigger than uncompressed es6, it is only ~17kb difference which makes all our efforts pointless.
> The question is why 200kb smaller js file compressed by brotli has pretty much the same file size as a much bigger js file? Is this expected result? Did we do something wrong?
>
> Some numbers:
>
> es5 es6 diff in bytes diff in %
> uncompressed 1640237 1436253 203984 12.44%
> gzip 442802 405184 37618 8.50%
> zopfli (50) 427317 390729 36588 8.56%
> brotli 326470 309400 17070 5.23%
>
>
> --
> You received this message because you are subscribed to the Google Groups "Brotli" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to brotli+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/brotli/d70ab214-570d-4eef-9e5b-c1df5c8bafc0%40googlegroups.com.
Also you may want to provide flags/scripts you are using to compress these files so that we can look at common mistakes like using small windows or lower compression settings.
As for the brotli benefits for ES5 browsers -- brotli is way faster at decompression (though with bigger windows it will likely use more memory on the device) so it will give some speedup.
PS. You can also try libdeflate -- it is not as slow as zopfli but gives a decent compression ratios.
PPS. We've described some of the pre-compression tricks in a blog post some time ago: https://blogs.dropbox.com/tech/2017/04/deploying-brotli-for-static-content/
--
t: @SaveTheRbtz
> On Aug 27, 2019, at 11:57 AM, Denys Mikhalenko <denys.mikhal...@gmail.com> wrote:
>
> Hi everyone,
>
> We're trying to implement differential serving of es5 transpiled (for older browsers) and es6 (for modern ones) javascript bundles and we realized that brotli compressed bundles are almost identical in terms of compressed size.
> While uncompressed es5 is ~200kb bigger than uncompressed es6, it is only ~17kb difference which makes all our efforts pointless.
> The question is why 200kb smaller js file compressed by brotli has pretty much the same file size as a much bigger js file? Is this expected result? Did we do something wrong?
>
> Some numbers:
>
> es5 es6 diff in bytes diff in %
> uncompressed 1640237 1436253 203984 12.44%
> gzip 442802 405184 37618 8.50%
> zopfli (50) 427317 390729 36588 8.56%
> brotli 326470 309400 17070 5.23%
>
>
> --
> You received this message because you are subscribed to the Google Groups "Brotli" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to brotli+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/brotli/d70ab214-570d-4eef-9e5b-c1df5c8bafc0%40googlegroups.com.
Evgenii Kliuchnikov
Aug 28, 2019, 4:00:59 AM8/28/19
to Brotli
Just a wild guess - "arrow functions" to blame.
When compressed "function (xxx) {yyy}" and "(xxx) => {yyy}" has almost the same entropy, while the first is much longer in uncompressed form.
Reply all
Reply to author
Forward
0 new messages