1926871 - etoland.co.kr - Page elements take longer to load

Status: NEW

(Core :: Performance, defect)

Description

[Calin Tanase (OOO until 22nd of Nov)]

Attachment: etoland FF vs Chrome.mp4

Environment:
Operating system: Windows 10
Firefox version: Firefox 131.0.3 (release)/133

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://etoland.co.kr/bbs/board.php?bo_table=star01&wr_id=1472529&cpage=1
2. Scroll fast down to the comment section.
3. Observe the comments and images.

Expected Behavior:
Elements load almost instantly.

Actual Behavior:
Elements/images require more time to load when compared with Chrome.

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

Performance Profile: https://share.firefox.dev/40gTXgo

---

Created from webcompat-user-report:01455f20-36c4-4b26-96d1-ce4b222b851d

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Markus Stange [:mstange]]

(In reply to Calin Tanase from comment #0)

Performance Profile: https://share.firefox.dev/40gTXgo

This profile shows that the gifs which are requested around the 11 second mark spend around seven seconds in the "HTTP response" stage.

Andrew, this might be an interesting test case for the network prioritization work. Can you reproduce a performance difference between Firefox and Chrome on this page? Also, should this bug be moved into the Networking component, or is it more likely to be Media-related (because loading the videos is maybe what causes the images to be delayed)?

Comment 3

[Andrew Creskey [:acreskey]]

Interesting bug --

In looking into the html, it turns out that the gifs in the comments are tagged as "lazy" loading, e.g.

<img src="/img/etocon/44/5.gif" width="100" height="100" loading="lazy" class="etocon-img" data-emoji-id="44" data-item-id="990" &nbsp;="" style="cursor:pointer;">

So I can understand why we defer loading them.
https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading

Implemented in dom, around here:
https://searchfox.org/mozilla-central/search?q=Loading%3A%3ALazy&path=&case=false&regexp=false

But priority does come into play as well -- the dom marks the load as background and it looks like defers loading it.
And then we further reduce the priority here:
https://searchfox.org/mozilla-central/rev/18f09bdf36a62ea7079c018301f1d257f71f655b/image/imgLoader.cpp#835-837

So in Firefox this is the priority header, low urgency of 5

Firefox Priority
u=5, i

And in Chrome it's the default of 3

Chrome
priority: i (default, 3)

So we could consider not penalizing the priority of the lazy loaded image.
It looks like the mp4's are given Priority u=4, so technically the server shouldn't even be serving the gifs until the videos are complete.
But based on your profile, they are returning bytes from numerous videos and images all at the same time.

But it doesn't look like a clear misprioritization issue to me.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

This bug was moved into the Performance component.

:ctanase, could you make sure the following information is on this bug?

• ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 5

[Markus Stange [:mstange]]

(In reply to Andrew Creskey [:acreskey] from comment #3)

So we could consider not penalizing the priority of the lazy loaded image.

That sounds reasonable.

I found this tidbit on a web.dev post about loading=lazy:

Note: The loading attribute does not affect the image's network priority.

Comment 6

[Andrew Creskey [:acreskey]]

(In reply to Markus Stange [:mstange] from comment #5)

(In reply to Andrew Creskey [:acreskey] from comment #3)

So we could consider not penalizing the priority of the lazy loaded image.

That sounds reasonable.

I found this tidbit on a web.dev post about loading=lazy:

Note: The loading attribute does not affect the image's network priority.

Ah, good find.

I logged bug 1930738 to look at removing this priority lowering code.

For this site we may still end up displaying the lazy-loaded images later because of how we defer them, but we can revisit if that's the case.