--- title: Waterfall slug: Tools/Performance/Waterfall translation_of: Tools/Performance/Waterfall original_slug: Tools/Производительность/Waterfall ---

Водопад (Waterfall) даёт вам представление о различных процессах, которые происходят внутри браузера, когда вы открывайте ваш сайт или запускаете ваше приложение. Он основан на идее разделения всех происходящих внутри браузера процессов на различные типы - запуск JavaScript, обновление layout и так далее - и что в любой момент времени браузер выполняет один из этих процессов.

Поэтому если вы увидите признаки проблем с производительностью - например, падения частоты кадров - вы можете запустить Waterfall, чтобы увидеть, что делает браузер в этот момент.

Ось X это ось времени. Записанные операции и вызванные маркеры отображаются в виде горизонтальных прямоугольников, расположенных в виде водопада, чтобы подчеркнуть последовательность выполнения внутри браузера.

При выборе маркера вы увидите подробную информацию о нем на панели справа. В этой панели вы сможете узнать продолжительность и другую специфичную для конкретного типа процесса информацию .

Markers

The markers for operations are color-coded and labeled. The following operations are recorded:

Name and description	Color	Detailed information
DOM Event JavaScript code that's executed in response to a DOM event.		Event Type For example, "click" or "message". Event Phase For example, "Target" or "Capture".
JavaScript functions executed in the page are labeled with the reason the function was called: Script Tag setInterval setTimeout requestAnimationFrame Promise Callback Promise Init Worker JavaScript URI Event Handler		Stack Call stack, with links to functions.
Parse HTML Time spent parsing the page's HTML.		Stack Call stack, with links to functions.
Parse XML Time spent parsing the page's XML.		Stack Call stack, with links to functions.
Recalculate Style Calculating the computed styles that apply to page elements.		Restyle Hint A string indicating what kind of restyling is needed. The hint may be any of: Self Subtree LaterSiblings CSSTransitions CSSAnimations SVGAttrAnimations StyleAttribute StyleAttribute_Animations Force ForceDescendants
Layout Calculating the position and size of page elements. This operation is sometimes called "reflow".
Paint Drawing pixels to the screen.
GC Event Garbage collection event. Non-incremental GC events are labeled "(Non-incremental)".		Reason A string the indicating the reason GC was performed. Non-incremental Reason If the GC event was non-incremental, a string the indicating the reason non-incremental GC was performed.
Console The period between matching calls to `console.time()` and `console.timeEnd()`.		Timer name The argument passed to the `console` functions. Stack at start Call stack `console.time()`, with links to functions. Stack at End (New in Firefox 41). Call stack at `console.timeEnd()`. If this is inside a callback from a `Promise`, this will also show the "Async stack".
Timestamp A single call to `console.timeStamp()`.		Label The argument passed to `timeStamp()`.

The markers, and their colors, are the same in the Waterfall tool as in the Waterfall overview, making is easy to correlate from one to the other.

Filtering markers

You can control which markers are displayed using a button in the Toolbar:

Waterfall patterns

Exactly what you'll see in the Waterfall is very dependent on the kind of thing your site is doing: JavaScript-heavy sites will have a lot of orange, while visually dynamic sites will have a lot of purple and green. But there are common patterns which can alert you to possible performance problems.

Rendering waterfall

One pattern that you'll often see in the Waterfall view is something like this:

This is a visualization of the basic algorithm the browser uses to update the page in response to some event:

JavaScript Function Call: some event - for example, a DOM event - causes some JavaScript in the page to run. The JavaScript changes some of the page's DOM or CSSOM.
Recalculate Style: if the browser thinks the computed styles for page elements have changed, it must then recalculate them.
Layout: next, the browser uses the computed styles to figure out the position and geometry for the elements. This operation is labeled "layout" but is also sometimes called "reflow".
Paint: finally, the browser needs to repaint the elements to the screen. One last step is not shown in this sequence: the page may be split into layers, which are painted independently and then combined in a process called "Composition".

This sequence needs to fit into a single frame, since the screen isn't updated until it is complete. It's commonly accepted that 60 frames per second is the rate at which animations will appear smooth. For a rate of 60 frames per second, that gives the browser 16.7 milliseconds to execute the complete flow.

Importantly for responsiveness, the browser doesn't always have to go through every step:

CSS animations update the page without having to run any JavaScript.
Not all CSS property changes cause a reflow. Changing properties that can alter an object's geometry and position, such as width, display, font-size, or top, will cause a reflow. However, changing properties that don't alter geometry or position, such as color or opacity, will not.
Not all CSS property changes cause a repaint. In particular, if you animate an element using the transform property, the browser will use a separate layer for the transformed element, and doesn't even have to repaint when the element is moved: the new position of the element is handled in composition.

The Animating CSS properties article shows how animating different CSS properties can give different performance outcomes, and how the Waterfall can help signal that.

Blocking JavaScript

By default, a site's JavaScript is executed in the same thread that the browser uses for layout updates, repaints, DOM events, and so on. This means that long-running JavaScript functions can cause unresponsiveness (jank): animations may not be smooth, or the site might even freeze.

Using the frame rate tool and the Waterfall together, it's easy to see when long-running JavaScript is causing responsiveness problems. In the screenshot below, we've zoomed in on a JS function that's caused a drop in the frame rate:

The Intensive JavaScript article shows how the Waterfall can highlight responsiveness problems caused by long JavaScript functions, and how you can use asynchronous methods to keep the main thread responsive.

Expensive paints

Some paint effects, such as box-shadow, can be expensive, especially if you are applying them in a transition where the browser has to calculate them in every frame. If you're seeing drops in the frame rate, especially during graphically-intensive operations and transitions, check the Waterfall for long green markers.

Garbage collection

Red markers in the Waterfall represent garbage collection (GC) events, in which SpiderMonkey (the JavaScript engine in Firefox) walks the heap looking for memory that's no longer reachable and subsequently releasing it. GC is relevant to performance because while it's running the JavaScript engine must be paused, so your program is suspended and will be completely unresponsive.

To help reduce the length of pauses, SpiderMonkey implements incremental GC: this means that it can perform garbage collection in fairly small increments, letting the program run in between. Sometimes, though, it needs to perform a full non-incremental collection, and the program has to wait for it to finish.

When the Waterfall records a GC marker it indicates:

whether the GC was incremental or not
the reason the GC was performed
if the GC was non-incremental, the reason it was non-incremental

In trying to avoid GC events, and especially non-incremental GC events, it's wise not to try to optimize for the specific implementation of the JavaScript engine. SpiderMonkey uses a complex set of heuristics to determine when GC is needed, and when non-incremental GC in particular is needed. In general, though:

GC is needed when a lot of memory is being allocated
non-incremental GC is usually needed when the memory allocation rate is high enough that SpiderMonkey may run out of memory during incremental GC

Adding markers with the console API

Two markers are directly controlled by console API calls: "Console" and "Timestamp".

Console markers

These enable you to mark a specific section of the recording.

To make a console marker, call console.time() at the start of the section, and console.timeEnd() at the end. These functions take an argument which is used to name the section.

For example, suppose we have code like this:

var iterations = 70;
var multiplier = 1000000000;

function calculatePrimes() {

  console.time("calculating...");

  var primes = [];
  for (var i = 0; i < iterations; i++) {
    var candidate = i * (multiplier * Math.random());
    var isPrime = true;
    for (var c = 2; c <= Math.sqrt(candidate); ++c) {
      if (candidate % c === 0) {
          // not prime
          isPrime = false;
          break;
       }
    }
    if (isPrime) {
      primes.push(candidate);
    }
  }

  console.timeEnd("calculating...");

  return primes;
}

The Waterfall's output will look something like this:

The marker is labeled with the argument you passed to console.time(), and when you select the marker, you can see the program stack in the right-hand sidebar.

Async stack

New in Firefox 41.

Starting in Firefox 41, the right-hand sidebar will also show the stack at the end of the period: that is, at the point console.timeEnd() was called. If console.timeEnd() was called from the resolution of a Promise, it will also display "(Async: Promise)", under which it will show the "async stack": that is, the call stack at the point the promise was made.

For example, consider code like this:

var timerButton = document.getElementById("timer");
timerButton.addEventListener("click", handleClick, false);

function handleClick() {
  console.time("timer");
  runTimer(1000).then(timerFinished);
}

function timerFinished() {
  console.timeEnd("timer");
  console.log("ready!");
}

function runTimer(t) {
  return new Promise(function(resolve) {
    setTimeout(resolve, t);
  });
}

The Waterfall will display a marker for the period between time() and timeEnd(), and if you select it, you'll see the async stack in the sidebar:

Timestamp markers

Timestamps enable you to mark an instant in the recording.

To make a timestamp marker, call console.timeStamp(). You can pass an argument to label the timestamp.

For example, suppose we adapt the code above to make a timestamp every 10 iterations of the loop, labeled with the iteration number:

var iterations = 70;
var multiplier = 1000000000;

function calculatePrimes() {
  console.time("calculating...");

  var primes = [];
  for (var i = 0; i < iterations; i++) {

    if (i % 10 == 0) {
      console.timeStamp(i.toString());
    }

    var candidate = i * (multiplier * Math.random());
    var isPrime = true;
    for (var c = 2; c <= Math.sqrt(candidate); ++c) {
      if (candidate % c === 0) {
          // not prime
          isPrime = false;
          break;
       }
    }
    if (isPrime) {
      primes.push(candidate);
    }
  }
  console.timeEnd("calculating...");
  return primes;
}

In the Waterfall you'll now see something like this: