Wikipedia:Don't worry about performance
 | This is an information page. It is neither an encyclopedia article nor one of Wikipedia's policies or guidelines; rather, its purpose is to explain certain aspects of Wikipedia's norms, customs, technicalities, or practices. It may reflect differing levels of consensus and vetting. |
 | This page in a nutshell: Server performance is very important, but it's taken care of by the sysadmins, who know what they're doing. Try not to make policy decisions based on your (probably limited) understanding of performance issues. |
The Wikimedia Foundation is fast-growing and, as a non-profit organization unwilling to fund itself through advertising, it is perennially short on cash. Therefore, site performance may not always be what it should be: the site may be slow, it may act strangely, it may even crash. But you, as a user, should mostly not worry about site performance. In most cases, there is little you can do to appreciably speed up or slow down the site's servers. The software is, on the whole, designed to prohibit users' actions from slowing it down much.
In a few cases, there are things sysops can do that will slow down or crash the site. These are, however, rare and not generally worth worrying about. On the rare occasion they occur, follow instructions from the system administrators who come in to pick up the pieces, and everything will be fine. Obviously you shouldn't do exactly the same thing again, but don't be afraid to do similar things. If you get chastised for trying to delete Wikipedia:Sandbox and crashing the site, don't try to delete the same page again, but also don't fearfully count the revisions of every page you want to delete. This damages Wikipedia far more than a minor temporary slowdown or twenty minutes' downtime. If you're unsure about something, you can ask a sysadmin on IRC if it makes you feel better, but generally it's not necessary.
That said, listen to the system administrators if they tell you not to do something. You don't have to worry about performance normally, but the safeguards we have in place are not perfect. Citing this page in response to a sysadmin noting poor performance on some level or forbidding some behavior (as has been done with past incarnations) completely misses the point: performance is an issue, just not one that will typically come up for users, and one that only those involved with Wikimedia server administration on a continual basis (you know who you are) will be fully qualified to speculate about.
Also, you can worry about performance if you can tell the difference yourself. If you find that a page takes ten seconds to load, and takes only one second to load if you remove a particular template, and you can reliably reproduce this and other editors confirm they can too, then obviously the template is slowing down that page. If you would like the page to load faster, then by all means remove or simplify the template. This is an editorial decision, not a technical one: would you prefer whatever convenience the template affords, or faster loading for this page? You can assume you aren't hurting the servers either way unless the sysadmins tell you so, but you can still weigh the costs and benefits for an individual page, if you can measure them. Still, consider consulting a developer or sysadmin before making any drastic changes for the sake of performance.
Please note that data storage space is not an issue for you as an individual user. Also, content never really gets deleted from the database – even if an administrator deletes a page, it is kept internally to provide tools like undeletion. Therefore, advocating deletion in order to save space does not make much sense.
Some quotes from other developers in other contexts
Site operations and keep-alive stuff is our concern. "Our" refers to
the development team and the system administration team, but I lump it all together for this. If something is *needed* in order to get on with the encyclopaedia-writing, or the dictionary-making, then do it. If it's unclean, let us know, and if there's an easier method we can implement to help, we will.
Adopt common sense, of course. If it's plain something could cause drastic problems, hold fire and check. But don't go running around screaming "teh servers, teh servers!!!" as an excuse to not do stuff, that's stupid.
Generally, you should not worry much about little things like templates and "server load" at a policy level. If they're expensive, we'll either fix it or restrict it at a technical level; that's our responsibility. . . .
As a technical matter, it's our responsibility to keep the system running well enough for what the sites require. In other words: it's not a policy issue. If and when we need to restrict certain things, we'll do so with technical measures. . . .
"Policy" shouldn't really concern itself with server load except in the most extreme of cases; keeping things tuned to provide what the user base needs is our job.
However – please be sensible about applying this...
I made a general recommendation not to go running around saying THE SKY IS FALLING THE SKY IS FALLING about templates BASED ON SUPPOSITION AND
PARANOIA.
That doesn't mean that AN ACTUAL PROBLEM, WHEN DISCOVERED, SHOULD BE IGNORED.
WHEN THERE IS AN ACTUAL, REAL, MEASURABLE PROBLEM, THEN IT MATTERS.
Addendum
It has come to my attention that this has been referred to as reason to use thumbnails with a large size in bytes instead of a smaller size in bytes (e.g., using a high-fidelity 50 KB PNG instead of an uglier 20 KB JPEG). I should note, therefore, that this essay applies only to affecting server-side performance issues, and in fact you can definitely slow down the loading of pages if you cram them with 100 KB images. Whether that's acceptable to you is an editorial choice, and there's not really much the developers or system administrators can or will do to either prevent or encourage it. —Simetrical (talk • contribs) 05:21, 11 July 2007 (UTC); 18:29, 18 September 2007 (UTC)
Examples
Examples of places where performance has been erroneously cited in the past:
- Wikipedia:Redirect#Do not "fix" links to redirects that are not broken (performance was cited as a reason against the guideline; see rebuttal here)
Examples of restrictions that developers have put into place at least partly due to performance: