Wikipedia:Analyzing performance issues

There are many ways to improve the performance of articles and templates on Wikipedia. Over the past years, many important performance issues have become clear, as to better ways to significantly re-structure articles and templates. Years ago, the old essay "WP:Don't worry about performance" (WP:PERF) had been written to deter people from "over-optimizing" articles or templates for some imagined concerns.

However, as real concerns began to cause severe problems, that essay was repeatedly updated to note "don't worry except in this case", and that case (etc.), of severe performance issues. Unfortunately, many people kept citing "WP:PERF" as an excuse not to think about any problems, and some people were even badgered to stop talking about performance. The resulting chill eventually led to a state where even many technical admins were puzzled when performance problems occurred, after years of chill, when everyone should have been discussing performance trends and learning from each other what really mattered.

Perhaps the most obvious issue is to avoid showing very large images, except in rare cases: instead images should use unsized "|thumb" or "|upright" (for auto-sized narrow images). However, another major problem has been the stacking of 4-to-12 bottom navboxes, where eventually some articles had exceeded the 2mb (actually 2,000kb) limit of formatted text on a page. The use of bottom navboxes typically doubles (2x) the size of an article, causing the text to display twice as slow, from start to finish. Similarly, templates can be restructured to run 2x-4x smaller or faster, such as evaluating numeric-formula parameters (with #expr) before invoking a template.

Now there are several technical essays and guidelines which explain performance problems and how to avoid them:

There are many other essays about performance issues, as well. The most important point is that now it is highly encouraged to talk, learn, and worry about performance issues before an article becomes a nightmare for admins to rescue. Most admins are extremely busy, and performance problems need to be predicted before they occur, so that there will be fewer last-minute crisis situations.