You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
42 lines
2.8 KiB
Plaintext
42 lines
2.8 KiB
Plaintext
# Identifying & Diagnosing Bottlenecks
|
|
|
|
When your application is not performing as you would like or expect, what can you do? What follows is my general approach to solving performance bottlenecks with a focus on React specific tools. There is an element of creativity to the process though so you should take this more as a guide and not something set in stone. You can start here but also try to find what works best for you.
|
|
|
|
These are the six main steps I use to solve performance bottlenecks:
|
|
|
|
* Describing the performance bottleneck
|
|
* Measuring the bottleneck
|
|
* Identifying the source
|
|
* Diagnosing the cause
|
|
* Generating possible solutions
|
|
* Selecting and implementing a solution
|
|
|
|
{width: "90%", caption: "Figure 1: Tree of components"}
|
|
|
|
|
|
As you can see in Figure 1, I use them in a cycle centered around measuring the bottleneck. Having some way to measure the bottleneck is extremely important. Without measuring you will not always be able to tell if the changes you made in the cycle had any effect.
|
|
|
|
## Describing Performance Issues
|
|
|
|
The first step is to identify and qualify the bottleneck. You can start by asking "what are the symptoms?" and "what triggers them?". It's very important to dig in as much as possible at this stage and gather as much information as possible. Here are the questions I generally use to get you started:
|
|
|
|
* What specifically is the issue?
|
|
* A lack of responsiveness?
|
|
* Temporary jankiness?
|
|
* What am I/the user being prevented from doing?
|
|
* When does the issue start?
|
|
* When does it finish?
|
|
* Is the intensity and/or duration variable or constant?
|
|
* Is it predictable? Does it always happen?
|
|
* Does it seem like anything triggers it?
|
|
|
|
You can start with trying to answer these questions or you can come up with your own. The only way to get good at it is practice as it's more and an art than a science at this stage.
|
|
|
|
This stage might not seem that important or the answers might seem obvious but being thorough here can actually save you a lot of time later on. It's very easy to misunderstand a bottleneck and then begin your investigation in the wrong place, wasting valuable time, or even worse, crafting a solution to the wrong problem.
|
|
|
|
## Measuring
|
|
|
|
Once you've described the performance issue in as much detail as you can it's time to move on to the next stage: measuring the issue. This stage is vital to the process. Do not skip this stage. The only way later on to ensure you've actually fixed the problem is to measure the problem to the best of your ability. The better you can quantify the issue the easier the rest of the process will be. This can be very challenging, especially with things that seem immeasurable, like UI jankiness but if you work at it there is generally a way to do. We will discuss a few techniques coming up.
|
|
|
|
|