memory cache appears to slow the page load

RESOLVED INVALID

Status

()

Firefox
Untriaged
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: solotandem, Unassigned)

Tracking

({regressionwindow-wanted, steps-wanted, testcase-wanted})

44 Branch
regressionwindow-wanted, steps-wanted, testcase-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 2016021000

Steps to reproduce:

Open Firebug or the built-in developer toolbox; enable the network tab. Load a page in browser; does not matter the URL.

Tested with two computers running different releases of Linux (openSUSE) and Firefox: the latter being 39.0 and 44.0.2. In each case, the Firefox 'config' settings are unmodified from the distro packages.



Actual results:

For the box running Firefox 44.0.2:

The timing statistics in the Net tab of Firebug indicate the BFCache items are not 'loaded' immediately and concurrently but are staggered, with each subsequent BFCache item having a later 'request start time since the beginning' with the delta being roughly equal to the 'waiting' time of the previous item.

The end result is a much slower page load, with the delay being 100-500% the time to perform all the other tasks. Example: page loads in 6 seconds versus 1 second.

For the box running Firefox 39.0:

The BFCache items are 'loaded' immediately and concurrently, resulting in a much faster page load.


Expected results:

Based on the Mozilla documentation and other online sources, my understanding is the BFCache items should not incur time for: blocking, DNS lookup, connecting, sending, waiting and receiving (although there is a positive value shown for waiting time). Further, most of these items should be 'loaded' essentially concurrently (which corresponds to zero times for each task [excluding waiting] mentioned in previous sentence). However, this does not appear to be the case in the computer running Firefox 44.0.2.

Updated

2 years ago
Component: Untriaged → Networking: Cache
Product: Firefox → Core
In your "Steps to reproduce" you refer "or integrated devtools".  But your later description refers ONLY to Firebug and what they call "BFCache".  It has already been established that Firebug is completely wrong and misleading with stating something as "BFCached".  

There is a mechanism in Gecko called bfcache, which has nothing to do with HTTP resource caching and timing.  It's used only for quick back and forth navigation.  

Ignore Firebug's results regarding they reference to what they call "BFCache" please, they simply reporting it wrong.

If you believe there is a regression between Firefox 39 and 44, please use only internal dev-tools that Firefox provides, not Firebug.  Also, if you are able to reproduce consistently, try to narrow the regression range more.
Component: Networking: Cache → General
Product: Core → Firefox

Comment 2

2 years ago
This really needs more details to be triaged effectively so we can fix it.
Component: General → Untriaged
Keywords: regressionwindow-wanted, steps-wanted, testcase-wanted
(Reporter)

Comment 3

2 years ago
Created attachment 8732989 [details]
fox-39-load-1.png
(Reporter)

Comment 4

2 years ago
Created attachment 8732990 [details]
fox-39-reload-1.png
(Reporter)

Comment 5

2 years ago
Created attachment 8732992 [details]
fox-44-load-1.png
(Reporter)

Comment 6

2 years ago
Created attachment 8732994 [details]
fox-44-reload-1.png
(Reporter)

Comment 7

2 years ago
Attached screen shots of Firefox developer toolbox, network tab. Target URL is this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257927. The attached file names follow this naming convention:

39: release 39.0
44: release 44.0.2
load: initial page load; nothing in cache; just opened browser
reload: page reload; several items in cache

There is a significant load time reduction with release 39, but almost none with 44. The load times can vary on 44; saw times of 6.6 seconds just before saving these images.

Comment 8

2 years ago
Hi Reporter, 

Please add steps to reproduce this, from beginning to the end. Also you can add a screen recording, you can use this link:http://screencast-o-matic.com/home

  Thanks
Flags: needinfo?(jim)
Also a more narrow (as I already mentioned) regression range would be appreciated.
(Reporter)

Comment 10

2 years ago
Based on further investigation, this seems not to be a Firefox issue but rather a Linux distro issue, specifically open SUSE.

From the Mozilla ftp site, I downloaded these binary releases:

39.0
41.0.2
42.0
43.0.2
44.0.2

to the "box running Firefox 44.0.2" in the original issue description and ran each binary on a set of pages from a single site. The timings were consistent in all releases and did not exhibit the staggered start times on each cache item on either initial page load or reload. Running release 44.0.2 from the distro packages continues to exhibit the staggered start times on each cache item and lack of time reduction on page reload.

It would seem I need to file an issue with openSUSE. Does anyone have any thoughts on what might be different between the compiled binaries from openSuse versus Mozilla? Or any suggestions on what they might look for as the source of the problem?
Flags: needinfo?(jim)
(In reply to solotandem from comment #10)
> Based on further investigation, this seems not to be a Firefox issue but
> rather a Linux distro issue, specifically open SUSE.

Based on this comment I will mark this bug as Resolved Invalid.

Regarding your questions, I will need info Honza Bambas, maybe he can answer your questions.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.