**Note, Experimental** - *This project is just starting. While we currently believe every adjustment to the resulting javascript should be safe and make things explicitly faster, it's hard to be 100% certain until we have a large number of projects using it successfully. So, beware!*
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.
**Another Note** — Before deploying your app, you should also minify it and gzip it. `elm-optimize` does not do that for you. [Check out this doc for a recommended setup.](minification.md)
The goal is to quantify different transformations that can be done to the JS output of the Elm compiler and what their effect would be.
To get started, [here's a current overview of all the JS transformations we explored](transformations.md) and a summary of their effect. Not all of them are included in the CLI tool because not all of them turned out to be beneficial.
A few are listed there as either incomplete or not attempted. That's future work!
**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/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](minification.md), these transformations should either have no effect on asset size, or may even make your app slightly smaller.
*For this project, contributions always start with communication before code!*
That being said, there are a few areas that might be opportunities for contribution.
**First and formost** is to try `elm-optimize` on any current Elm project you have.
We'd love to hear your results whether they be success, no effect, or caused a regression.
If your project saw an explicit improvement or performance regression, [leave a comment on this issue](https://github.com/mdgriffith/elm-optimize/issues/15).
For more serious issues, feel free to file a separate issue.
**Secondly**, if you believe there are public benchmarks that we could track that are *not essentially covered* by our current benchmarks, let us know! 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.
**Thirdly**, if you believe there are additional JS transformations that would be interesting to explore, or would like to try improving existing transformations in some way, get in touch!