Mediawiki: many transclusions make page loading speed slow? - mediawiki

Question

By transclusion I mean a page like
{{template
| blahblah=
| asd =
| df=
}}
So if there are too many "|"s, then will they make the page loading slow?
Let's say page "Template:*" is
*
so that {{*}} will render a bullet.
Please compare
(Template:A and page "A page")
and
(Template:B and page "B page")
Both A page and B page will display the same thing but which one will be faster to load if there are thousands more transclusion in this way?
Template:A
* {{{a}}}
* {{{b}}}
* {{{c}}}
A page
{{A
|a=q
|b=w
|c=e
}}
Template:B
{{{a}}}
B page
{{B
|a={{*}} q <br> {{*}} w <br> {{*}} e
}}
=====Question added==============
#llmari_Karonen Thank you very much.
What if the number is nearly 1000, so that the A page is
{{A
|a1=q
|a2=w
|a3=e
....
|a999=w
|a1000=h
}}
Still, thanks to caches, "for most page views, template transclusion has no effect on performance"?
And what do you mean by "for most page views"? You mean low enough page views?
You said "the recommended way to deploy MediaWiki is either behind reverse caching proxies or using the file cache. Either of these will add an extra caching layer in front of the parser cache."
Should this be done "before" posting any content on mediawiki? Or it doesn't matter if I do it after I post all the pages to mediawiki?
===What if the transclusion relationship is very complex===
#llmari_Karonen I got one more question. What if the transclusion relation is very complex?
For example
Page A is
{{temp
| ~~~
| ~~~
... (quite many)
| ~~~
}}
And Template:Temp has {{Temp2}},
and Template:Temp2 is again
{{temp3
|~~~
|~~~
... (very many)
|~~~
}}
Even in such case, due to the reasons you mentioned, numerous transclusions won't affect the loading speed of Page A?

Answer 1

Yes and no. Mostly no.
Yes, having lots of template transclusions on a page does slow down parsing somewhat, both because the templates need to be loaded from the DB and because they need to be reparsed every time they're used. However, there's a lot of caching going on:
Once a template is transcluded once on a given page, its source code is cached so that further transclusions of the same template on that page won't cause any further DB queries.
For templates used without parameters, MediaWiki also caches the parsed form of the template. Thus, in your example, {{*}} only needs to be parsed once.
In any case, once the page has been parsed once (typically after somebody edits it), MediaWiki caches the entire parsed HTML output and reuses it for subsequent page views. Thus, for most page views, template transclusion has no effect on performance, since the page will not need to be reparsed. (However, note that the default parser cache lifetime is fairly low. The default is OK for high-traffic wikis like Wikipedia, but for small wikis I'd strongly recommend increasing it to, say, one month, and setting the parser cache type to CACHE_DB.)
Finally, the recommended way to deploy MediaWiki is either behind reverse caching proxies or using the file cache. Either of these will add an extra caching layer in front of the parser cache.
Edit: To answer your additional questions:
Regardless of the number of parameters, each page still contains only one template transclusion (well, except for the {{*}} transclusions on page B, but those should be efficiently cached). Thus, they should be more or less equally efficient (as in, there should not be a noticeable difference in practice).
I mean that, most of the time when somebody views the page, it will (or at least should) be served from the cache, and so does not need to be reparsed. Situations where that does not happen include when:
the time since the page was last parsed exceeds the limit specified by $wgParserCacheExpireTime (24 hours by default, but this can and IMO should be increased for most wikis),
the page has been edited since it was added to the cache, and so needs to be reparsed (this typically happens immediately after clicking the "Save page" button),
a template used on the page has been edited, requiring the page to be reparsed,
another page linked from this page has been created or deleted, requiring a reparse to turn the link from red to blue or vice versa,
the page uses a MediaWiki extension that deliberately excludes it from caching, usually because the extension inserts dynamically changing content into the page,
someone has deliberately purged the page from the cache, causing an immediate reparse, or
the user viewing the page is using an unusual language or has changed some some other options in their preferences that affect page rendering, causing a separate cached version of the page to be generated for them (this version may be reused by any other user using the same set of preferences, or by the same user revisiting the page).
You can add a proxy in front of your wiki, and/or enable the file cache, at any time. Indeed, since setting up effective caching is a somewhat advanced task, you may want to wait until you get your wiki up and running without a front end cache first before attempting it. This also allows you to directly compare the performance before and after setting up the cache.