Fix the Document Object Model (DOM) for performance
It is easy to be critical. It is much harder to present practical solutions. I hesitate to write critical articles if they do not offer a better way. However, even though this article does not offer a better way, DOM performance is the elephant in the room that must be talked about.
What’s Wrong With The DOM?
The DOM (Document Object Model) provides an API that lets programs flexibly and dynamically query and change a web browser’s contents. Through it, we can access pretty well anything that is displayed within the web browser.However, this benefit has its cost. Most programmers do not know how to access the DOM in a performance-optimal manner. Even those who do know the tricks of the DOM-masters face system-imposed limitations. They can go only so far. Handling the DOM has been identified by many experts as one of the top three performance problems across the entire World-Wide Web.The DOM’s performance issues stem from all of:
- algorithms that do not scale well;
- every individual DOM change triggers its own reflow, even if it’s part of a group of changes (recent changes have implemented batching, which is a big help, but more is needed);
- the cascading nature of reflows (a change to one element can change many, many other elements);
- the impact of a simple query (asking the DOM a formatting question can trigger a non-batched reflow);
- the speed (or lack thereof) of the machine’s video subsystem;
- reflows, more reflows, and yet more reflows.
How To Fix It
And now we come to the part of the article where I have questions without answers. Please consider this a cry for help directed to those who have the technical skill and creativity to take on this task. [Artificial Intelligence experts, for example, may be able to make a significant contribution.]This raises another question: Can the DOM be fixed or must it be replaced? If we implement changes in baby steps, we may eventually arrive at a performance level we find acceptable. However, we may not. Perhaps a better interface between JavaScript and the displayed visuals is just waiting to be discovered. What do you think?
Conclusion
Everyone seems to agree on one point: For slow websites, the DOM is one of the most common culprits. I propose that the standard needs to be fixed, but recognize that this task requires a level of technical skill not commonly available.We are left with a question: Should we fix the DOM or replace it? I wonder what the answer will be.
