_New to Elm? Check out the [Elm Guide's section on optimization](https://guide.elm-lang.org/optimization/). Elm already has a lot of optimization stuff built in, [like the `--optimize` flag](https://guide.elm-lang.org/optimization/asset_size.html)! Definitely check those out before using this project._
**Beware, Experimental** - _This project is just starting and does have the power to break your Elm code in very un-Elm ways! While we currently believe every adjustment to the resulting javascript should be safe and make things explicitly faster, some of this code is subtle and it's hard to be 100% certain until we have a large number of projects using it successfully._
_If you want to help out, try it out, **run your test suite** and let us know how it goes by leaving [a comment in this issue](https://github.com/mdgriffith/elm-optimize-level-2/issues/15)!_ :smiley:
1. Explore different javascript representations for Elm code. This means gathering data on what a given representation would mean on realworld projects, and across browsers.
**Note** This work was given a massive headstart by [Robin Heggelund Hansen's article on areas where the Elm Compiler's output could be improved](https://dev.to/skinney/improving-elm-s-compiler-output-5e1h). Go read it! It's great.
**Another Note** — Before deploying your app, you should also minify it and gzip it. `elm-optimize-level-2` does not do that for you. [Check out this doc for a recommended setup.](notes/minification.md)
You can also provide `--optimize-speed` (`--O3`) to `elm-optimize-level-2`, which will attempt to generate even faster code at the expense of asset size.
If you enable this option you may experience a ~5% bigger js file, but with significantly faster record updates.
If you're interested in getting to know what's happening, [here's an overview of all the JS transformations we are exploring](notes/transformations.md)!
Not all of them are included in the CLI tool because not all of them turned out to be beneficial. Part of this endeavor is a science project :bowtie:, where we capture data so we can know which transformations turn out to be worthwhile.
**Note** — _These results are really exciting! However, it's not totally obvious that your project will see similar gains. Performance is a tricky beast! If you do see significant speedups in your project, [leave a comment here on this issue](https://github.com/mdgriffith/elm-optimize-level-2/issues/15), we love to see realworld cases._
In an effort to quantify these transformations, we've put together a number of benchmarks, including some from exisiting Elm packages such as `dillonkearns/elm-markdown`, `w0rm/elm-obj-file`, and `mdgriffith/elm-ui`.
Our goal is to have benchmarks that track performance on code where performance is meaningful.
**Note** — keep in mind that these numbers have _all the caveats_ that benchmarks usually have. You may not see similar numbers depending on your machine, your browser, subtle differences in your code, etc.
**Another Note** — From what we've seen, given that you're [minifying and gzipping your JS](notes/minification.md), these transformations should either have no effect on asset size, or may even make your app slightly smaller.
If your project saw an explicit improvement or performance regression, [leave a comment on this issue](https://github.com/mdgriffith/elm-optimize-level-2/issues/15).
We want the benchmarking suite to be as comprehensive as possible, though we have to weigh that against having a million benchmarks that essentially test the same thing.