You want to go on a mind trip? What if you could build great static sites with a JavaScript single-page application framework? I’m talking the root-level, unadulterated site that represents your business or your person. Something that replaces Jekyll or Middleman or your language’s equivalent. I went on that mind trip and what I found—wait for it—might surprise you.

Reading through the previous posts on this blog, you would not be surprised to learn that I am currently smitten with Ember and its ecosystem. But there are certain tools for certain jobs: the boring, logicless home site usually calls for a static site generator like Jekyll. It serves up pure HTML and is therefore damn fast. With a correctly-configured web server, you’ll hardly be sending any data over the wire with each new page.

The static site is good: it’s simple, it’s maintainable, it’s understandable. It also tests extremely well with tools like PageSpeed Insights, YSlow, etc. But I’m afraid these tools might be optimizing for developer egos rather than the customer experience.

The tools for measuring sites always take a single request in isolation. Do you have your Cache-Control headers set? Are you using a CDN? Are your assets minified? But customers and potential customers don’t just look at one page. Even the smallest funnel is 2 page loads. What every page speed tool doesn’t tell you is: how fast is my site when your customer clicks “Register”?

I did some cursory tests with the Ember Inspector and a recreation of the imgix home site in Ember Canary, currently with the new Glimmer engine. The results were much better than I expected. The initial page load of the first hit was a mere 100 KB heavier and added about 100ms to DOMContentLoaded, Loaded, and Finished timings in the Chrome inspector. For reference, the imgix home page weighs in at 615 KB.

However, navigating around the Ember “static” site beats the pants off of the traditional competition. New page loads happen in <1ms and request zero new bytes. The page has loaded before there is air between your finger and your mouse. I cannot emphasize how insanely fast this feels.

This is where my static site world breaks down, and I begin to question how I’ve been operating in the past. We should not optimize for the grade at the top of the paper, but instead for the entire experience. Ember is the best framework or library I’ve found for delivering this experience out of the box. It has first-class routing capabilities, a sensible application structure, strong tooling, and an eye toward performance.

There are a few places for improvement, though. Before we can use Ember for static sites without reservation, two things must be addressed: SEO and the initial load issue. Those two concerns have the same solution: FastBoot. FastBoot will serve out vanilla HTML pages from your same Ember application running server-side. The client-side Ember application payload will then “follow” that page and hydrate the it, adding in all of the interactivity expected. Unfortunately, FastBoot has some time before it will land and be supported. (For those impatient, you can get SEO through a service called Prerender. It spits out vanilla HTML to your neighborhood web crawler.) Without FastBoot, serving Ember sites to mobile devices is also a bit more of a question mark due to traditionally slower JavaScript engines. I haven’t run tests around this yet, so it could be okay for smaller sites.

The next time you’re tasked with creating a static site, whether for yourself or your company, run a few tests to see if Ember is a good fit.

–

Special thanks to Jonathan Shariat, Erik Bryn, Jordan Hawker, and Bryan Langslet for looking at drafts of this post.