Safe maximum number of nodes in the DOM?

Question

For a web client designed for handheld computers sold from 2013-2017. Android, IOS (250 to 4000 MB RAM), what is the safe maximum number of DOM nodes, including text nodes, that can be generated using HTML?

Before running out of memory or device crashes. Also before it slows down. The same question for all browsers, if there are any differences (IE 11 and Edge, firefox, opera, chrome, safari).

Is there a hard limit in any browser so as not to cross each tab?

Answer 1

This is a question for which only a statistical answer can be accurate and comprehensive.

Why

The corresponding equation is this: where N is the number of nodes, _N bytes are the total bytes needed to represent them in the DOM, and the index node n ∈ [0, N) .

bytes _N = Σ ^N (bytesContent _n + bytesOverhead _n )

The value asked in the question is the maximum value of N in the worst handheld device, operating system, browser, and operating conditions. The solution for N for each permutation is not trivial. The equation above shows three dependencies, each of which can radically change the answer.

• The average size of a node depends on the average number of bytes used in each to store content, such as UTF-8 text, attribute names and values, or cached information.
• The average overhead of a DOM object depends on the HTTP user agent that controls the DOM presentation of each document. W3C Frequently Asked Questions about the Document Object Model : "Although all DOM implementations must be compatible, they can vary significantly in code size, memory requirement, and performance of individual operations.
• The memory available for use in DOM views depends on the default browser used (which may vary depending on which browsers or users prefer handheld devices), default browser user redefinition, operating system version, pocket device memory size, general background tasks and other memory consumption.

Strict decision

You could run tests to determine (1) and (2) for each of the common HTTP agents used on handheld devices. The distribution of user agents for any given site can be obtained by setting up the web server logging mechanism to put HTTP_USER_AGENT if it is absent by default, and then deletes everything except this field in the log and counts the instances of each value.

The number of bytes per character should be checked for both attribute values ​​and the internal text of UTF-8 (or any other) in order to get a clear pair of factors for calculation (1).

Available memory also needs to be tested in a variety of conditions, which in itself is a major research project.

The particular value of the selected N must be ZERO to handle the worst case, so a certain percentage of typical content cases, node structures, and runtime conditions could be selected. For example, you can take a sample of cases using some form of randomized in situ (under normal environmental conditions) studies and find N that satisfies 95% of these cases.

Perhaps many cases can be checked by the indicated methods and the results placed in the table. This will be a direct answer to your question.

I guess this will require an excellent mobile software programmer with a good mathematical background and a statistic expert who will work together full time with a significant budget for about four weeks to get reasonable results.

More practical assessment

You can guess the worst case scenario. With a few full days of research and several proof-of-concept applications, this proposal could be clarified. Lack of time for this, here is a good first guess.

Consider a cell phone that permits 1 GB for the DOM, because normal operating conditions use 3 GB of 4 GB for the above purposes. We can assume that the average memory consumption for node will be as follows to get the number of the spherical field.

• 2 bytes per character for 40 characters of internal text on node
• 2 bytes per character for 4 attribute values ​​of 10 characters each
• 1 byte per character for 4 attribute names, 4 characters each
• 160 bytes for C / C ++ node service messages

In this case, N is the _{worst_card the} worst smallest node,

 = 1,024 X 1,024 X 1,024 / (2 X 40 + 2 X 4 X 10 + 1 X 4 X 4 + 160) = 3,195,660 . 190,476. 

However, I would not have created a document in a browser with three million DOM nodes, if it could have been avoided at all. Consider using the more common practice below.

General practice

The best solution is to stay far below what N may be and simply reduce the total number of nodes to an extent using standard HTTP development methods.

• Reduce the size and complexity of what is displayed on any page, which also improves visual and conceptual clarity.
• Request the minimum amount of data from the server, set aside content that is not yet visible using window processing methods, or balance response time with memory consumption in well-planned ways.
• Use asynchronous calls to help with this minimalism.

Answer 2

There are no restrictions for the DOM. Instead, there is a limit to a running application called a “browser”. Like all other applications, it has a limit of 4 GB of virtual memory. How much resident memory is used depends on the amount of physical memory. With low RAM, you may encounter a situation of constant replacement and exit (having available paging memory). Some systems (Linux, Android) have a special kernel task for destroying applications if the system runs out of memory. In addition, the maximum application size on Linux systems is typically limited to 2 MB of virtual memory and can be changed ulimit command.