Slow performance on https://github.com/public-apis/public-apis compared to Chrome
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
Performance Impact | low |
People
(Reporter: ksenia, Assigned: emilio)
References
Details
Attachments
(2 files, 2 obsolete files)
### Basic information
This was initially reported in https://github.com/webcompat/web-bugs/issues/131302 where a user is experiencing slow page and content load
Steps to Reproduce:
- Sign in on GitHub
- Visit https://github.com/public-apis/public-apis
Expected Results:
Page and content loads fast
Actual Results:
Page and content load takes a lot of time
Performance recording (profile)
Profile URL: https://share.firefox.dev/3SeCe4V (recorded in Firefox Nightly 123.0a1 (2024-01-02))
System configuration:
OS version: Windows 10, but can be reproduced on other platforms as well
Reporter | ||
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Emilio has indicated this might be improved by: https://bugzilla.mozilla.org/show_bug.cgi?id=1866161
The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.
Platforms: Windows
Impact on site: Causes noticeable jank
Websites affected: Rare
[x] Able to reproduce locally
Comment 2•1 year ago
•
|
||
The page loads fast to me in Nightly.
Bug 1866161 landed awhile ago, but I think there was some other fix which landed recently.
Assignee | ||
Comment 3•1 year ago
|
||
I can reproduce on Nightly.
Assignee | ||
Comment 4•1 year ago
|
||
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 5•1 year ago
|
||
Comment on attachment 9379220 [details]
Attempt at a test-case.
Meh, that doesn't work. In any case it seems to be this code.
Assignee | ||
Updated•1 year ago
|
Setting to S3 because of "performance impact: low". Feel free to upgrade it if this is more important.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 7•1 year ago
|
||
Assignee | ||
Comment 8•1 year ago
|
||
Make sure to do no work on insertions if the dir=auto element has
already the right strong directionality, but record that the node might
be the one impacting the dir=auto resolution.
Also get some node flags back.
To be landed after merge of course.
Updated•1 year ago
|
Assignee | ||
Comment 9•1 year ago
|
||
This is probably because I've been awake for too long at this point
while traveling back from CSSWG meetings, but these make my head
spin.
Let's avoid the double-negatives. I think it's easier to reason
about.
Depends on D202071
Assignee | ||
Comment 10•1 year ago
|
||
Uh, latest version has some orange on try which I need to fix up.
Updated•1 year ago
|
Assignee | ||
Comment 11•1 year ago
|
||
This test caught a subtle bug in one of the versions of my previous
patch, but it caught it by chance.
The reason it got caught is because the reftest harness uses a mutation
observer, and thus disables the textContent optimization that reuses the
text node.
WPT didn't catch this, so move the test there, and add tests for the
characterData mutation and removal-and-append explicitly, to not depend
on textContent optimizations.
Assignee | ||
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
Comment 16•1 year ago
|
||
bugherder |
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Description
•