# Large bundle size despite use of —optimize

**URL:** <https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725>\
**Category:** Learn\
**Created:** [September 1, 2021, 10:42am UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725 "2021-09-01T10:42:45Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Aarkon](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/aarkon/32/4157_2.png) [@Aarkon](https://discourse.elm-lang.org/u/Aarkon)\
**Post date:** [September 1, 2021, 10:42am UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/1 "2021-09-01T10:42:45Z")

</div>

Hey everyone!

I’m building a small page to learn Elm over [here](https://gitlab.com/jakob.ledig/querweg-status) (sorry for the language in the app itself being only German, but that’s how my potential user base would roll 😉).

Everything works kind of fine so far, but when I inspect my deployed page with the dev tools in the browser, I can see that the application code takes up more than 400 kilobytes even though I build with the optimisation flag set:

`elm make src/TidesWater.elm --optimize --output out/index.html `

Reading up on [minification in Elm](https://elm-lang.org/news/small-assets-without-the-headache), I would expect to be lighter than 25 kB because I have only around 500 loc.

Do external minification and gzip make up for the difference or am I doing something wrong? I already tried compiling to a JavaScript file and embedding it into a separate handcrafted `index.html`, but that didn’t change anything (as I assumed).

---

<div class="post-metadata">

**Author:** ![robin.heggelund](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/robin.heggelund/32/1330_2.png) [@robin.heggelund](https://discourse.elm-lang.org/u/robin.heggelund)\
**Post date:** [September 1, 2021, 11:25am UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/2 "2021-09-01T11:25:57Z")

</div>

The numbers mentioned in the article you’re linking to are after minification and gzip. You need to use a minifier and gzip to get comparable numbers.

---

<div class="post-metadata">

**Author:** ![Warry](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/warry/32/3998_2.png) [@Warry](https://discourse.elm-lang.org/u/Warry)\
**Post date:** [September 1, 2021, 11:46am UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/3 "2021-09-01T11:46:45Z")

</div>

Hi !

I’m using Parcel as a dev tool and packager, and I strongly recommend it. It’s a zero config tool, and defaults are super nice for Elm. You use `parcel watch index.html` for dev, then `parcel build index.html` for prod and it will automatically build and minify your sources (elm, js, rust, typerscript, less or sass…).

o/

---

<div class="post-metadata">

**Author:** ![passiomatic](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/passiomatic/32/1250_2.png) [@passiomatic](https://discourse.elm-lang.org/u/passiomatic)\
**Post date:** [September 1, 2021, 12:11pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/4 "2021-09-01T12:11:15Z")

</div>

> [@Aarkon](#):
>
> Do external minification and gzip make up for the difference or am I doing something wrong?

Yeah, gzipping makes a huge difference. Normally compression is done by the web server, so you publish your _minified_ JS bundle, the server compresses upon serving and browser decompress it on the fly. Of course you can gzip your bundle manually to see how much you can save but in my experience you let that phase to the deploy web server.

---

<div class="post-metadata">

**Author:** ![lydell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/lydell/32/178_2.png) [@lydell](https://discourse.elm-lang.org/u/lydell)\
**Post date:** [September 1, 2021, 5:51pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/5 "2021-09-01T17:51:14Z")

</div>

See also:

> [@What I’ve learned about minifying Elm code](https://discourse.elm-lang.org/t/what-i-ve-learned-about-minifying-elm-code/7632):
>
> Summary The Elm Guide has a page on [minification](https://guide.elm-lang.org/optimization/asset_size.html), but it’s not the end of the story. The [UglifyJS](https://github.com/mishoo/UglifyJS) command in the Elm Guide can be tweaked to produce slightly smaller code a tiny bit faster. But you can get even smaller by first running just parts of UglifyJS and then [esbuild](https://github.com/evanw/esbuild/) – and much faster! Gzip is really unpredictable. Slightly increasing the minified size can sometimes decrease the gzipped size. If you’re OK with ~2% more of the original JS, you can run only esbuild in less than a second …

---

<div class="post-metadata">

**Author:** ![pdamoc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/pdamoc/32/36_2.png) [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)\
**Post date:** [September 2, 2021, 6:52am UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/6 "2021-09-02T06:52:59Z")

</div>

> [@Aarkon](#):
>
> I would expect to be lighter than 25 kB because I have only around 500 loc.

500 LOC with dependency only on core & `elm/html` would probably result in something around 10-15k minified-gzipped bundle.

500 LOC with a lot of functionality brought in from various dependencies is a different story. You have to take into account the code from the libraries you import. Your current code is around 26k (minified-gzipped) for `363` total LOC. In any case, this is a starting point. From here, if the dependencies remain the same, extra code should only increment the final bundle by minimal amounts.

---

<div class="post-metadata">

**Author:** ![Aarkon](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/aarkon/32/4157_2.png) [@Aarkon](https://discourse.elm-lang.org/u/Aarkon)\
**Post date:** [September 2, 2021, 12:46pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/7 "2021-09-02T12:46:17Z")

</div>

Thank you all, this is insightful. 🙂

To point one thing out: My goal is not to squeeze the bundle size as far as it can go & down to the last bit, just getting into the order of magnitude of less than 50 KByte or so is absolutely fine for me. Therefore, I think I’ll give parcel a try, that one looks promising with its easy setup, requiring no extra plugin for Elm.

Also, I’ll mark this as solved as soon as I get somewhere.

---

<div class="post-metadata">

**Author:** ![Aarkon](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/aarkon/32/4157_2.png) [@Aarkon](https://discourse.elm-lang.org/u/Aarkon)\
**Post date:** [September 3, 2021, 1:35pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/8 "2021-09-03T13:35:08Z")

</div>

Here I am, having learned a thing or two.

First, I tried out good old `uglify-js`, but that didn’t play together with Elm as nicely as promised (the set of parameters recommended everywhere gave me an error about not defined functions).

Next, I looked into `parcel`, which was more invasive on my `package.json` than I expected, adding for instance the `node-elm-compiler` on its own, which I was not too happy about - also, I felt somewhat forced to wrap my entire dev environment in parcel, which doesn’t suit my taste too well because I like the shallow simplicity of the Elm setup I have.

So after all, I settled with `elm-minify`. The GitHub repo is archived and the last commit is from 2019, but it does what it is supposed to: With one simple call, it reduces my compiled JavaScript from about 400 to something in the figures of 80 KBytes.

Because GitLab Pages does not offer server side gzip compression, I’m now doing this myself as well. And because I was already at it, I even added `brotli` to the fold. So now my deploy stage looks something like this:

```auto
pages:
  stage: deploy
  artifacts:
    paths:
      - public
  only:
    - main
  script:
    - elm-minify out/elm.js --overwrite
    - mkdir -p public
    - cp out/elm.js public/.
    - cp index.html public/.
    - find public -type f -regex '.*\.\(htm\|html\|txt\|text\|js\|css\)$' -exec gzip -f -k {} \;
    - find public -type f -regex '.*\.\(htm\|html\|txt\|text\|js\|css\)$' -exec brotli -f -k {} \;

```

This process brings my bundle size down to just above 22 KBytes, which makes loading the page practically instantaneous on a normal connection and bearable even on the most throttled one browsers do simulate. Being situated in a rural area in Germany, this really is a selling point. 😄

---

<div class="post-metadata">

**Author:** ![lydell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/lydell/32/178_2.png) [@lydell](https://discourse.elm-lang.org/u/lydell)\
**Post date:** [September 3, 2021, 2:54pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/9 "2021-09-03T14:54:09Z")

</div>

> [@Aarkon](#):
>
> the set of parameters recommended everywhere gave me an error about not defined functions

This is interesting! I have never heard of that before.

- Which set of parameters is that?
- Can you link to where you got it from?
- Can you show the error you got?

> [@Aarkon](#):
>
> So after all, I settled with `elm-minify` .

elm-minify uses [terser](https://github.com/terser/terser) which is a fork of UglifyJS with basically the same API. It uses the options from the [Elm guide](https://guide.elm-lang.org/optimization/asset_size.html).

[https://github.com/opvasger/elm-minify/blob/c42677a6730329d148b4bca00450806f8174650e/src/api.js#L4-L27](https://github.com/opvasger/elm-minify/blob/c42677a6730329d148b4bca00450806f8174650e/src/api.js#L4-L27)

This makes me somewhat doubtful that UglifyJS would break your code – but you never know! 😄

---

<div class="post-metadata">

**Author:** ![Aarkon](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/aarkon/32/4157_2.png) [@Aarkon](https://discourse.elm-lang.org/u/Aarkon)\
**Post date:** [September 9, 2021, 4:56pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/10 "2021-09-09T16:56:37Z")

</div>

Oh hi!

I’m sorry to have caused a misunderstanding, but you’ve got me wrong: Uglify didn’t break my code, rather did running the recommended set of arguments already return the described error. The command used was basically this one:  
`uglifyjs $js --compress 'pure_funcs=[F2,F3,F4,F5,F6,F7,F8,F9,A2,A3,A4,A5,A6,A7,A8,A9],pure_getters,keep_fargs=false,unsafe_comps,unsafe' | uglifyjs --mangle --output $min` (and yes, I replaced variables with actual file names and whatnot 😉 )

I’ve read through multiple guides, including the official one, and couldn’t make Uglify work. `elm-minify` gives me what I want, so I don’t spend too much thought on whether it implements something on itself or just encapsulates existing tools.

That’s not to say you _can’t_ make it work, it just took me longer than I hoped to be stuck on a cryptic error. 😉

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [September 19, 2021, 4:56pm UTC](https://discourse.elm-lang.org/t/large-bundle-size-despite-use-of-optimize/7725/11 "2021-09-19T16:56:56Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.