Urban Jungle v2.0 has launched!

On the surface, the look isn’t that different. On the technical side however, we’ve been excited about making the code cleaner, the app faster and hopefully the overall experience for the user, better.

What was the challenge?

At Urban Jungle, we’re all about making it super easy to get your home insurance sorted. So for ease of use and smoother experience, we’d chosen to go with a single-page app (SPA) architecture.

The tradeoff is, the app is loaded up front when a user lands on the site. We were concerned that this meant some users, particularly those with a bad mobile connection, could suffer slow speeds at the previous build size.

Summary —what did we achieve?

For users:

• Reducing load time to a third of what it was (from 7.9 seconds to 2.6 seconds based on google analytics)
• Cutting initial bundle size to one sixth(!) of what it was (from 6.2MB to <1MB)

For us:

• Tighter build-measure-learn loop — faster deployment of a more maintainable library

How did we do it?

The team had earmarked 3 months for a rewrite of the site after the launch of v1 (our minimum viable product) in July. While the aim of v1 was to get something out to test the market, v2 was about streamlining a solid base for vN.

1. Biting the bullet and migrating from Angular 2 to Angular 4

The front end of Urban Jungle is built using Angular, an open-source framework designed by Google who this year released its upgrade (good summary here).

In essence, Angular 4 apps use less space and run quicker compared to Angular 2 apps. However, the decision to migrate is hardly ever (dare I say never?) cost free. We knew we would have to update the codebase and rewrite some key components to accommodate the changes. The technical team made the conscious decision to migrate, and invest the time doing so, to make sure we continue to provide the best product.

2. Utilising Lazy Loading

Lazy loading speeds up the app by only loading features when the user navigates to their routes. So rather than loading the whole app upfront, this technique breaks it up into smaller bundles that are loaded on demand.

We then combined this with a pre-loading strategy for setting the order of modules to be pre-loaded in the background, in anticipation of what may be needed next. This reduces build size and contributes to a smoother user experience.

3. Stripping out vendor packages

As a point of general housekeeping, it’s good to delete redundant package imports to a module so that it isn’t bundled unnecessarily with a build. When making a Javascript app, it’s easy to get npm happy; you read about a cool implementation or bug fix in stack overflow and before you know it, you’re 6 months in with a thousand dependencies.

A solid win from our vendor tidy-up was moving from bundling Auth0 dependency in our app, to using their hosted page solution. This reduced the size of the app by a fair chunk as well as removing a number of javascript dependencies.

We also looked to make the best use of any external libraries i.e. doing 5 things with 3 libraries rather than 5 (if possible) which meant being more discerning with the libraries we chose.

All in all, the rewrite gave us the opportunity to revisit those moments which made us go “if I could do this again, I would’ve done it differently”.

During this period, we took the time to review and tidy up the codebase by making features more modular and the code cleaner (made components more reusable and better use of services). This not only makes for happier development (and developer) but also faster deployment of a more maintainable library.