I'm using firefox 32 and did some tests on this on en,wikipedia, and beta en, which runs HHVM, but is on a virt cluster.

Article name:Barack Obama
beta en: 41.7s
en : 17.6s

Article name: Cat
beta en: 31.7s
en: 16.4s

Article name:Beyoncé Knowles
beta en: 16.9s
en: 25.4s

Article name: India
beta en: 36.4s
en : 26.8s

Article name: Richard Nixon
beta en:16.2s
en: 9.9s

Article name:Europe
beta en: 26.8s
en: 28.3s

Article name: English language
beta en:23.7s
en: 18.2

I think although it is a small test it does show the trend.

The computer running this test is an i7 quad core from the 3rd gen with 8G of ram, so shouldn't be any issue on this front.

Would be glad to provide any other info needed.

adding Ori for possible HHVM implications

Adding timings in chromium 37 for comparison:

Article name:Barack Obama
beta en: 8.1s
en : 17.2s

Article name: Cat
beta en: 7.7s
en: 16.0s

Article name:Beyoncé Knowles
beta en: 5.1s
en: 7.5s

Article name: India
beta en: 4.8s
en : 5.6s

Article name: Richard Nixon
beta en:3.6s
en: 5.6s

Article name:Europe
beta en: 5.7s
en: 7.1s

Article name: English language
beta en:3.5s
en: 8.0s

(In reply to matanya from comment #1)

I'm using firefox 32 and did some tests on this on en,wikipedia, and beta
en, which runs HHVM, but is on a virt cluster.

Comparing the time to execute of anything between beta and prod is comparing nothing of value. Different hardware, different cluster sizes (for cache, execute and db) and different code.

Could you compare loading times for these articles now, three months later?

Added the new data, one thing to note is if you check chrome before firefox, or check only firefox, the results are almost the same for firefox. but if you check chrome after firefox, it is faster, i guess due to caching. So, more food for thought.

Those are pretty major performance improvements, much more than I was expecting. Odd.

This is really a tracker bug more than a specific call-to-action, so we decided in the meeting to remove it from the Q3 blockers list at the triage on 2015-02-11.

Firefox 57 really improves that issue (I can notice it even with my good computer which had a fast enough Firefox). Maybe reconsider that task?

In T52616#3769691, @Trizek-WMF wrote:

Firefox 57 really improves that issue (I can notice it even with my good computer which had a fast enough Firefox). Maybe reconsider that task?

Yeah, I doubt we'll work specifically on improving Firefox 57 performance directly, and instead choose to work on performance more generally. I can merge this into a more general task. In the unlikely event we do decide to work directly on Firefox 57 in the future, this can be reopened.

I actually don't see a more general task for improving performance of the visual editor anywhere, so I guess I'll just leave this as it is for now.

In T52616#3769774, @Deskana wrote:

I actually don't see a more general task for improving performance of the visual editor anywhere, so I guess I'll just leave this as it is for now.

Good idea actually: I was telling myself that there is plenty of computers which will not receive the update son (or will never receive an update), and we still have to improve performances for them.

In T52616#3769774, @Deskana wrote:

I actually don't see a more general task for improving performance of the visual editor anywhere, so I guess I'll just leave this as it is for now.

T171093 ?

In T52616#3769993, @Elitre wrote:

T171093 ?

That's for a performance review, which isn't technically the same as making performance improvements. I don't particularly object to merging this into that, but I don't think it's quite right.

From the task description:

Article	FF 32, 2014-09	Cr 37, 2014-09
Barack Obama	17.6s	17.2s
Cat	16.4s	16.0s
Beyoncé Knowles	25.4s	7.5s
India	26.8s	5.6s
Richard Nixon	9.9s	5.6s
Europe	28.3s	7.1s
English language	18.2	8.0s

Article	FF 34.05 2014-12	Cr 39 2014-12
Barack Obama	13.23s	10.61s
Cat	11.59s	5.82s
Beyoncé Knowles	8.01s	5.13s
India	8.90s	5.64s
Richard Nixon	8.85s	6.36s
Europe	10.31s	6.52s
English language	6.98s	5.45s

Six years later – some updated numbers. I couldn't find any record of how the above was measured. I'm measuring the below based on the timing.ve.mwTarget.performance.system.activation metric. Method: open article while logged-in, click Edit, wait for loading to complete, and only then open the console and run mw.trackSubscribe('timing', console.log). I then close the console, close the editor, hard refresh, and measure it once more. Numbers were trimmed to 1 decimal without rounding.

Setup: MacBook Pro with macOS 10.15 Catalina. Using unthrottled latest stable Firefox, Chrome, and Safari.

The load times have shrunk a lot across the board. It's also interesting to see that while Safari generally feels faster than either Chrome or Firefox when browsing day-to-day, with the specific payload of initialising VisualEditor it's more or less on part with Firefox, with Chrome still being notably faster.

Having said that, I would say overall that the differences are now small enough to not need a ticket specifically about Firefox. And that generally speaking we are still consistently taking more than one second to load popular articles which would be great to bring down, but that's outside the scope of this task and it's certainly much much better than it was six years ago.