Coming from a developed country it can be easy to take high speed internet for granted. Any site, video or song can be consumed on demand with ubiquitous 4G and WiFi networks.

Guess what, it’s not like that everywhere…

Last couple of months I have been traveling around remote northern parts of Australia and beautiful Bali. Finding a good internet connection in these places can be very challenging and sometimes even impossible. Connection is flaky and most of the time downright slow. Sharing a single WiFi access point with dozens of lovely hostel guests also doesn’t make the situation any better.

If we realize that in many places slow and unreliable internet is an inescapable fact of life we can start thinking about how we can enhance our apps to provide best user experience possible.

Psst! I just wrote a new article about Angular CLI budgets that help you keep your app lean and fast so that it loads fast on slow networks… Check it out!

Default Angular CLI solution

Angular CLI used to display black “Loading…” text on the white background but as of version 1.5.0 we only get <app-root></app-root> in our index.html file. This means that our users will see only blank white screen until our app and all vendor libraries are fully loaded and Angular successfully bootstrapped. This can easily take anything from three to tens of seconds on slower networks.

Better Solution

Lets provide our user with visual cues that our app is not broken and is in fact loading. This will increase probability that user will wait and use our app instead of leaving and searching for some alternatives.

In the following example animation loading takes only around 1.5 seconds but remember that in practice it could easily be more than 10 seconds on slow networks…

Loading animation is much better than nothing or default “Loading…” provided by previous versions of Angular CLI

ADVANCED: Some of you are surely already thinking about PWAs and their support for better offline / flaky internet scenarios but even with PWA we still need some visual loading cue during the initial visit until everything was loaded and cached in the service worker.

Anatomy of Angular application startup

During the development of our app we’re used to working with raw source files, be it Typescript or Sass styles. However this is not the form in which our app is consumed by the browser.

Building our app means that Angular CLI uses Webpack and a multitude of loaders to transpile and process all source files and assets to provide us with bundles which we then deploy to a server. Our app becomes available and can be requested by any user possessing correct URL.

What happens when user navigates browser to our app?

One picture is worth thousands of words so lets get right to it…