Improve VisualEditor's loading performance in Firefox
Open, LowPublic0 Story Points

Description

I imagine this is mostly due to Firefox's JS engine, but I commonly run across articles that take an extremely long time to load the new VisualEditor interface. For example, "Domestic violence" and "Feminism" take about 30 seconds. Really long articles like "World War II" take over a minute. The interface loads in about half that time in Safari. I'm using Firefox 21.

Comparative loading figures:

ArticleFF32, 2014-09Cr37, 2014-09FF 34.05 2014-12Cr39 2014-12
Barack Obama17.6s17.2s13.23s10.61s
Cat16.4s16.0s11.59s5.82s
Beyoncé Knowles25.4s7.5s8.01s5.13s
India26.8s5.6s8.90s5.64s
Richard Nixon9.9s5.6s8.85s6.36s
Europe28.3s7.1s10.31s6.52s
English language18.28.0s6.98s5.45s

Details

Reference
bz50616
bzimport raised the priority of this task from to High.
bzimport set Reference to bz50616.
kaldari created this task.Jul 2 2013, 9:57 PM

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.

Jdforrester-WMF renamed this task from VisualEditor: Significant slowness in loading in Firefox to Improve VisualEditor's loading performance in Firefox.Dec 2 2014, 9:56 PM
Jdforrester-WMF set Security to None.

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

Matanya updated the task description. (Show Details)Dec 10 2014, 8:24 PM

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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 21 2015, 6:47 PM

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?

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.

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.

Deskana lowered the priority of this task from High to Low.Nov 17 2017, 2:57 PM

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 ?

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.