Riot is some busy beez right now , they are not only releasing games they are also improving the biggest of them all. League of Legends client is going under the knife. Here is what Riot says about it.
TL;DR: Over the next six months or so we’ll ship a number of changes and improvements to the League client’s backend infrastructure. To track our process, we’ll be sharing specific targets for two main client performance metrics: client bootstrap time (how long it takes for the client to boot up) and champ select lock-in time. In the process of improving these metrics, we’ll also be tackling things like bugs, crashes, etc. Put simply, our goal is to fix the client.
“Riot, when are you going to fix the client?”
It’s a question a lot of you have been asking. The client is not in great shape. It’s got too many bugs, too much lag (especially in champ select), and a whole host of issues like memory leaks, crashes, freezes, and on and on. We’ve made commitments to do something about the client before, and yet problems remain.
So we want to try something different.
Instead of talking in vague terms about our plans, today we’re sharing specific performance targets and clear details on the changes we intend to ship over the next six months.
First, let’s talk about some recent performance improvements we’ve made and dig into some hard numbers that will serve as guideposts as we pursue future improvements.
THE CLIENT IN NUMBERS
Late last year, we added some tools to the client that allow us to track basic performance indicators like, for example, the amount of time it takes for the client to boot up and become fully functional (aka “bootstrap”).
We would like bootstrap to take under 15 seconds, even for players with relatively slow machines. However, we found that, currently, bootstrap can take up to three or even four times that long for some players.
Another major thing we’ve been tracking is “champ select lock-in” time. This is the amount of time that it takes the client to register that you’ve locked in your champ after you click the button. In the chart below, you’ll see average response times for champ select lock-in during patch 9.22 (orange line) and in patch 10.2 (blue line). Lock-in response time is calculated in milliseconds.
The chart above shows how vastly different champ-select response times can be for different players. Of course, client performance varies depending on how fast your machine is. If, for instance, it takes under 200ms for you to lock-in, your machine is in the 10th percentile, and your response times are faster than 90% of all players. Likewise, if response times for you are over 800ms, you’re in the 90th percentile, which means your client is running slower for you than for 90% of all players.
As you can see, lock-in times got a lot better for players during patch 10.2 compared to patch 9.22. The big reason for the improvement is that, in patch 9.23, we updated the version of Chromium that the client runs on. It got us some big gains, but we think the client is still far too slow for many of you.
To see what we mean, let’s take a peek at a more detailed view of champ select lock-in response speed over time for a few of those specific groups.
As you can see, the blue line represents the 50th percentile, or the “median” player. The big drop in response times for the median player here is good. But you can see that even as of early 2020, champ select response times for the median player are hovering around 300ms. That’s not horrible, but it’s still a perceptible delay.
The 70th percentile players (green line) have also experienced big improvements recently, but champ select response times for them are hovering around 450ms. That’s nearly a half a second delay, which is frankly much slower than what we’d want for anyone with a halfway decent machine.
Lastly, take a look at the 90th percentile (orange line) in all its terrible glory. By definition, these players are going to be experiencing a slower response time than most. But 800ms is too high, and that’s where these players are sitting even after the Chromium update.
So! Let’s talk about what we’re going to do next.
WHAT WE’RE GOING TO PRIORITIZE NEXT
There are two specific, long-term targets for client performance that we’re prioritizing:
- We want to lower bootstrap time to about 15 seconds, even for 90th percentile players. That’s between three and four times faster, compared to where it’s at now.
- We want to get champ select lock-in response times down to around 100ms for 90th percentile players. That’s about eight times faster than today.
We know what you’re thinking. What about the bugs? What about crashes and memory leaks?
Why prioritize these two things first? The reason is that, in the process of addressing bootstrap time and champ select lock-in time, we’re going to be cleaning up and reworking certain fundamental aspects of the client’s architecture. We believe that we’ll be able to opportunistically address bugs, memory leaks, and crashes while pursuing these targets.
Issues like the “black screen” bug in champ select and rune pages not saving properly are just examples of things we intend to address as part of this process. But we want to be very transparent about the fact that this will take time. We currently have a rough six month plan that we believe will earn us meaningful progress toward these goals. But reaching our long-term targets will likely take longer.
These are targets, and it’s possible we may fall short. We’re sharing our targets with you because we know that in order to build back up trust in the client, we have to be more transparent than ever.
So, you’re asking, how exactly are we going to do it?
HOW WE’RE GOING TO DO IT
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.