Performance is poor loading booking data from




a year ago
8 months ago


(Reporter: Greg K., Unassigned)



53 Branch

Firefox Tracking Flags

(firefox55 affected, firefox57 ?)


(Whiteboard: [qf:investigate])



a year ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:


Actual results:

Complete page display ("Kalendar" and "Buchungen" load via script) took fifteen seconds

Expected results:

Complete page display should have completed in less time
Hey Gregg,
I've run a quick test loading "" in Chrome(11s), FF 55(13s) and Safari(10s) - (these are manual and aproximate results). The results vary on the default selected date, but as far as I can speculate the big wait time here is the query completion and not necessarily populating the page.
Could you please tell me if the above difference in performance vs competition is your concern, or is it the case that the is loading faster on an older FF version and you think it's a regression? Also, what do you mean by  ( "Kalendar" and "Buchungen" load via script )?
Flags: needinfo?(bugmail)

Comment 2

a year ago
Adrian, I reported this because load seemed to take longer than what I imagined was really necessary. I did not test the competition. In older Firefox versions, in fact, the site would trigger the nonresponsive-script dialog, which the current version no longer does.

By ("Kalendar" and "Buchungen" load via script) I was referring to the "Lade Kalendar" and "Lade Buchungen" which are shown on the page while the script runs.

In my own testing on macOS 10.12.5, my results were as follows.

Vivaldi 1.9.818.50 (Stable channel) (64-bit): 12.45s
Firefox 53.0.3 (64-bit): 17.70s
Safari 10.1.1 (12603.2.4) 11.76s
Opera 45.0.2552.812: 12.57s
Chrome 45.0.2454.93 (64-bit): 14.98s

Thus, it still appears Firefox lags behind the others, at least a little bit.

If you have any further questions, please let me know.
Flags: needinfo?(bugmail)
I think this is a good nominee from quantum, therefore tagging it for qf triage.
Whiteboard: [qf]
Whiteboard: [qf] → [qf:investigate]
Adding a gecko profile, hope it helps moving forward:
Test run on 56.0a1 20170709100223 running link:
I am unsure what the next step for this bug should be. 
Naveed, could you please help our bug triage effort? On what component will this bug most likely get additional attention?
Flags: needinfo?(nihsanullah)
Adrian those numbers are concerning. There are numerous improvements in FF57. Can you re-run with FF57 numbers compared to Chrome an describe the hardware generating the numbers? If a large gap still exists attaching a profile of that load will be helpful too.

This might be something we can investigate post FF57 riding the trains. Thanks.
status-firefox55: --- → affected
status-firefox57: --- → ?
Flags: needinfo?(nihsanullah)
Priority: -- → P3
I redid the tests on FF59,FF57 and Chrome 62.0. I think that the test was a bit biased, since my above FF tests were done on new profile and Chrome tests were done with the existing profile, so there would be a caching difference. 
When I evened up the play field, using profiles for both browsers that have already ran the site once within 5 tries I got Chrome >FF Nighty59 with 0.86% and Chrome >Beta57 with 0.76%, which is irrelevant from my point of view.

Greg, could you confirm the testing approach? Also, if you could run the test, again, on your machine, in order to validate the results? Also, if the comparison results differ significantly, could you please record a performance profile? (

here's my steps:
1. open FF59, FF57, with new profiles (run, close browser.
2. Open Chrome, open, close browser.
3. Open FF59, FF57, Chrome and with an external chronometer, measure how much time elapses until full page load.
4. Run 1-3 STR several times.

Chrome: Version 62.0.3202.89 (Official Build) (64-bit)
Firefox 59.0a1 	20171113100232
Firefox 57.0 20171109183137

I'll also run the tests without having the site cached and get back with the results.
Flags: needinfo?(bugmail)
Flags: needinfo?(adrian.florinescu)

Comment 8

8 months ago
@AdrianSV, your testing approach seems correct to me.

I must decline to use or even test Firefox 57 until the org makes public a specific plan to address bug 106400.
Flags: needinfo?(bugmail)

Comment 9

8 months ago
Agree with AdrianSV, response when loaded from website is highly variable - up to 15 seconds as Greg comments. But on multiple repeats the difference between chrome and FF is nominal.
When page is saved to local disk and loaded from disk I see no significant difference between FF and chrome
Tested on win7 with 56.0a1 2017-07-28 (with 700+ tabs open) and chrome Version 63.0.3239.59
Thanks Wayne for the tests & input.
Redoing the tests from comment 7 without the site cached (using clean chrome and firefox install/profiles)(windows 10) did not show any significant difference in performance, therefore I shall mark this issue as WFM.
Last Resolved: 8 months ago
Flags: needinfo?(adrian.florinescu)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.