Planet Lean: The Official online magazine of the Lean Global Network
Doubling the number of performant Apps using kaizen

Doubling the number of performant Apps using kaizen

Nicolas Goutay
August 8, 2018

BUILDING BRIDGES – A member of the lean software development company Theodo team tells us about their attempts to improve the performance of their Web apps using lean principles.


Words: Nicolas Goutay, Web Performance Evangelist, Theodo

Photo by Helloquence on Unsplash


The consensus today is that a Web app should load in under three seconds under normal conditions. However, the fact that performance is often overlooked during development – coupled with the growing complexity of the Web – typically leads to the creation of rather slow Apps.

This is a problem that we at Theodo are very much aware of. In early 2018, nearly 80% of the applications we were working on were considered too slow. This was a pain point for our clients, and for their users.

In February, I teamed up with Kévin Jean, also a Software Architect, to improve the performance of our apps. As we both believe that lean thinking is a powerful framework for solving complex problems, our effort quickly turned into a kaizen.


INVESTIGATING THE STATE OF THE ART

Our first step was to research what the best companies out there had already achieved in terms of Web Performance. The first we looked at was Uber.

Confronted with a growing user base in emerging countries, Uber faced the challenge of delivering a streamlined user experience to entry-level devices on poor network conditions. They built m.uber.com, which packs the core of the Uber customer flow into a mind-bogglingly lightweight App:

Uber created a light App that loads fast

The Uber team used skillful techniques to shrink the App’s size to a mere 50 kilobytes — a 97% reduction from the average size. A lighter App means a shorter download time, which in turn means that the user can interact with the page more quickly. This outstanding achievement was a major source of inspiration for us.


IDENTIFYING THE PERFORMANCE VALUE FLOW

For our first foray into Web Performance, Kévin and I focused on the obvious: our own projects. Using our expertise and following our intuition, we managed to code our way through to reach the three seconds threshold. However, it became clear that we had not learned anything with regards to the kaizen. Indeed, there had been no concerted effort to analyze our clients’ websites in a lean-oriented way.

Thus, we began thinking about an analytic framework that could help us analyze any website, not just our own. We tried to think of a website like it was a factory. A factory takes a customer’s order, processes it and delivers the finished good. A website takes a user interaction (clicking on a link), processes it, and delivers the result (the home page). Our performance problem had turned into a lead-time problem.

To analyze the lead-time, we started by identifying the value flow: what steps does a Web browser go through to go from a click to a Web page? We began by dividing this process into three main steps: the HTML, the Assets, and the Data. (The HTML is the basic structure of a website, the assets are what makes it pretty – like images, style, interactivity – and the data is what makes it useful, like the contents of a user’s cart in an e-commerce website.)

Breaking down the process from click to page loading

This approach looked promising, although it turned out to be too simplistic when applied to other projects: there are many reasons why the assets step might take too long. We then zoomed in further. We completed the value flow by setting up standard timings adding up to 3 seconds. (The timings were devised based on our experience and on what we learned from our state-of-the-art research.)

Assigning standard timings to all steps in the process

We now had a performance value flow that had the potential to show specific problems in Web applications. We set out to use it to help Theodo build faster apps.

Our Theodo colleagues came to see us for help with the performance of their own products. Their problems were similar, although the causes varied (there can be many reasons behind a slow Web page). We taught them to map out their value flows so that potential performance bottlenecks became visible:

Value flows were drawn in multiple teams at Theodo

Then, by researching specific issues, we began collecting information on how to fix specific parts of the flow. We turned this knowledge into standards that were associated to different parts of the value flow, to directly link solutions to problems. Of course, the more projects used the value flow, the more standards were written — in a virtuous-circle fashion.


REDUCING WASTE IN WEB APPS

One advantage of the value flow is that it helps us to identify the Pareto ratio of performance. A quick look at the biggest gap between the standard timings and the actual loading times now tells us what to focus on next.

A critical step in terms of performance is typically the sixth one – “the browser downloads the assets”. This is where a heavy App causes an unsatisfactory download time.

Our kaizen showed us that developers often load libraries (reusable pieces of code developed and distributed by the community) that are not necessary to the application code, which often leads to wasteful downloads of chunks of code that will never be executed. One example of this is Lodash, a popular Javascript library that encapsulates 100+ often-used functions (it’s basically the Swiss Army knife of the Javascript developer). Say a developer needs to use the “flatten” method of the Lodash library to transform complex data structures into simpler ones. The naive way to use it would be to import it as is:

import { flatten } from 'lodash'; // weighs 71Kb

This, however, has the unexpected side effect of loading all of the 100+ Lodash functions, even though we only need to use one.

To avoid waste, a lesser-known approach to load only the specific function needed would be the following:

import flatten from `lodash/flatten`; // weighs 2.8Kb

This simple trick brings a size reduction of 68Kb, enough to speed up the loading time by 1 second for a 3G user!

Today, 60% of the Theodo Web applications load in under three seconds. We have also built a knowledge base of over 10 standards, covering many performance problems.

Our next challenge is to go from being reactive (fixing apps) to proactive (making performant apps from the get-go). To get there, we will need to learn how to code right first time for optimal Web Performance… I have no doubt kaizen will show us the way.


THE AUTHOR

Nicolas Goutay picture
Nicolas Goutay is a Web Performance Evangelist at Theodo

Read more

A bold lean experiment in one of our kitchens
November 27, 2018
A bold lean experiment in one of our kitchens

FEATURE – The lean mindset Legal Sea Foods has developed is allowing the company to run bold, aggressive experiments that might some day reinvent the way their restaurant kitchens work.

Continue reading
Transforming our way of managing using lean
November 4, 2021
Transforming our way of managing using lean

CASE STUDY – The turning point in this Colombian construction company’s transformation came when they started to embrace lean as a culture rather than just a set of tools.

Continue reading
Fancy a cup of lean coffee?
October 28, 2019
Fancy a cup of lean coffee?

FEATURE – What started as the idea of two friends to meet up and discuss their lean journeys turned into a regular get-together of lean practitioners in the Cape Town area. Another example of the importance of sharing.

Continue reading
Two years of hoshin at the Dutch Ministry of Infrastructure
August 27, 2015
Two years of hoshin at the Dutch Ministry of Infrastructure

FEATURE – The theory of hoshin kanri is clear, but how can you adapt it to a government organization structured in departments where making A3s is not a daily practice? A Dutch ministry shares its experience.

Continue reading

Read more

No items found.