Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid an excessive DOM size #434

Open
wisniewski94 opened this issue May 3, 2022 · 3 comments
Open

Avoid an excessive DOM size #434

wisniewski94 opened this issue May 3, 2022 · 3 comments

Comments

@wisniewski94
Copy link

wisniewski94 commented May 3, 2022

Step 1: Describe the problem:

Steps to reproduce:

  1. Open Demo
  2. Run the lighthouse performance audit

Observed Results:

  • You should see Avoid an excessive DOM size (3,458 elements) error

This is because of the use of the HTML tables which add a few layers of depth to the DOM tree. With more complex usages this number can grow up to 10k+. I don't think this problem can be completely solved because highlight.js adds a lot of HTML elements but it should be possible to lower this number a bit by avoiding the <table> element. Proof of concept is browser visual studio code diff which uses only a combination of divs and spans.

I am going to spend some time on this issue to see what are potential cons of this approach.

@rtfpessoa
Copy link
Owner

👋 let me know how it is going and if you can find some improvements we can do.

Honestly to get to this state it took a lot of trial and error. Frontend is not my main language and it took me a while. 😓

If you have improvements we can do, they are very welcome. I can help test if they break something.

@brandonsturgeon
Copy link

I have to display a diff that comes from other changes. I can't guarantee that it will be small.

Right now, with a sizable diff (lots of files, specifically), loading diff2html is really slow. I wonder if the element count has something to do with it.

Any progress on this?

@wisniewski94
Copy link
Author

@brandonsturgeon I have paused the work on this due to higher priorities in other projects. I could go down with the count slightly but the further I went the more hacks I implemented with which I did not feel ok and ultimately lost motivation for a moment. I guess if we could break it into steps of minor improvements, the progress of this task would be better. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants