Articles EmberJS

An Elementary Guide to Ember Build Performance

An Elementary Guide to Ember Build Performance

When we talk about build performance, it is important to understand that there are several build phases:

  • Cold build
  • Warm build
  • Rebuild

Cold build

Cold build is the build which happens when you boot your app up for the first time. This build is the slowest because the cache is not yet populated and the application is booting for the first time.


Build time varies and depends on the number of dependencies that application has but ballpark should be around 5 seconds for small to middle size applications and around 15 seconds for large size applications.

Warm build

Warm build is the build which occurs while you boot your app when cache was populated. This build is faster than cold one because the cache was populated already and it takes less time re-compute dependencies.


Build time varies but ballpark should be around 2 seconds for small to middle size applications and around 10 seconds for large size applications.


Rebuild is the subsequent rebuilds that happen on file change. Rebuild aims to be the fastest because it happens the most often.


App/ JavaScript Rebuild time varies but ballpark should be around 200-300ms for small to middle size applications and up to 1 second for large size applications (200kloc js + 3000 modules).

The Rebuild is majorly classified into three broad categories based on the asset types like:

  • Rebuild of JS in app/
  • Rebuild of CSS/Sass/Less in app/
  • Rebuild of vendor/, bower_components/

Rebuild of JS in app/

This is likely the most common type of rebuilds, since it concentrates mostly on the javascript assets under app/ folder and is one of the major concerns for the Core Team to improve the performance.

Rebuild of CSS

This kind of rebuilds largely depends on three factors:

  • the size of bower_component (the Ember Core Team have plans to largely mitigate this one)
  • which preprocessor is being used (libsass vs ruby-sass vs less vs …)
  • the amount of CSS

Rebuild of vendor/

This kind of builds are somewhat costly still, due to how slow available sourceMap Libraries are. The Core Team have a work in progress item with a more V8/JIT friendly sourceMap lib, already showing some very nice improvements.

Build Performance Comparison

The various builds are compared based on their characteristics and performance:

These times are based on a posix box with and SSD, win32 unfortunately tends to be slower. As the Core Team continues to improve performance, both posix and win32 will improve, hopefully future work will bring these platforms build times closer together.

If you see that application timings escape, there might be a problem.

Addons known to cause a slow down (but have not yet been addressed):

  • any old non-patch based broccoli plugin
  • ember-cli-component-css
  • ember-browserify
  • … ?

Make sure to mention which type of the build seems to be the problem so we can help identify and fix issues faster.

FAQ/Common Issues & Solutions:

My rebuilds are slow. (And I have anti-virus installed)

The build-system assumes a relative fast/performant file system (although, Ember continue to reduce IO related work). It is quite common for a Anti-virus to slow down IO.

Common issues:

  • anti-virus scanning of tmp, oftentimes this can be avoided altogether.
  • anti-virus on-file-access re-scanning files, oftentimes this can be disabled for the app directory. or ember can be whitelisted.

My rebuilds are slow. (And I am using an encrypted thumb-drive to host my project)

These sorts of drives are notoriously slow. Although Ember continue to reduce our IO overhead, you will be running at a disadvantage. Oftentimes, a much better alternative is hardware supported full-disk encryption, like on most OSX corporate laptops use. This setup is both reasonably secure, and has negligible impact on performance.

My JavaScript rebuilds are still slow.

Please run:

and ideally the following should be true (otherwise some upgrades may be required)

  • broccoli-funnel should be at ^1.0.1
  • broccoli-merge-trees should be at ^1.1.0
  • broccoli-persistent-filter should be at ^1.1.6
  • broccoli-filter often needs to be replaced with broccoli-persistent-filter (we hope to re-merge the two eventually)
  • broccoli-sourcemap-concat should be at ^2.0.2 but will soon be replace by broccoli-concat (we have just re-merged the two)
  • broccoli-caching-writer should be at ^2.2.1
  • broccoli-concat should be at ^2.0.3
  • broccoli-stew should be at ^1.2.0
  • likely more…

Up next we should check for old and deprecate plugins

this should no longer be used, rather broccoli-funnel at v1.0.1 should be used

Up next we should look for not-yet-fixed plugins

