What browser/version?

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

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.

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

• Bug 24356 has been marked as a duplicate of this bug. ***

• Bug 24469 has been marked as a duplicate of this bug. ***

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.

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

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.

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

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!

narushio_ss595 wrote:

misstake.

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

Updated csshover in trunk in r70975

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

narushio_ss595 wrote:

(In reply to comment #13)

Updated csshover in trunk in r70975

Thank you to your quick action.
Arigatou.

throwf wrote:

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

@fbjon

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

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

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

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.

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.

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

}

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

$wgDefaultSkin = 'monobook';

...
makes you feel better :)

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

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.

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

Thorncrag wrote:

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

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.

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

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

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

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

mhershberger wrote:

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

Closing, seems kinda outdated.

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.

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

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.

(In reply to alterego from comment #37)

You are also welcome to try to replicate these benchmarks

Ahem, it's what I just did.

reflection wrote:

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

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

reflection wrote:

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

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.

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.

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

reflection wrote:

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