For feedback: Splash Screen for 'index.html' with Gist

Performance
1

I’ve noticed that my Ember app (somewhat smallish-medium proprietary app) takes 1-5 seconds to boot from hitting the URL to the first UI elements on the screen. On mobile, this can feel even more like an eternity.

Therefore, I took a few hours last week and hacked away at my index.html and came up with this Gist, linked below.

In short, it functions as an “app shell” to bootstrap Ember by first rendering a splash screen as quickly as possible, and only then actually making a network request for the ember code and app scripts.

  • It takes all the usual ‘index.html’ boilerplate (/vendor.js, /vendor.css, /appname.css, appname.js, etc) - everything Ember-specific - and puts it in a hidden <textarea>.
  • Then it declares the CSS for a loading animation and HTML with inline styles to render a simple full-page splash screen
  • Then, my additional in-page javascript asks for an animation frame and inside that, adds the contents containing the usual Ember boilerplate to the actual DOM element for the head, and the Ember body boilerplate to the body.
  • The only special thing my javascript has to do is query all the Ember boilerplate for all tags and explicitly add them to the DOM by creating new tags. It does this sequentially to get them to load in the right order (the order they appear in the boilerplate.)

Posting here in hopes that others may find it useful, as well as for people to critique if desired and give feedback on best practices. And, if someone else has already done this, point it out too! :slight_smile: Thanks everyone!

4 Likes
2

Isn’t the same as ember-web-app addon does?

3

That’s a great question! I looked at that add-on, and it looks like it focuses on generating the Manifest as well as appropriate index tags, which is great!

However, my main focus on this alternate index was not so much the Manifest or the index tags, as much as delaying the actual loading of the core Java Script files until after the first frame of the splash screen had a chance to render, providing instant user feedback that the application was booting up. I don’t see any reason why my simple delayed loading scripts couldn’t be also used in conjunction with that add-on, in fact.

Great Point, thanks for linking to that here so other people can see that excellent add-on!

1 Like
4

Have you seen ember-load addon? This does the trick for most of my use-cases.

5

Late to the party here but i’d love to contribute.

I was suffering the same issues with my ambitious web app the very same, and like the OP experienced, mobile is worse. For me, Android users would literally stare for 10 - 12 seconds at a blank white screen.

Anyway, the OP’s solution is creative but I’ll also explain my method incase anyone wants another alternative.

First, ensure that you use Fastboot to render the initial page html on the server (nodejs), there’s a convenient middleware that comes with as well called fastboot-app-server.

Second, use Dockyard’s ember-service-worker to register a service worker for your web app. There are many other benefits of doing this. Then install the plugin ember-service-worker-index to cache your index.html, but instead of index.html, create a new html file eg app-shell.html in your public folder and add links to vendor.js and app.js. ember cli will put this file in your dist folder upon build with the required fingerprints on production environment.

Lastly, add a splash div or container to your app-shell then, on the application route, add a script call to remove the splash screen on after model hook, this is when ember is just ready to render the first content in the body. ensure you wrap this call in an if fastboot call first since fastboot doesn’t have dom access. Mine is something like this

afterModel(resolvedModel , transition) {
    let isFastBoot = this.get('fastboot.isFastBoot');
    if (!isFastBoot) {
        Ember.$('#splash-screen').remove();
    }
}

Enjoy!

1 Like
6

I did not know about the ember-load addon when I wrote the OP, no - looks like a great addon! Haven’t tried it personally, though. Thanks for bringing it to the attention of future readers!

7

Thanks for the feedback - agreed, mobile is difficult! I also use ember-service-worker as well with this, still isn’t the magic bullet.

I’m serving my app just using nginx for the ember side and FeathersJS for the data API, so I haven’t tried putting fastboot to the test yet on the server. Perhaps when trying to scale out more, I may.

Thanks for contributing to the discussion - you had a lot of good points there!

8

Always glad to help where I can, just a little under a year in Ember. Totally agree service worker is not the silver bullet, but coupled with other things like Fastboot and app-shell it helps, but adds to the complexities. Fastboot is still undergoing a lot of changes so you should probably wait a little to try it out properly unless there’s pressing issue. For me, a non-negligible portion of my users are still on 2G!

Anyway, thanks for the post and do share anything else you learn with the community. Cheers!

9

2G? Wow, that’s quite the deliverable target! Impressive! Yes, agreed, service workers definitely help, didn’t mean to dismiss them carte blanche. Thanks for the feedback as well, and for sharing with the community!