npm v3 made my build slow

Well what happened is npm v3 changed the module topology, this coupled with a misbehaving plugin may result in extra files (maybe all of node_modules) being pulled into the build. This is going to be slow.., the solution is to find the offending plugin, and upgrade (or report the issue if it is not yet fixed).

One such plugin is ember-cli-ic-ajax, which has been fixed. So please be sure to upgrade.

Finding such plugins, we can use a series of DEBUG flags, to gain more insight

Despite of all the above scenarios and possible solutions, if the issue still persists, please report an issue in Github with ember-cli project.

Be sure to include:

  • npm version
  • npm ls (as a gist)
  • ideally a reproduction

How to explore/debug and hopefully address performance issues

DEBUG logging

We can use heimdalljs-logger for logging, which supports the same usage as the de-facto standard debug. Quite often this can be used to quickly discover obviously wrong things.


For all logging (this will be very verbose):

For all ember-cli logging:

For all broccoli logging:

For both broccoli and ember-cli logging:

The above patterns will be very verbose. But to make them even more verbose you can set the log level via DEBUGLEVEL

To make them a bit less verbose, a curated set of performance related logging flags are:

Because many plugins are used repeatedly it may be difficult to see the context for log entries. By default, 3 nodes of context are shown.

To show more (or fewer) lines of context, specify the environment variable DEBUG_DEPTH

[… ConcatWithMaps#782 -> BroccoliMergeTrees#783] means that the log entry occurred in broccoli merge-trees node with id 783, whose parent was a concat with maps node with id 782. These ids are shown in the visualization graph.


  • Visualization

    To visualize build tree, we can use graphviz.

    Graphviz is an open source graph visualization program. Graph visualization is a way of representing structural information as diagrams of abstract graphs and networks. It has important applications in networking, bioinformatics, software engineering, database and web design, machine learning, and in visual interfaces for other technical domains.

    To install it run

    or download it directly from here.

    You will also need to install broccoli-viz version 3.0.3 or higher.

    broccoli-viz is a library to read/parse and produce various visualizations of broccoli.

    To generate visualization:

    To get a better understanding, you can watch this talk:

    Dissecting an ember-cli build by Estelle Deblois


    An example visualization graph should look like this, with only a subset of the whole graph cropped for clear understanding.

    Each build will generate an additional graph,

  • in-depth look

    in-depth tooling, aimed to provide much deeper insight into the given build

    • dot: is the input to graphviz, allowing tree visualization
    • json: more detailed counts and timings related to the corresponding build

Cover Image from Unsplash by:


Articles EmberJS

How to create an accessible checkbox component in Ember?

How to create an accessible checkbox component in Ember?

In this tutorial we will see how to create an accessible checkbox component in Ember based on the WAI-ARIA authoring practices.

A checkbox allows the user to toggle between two choices – checked and not checked.

Class diagram

Let us take a look at what are the different things that make up the checkbox component in Ember


Component Interface

As far as the component properties are concerned, we are having only one property checked for the component to determine whether the checkbox is toggled or not.



The template for this particular component is not having any HTML markup, since it is just going to yield the markup whatever is just given to the component.

So the template for this component looks like this:

And we are looking at a target markup like this when the component is rendered in the page.


Now it is time for look into the component.js for the ember-aria-checkbox component. We will be starting with a bare component skeleton like this:

Next , we will be adding the essential classnames and attributes for the component.

Next we add a computed property ariaChecked to track the toggled state of the component from the checked property.

Then we will be adding the requisite properties for the component to track the toggled and focus states along with the tabindex

Now we shift our focus to the event handling part of the component. First we look at the keyDown events like whenever a particular key is pressed, we will toggle the component state from checked to unchecked and vice-versa.

As per the WAI-ARIA recommendations, the SPACE key is used for this purpose as soon as the checkbox got the focus. For that first we need to define the keycode mappings and the handling function for the keyDownevent for the component.

Next the main click handler for the component where we just toggle the component state checked

Finally, to set the focus classnames for the component, we will be setting the respective property focus to true on focus and false on blur.


The source code for this addon is hosted in Github


You can also see the component in action here

Author: Rajasegar

Created: 2018-02-16 Fri 10:25