Bewerken

Delen via


Fix memory problems

To find memory issues that affect page performance, including memory leaks, memory bloat, and frequent garbage collections, use the following tools:

  • Microsoft Edge Browser Task Manager.
  • The Performance tool's Memory checkbox.
  • The Memory tool's various profiling types.

Tools for investigating memory usage

Use case Tool Article
Monitor how much memory a webpage uses, in realtime. Microsoft Edge Browser Task Manager Monitor memory use in realtime (Microsoft Edge Browser Task Manager)
Visualize the memory usage of a webpage over a period of time. Performance tool > Memory checkbox Visualize memory leaks (Performance tool: Memory checkbox) in Performance features reference.
Spot frequent garbage collections. Microsoft Edge Browser Task Manager, or Performance tool > Memory checkbox Spot frequent garbage collections (Microsoft Edge Browser Task Manager, Performance tool's Memory checkbox), below.
Inspect the contents of the memory used by a webpage. Memory tool > Heap snapshot Record heap snapshots using the Memory tool ("Heap snapshot" profiling type)
Find out which JavaScript objects get created over a period of time, to isolate memory leaks. Memory tool > Allocations on timeline Use Allocation instrumentation on timeline ("Allocations on timeline" profiling type)
Find out which JavaScript functions allocate memory over a period of time. This profile type has minimal performance overhead and can be used for long-running operations. Memory tool > Allocation sampling Speed up JavaScript runtime ("Allocation sampling" profiling type)
Find DOM tree memory leaks. Memory tool > Detached elements Debug DOM memory leaks ("Detached elements" profiling type)

The Memory tool

The main tool for investigating memory issues is the Memory tool:

The Memory tool

A Detached Elements profile in the Memory tool:

A Detached Elements profile

To return to the list of option buttons for profiling types, in the upper left of the Memory tool, click Profiles (the Profiles icon).

Overview of fixing memory problems

In the spirit of the RAIL performance model, the focus of your performance efforts should be your users.

Memory issues are important because they are often perceivable by users. Users may perceive memory issues in the following ways:

  • The performance of a page gets progressively worse over time. This is possibly a symptom of a memory leak. A memory leak is when a bug in the page causes the page to progressively use more and more memory over time.

  • The performance of a page is consistently bad. This is possibly a symptom of memory bloat. Memory bloat is when a page uses more memory than is necessary for optimal page speed.

  • The performance of a page is delayed or appears to pause frequently. This is possibly a symptom of frequent garbage collections. Garbage collection is when the browser reclaims memory. The browser decides when this happens. During collections, all script running is paused. So if the browser is garbage collecting a lot, script runtime is going to get paused a lot.

Memory bloat: How much is "too much"?

A memory leak is easy to define. If a site is progressively using more and more memory, then you have a leak. But memory bloat is a bit harder to pin down. What qualifies as "using too much memory"?

There are no hard numbers here, because different devices and browsers have different capabilities. The same page that runs smoothly on a high-end smartphone may crash on a low-end smartphone.

The key here is to use the RAIL model and focus on your users. Find out what devices are popular with your users, and then test out your page on those devices. If the experience is consistently bad, the page may be exceeding the memory capabilities of those devices.

Spot frequent garbage collections (Microsoft Edge Browser Task Manager, Performance tool's Memory checkbox)

If your page appears to pause frequently, then you may have garbage collection issues. To spot frequent garbage collection, you can use either:

  • Microsoft Edge Browser Task Manager. Frequently rising and falling Memory or JavaScript Memory values represent frequent garbage collection. See Monitor memory use in realtime (Microsoft Edge Browser Task Manager).

  • The Performance tool's Memory checkbox. In Performance memory recordings, frequent changes (rising and falling) to the JS heap or node count graphs indicate frequent garbage collection. See View memory metrics in Performance features reference.

After you have identified the problem by using either of those tool, you can then use the Memory tool's Allocations on timeline profiling type to find out where memory is being allocated, and which functions are causing the allocations. See Use Allocation instrumentation on timeline ("Allocations on timeline" profiling type).

Find DOM tree memory leaks from detached elements

A DOM node is only garbage-collected by the browser when there are no references to the node from either the DOM tree or JavaScript code running on the page. A node is said to be "detached" when it is removed from the DOM tree but some JavaScript still references it. Detached DOM nodes are a common cause of memory leaks.

Tools for investigating detached elements

Use case Tool Article
Show detached elements only, as DOM tree nodes. Memory tool > Detached elements profiling type Debug DOM memory leaks ("Detached elements" profiling type)
Show all objects in memory, filtered to display detached elements, with links to the JavaScript source code. Memory tool > Heap snapshot profiling type > Detached Find DOM tree memory leaks ("Heap snapshot" profiling type > Detached) in Record heap snapshots using the Memory tool ("Heap snapshot" profiling type).
Show detached elements only, as DOM tree nodes, with links to the JavaScript source code. Detached Elements tool Debug DOM memory leaks by using the Detached Elements tool

See also

External:

Note

Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons Attribution 4.0 International License. The original page is found here and is authored by Kayce Basques.

Creative Commons License This work is licensed under a Creative Commons Attribution 4.0 International License.