Closed Bug 860477 Opened 8 years ago Closed 3 years ago
about:healthreport loads slowly
It has been observed that sometimes when you open about:healthreport it presents as a blank white pane, and then the healthreport appears after a delay of a few seconds. Anecdotal evidence suggests it occurs the first time the report is loaded in a freshly downloaded build. I personally have observed this on OS X in Nightly. I'd like to: - get reliable STR (QA <3) - work out if the slowness is server or client - take steps to remediate Ideally we should render some parts of the page as quickly as possible, even if the data/graph takes longer to come in.
I think it might help, as Asa suggests, to have some sort of "loading" indicator instead of a blank white page. That said, I'll do some testing to measure load times.
QA Contact: anthony.s.hughes
FWIW, in a Windows 7 VM on Aurora 22.0a2 about:healthreport loads in ~3 seconds on first run and almost immediately on subsequent loads. I would assume this difference would be more pronounced on lower performing systems and larger profiles.
Steps to reproduce: A. a. to get a blank report/empty about:healthreport page 1. disable your internet connection 2. using FF Beta visit about:healthreport and refresh the page Actual: about:healthreport displays as an empty page Steps to reproduce: B. 1. throttle your internet connection 2. using FF Beta visit about:healthreport and refresh the page Actual: about:healthreport initially displays as an empty white page, after a few seconds the report loads as expected.
The delay to load about:healthreport will come from a variety of sources: 1) Network latency to load the iframe 2) FHR initialization delay 3) Data collection and document generation delay #2 should only come into play if this is within 1 minute of launching a completely fresh profile or within 10s of app startup on an existing profile (FHR is initialized 10s after app startup). #1 and #3 will always occur. Telemetry figures reveal that a delay of a few seconds when requesting the payload is not uncommon. The client team can work to reduce this delay by optimizing FHR's storage and caching mechanism. Until then, the iframe could render a "waiting for data" message or something between when it asks for the payload and when the payload is returned.
(In reply to Gregory Szorc [:gps] from comment #4) > The client team can work to reduce this delay by > optimizing FHR's storage and caching mechanism. Until then, the iframe could > render a "waiting for data" message or something between when it asks for > the payload and when the payload is returned. I think both of these are great ideas. In terms of scope, if we could get the "loading" iframe implemented in time for Firefox 21's release, I'd be okay with the performance improvements coming in later releases.
The only solution I can think is to add a loader that is shown by default and is removed on document ready. I will open a PR for this and we can test if this solves the problem.
Pull request sent: https://github.com/mozilla/fhr-jelly/pull/67 Is this does not work then the loader needs to be added to the parent document.
Very unscientific performance numbers can be found at the link below. Testing was done across several systems ranging from a netbook up to a quad-core i7. On the fastest system, first run took 2.3s to load while it took 8.0s to load on the slowest system. Subsequent loads under various conditions were anywhere from 2x to 3x faster. In any case a "loading" page is likely wanted. https://wiki.mozilla.org/QA/Desktop_Firefox/Firefox_Health_Report#bug_860477_about:healthreport_loads_slowly
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #8) > https://wiki.mozilla.org/QA/Desktop_Firefox/ > Firefox_Health_Report#bug_860477_about:healthreport_loads_slowly One other thing I observed is that it can take some time for data to fill in on slower systems and connections. It's not indicated in my link above but I observed the following behaviour on first run with my netbook on Win 8: First Run: > 0:01: Blank page > 0:08: FHR page loaded with static content only > 0:10: FHR page loaded with my data Subsequent Loads: > 0:01: Blank page > 0:03: FHR page loaded with static content > 0:05: FHR page loaded with my data Times are approximate but it seems whether during first run or not we might benefit from a "loading your data" indication on about:healthreport. Otherwise it just looks like a skeleton of a page until your data is loaded.
Thanks Anthony for all of the provided info. I am definitely going to optimize the code a lot still but with the pull request mentioned in comment 7 now merged, we will have a loader as soon as the latest code is pushed to production.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Thanks Schalk. Can you let me know once it's pushed to production so I can spotcheck it?
Laura let me know on IRC that this should be okay to test now. I just tried and I still get a blank white page for a few seconds on first run. Can someone please confirm this has been pushed?
Reopening this bug. Neither Matt Brandt or I are able to get the "loading" page to appear. We are still seeing a blank page until about:healthreport loads.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
After discussion with espressive and mconnor, we agreed to put the spinner in the chrome, since it's apparently needed earlier in the process. Reassigning to mconnor for implementation.
Assignee: sneethling → mconnor
Component: Web: Health Report → Client: Desktop
We're going to need something similar to this on Android, where the slow load is even more pronounced.
I'm the wrong person to implement this at this point.
Assignee: mconnor → nobody
Priority: -- → P4
I'm marking this bug as INVALID, because about:healthreport was removed in bug #1352497.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 3 years ago
Resolution: --- → INVALID
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.