HOW WE’RE GOING TO DO IT

So far we've identified two major architectural problems that contribute to slow bootstrap times. The first is our plugin architecture, which allows us to break the code for the client up into useful chunks. This architecture has gotten bloated as we've added more new functionality to the client. Second, we're misusing the Javascript framework (called Ember) that drives our UI.

Right now, the client uses far too many plugins and Ember apps. In fact, during the client's bootstrap process, we load in 41 separate plugins and 16 apps. Each of these takes anywhere from 100ms to 800ms each to start up. That's not great.

Our plan is to consolidate all those plugins and apps down into way fewer (and theoretically more efficient) plugins and apps. We're going to focus on the ones that start up during bootstrap first because we believe that'll get us the biggest gains throughout the client.

PHASE 1: BOOTSTRAP

Today it takes as long as 40 seconds for many of you to get through bootstrap. If you're one of these players, you know that the experience can be extremely slow and janky. It also means that when your client crashes, restarting it is that much more painful.

Lots of things throughout the client like notifications, the friends list, and the collection tab are affected by the plugins and apps that start up during bootstrap. So although our stated long-term goal is to get bootstrap time down to 15 seconds for the 90th percentile player, we think that in the process we'll also be addressing a bunch of bugs and inefficiencies that have an impact throughout the client.

After a few months of focusing on bootstrap, we'll assess how close we are to our goals, and then—probably near the end of spring—we'll move on to focus specifically on champ select.

PHASE 2: CHAMP SELECT

Champ select introduces many additional plugins and Ember apps. To put it bluntly, almost everything you do in champ select creates new apps. Trading champions generates two of them. So does changing your summoner spell.

The longer you play League in a single session, the more these apps pile up on top of each other, resulting in an increasingly laggy experience. This problem is compounded by the fact that most of the actions you take during champ select rely on communication with our servers, adding latency to every interaction.

The real, root problem in champ select is the way that our backend systems manage data. The current architecture of champ select allows us to pass a lot of powerful data through our systems. For example, if Riot decides to disable a champion in ranked, that champion will become disabled almost immediately for all players, including those who are currently in champ select when the disable is pushed live.

That's a very powerful system, but it requires a lot of horsepower to make it work. And the way the system is currently set up, there's a lot of unnecessary gates and bottlenecks in the process. So oftentimes, tons of data gets re-rendered when only one small input has been changed. This results in tons of damage to your client experience.

To fix this, we'll have to fundamentally change the way our champ select backend infrastructure works. We're going to rework how all data is passed through from server to client during champ select, which will take some time.

We have other ambitious, long-term goals that could make champ select even more efficient, like consolidating the whole client down to a single Ember app with no plugins at all. But for the short term, we want to implement enough changes to make the client run at our target rates, which we've shared above.

It's unclear how close to "good" we'll be when we finish this six-month process. But when we get to the end of it, we think we'll probably have made a ton of progress and discovered clear next steps.