Last modified: 2014-06-17 18:10:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 23612 - en.wikipedia with Vector is reported to be slow
en.wikipedia with Vector is reported to be slow
Status: RESOLVED FIXED
Product: MediaWiki skins
Classification: Unclassified
Vector (Other open bugs)
unspecified
All All
: Lowest minor
: ---
Assigned To: Nobody - You can work on this!
: performance
: 24356 24469 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-20 22:20 UTC by Amir E. Aharoni
Modified: 2014-06-17 18:10 UTC (History)
20 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Amir E. Aharoni 2010-05-20 22:20:05 UTC
On various Vector feedback pages as well as on OTRS many people report that since the switch to Vector it takes significantly more time for Wikipedia pages to load.

I didn't think that i experience significant slowness myself, but after seeing a few reports i tried to measure it in a very non-precise way: I loaded [[The Holocaust]], a long article with a lot of images. It took 25 seconds with Vector and 15 seconds with Monobook. I did both measurements after cleaning the cache.

Some other articles:
* [[Slavery in the United States]] - 13 sec. on Vector, 7 sec. on Monobook
* [[Jehova's Witnesses]] - 10 sec. on Vector, 6 sec. on Monobook
* [[Nuclear program of Iran]] - 14 sec. on Vector, 9 sec. on Monobook.

Seems quite consecutive, but i'm not a professional website performance tester.
Comment 1 Sam Reed (reedy) 2010-05-21 00:51:29 UTC
What browser/version?
Comment 2 Amir E. Aharoni 2010-05-21 06:54:13 UTC
(In reply to comment #1)
> What browser/version?

I did my measurements with Firefox 3.6.3 on XP.

An OTRS user reported: "I am using Explorer 6. Windows XP. Up until last week the page loading was virtually immediate. Now It could be ten, fifteen seconds."
Comment 3 Thomas Bertels 2010-06-10 09:41:54 UTC
There's also the slow back forward browsing.
See https://developer.mozilla.org/en/using_firefox_1.5_caching for a list of possible culprits.
Comment 4 Roan Kattouw 2010-06-10 16:37:16 UTC
In reply to comment #3)
> There's also the slow back forward browsing.
> See https://developer.mozilla.org/en/using_firefox_1.5_caching for a list of
> possible culprits.
There's a different bug about that; we're aware of the issue and know how to fix it.(
Comment 5 Roan Kattouw 2010-07-21 13:59:17 UTC
*** Bug 24356 has been marked as a duplicate of this bug. ***
Comment 6 Roan Kattouw 2010-07-21 13:59:23 UTC
*** Bug 24469 has been marked as a duplicate of this bug. ***
Comment 7 Biezl 2010-07-26 09:27:28 UTC
Page loads on wikipedia are still very slow with IE6. Often five times slower
than it is with JavaScript disabled.

A short page needs 2 Seconds to load with Scripts disabled by browser settings
and 10 Seconds with all enabled.
Comment 8 Derk-Jan Hartman 2010-08-12 00:42:13 UTC
I note that i see "<!--[if lt IE 7]><style type="text/css">body{behavior:url("/w/skins-1.5/vector/csshover.htc")}</style><![endif]-->" after all the scripts. In general CSS should be defined before all the CSS, otherwise there is a large speed penalty. I'm wondering if the Explorer reported issues are related to the positioning of this csshover.htc
Comment 9 Thorncrag 2010-08-12 00:55:06 UTC
I just wanted to comment in concurrence here, that my experience with our internal wiki where we are (very sadly) required to run IE6 has the same exact problem, so this is not strictly  Wikipedia-related.  Page loads (even on very simple pages) are drastically reduced by at least half when using vector versus our monobook-based skin.
Comment 10 Roan Kattouw 2010-08-12 07:33:54 UTC
(In reply to comment #8)
> In general CSS should be defined before all the CSS,
Is this a typo?

> otherwise there is a large speed penalty. I'm wondering if the Explorer
> reported issues are related to the positioning of this csshover.htc
So where should it be moved to?
Comment 11 Narushio SS595 2010-08-12 17:10:15 UTC
In my PC (PentiumIII 850Mhz, 512MB RAM, Windows XP SP3), when it starts opening the Vector Skin page, IE6 is frozen.
When freezing starts, drawing stops, can not do scroll, can not move to other pages, can not close the window and CPU load factor becomes 100%.
Therefore, it takes very long time to finish opening any page.

IE6 + Vector Skin   + open MAINPAGE -> 27 sec.
IE6 + Vector Skin   + open LONGPAGE -> 637 sec.
IE6 + Monobook Skin + open MAINPAGE -> 7 sec.
IE6 + Monobook Skin + open LONGPAGE -> 56 sec.
GC  + Vector Skin   + open MAINPAGE -> 10 sec.
GC  + Vector Skin   + open LONGPAGE -> 24 sec.
GC  + Monobook Skin + open MAINPAGE -> 6 sec.
GC  + Monobook Skin + open LONGPAGE -> 24 sec.

IE6 = Internet Explorer 6.0.2900.2180.xpsp_sp3_gdr.100216-1514
GC = Google Chrome 5.0.375.126
MAINPAGE = [[:en:wikipedia:Main_Page]]
LONGPAGE = [[:en:wikipedia:MAINPAGE = [[:en:wikipedia:List_of_The_Tonight_Show_Starring_Johnny_Carson_episodes]]

By the way, I am anxious about the version of csshover.css.
Wkipedia use csshover.css V3.00.081222 and the latest version is csshover.css V3.11

The author of csshover.css is describing as follows. 

http://www.xs4all.nl/~peterned/
> Whatever:hover 3.11 november 15, 2009 # 
> The latest update to Whatever:hover fixes a huge performance issue
> with the css expressions. Before 3.10 they were not cleared properly,
> so if you're using an older version, you're advised to update!
Comment 12 Narushio SS595 2010-08-12 17:12:53 UTC
misstake.

LONGPAGE = [[:en:wikipedia:List_of_The_Tonight_Show_Starring_Johnny_Carson_episodes]]
Comment 13 Platonides 2010-08-12 17:58:21 UTC
Updated csshover in trunk in r70975
Comment 14 Biezl 2010-08-12 20:19:54 UTC
When will the fix go live and if it goes live please report here so I'll check IE6 on my windows machine. Or is there a prototype wiki where can I test if it has fixed my performance problems (except by installing it on my own server).
Comment 15 Narushio SS595 2010-08-13 11:19:15 UTC
(In reply to comment #13)
> Updated csshover in trunk in r70975

Thank you to your quick action.
Arigatou.
Comment 16 fbjon 2010-08-16 12:00:32 UTC
For me, replacing the file with the latest does not fix the performance problem.
Comment 17 Biezl 2010-08-16 13:32:51 UTC
@fbjon

How did you test this? Wikipedia.org hasn't updated yet, nor mediawiki.org did. It's just fixed in the developer respository.
Comment 18 Derk-Jan Hartman 2010-08-16 14:00:06 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > In general CSS should be defined before all the CSS,
> Is this a typo?

Eh yes, CSS should be before any scripts. Normal behavior is to Load css, first render, execute scripts, update rendering. The way it is now, IE 6 will start running scripts and only do the first rendering when it reaches the last CSS style block in the head or something. So even though .htc is script, it is a script loaded from CSS and should thus probably be the last CSS inclusion and the first script.

> > otherwise there is a large speed penalty. I'm wondering if the Explorer
> > reported issues are related to the positioning of this csshover.htc
> So where should it be moved to?

Somewhere along the style elements.

...
prohibits progressive rendering in many browsers, including Internet Explorer. These browsers block rendering to avoid having to redraw elements of the page if their styles change. The user is stuck viewing a blank white page.
Comment 19 Derk-Jan Hartman 2010-08-16 14:12:02 UTC
Smart usage of the defer property of <script> might also be very useful here. Such scripts CANNOT contain document.write however (but we already try to avoid that due to webkit issues which basically defers all scripts automatically).
Comment 20 fbjon 2010-08-20 06:29:33 UTC
(In reply to comment #17)
> How did you test this? Wikipedia.org hasn't updated yet, nor mediawiki.org did.
> It's just fixed in the developer respository.

I did the same fix (updating csshover.htc to 3.11 as in r70975) on our organization's internal MediaWiki installation, but IE6 still freezes for a few seconds.
Comment 21 bertignac 2010-08-26 08:24:39 UTC
Same here. Fresh MediaWiki 1.16 installation with last 3.11 version of csshover.htc, and it's still very slow with IE6 and vector skin.
Comment 22 bertignac 2010-08-27 14:31:25 UTC
Well, I'm not proud of the fix, but in case it could help someone, I added this in LocalSettings.php :

if( preg_match('/MSIE 6/', $_SERVER['HTTP_USER_AGENT']) ) {
        $wgDefaultSkin = 'monobook';
} else {
        $wgDefaultSkin = 'vector';
}
Comment 23 Platonides 2010-08-27 20:41:47 UTC
Perhaps doing
 if( strpos( $_SERVER['HTTP_USER_AGENT'], 'MSIE 6' ) !== false ) {
         $wgDefaultSkin = 'monobook';
...
makes you feel better :)
Comment 24 Helder 2010-08-31 15:55:15 UTC
Bug 23510 shows that the "search and replace" dialog from the vector enhanced editing toolbar is also very slow.
Comment 25 Krinkle 2011-03-11 22:44:34 UTC
Moving to Vector-extension as speed is (almost) unrelated to the Vector *skin*.
Instead related to the javascript modules loaded with it from the extension.
Comment 26 Mark A. Hershberger 2011-06-07 02:16:13 UTC
This really won't block RL 1.0. So taking off that blocker.  It probably needs more investigation than we have time for for 1.0
Comment 27 Thorncrag 2011-06-16 18:36:00 UTC
I just deployed 1.17rc1 and tested IE6.  It seemed to run just fine.
Comment 28 Amir E. Aharoni 2011-06-17 14:43:29 UTC
It runs, but the question of how fast does it run in comparison to Monobook is not completely dead yet.

Unfortunately, in a year that passed since i opened this bug, i have failed to develop proper website performance measurement skills, but i still hear people saying that they intentionally use Monobook, because they feel that Vector is slow.
Comment 29 Mark A. Hershberger 2011-06-18 01:40:07 UTC
(In reply to comment #28)
> Unfortunately, in a year that passed since i opened this bug, i have failed to
> develop proper website performance measurement skills

Amir, could you please read my mind? Oh, never mind.  Just develop these skills?
Comment 30 alterego 2011-06-18 02:36:45 UTC
(In reply to comment #28)
> Unfortunately, in a year that passed since i opened this bug, i have failed to
> develop proper website performance measurement skills, but i still hear people
> saying that they intentionally use Monobook, because they feel that Vector is
> slow.

A nice tool is the Firebug for Firefox extension. Use the Net tab and select the "Disable Browser Cache" option. Here are example runs for vector and monobook:

http://grey.colorado.edu/mediawiki/sites/mingus/images/a/aa/firefox-perf-mainpage-vector.png
http://grey.colorado.edu/mediawiki/sites/mingus/images/a/af/firefox-perf-mainpage-monobook.png

Ideally you would run this on many browsers and many operating systems, and multiple times for each one. Unfortunately this means you'll need a different benchmarking tool for each browser. Let's go ahead and test my setup for starters, which is Kubuntu Natty with Firefox 4.0.1 on an Intel Core 2 Duo @ 3Ghz. 

According to the results below the differences between the two skins are certainly not perceptually discernible. Vector is .27 seconds slower on average using the Nuclear program of Iran page but we're talking about a page that already takes about four seconds to load.

== Vector ==
URL: http://en.wikipedia.org/wiki/Main_Page?useskin=vector
Logged in: No
Cache disabled: Yes
Raw data: {1.17, 1.34, 1.54, 1.11, 1.49, 1.22, 1.15, 1.5, 1.43, 1.22, 1.14, 1.41, 1.23, 1.44, 2.53, 1.19, 1.22, 1.37, 1.23, 1.28, 1.62, 1.25, 1.3, 1.1, 1.27}
N: 25
Mean: 1.35 s
Stdev: .28 s

URL: http://en.wikipedia.org/wiki/Nuclear%20program%20of%20Iran?useskin=vector
Logged in: No
Cache disabled: Yes
Raw data: {3.86, 4.01, 3.44, 3.82, 3.63, 4.15, 3.51, 4.13, 4.45, 4.69}
N: 10
Mean: 3.7 s
Stdev: .4 s

== Monobook ==
URL: http://en.wikipedia.org/wiki/Main_Page?useskin=monobook
Logged in: No
Cache disabled: Yes
Raw data: {1.64, 3.07, 1.72, 1.44, 1.67, 1.05, 1.23, 1.43, 1.26, 1.43, 1.18, 1.4, 1.6, 1.43, 1.26, 1.12, 1.25, 1.33, 1.5, 1.25, 1.24, 1.27, 1.23, 1.44, 1.41}
N: 25
Mean: 1.43 s
Stdev: .38

URL: http://en.wikipedia.org/wiki/Nuclear%20program%20of%20Iran?useskin=vector
Logged in: No
Cache disabled: Yes
Raw data: {3.96, 2.75, 3.69, 3.49, 3.21, 3.14, 3.75, 3.33, 3.76, 3.27}
N: 10
Mean: 3.43 s
Stdev: .36
Comment 31 Aryeh Gregor (not reading bugmail, please e-mail directly) 2011-06-19 22:09:49 UTC
The skin's effect is going to be minimized on a big page like those.  Try a stub.  If there's a quarter-second difference there, it will be much more perceptible.  Also remember that total load time is not the only performance metric people notice, and probably not the most important either.  If Vector slows down time to first paint by a quarter-second, for instance, that might be visually noticeable even on a large article.

(Not saying you have to do more work than you have -- data is much appreciate.  But I don't see enough evidence to close this bug yet.)
Comment 32 alterego 2011-06-19 22:33:07 UTC
Using a stub seems like a good condition. I did this on enwp and on my own web server which is running the same version of MediaWiki as Wikipedia. On Wikipedia the vector skin is .18 seconds slower on average when loading the [[Seed germinator]] article. I then ran Firefox directly on my web server and loaded the [[Sandbox]] article which only contained the letter 'a'. This reduced the standard deviation of load times of both skins down to only .02 seconds. In that case Vector was actually .15 seconds faster than Monobook. Given that the standard deviation was so low, that seems like the most reliable result so far.

= enwp: [[Seed germinator]] =

== Vector ==
URL: http://en.wikipedia.org/wiki/Seed_germinator?useskin=vector
Logged in: No
Cache disabled: Yes
Raw data: {1.43, .86, .924, .983, .967, 1.02, .912, .96, .901, 1.48, 1.17, .811, .917, 1.25, .975}
N: 15
Mean: 1.04 s
Stdev: .2 s

== Monobook ==
URL: http://en.wikipedia.org/wiki/Seed_germinator?useskin=monobook
Logged in: No
Cache disabled: Yes
Raw data: {1.64, 3.07, 1.72, 1.44, 1.67, 1.05, 1.23, 1.43, 1.26, 1.43, 1.18,
1.4, 1.6, 1.43, 1.26, 1.12, 1.25, 1.33, 1.5, 1.25, 1.24, 1.27, 1.23, 1.44,
1.41}
N: 25
Mean: .86 s
Stdev: .09

= grey: [[Sandbox]] =

== Vector ==
URL: http://grey.colorado.edu/mingus/index.php/Sandbox?useskin=vector
Logged in: No
Cache disabled: Yes
Raw data: {.788, .761, .812, .769, .773, .770, .777, .762, .725, .784}
N: 10
Mean: .77 s
Stdev: .02 s

== Monobook ==
URL: http://grey.colorado.edu/mingus/index.php/Sandbox?useskin=monobook
Logged in: No
Cache disabled: Yes
Raw data: {.883, .889, .906, .926, .908, .91, .892, .944, .978, .917}
N: 10
Mean: .92 s
Stdev: .02
Comment 33 Bugmeister Bot 2011-08-19 19:12:50 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 34 Amir E. Aharoni 2012-03-05 14:52:51 UTC
Closing, seems kinda outdated.
Comment 35 alterego 2014-06-17 17:06:51 UTC
I don't see why this bug should be closed. It contains benchmarks. Before closing the bug it should be shown that the results shown in the benchmarks are no longer valid, suggesting any underlying speed issues have been fixed.
Comment 36 Nemo 2014-06-17 17:27:47 UTC
(In reply to alterego from comment #35)
> I don't see why this bug should be closed. It contains benchmarks. Before
> closing the bug it should be shown that the results shown in the benchmarks
> are no longer valid, suggesting any underlying speed issues have been fixed.

http://www.webpagetest.org/testlog.php?days=365&filter=useskin&all=on

I don't see clear patterns, sometimes monobook "wins" and sometimes not; further investigations on your end very welcome. As a test site, better choose one with less custom extensions/configurations and local scripts/gadgets (and without centralnotice banners running).

Note, this may have been fixed with bug 39035, like many other bugs in Vector which have now been closed. There is now some push to improve in this area, specific reports are way more likely to be acted upon than 4 years ago.
Comment 37 alterego 2014-06-17 17:33:20 UTC
You are also welcome to try to replicate these benchmarks, and once someone shows that they can no longer be replicated the bug can be closed.
Comment 38 Nemo 2014-06-17 17:36:57 UTC
(In reply to alterego from comment #37)
> You are also welcome to try to replicate these benchmarks

Ahem, it's what I just did.
Comment 39 alterego 2014-06-17 17:43:12 UTC
It looks mostly good however you need to add &action=purge to the URLs.
Comment 40 Nemo 2014-06-17 17:51:22 UTC
(In reply to alterego from comment #39)
> It looks mostly good however you need to add &action=purge to the URLs.

I was trying to reproduce your measures, which didn't include action=purge. :)
Comment 41 alterego 2014-06-17 17:52:15 UTC
It's not in the URL but I believe I was using it since I wrote `Cache disabled: Yes' for every test.
Comment 42 Andre Klapper 2014-06-17 18:01:51 UTC
I don't see why this bug should be open without any *recent* benchmarks being provided that show that there is actually still an issue. 
Benchmark output from browser's developer tools welcome.
Comment 43 alterego 2014-06-17 18:06:01 UTC
When the user provides a replicable test case the bug should be left open until there is a failure to replicate indicating the bug has been fixed.
Comment 44 Nemo 2014-06-17 18:06:29 UTC
(In reply to alterego from comment #41)
> It's not in the URL but I believe I was using it since I wrote `Cache
> disabled: Yes' for every test.

That's not what action=purge does. The tests I linked above already take care of the local cache.
Comment 45 alterego 2014-06-17 18:10:39 UTC
Looks good to me. I am surprised that Vector is only slightly faster than Monobook.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links