I've a couple of Mediawiki (1.19.1 with Vector Skin) sites on Dreamhost shared hosting and I've found that access trough Firefox is much slower than trough Chrome. For example at this moment, after cleaning the cache in both browsers:


  • 11.1 seconds for the first page (RecentChanges)
  • 7.7 seconds for the second page (Home)


  • 9.2 seconds for the first page (RecentChanges)
  • 3.2 seconds for the second page (Home)

This numbers confirm previous tests, made in 2 different days a few weeks ago. Please note the huge difference for the second page.

An older version of Mediawiki on a different server does not seem to have this problem. Firefox and Chrome have similar results.

I need to know how to make access trough Firefox as fast as trough Chrome, without changing the hosting company/plan, Mediawiki or asking users to change Firefox's defaults.


Cache-Control   private, must-revalidate, max-age=0, public
Connection  Keep-Alive
Content-Encoding    gzip
Content-Language    es
Content-Type    text/html; charset=UTF-8
Date    Thu, 23 Aug 2012 06:35:11 GMT
Expires Thu, 01 Jan 1970 00:00:00 GMT
Keep-Alive  timeout=2, max=100
Server  Apache
Transfer-Encoding   chunked
Vary    Accept-Encoding,Cookie
X-Content-Type-Options  nosniff
X-Frame-Options DENY

Cache-Control   public, max-age=300, s-maxage=300, public
Connection  Keep-Alive
Content-Encoding    gzip
Content-Type    text/css; charset=utf-8
Date    Thu, 23 Aug 2012 06:35:13 GMT
Expires Thu, 23 Aug 2012 06:40:17 GMT
Keep-Alive  timeout=2, max=100
Last-Modified   Tue, 21 Aug 2012 21:59:38 GMT
Server  Apache
Transfer-Encoding   chunked
Vary    Accept-Encoding
X-Content-Type-Options  nosniff

Cache-Control   public, max-age=300, s-maxage=300, public
Connection  Keep-Alive
Content-Encoding    gzip
Content-Type    text/javascript; charset=utf-8
Date    Thu, 23 Aug 2012 06:35:13 GMT
Expires Thu, 23 Aug 2012 06:40:14 GMT
Keep-Alive  timeout=2, max=100
Last-Modified   Wed, 22 Aug 2012 12:55:25 GMT
Server  Apache
Transfer-Encoding   chunked
Vary    Accept-Encoding
X-Content-Type-Options  nosniff

Accept-Ranges   bytes
Cache-Control   max-age=2592000, public
Connection  Keep-Alive
Content-Length  206
Content-Type    image/png
Date    Thu, 23 Aug 2012 06:35:13 GMT
Etag    "ce-4c25eaaf8f780"
Expires Sat, 22 Sep 2012 06:35:13 GMT
Keep-Alive  timeout=2, max=99
Last-Modified   Wed, 13 Jun 2012 18:22:38 GMT
Server  Apache
  • Just an observation, but not counting the last one, these times seem kind of slow regardless of browser. (Admittedly we know little about the documents.) You say this confirms previous tests, presumably with the same machine/connection. Have you tried from other systems or even services like Pingdom to corroborate? Also, have you done any performance/cache tuning for MW? – Su' Aug 20 '12 at 9:57
  • I've tested in different days both with a MacOS and a Windows Vista Machine. Yes DH it's a little slow when compared with other hosts, at least with my assigned machine, but that's not the problem I'm trying to solve at the moment. I suspect the current server configuration does not allow FF to do browser caching and all CSS/Js/images are loaded with every page. The installs are MW default installs, no tuning. – Osvaldo Aug 20 '12 at 10:07
  • Can you please give us the output from Firebug? It would be interesting to see the "network" tab when you load the first page. Then we can see what is taking how much time. – Raffael Luthiger Aug 22 '12 at 15:41
  • I've added the http response headers. Please note that the main problem is the difference between cache clean page loading times with different browsers. – Osvaldo Aug 23 '12 at 6:50
  • 1
    The response headers do not help. It is important to see how many files are loaded at the same time and how much time is spent on each part of the request (DNS lookup, request, response, render, etc.) Furthermore it is important to see how many 304 requests you have on the second load. Only then you can start to compare the browsers and see where each browser is faster. – Raffael Luthiger Aug 23 '12 at 23:10

You should test the site on http://tools.pingdom.com/ first, see what files are taking the longest to load. More importantly, is it the connection time and lookups, or is it the file transfer? If it's the former, then you need to look into better hosting. If the latter, then you'll need to read the rest of this answer.

Now before I say any more, try with different DNS resolvers -- Google Public DNS, OpenDNS, and your ISP's default. If you're loading many many files from many different domains, it will take longer than from the same domain since it has to spend time resolving more domains. Another important thing to test, is the speed of the initial transfer. Is the HTML loading quickly but then loading images and stylesheets taking longer? Or is the HTML being delivered slowly so that the browsers can't fetch the resources in a timely manner?

Back to optimization:

  • Try to decrease the number of resources you have to load. Perhaps put the JS at the END of the HTML, it will significantly increase the speed.
  • You could further minify the CSS and JS using http://cssminifier.com/ and http://refresh-sf.com/yui/ respectively (the latter can also compress CSS as well)
  • How are your images? Are they taking a long time to load? You can try to optimize them by either compressing them, or shrinking the resolution.
  • Does your server use GZIP? You'll save up to 80% bandwidth (and improve performance)
  • Look into a CDN like CloudFlare (http://www.cloudflare.com) which automatically minifies your resources AND caches them. (Caching further could be done with Google's mod_pagespeed at https://developers.google.com/speed/pagespeed/)
| improve this answer | |
  • Thanks. The issue here is the huge difference between Firefox and Chrome (both after cleaning their caches), that does not happen in other Mediawiki sites with the same skin. I'm using the default skin, which is quite well optimized accordingly to Yslow. I've added http response headers. – Osvaldo Aug 23 '12 at 6:47
  • @Osvaldo - I just installed MW myself... It's slow for me too. Very strange. I'll have to benchmark it later too. – ionFish Aug 23 '12 at 11:15
  • Thanks @ionFish You installed it in DH? – Osvaldo Aug 23 '12 at 22:13
  • @Osvaldo - No, on my own server. I was just testing the speeds. It's about 10 seconds to load, with LAN connection to the server, but it's got 256MB RAM and a dual core 2.2gHz processor (256MB ram because it's a VM) with nothing installed except Apache and MySQL. – ionFish Aug 23 '12 at 22:22

You could do what runrunforest suggested on SO.SE. Basically, add a header to your .htaccess file and define exactly what files should be cached (That would be your images, css and JS).

WARNING: Firefox has a common problem to not update the page once cached. Most people try to prevent Firefox from caching pages.

Other pages on caching headers. (PHP Specific)

Other than that, tuning might be your best bet. Depending on the CSS/JavaScript, Firefox does indeed render certain special effects (rounded corners, etc) differently than other browsers, and with that it is slower than other browsers to draw the page.

Look at various code optimization techniques - from the load times it looks as though your connection as it stands is pretty slow. Some techniques are

  • JavaScript Optimization: Use JSLint or some other service that will clean up your JavaScript.
  • CSS Sprites: Although some say that this is outdated simply because everyone has fast enough connections that it won't make enough difference, this can vastly decrease HTTPRequests and increase load times. Since Firefox doesn't cache these documents, limiting the number would help.
  • Check your CSS/HTML/JavaScript against http://caniuse.com/ to see if the code isn't optimized for Firefox.
| improve this answer | |
  • Thanks, I'll test. The difference between both browsers is quite large. And this is the default wikipedia skin! I think the problem may be on how browsers cache, directed by Apache. Can you help by looking at the http response headers. I've added them to the question. – Osvaldo Aug 23 '12 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.