Criticizing Wikimedia and Wikipedia

Wikipedia’s pages too big for Africa?

Posted on: May 10, 2009

English Wikipedia (and most likely any other Wikimedia site running MediaWiki) has pages that are literally hundreds-times bigger than their actual content. I did a testing consisting of saving a blank Wikipedia article page and it ended up being 211,207 bytes of stuff to download (HTML, JavaScript, images etc.) for exact 1,249 bytes of text (menus, header, footer etc.). This resolves into a 169:1 ratio for article size vs. article actual content. Pretty big number, isn’t it?

The three largest files to download resulted to be index.php, which took about 32 KB, followed by 30 KB large wikibits.js and 27 KB of main.css. There were still more files of each type though. The HTML file with the actual page text was 17 KB. The Wikipedia logo did not download (I have no clue why).

The total download consisted of 19 files. The file type sizes summarize approximatelly as following:

  • CSS: 77 KB
  • JavaScript: 63 KB
  • PHP: 47 KB
  • HTML: 17 KB
  • images: 4 KB

This is an appeal to a current usability project that is under way over at I was really surprised by the bloat that web code brings to the user, while there is close to no AJAX on Wikipedia as far as I know which usually brings lots of size. The usability team should think of this rather “technical” optimization too.

Of course there are all those “mobile” versions of Wikipedia, which draw far less bandwidth and might be very close to the actual information size with their code sizes. However, I would deprecate the use of these versions for ICT4D in developing world, because of two reasons – Wikipedia is not critical application for expensive mobile data there and finally, as far as I know, none of these versions offer editorial access to the site.

Do we really want to neglect the technical aspect of Wikipedia’s great mission while it might cost only a few hours of optimization? Let us think about it!


7 Responses to "Wikipedia’s pages too big for Africa?"

I don’t think the Internet in Africa is THAT slow!.. I agree with your research but I think it works just fine,, casually speaking, wikipedia is one of the fastest websites to load in here (at least in Egypt)… and even mobile versions work almost flawlessly..
However, i think embedding CSS code into the page source itself rather than independently would make it faster to load, thought I think it’s not so safe, right??

We at the usability initiative minify our JS and CSS and send it over the net gzipped (gzip is a compression format), so we make every effort to keep the bytesize down. jQuery 1.4, which we will introduce shortly, was minfied with the Google closure compiler, which makes it even smaller.

Also, please note that the file sizes you’re reporting aren’t actually being sent over the wire: we gzip everything provided the client accepts gzipped content.

Also note that all our CSS and JS is client-cachable for a month: if the client supports client-side caching, CSS and JS will only be requested each month (or whenever we update our software, which is typically even less frequent). This applies to the JS/CSS you mentioned as well as usability’s.

Of course this doesn’t really help you on the *first* load, but every page view after that is gonna be faster provided your client supports client-side caching.

Thanks for the feedback. Just to make things clear, my measurements were made for an “anonymous” client (not logged in) – that means the skin measured was MonoBook and not the new Vector beta one. The info you provide is valid for Vector or MonoBook? Is there a page on Usability wiki that would watch and explain this technical aspect of new Vector skin?

It’s valid for both skins, since it’s part of our general skinning system. This is also why it’s not documented on usabilitywiki since it’s really just a feature of the core software that was there way before our time.

This is still, as of May 2011, a bit of an issue. The guy writing from Egypt may not have issues, but the less developed areas in Central Africa certainly experience trouble. A few rural areas (towns, but just somewhat remote) in Uganda, for instance, often share a single satellite connection via wireless across the whole town, or individual users receive their internet connectivity through older-style cellular service (which has older-style cellular bandwidth…). 200k+ is not a good thing at those speeds, particularly given shared internet.

Interestingly, Google’s idea to make ads into text has made them the popular choice for folks targeting the rural audience for this reason. Obnoxious Flash stuff just won’t come through (unless it is a game involving semi-nude images — people in remote places seem to be infinitely patient for those sort of downloads…)

Hi zxq9, thanks for a comment! There was a new “feature” called ResourceLoader introduced to Wikimedia wikis throught MediaWiki 1.17 which addresses this issue. I guess the size of pages was reduced a bit.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


  • None
  • Jan Kucera (Kozuch): to zxq9: I think you are wrong. Facebook and Wikimedia are in exactly the same market - trying to attract new users. Finally, the Internet is only one
  • zxq9: Wikimedia does exist in the same space as commercial sites such as Facebook. But to imagine that they are literally in the same market is wrong. Faceb
  • Jan Kucera (Kozuch): Interesting insight, especially on the number of user interfaces! However, I think Wikimedia is in the same competition for users (readers and editors


%d bloggers like this: