Open Bug 1913550 Opened 2 months ago Updated 1 month ago

Using a large number of individual javascript files is significantly slower (~1s) than chrome (~80ms) even when cached

Categories

(Core :: Networking: Cache, defect, P2)

Firefox 128
defect

Tracking

()

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

  1. Create this simple source website https://github.com/midnightveil/firefox-cache-bug
  2. Load up the page in firefox
  3. Refresh the page

Actual results:

Site takes nearly a second to load and run the 50 or so javascript files, even from cache. This causes the rendered javascript to appear after almost a second.

Expected results:

I expected this to be near instant, given that all the files are tiny and haven't changed between requests. Also, they were in cache and weren't refetched from the server. It is nearly instant with Chrom(ium) (taking about 70ms)

Performance profile: https://share.firefox.dev/3X8H4TJ
Mostly shows time spent in poll().

Also tried in the nightly 131.01a1 and there was no change from my version (128).

There's a few more images of things in the source repo: https://github.com/midnightveil/firefox-cache-bug

I noticed this when writing a small application, and instead of combining all the javascript files into one with a build step, just used as is. This means there are a lot of source files that are downloaded (even though each is only a few hundred bytes)

This technique also seems to be used in https://app.fastmail.com/login ; it is notably faster to refresh in chrome than firefox.

Thank you for this report.
A few things I noticed in the video is that Chrome appears to serve the resource from the memory cache, where Firefox is probably using the disk cache.
Also, in the first run, Firefox does 304 revalidations, where Chrome doesn't appear to do so.

Another important observation, while clicking Disable cache in chrome tends to increase the time to to load the page, in Firefox it doesn't seem to change it that much.
It may be that the JS execution time of the JS module may take longer than the effective load of the resources.
I think this is a great test case to dig into.

Additional note: having devtools open severely affects pageload, in both Chrome and Firefox. That's another thing we should try to improve.

Blocks: necko-perf
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Whiteboard: [necko-triaged]

Yep, I noticed what Disable Cache does too. Note that Chrome does also sometimes sent 304 requests; but it seems to be every once in a few requests (sporadically) rather than the "first" time - Firefox also does similar (I think) or at least the notion of first is ill-defined; so it's possibly just an artifact of the video.

I noticed that Chrome mentioned memory cache, but disabling firefox's disk cache with browser.cache.disk.enable = false (confirmed by about:cache) made no difference.

(In reply to julia from comment #2)

Yep, I noticed what Disable Cache does too. Note that Chrome does also sometimes sent 304 requests; but it seems to be every once in a few requests (sporadically) rather than the "first" time - Firefox also does similar (I think) or at least the notion of first is ill-defined; so it's possibly just an artifact of the video.

That is correct. Chrome and Firefox both do 304 from time to time.

I noticed that Chrome mentioned memory cache, but disabling firefox's disk cache with browser.cache.disk.enable = false (confirmed by about:cache) made no difference.

I have manually confirmed that:

  1. Firefox seems to be using the memory cache too
  2. It doesn't seem to make much of a difference.

One thing that does matter, is if the script is type="module" or not.
It seems to double the time in Firefox for me.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: