Wikipedia talk:Don't worry about performance

message: Is there any reason why this isn't policy or guideline? — Omegatron 15:54, 14 July 2006 (UTC)
replies: text: Don't think so, no.  I've changed it to proposed. —Simetrical (talk • contribs) 20:51, 14 July 2006 (UTC)
replies: text: It should be a policy. --Meno25 04:53, 29 November 2006 (UTC)

text: I agree it should be policy as it merely paraphrases statements of the developers, who would know best about this sort of thing. HighInBC (Need help? Ask me) 19:11, 15 December 2006 (UTC)
thread_title: Page status

message: I've twice (once above and once in an edit summary) said that developers don't make policy.  This was not my intent, and only when reading S's response above did I see my error.  What I was objecting to was the implication that developer hearsay was policy, in a sort of second-hand appeal to authority.  My response was also overheated in general.  So... Nothing to see hear, move along. 152.91.9.144 03:24, 13 December 2006 (UTC)
thread_title:  Erratum  

message: Based on Brion's recent wikitech-l post, perhaps this page should be redirected to Wikipedia:Use common sense. Angela. 20:44, 16 January 2007 (UTC)
replies: text: Agreed. Or we could stick Brion's new post in here too... — Edward Z. Yang(Talk) 21:03, 16 January 2007 (UTC)

text: Hehe.  Brion loves to push that key, doesn't he?  We should just add that quote here, since Wikipedia:Use common sense isn't about server issues. — Omegatron 21:19, 16 January 2007 (UTC)
replies: text:  Already added it before seeing this discussion. --HappyDog 22:38, 16 January 2007 (UTC)
thread_title:  Redirect? 

message: To be somewhat helpful, this page should give examples of what might constitute actual problems and what is not. // habj 22:33, 23 January 2007 (UTC)
thread_title:  Usability of page 

message: I hate to say it, but reading this page actually made me feel less comfortable about Wikipedia's performance than ever before, because all the quotes seem to consist of straw-man attacks and weird, conspiratorial-sounding "there are no problems because we say there aren't" stuff. No, I don't think any of the speakers have actual negative intentions, but they could sure be expressing their positive ones better. I imagine the quotes were derived following their fatigue of hearing people constantly expressing these fears, but that's still not an excuse for this page's absence of sources. When people claim that contact with toads gives one warts, you don't just say, "That's silly! You're wrong, and you also say 'teh' a lot." You present evidence to the contrary, no matter how tiresome it feels to do so.
All I'm wondering is a (hopefully) simple piece of data: What, roughly, is the server capacity? How much of this has been "filled"? What might be a good analogy for how freaking huge the space available is? (An answer for that last one, however contrived, might be particularly helpful for people like me to get the idea.) Am I oversimplifying how server capacity works (very likely, I know)? Or is this all hacker-sensative information that shouldn't be released (although a quick trip to Tampa might glean the same info...)?
In any case, "this is our job" isn't really enough to satisfy the more paranoid among us (possibly including myself); it's like a cop assuring citizens that they don't need to worry about crimes in their community, not because of the documented low crime rate, but because they're cops and it's "their job." Nobody's questioning that developers develop, or that they develop extremely well. We just need an assurance that either (a) Wikipedia isn't anything like our desktop hard drives, or (b) it is, but to a degree beyond our comprehension. (Or (c) whatever I didn't think of.)
Additionally, it wouldn't hurt to figure out a way to reconcile this guideline with the so-asking-for-it repsonse, "What do you need donations for, then?" And I'm sure such reconcilitation can be done, but only as long as it comes in conjunction with a lessening of this "don't worry your pretty little n00b heads" attitude. \sim Lenoxus " * " 19:35, 26 March 2007 (UTC)
replies: text: Sources cannot be provided for every single performance impact assessment by a sysadmin or developer.  It would be essentially the same thing as interrogating your doctor as to what medical reference works he used when diagnosing you, with the notable differences that WMF sysadmins and developers tend to be a) volunteers b) poorly paid if not volunteers c) not paid more than a fraction of a cent by you unless you've donated truly exorbitant amounts and d) busy.If you have technical background in server administration and/or software development, you would probably appreciate immediately why most things banned for slowness are slow, given a two-sentence summary, and likewise for things permitted for non-slowness.  If you were interested, and knew what you were talking about (I don't say that you in particular don't, but the vast majority of non-developers don't), most devs would probably have no problem with chatting about other implementations or suchlike.  If you do not have the background to fully appreciate the implications of any particular change, quite simply, you are not going to properly understand anything we're talking about, and will have to be satisfied with either "trust us" or some technical gibberish that amounts to the same thing.  This is a basic fact of such intense specialization as we have today.To answer your question, it is not so simple as "server capacity".  Servers have many, many, many bottlenecks that can slow them down.  They are not straightforward devices.  To summarize the rough state of the game as far as I know it (which is not extensively, because while I am a developer I am not a sysadmin): we have effectively unlimited disk space, which I mention because it's about the only thing that can be said to "fill up" in any real sense.  In many other respects (CPU, memory, number of servers generally) we're lacking.  The site is often slow, and this could be mostly fixed by throwing more servers at it.  We don't currently have as many servers as we could use, because the Wikimedia Foundation runs on a budget that other top-ten websites would spend on toilet paper.  Google is faster and more reliable because they own an estimated 450,000 servers and growing; the Wikimedia Foundation owns about 300.None of this is sensitive.  Beyond passwords and cryptographic keys, only a very few small things are strictly confidential.  We're open on the technical side as well as on the content side.Police officers are, with no offense to them, semiskilled at best, closer to unskilled.  A layman cannot expect to understand the details of the work of a programmer any more than that of a theoretical physicist or a rocket-propulsion designer.  You can understand only the effects, not the means or the logic.  If this makes you unhappy, you can try to learn about this kind of thing and gain first-hand experience with it, but until then you'll have to take our word, on the basis that we appear to have a much better idea of what we're talking about than you do.  Which, no offense, we do, as evidenced by the fact that the servers run and the software mostly does what it's supposed to, which people not experienced in the appropriate fields could not make them do.  We are not perfect but we do know something; those who know as much or more can criticize us, but those who know much less have no way of forming criticism.Nothing on this page was meant to imply that performance is not an issue.  More servers are absolutely necessary.  But it's an issue for developers and others with technical knowledge.  Saying that such-and-such will put too much strain on the servers implies that you know what you're talking about; if you don't, don't say it.  In general, we will try to stop users from doing anything too damaging, but in some cases we have not or cannot, and then you will have to accept our (more particularly, the core server admins', such as Brion, Tim, Domas, and Mark) instructions not to do things.  The point of this page is to say that you should not make up your own instructions not to do things, and you should not try to generalize or extend instructions by people who do know what they're talking about.  And it bears mentioning that even those with extensive server experience should not come up with their own opinions unless they have extensive knowledge of our server setup and the software we use.In any case, I think this page would be best rewritten as a real essay, not a collection of out-of-context quotes addressed to something else.  I think I'll do that now. —Simetrical (talk • contribs) 04:21, 27 March 2007 (UTC)
replies: text:  Good. — Omegatron 04:50, 27 March 2007 (UTC)
thread_title:  Less patronizing, more detail? (warning:long) 

message: From WP:POL, "Policy change now comes from three sources ... Declarations from Jimmy Wales, the Board, or the Developers, particularly for copyright, legal issues, or server load". >Radiant< 08:42, 10 April 2007 (UTC)
replies: text: No developer has declared this page to be a policy or guideline.  Therefore, it is not at present, even using that logic.  Developers have never to my knowledge declared policy as such, anyway.  Rather, they may instruct people to do or not to do particular specific things on a case-by-case basis (e.g.: deleting Wikipedia:Sandbox, creating a ridiculously load-making template on es-wiki), or they may implement software checks that prevent the action entirely (e.g., template inclusion limits, renaming users with many edits).  Neither qualifies as making policy.Of course, anyone given any position of authority (such as system administrator) by the Foundation can exercise that authority where necessary, which depending on their role may extend to declaring behavior as officially either required or unacceptable, i.e., making policy.  That's not unique to sysadmins; I recall that when Essjay was an election official, he threatened to have Geni's sysop privileges removed when Geni removed an announcement of the nomination period from the site notice.  I have little doubt he would have succeeded should Geni have unwisely persisted.  So your quote seems poorly conceived to me.Oh, and in case you still want to add it back, I'm a developer, so according to you I have the right to tell you what to do.  Thus if you're wrong you shouldn't re-add it because it's wrong, and if you're right you shouldn't re-add it because I, a sacred Developer, said not to.  :P —Simetrical (talk • contribs) 02:41, 12 April 2007 (UTC)
replies: text: You're kind of missing the point here. A guideline is not made by a tag on the page, that's the bureaucratic approach. The practical approach is that (1) the developers employed by MediaWiki tell us not to worry about performance, (2) those developers are paid know about that sort of thing, so (3) we should not worry about performance. That is not someone's opinion, that's the way we work. Very simple. A guideline is not something legalistic. >Radiant< 08:38, 12 April 2007 (UTC)

text: *Or, to put it differently, please find me anyone who (1) disagrees with the premise that we shouldn't worry about performance, and (2) really knows what he's talking about in that area. >Radiant< 08:41, 12 April 2007 (UTC)

text: *:There's a difference between disagreeing with the general premise, and disagreeing with the idea that a big impressive "guideline" sticker should be slapped on the exact words of the essay.  If someone is not convinced by the CTO and two separate developers saying they shouldn't worry about performance, I doubt  will convince them anyway.  I'm not pleased with the idea of my words being picked apart like some sacred text, which is undoubtedly what will occur if/when a dispute comes up involving performance and one side or another tries to argue that the words of the guideline support them.  I don't see that anything is served by making this a guideline.  And I'm the one who wrote the page in its current form, for crying out loud.I am not, however, interested in getting into a revert war.  You want to leave it , I'm not going to try to stop you. —Simetrical (talk • contribs) 17:32, 12 April 2007 (UTC)

text: **The point is that guidelines aren't supposed to be big and impressive, and certainly not a sacred text. Also, not everybody knows Brion's name. >Radiant< 08:14, 13 April 2007 (UTC)
thread_title:  Note 

message: 10-July-2007: Oh boy, where do I begin?  The most appropriate caveat is to note: beware "tempting fate" (boasting that something doesn't matter).  That having been said, I got the message: "The wiki ship is unsinkable" (re: Titanic), so don't worry, be happy.  
Now, back to reality.  Performance bottlenecks evolve into almost any long-term environment, in any generation.  There are some major growing problems to notice in WP/Wikimedia:
* PNG files are eating Wikipedia performance:  many articles that were formerly 70% text (+30% JPEG images) are now 180% PNG files waiting to display, because PNG files are often 6x times larger than JPEG format (6 x 30=180%).  Are you aware that PNG-fanatics are actively converting/DELETING the quick JPEG files and forcing people to display thousands of massive PNG files?  To be precise, PNG files range from 5x to 21x (yes, twenty-one) times larger than JPEG format due to WP or Wikimedia resizing algorithms that favor JPEG format and keep JPEG files roughly 10x faster.  This is not a minimal 8% performance issue:  PNG files are typically a full magnitude (10 times = 1_000%) slower.  However, there is also a negative synergy: people have learned that displaying PNG files as tiny thumbnails makes them only 3x times slower than normal-size JPEGs, but, of course, now to see any details, people must "click to enlarge" and view the full "350kb" PNG, which is often 15x times larger than the normal-sized JPEG image (20kb) which had been clear enough to see w/o enlarging.
* Pop-up animations:  Several users have started a dangerous trend: moving-picture articles (and that is understandably "the way of the future").  However, an article that began as 25kb of text, now includes a default "short film" animation generated by auto-loading a 1-megabyte animated-graphic file.  The animation is not a "click-to-rotate" link, but rather a default auto-download of the entire short-film: 1050kb vs. 25kb, so the article hits the WP servers as 42x more data than before.
I'll stop there.  The general trend is (can you guess): tramp data is now hitchhiking into many articles, making broadband speeds almost as slow as dial-up had been, years ago.  The broadband performance revolution will soon be defeated because they "don't worry about performance" and that was before you encouraged them.  "Madam, God Himself could not sink this ship."  -Wikid77 08:50, 10 July 2007 (UTC)
replies: text: * UPDATE: The performance ship sank by December 2008; see below: #Reality update June/2009. -Wikid77 08:01, 23 June 2009
Note to interested readers: discussion is ongoing at Talk:Windows Vista#Windows Vista Snapshot changed to JPG and #All PNGs with JPEG.  Powers T 19:30, 10 July 2007 (UTC)

text: Of course, all the points in this essay are intended to apply only to server performance, not client-side loading speed.  It is not relevant to the editorial decision of what balance to pick between image quality and image size and should not be cited in any such discussion.  I've added a note to this effect.  As for analogies to the Titanic, well, I don't think the passengers on that noble ship could have done much to stop it from sinking had they decided (without consulting the crew) that it was necessary they jump up and down to reduce its weight.  If you read this as saying "we're invincible" and not "leave questions of server performance to people who are given the responsibility of managing it", you misread it. —Simetrical (talk • contribs) 05:26, 11 July 2007 (UTC)
thread_title:  Tempting fate 

message: *Does deleting the sandbox really crash the site?  Has it happened before?user:hillgentleman|user talk:hillgentleman|Sat, 4 Aug 2007 13:12:06 +13:12 13:12, 4 August 2007 (UTC)
thread_title:  Deleting the Sandbox 

message: On the Dutch wikipedia people worry about~users doing too many edits. New users are warned not to do too many edits on a page, but use "show preview" all the time instead before saving. People are worried about the servers getting out of free space because of the too many edits. We even have a special warning-template for this. It seems to me that the serverspace shouldn't be something to worry about as long as it's just about text. Can any sysop confirm my view, or tell me that I'm wrong?
JacobH 10:11, 4 September 2007 (UTC)
replies: text: I am a developer of the MediaWiki software, and I can tell you authoritatively that there is absolutely no harm done to the servers by making edits rather than previewing.  If the Wikimedia Foundation needs more space it can buy more hard disks, which cost nowadays something like fifty cents per gigabyte and dropping.  A single extra edit to fix typos and whatnot would use well under a kilobyte, compressed, at a cost (assuming replication to ten different disks) of 0.0005 cents at most.  2,000 of those a day would amount to a whole $3.65 per year, which is on the order of one millionth of the Wikimedia Foundation's budget and is worth a lot less than annoying thousands of contributors to the Dutch Wikipedia.However, editing rather than previewing may be annoying in terms of clogging up histories with repeated edits where only one would do.  You might want to discourage repeated edits on that basis.  But please don't worry about the servers. —Simetrical (talk • contribs) 16:38, 4 September 2007 (UTC)
thread_title:  Too many edits 

message: It has come to my attention that this has been referred to as reason to use high-quality images instead of low-quality images. 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)
replies: text: Images are resized server-side, and cached in their resized form (as anyone who didn't know all along discovered this week) so this guideline is IMO still applicable. Now, the quantity and size of images placed on a single page can affect client-side/bandwidth issues, but I don't see how that applies to the choice of uploading a 100x100 or 900x900 image that will be displayed on the page at 50x50 anyway. The fact that :Image:Whole_world_-_land_and_oceans_12000.jpg is not only present, but used on World, should be the basis for comparison here - Given this guideline, there is no reason to limit the size of uploaded images) --Random832 15:10, 18 September 2007 (UTC)
replies: text: See, now my addendum is being misinterpreted too.  :)  I said "high-quality images instead of low-quality images", not "large images instead of small images".  This would apply to PNG vs. JPEG where the latter is smaller, and maybe high-quality JPEG vs. low-quality JPEG.  The point is that serving large images doesn't hurt the servers, but it does slow down page views for users on slow connections.  I'll clarify it again. —Simetrical (talk • contribs) 18:27, 18 September 2007 (UTC)
replies: text: It was cited in a discussion as justification for limiting public-domain (expired copyright) TIME covers to low resolution as if they were fair use; and, somewhat ominously, to claim that low-resolution images _in general_ [even of clearly free images] are "best practice". --Random832 18:29, 18 September 2007 (UTC)
replies: text: The point is the thumbnails.  The size of thumbnails directly affects viewing experience for users with slow connections.  The size of the base image does not. —Simetrical (talk • contribs) 02:54, 20 September 2007 (UTC)
replies: text: Where this is a real problem (and it can be), it's probably best to use thumb=whatever.jpg - so getting the size benefit of a JPG with the clarity on clickthrough of PNG. It does require extra effort on the editing side, but for the kind of high-traffic pages concerned that probably isn't much of a problem. GreenReaper (talk) 23:05, 26 August 2009 (UTC)
thread_title:  Re: Addendum 

message: Has anyone seen the Wikipedia:Overlink crisis page yet? Wikid77 has a big concern about performance and has started changing things to address it. --Explodicle (talk) 16:41, 13 February 2008 (UTC)
replies: text: Thank you for mentioning this here.  I've replaced a chunk of Wikipedia:Overlink crisis with an explanation of why there is no technical problem, which is the case.  There may still be aesthetics or usability concerns, of course, although those seem a little minor to term this a "crisis". —Simetrical (talk • contribs) 00:31, 14 February 2008 (UTC)
thread_title:  Overlink crisis 

message: Why mention it here? Why not just block its deletion by anyone and solve the problem? --Emesee (talk) 04:50, 15 June 2008 (UTC)
replies: text: It was just an example.  In fact, its deletion is now blocked, although it wasn't at the time that was written.  Why it took so long is a question not really relevant to the essay ― basically, though, a solution in which it could be deleted without crashing the site was preferable, and until it was clear that wasn't coming along soon, no one was going to put in a hacky workaround. —Simetrical (talk • contribs) 19:12, 15 June 2008 (UTC)
thread_title:  Mentioning sandbox 

message: Perhaps this page could get a "this page in a nutshell" box, like many other wikipedia policies? (for instance, WP:NPOV). --OscarBor (talk) 11:23, 30 July 2008 (UTC)
thread_title:  Nutshell 

