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•9 months ago
|
Comment 1•8 months 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•8 months 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•8 months ago
|
||
I can reproduce on Nightly.
Assignee | ||
Comment 4•8 months ago
|
||
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 5•8 months 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•8 months ago
|
Comment 6•8 months ago
|
||
Setting to S3 because of "performance impact: low". Feel free to upgrade it if this is more important.
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 7•7 months ago
|
||
Assignee | ||
Comment 8•7 months 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•7 months ago
|
Assignee | ||
Comment 9•7 months 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•7 months ago
|
||
Uh, latest version has some orange on try which I need to fix up.
Updated•7 months ago
|
Assignee | ||
Comment 11•7 months 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•7 months ago
|
Comment 12•7 months ago
|
||
Assignee | ||
Updated•7 months ago
|
Assignee | ||
Comment 14•7 months ago
|
||
Comment 15•7 months ago
|
||
Comment 16•7 months ago
|
||
bugherder |
Assignee | ||
Updated•7 months ago
|
Updated•7 months ago
|
Description
•