en.wikipedia with Vector is reported to be slow
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: minor

bzimport added projects: Vector, Performance.Via ConduitNov 21 2014, 11:08 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz23612.
Amire80 created this task.Via LegacyMay 20 2010, 10:20 PM
Reedy added a comment.Via ConduitMay 21 2010, 12:51 AM

What browser/version?

Amire80 added a comment.Via ConduitMay 21 2010, 6:54 AM

(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."

The_RedBurn added a comment.Via ConduitJun 10 2010, 9:41 AM

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.

Catrope added a comment.Via ConduitJun 10 2010, 4:37 PM

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.(

Catrope added a comment.Via ConduitJul 21 2010, 1:59 PM
  • Bug 24356 has been marked as a duplicate of this bug. ***
Catrope added a comment.Via ConduitJul 21 2010, 1:59 PM
  • Bug 24469 has been marked as a duplicate of this bug. ***
Menner added a comment.Via ConduitJul 26 2010, 9:27 AM

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.

TheDJ added a comment.Via ConduitAug 12 2010, 12:42 AM

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

bzimport added a comment.Via ConduitAug 12 2010, 12:55 AM

Thorncrag wrote:

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.

Catrope added a comment.Via ConduitAug 12 2010, 7:33 AM

(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?

bzimport added a comment.Via ConduitAug 12 2010, 5:10 PM

narushio_ss595 wrote:

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!

bzimport added a comment.Via ConduitAug 12 2010, 5:12 PM

narushio_ss595 wrote:

misstake.

LONGPAGE = [[:en:wikipedia:List_of_The_Tonight_Show_Starring_Johnny_Carson_episodes]]

Platonides added a comment.Via ConduitAug 12 2010, 5:58 PM

Updated csshover in trunk in r70975

Menner added a comment.Via ConduitAug 12 2010, 8:19 PM

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).

bzimport added a comment.Via ConduitAug 13 2010, 11:19 AM

narushio_ss595 wrote:

(In reply to comment #13)

Updated csshover in trunk in r70975

Thank you to your quick action.
Arigatou.

bzimport added a comment.Via ConduitAug 16 2010, 12:00 PM

throwf wrote:

For me, replacing the file with the latest does not fix the performance problem.

Menner added a comment.Via ConduitAug 16 2010, 1:32 PM

@fbjon

How did you test this? Wikipedia.org hasn't updated yet, nor mediawiki.org did. It's just fixed in the developer respository.

TheDJ added a comment.Via ConduitAug 16 2010, 2:00 PM

(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.

TheDJ added a comment.Via ConduitAug 16 2010, 2:12 PM

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).

bzimport added a comment.Via ConduitAug 20 2010, 6:29 AM

throwf wrote:

(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.

bzimport added a comment.Via ConduitAug 26 2010, 8:24 AM

bertignac wrote:

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.

bzimport added a comment.Via ConduitAug 27 2010, 2:31 PM

bertignac wrote:

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';

}

Platonides added a comment.Via ConduitAug 27 2010, 8:41 PM

Perhaps doing
if( strpos( $_SERVER['HTTP_USER_AGENT'], 'MSIE 6' ) !== false ) {

$wgDefaultSkin = 'monobook';

...
makes you feel better :)

He7d3r added a comment.Via ConduitAug 31 2010, 3:55 PM

Bug 23510 shows that the "search and replace" dialog from the vector enhanced editing toolbar is also very slow.

Krinkle added a comment.Via ConduitMar 11 2011, 10:44 PM

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.

MarkAHershberger added a comment.Via ConduitJun 7 2011, 2:16 AM

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

bzimport added a comment.Via ConduitJun 16 2011, 6:36 PM

Thorncrag wrote:

I just deployed 1.17rc1 and tested IE6. It seemed to run just fine.

Amire80 added a comment.Via ConduitJun 17 2011, 2:43 PM

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.

MarkAHershberger added a comment.Via ConduitJun 18 2011, 1:40 AM

(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?

bzimport added a comment.Via ConduitJun 18 2011, 2:36 AM

reflection wrote:

(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

bzimport added a comment.Via ConduitJun 19 2011, 10:09 PM

ayg wrote:

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.)

bzimport added a comment.Via ConduitJun 19 2011, 10:33 PM

reflection wrote:

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

bzimport added a comment.Via ConduitAug 19 2011, 7:12 PM

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

Amire80 added a comment.Via ConduitMar 5 2012, 2:52 PM

Closing, seems kinda outdated.

bzimport added a comment.Via ConduitJun 17 2014, 5:06 PM

reflection wrote:

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.

Nemo_bis added a comment.Via ConduitJun 17 2014, 5:27 PM

(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.

bzimport added a comment.Via ConduitJun 17 2014, 5:33 PM

reflection wrote:

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.

Nemo_bis added a comment.Via ConduitJun 17 2014, 5:36 PM

(In reply to alterego from comment #37)

You are also welcome to try to replicate these benchmarks

Ahem, it's what I just did.

bzimport added a comment.Via ConduitJun 17 2014, 5:43 PM

reflection wrote:

It looks mostly good however you need to add &action=purge to the URLs.

Nemo_bis added a comment.Via ConduitJun 17 2014, 5:51 PM

(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. :)

bzimport added a comment.Via ConduitJun 17 2014, 5:52 PM

reflection wrote:

It's not in the URL but I believe I was using it since I wrote `Cache disabled: Yes' for every test.

Aklapper added a comment.Via ConduitJun 17 2014, 6:01 PM

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.

bzimport added a comment.Via ConduitJun 17 2014, 6:06 PM

reflection wrote:

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.

Nemo_bis added a comment.Via ConduitJun 17 2014, 6:06 PM

(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.

bzimport added a comment.Via ConduitJun 17 2014, 6:10 PM

reflection wrote:

Looks good to me. I am surprised that Vector is only slightly faster than Monobook.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.