message: 23-June-09: Back in 2007, I had written that essay, "WP:Overlink crisis" based on mathematical implications of the growing problem. I did not just "want to be right" but, of course, by December 2008, the Wikipedia servers could no longer re-format pages, within 1 hour, where navboxes had been changed. How bad did it get: (if you weren't here, you wouldn't believe it) in early 2008, the servers would reformat a set of 400 articles, which shared a changed navbox, in 4 minutes (that speed was the same on many different days); however, by December 2008, the servers took days to reformat only 20 articles that shared a changed navbox. Checking some of those articles, on the next day, revealed that the old navbox was still being displayed, over 24 hours later. Simplifying the delay-time as exactly 2 days, or 48 hours, to reformat the 20 articles, when 400 had formerly been done in 4 minutes (on any day in early 2008), the speed difference is gigantic.
OCEAN
"Dont-blubblub-worry-blublub-about-blubblub-Berformance-blub-blub-blub."   -S.S. WP:PERF
(BOTTOM)
The speed-comparison for performance is: formerly 400 in 4 minutes, or 100 per minute (1 per 0.01 min), versus 20 in 48*60 (or 2,880) minutes, or 1 in 144 minutes. The time required in December 2008, was slower by a factor of 144/0.01 = 14,400 times slower than early 2008. That's what happens when you "don't worry about performance": it doesn't just get twice as bad, or 10 times worse, or 100x worse, or 1000x worse. Sorry, but performance gets 14,400x times worse (and that's a low estimate). The speed difference is not only gigantic, but let's also say, "Titanic".
As for the analogy between the R.M.S. Titanic and WP:PERF, well now, "That ship be sunk, too".
How could the developers have been so wrong, that what users did, instead, would drastically hinder performance for everyone, for days? ...because performance issues are very complicated, and what the developers understood was only a small part of the total system. In reality, everyone needs to worry about performance, and the more people study the issues, the more they can focus on the important factors, and learn which issues are relatively minor to be ignored. Contrary to the notion of "Don't worry about it (because you'll never understand)", when people work together and discuss the various issues, then a broader understanding really does occur, and people learn what to ignore, and then everyone can work together to make things run faster and smoother.
So, re-read essay "WP:Overlink crisis" and other essays, contact some helpful developers, and start learning about performance issues and how to help. The way articles are written, today, can drastically affect performance years from now. -Wikid77 (talk) 08:02, 23 June 2009 (UTC)
replies: text: I'm failing to see how this is relevant. "Don't worry about performance" is meant to be a caution against premature optimisation along with a note that unlike the direct knock-on effect that recycling your beer cans has on the polar bear population that editors cannot individually do anything to improve Wikipedia's global performance. Your analysis does nothing to change that, and indeed contains no metrics which indicate that the steps you recommend have any noticeable impact. Chris Cunningham (not at work) - talk 09:30, 23 June 2009 (UTC)

