Last modified: 2013-06-13 21:47:39 UTC
In Sanskrit wikipedia, where Narayam and Webfonts are both involved, page load is much slower. Page loads first and these two load. This is not much of a problem in faster connections and smaller pages. But if page is larger (say 30-40k), it becomes sluggish. Problem becomes worser if i try to edit. The edit box opens but its menu does not load till Narayam and Webfonts finish loading. It is manageable (though irritating) in a 300kbps wired connection. But when i test with mobile devices (like photon plus and MTS Mblaze), the delay is much. I tried in a browsing centre with about 200kbs connection and the experience is somewhere in between. Can something be done?.
Note: The same process in Translate wiki with Tamil (where narayam + webfonts +language are enabled) is much faster than in wikiprojects. I have been testing Tamil in Translate wiki for a few weeks now and didnt notice this performance lag in all the above mentioned internet connections
Scripts can be minimised, and gzipped, but at some point it's not going to be possible to reduce it, so to get the functionality, you'll have to sit and wait
Sam, you're not addressing the observation that translatewiki.net would be serving faster than Wikimedia [citation needed]. For the rest, I agree with the fact that more functionality usually means more code, means more data that needs to be transferred, and without changing bandwidth, that needs longer load times. This currently isn't our highest priority, but eventually we will look into this a little deeper. Please feel very free to do the analysis for us. What is needed IMO is insight in the data volume added by WebFonts, as well as an assessment of the code quality with regards to size optimisation.
I am lowering the priority of this. We will consider this while rewriting Narayam and WebFonts as mediawiiki independent modules.
Btw, some modern browsers allow profiling page rendering times (JavaScript and CSS).
http://sa.wikipedia.org/ does not have Narayam and Webfonts anymore but UniversalLanguageSelector now (see the small gear wheel logo next to "Other languages"), hence closing as WONTFIX (or INVALID, as the issue does not apply anymore).