text: * See below: #Metrics must combine thousands of articles. -Wikid77 (talk) 10:25, 30 June 2009 (UTC)
thread_title: Reality update June/2009

message: 30-June-09: The metrics involve thousands of navboxes, in thousands of articles. It's not the impact of a single user, but the combined impact of thousands of users doing similar activities. The problems have been growing for years, so the above comments don't list the thousands of examples that, combined together, constitute the performance problem. Perhaps, I can mention 1 article, "Morocco" as an example of overlinking: that article has 11 (eleven) bottom navboxes, doubling the size of the article by adding another 840 wikilinks (which also doubled the HTML data-kb size). You might know that, also, psychologically, people will get "navbox-numbing" when the amount of navbox links will grow to just an ocean of "stuff" at the bottom (but that's a human performance issue, not server-load). Plus, these "1 individuals" have been very busy (using bots or convincing others) to but navboxes on "900" articles at a time. The age-old concept in computer science is termed "tramp data" as non-related data that requires updating the affected modules (pages) simply because someone threw a data item (navbox) onto the bottom of 10,000 articles.Meanwhile, I like small, or limited, navboxes: it's ok to put a rarely-changing navbox on 50,000 articles, or put a large, unstable navbox on 40 articles. However, numerous people have put unstable navboxes on "900" articles at a time. Why it became a problem: if 900 articles wikilink to a shared article, those 900 don't need to be updated when changing that article, but 900 articles using a shared navbox do need to be updated (to provide an accurate list for "What links here"). The impact is 900x times more, and when something is 900x more, then performance is very likely to suffer. High-speed internet connections are typically, only 50-70x times faster than dial-up speeds: if users increased to 10-megapixel images in articles, then that 900x more image data would overwhelm a 50-70x faster internet line (by 12-18x times slower). Similarly, when articles formerly linked by just wikilink (or by navboxes used in 30 articles), then there was little delay time. However, navboxes are used in thousands of articles, and many are designed to be changed every week (such as "Products and managers of big company ZZZ"). Formerly, the trend was just wikilink 900 times to article "Big company ZZZ", but now, the trend is to transclude 900 times with the boxified contents of that company-article as navbox "Products and managers of big company ZZZ". That's why the problem is growing to become 900x bigger. I hope that explanation clarifies the issues. -Wikid77 (talk) 10:25, 30 June 2009 (UTC)
thread_title: Metrics must combine thousands of articles

message: By the end of 2009, many people were aware that essay WP:PERF was not an excuse to use large images or massive templates in frequently-read articles. Unfortunately, the use of navboxes has continued to increase, such as in medical articles, with many adding multiple navboxes totalling over 2,500 extra wikilinks in bottom navboxes. As might be expected, people have stopped putting every navbox on "every" possible article, such as using a navbox on only 50 of 700 articles linked in the navbox. Slow or cumbersome templates were generating mysterious fatal errors, still during May 2010 (see below: "#Template limits cause: WIKIMEDIA FOUNDATION ERROR"). -Wikid77 08:57, 8 May 2010 (UTC)
replies: text: Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
Since the reader's screen is completely overwritten by that message box, it is necessary for users to realize what page, which they were attempting to read, had led to the Wikimedia Error screen. If the page, causing the error, is changed to use a faster template, then that WIKIMEDIA message page is no longer re-displayed. -Wikid77 (talk) 8 May revised 11:37, 13 May 2010 (UTC)
thread_title: Reality update May/2010

message: 08-May-2010: During 2009 into 2010, some massive templates, when used many times per page, were causing a long delay followed by the Wikimedia Foundation Error box, as follows:
WIKIMEDIA  FOUNDATION
----
Error
; English 
: Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
Since the reader's screen is completely overwritten by that message box, it is necessary for users to realize what page, which they were attempting to read, had led to the Wikimedia Error screen. If the page, causing the error, is changed to use a faster template, then that WIKIMEDIA message page is no longer re-displayed. -Wikid77 (talk) 8 May revised 11:37, 13 May 2010 (UTC)
thread_title: Template limits cause: WIKIMEDIA FOUNDATION ERROR

message: I'd like to see an update to this article, and it upgraded back to a guideline. There are still editors who think stripping whitespaces from an article is somehow beneficial, which saddens me because Wiki began as supposedly easier to read, more human friendly markup. On a technical level that fact pages are compressed at multiple points before they arrive in front of the user anyway. On a structural level and content level I've always thought splitting lists or tables off into subpages was a more productive way to reduce page size, and load times, and keep the most relevant text where readers need it. 
I think readers would benefit from with some broad principles about what to worry about and what not to worry about, or examples of better things to worry about. 
If I might attempt to summarize the above discussions excessive templates seems to be an issue, even if it is one best left to developers to fix. 
Overlink has been mentioned, so readers might be redirected to other guidelines such as WP:OVERLINK which address those issues as a matter of style and content instead of as a performance issue. 
Instead of telling readers what not to do, it would be better to be positive and recommend things editors should do, putting the section "Editors have a role to play" higher up the article, and having it explain more. -- 109.79.73.193 (talk) 12:41, 21 December 2018 (UTC)
thread_title:  Editors still have a role to play