Thread:Talk:New skins system/Don't remove all the non-CSS-heavy skins!/reply (3)

The mobile site will eventually have editing and that point will end up moot. In any case as I have already explained simple/chick are not low bandwidth they offer no significant bandwidth savings. And any small fraction of savings you gain is mooted by the browser caching. So Simple and Chick still don't have a proper rationale to stay.

As for scriptless, if you don't wan't scripts then disable JavaScript. If it's not enabled then the browser doesn't download it.

As for the idea that we should offer a skin that loads stuff like commons.js but not other things. I should first point out that what you are describing is not a skin. It has nothing to do with this. All of those things are general features loaded in all skins by mw, not by skins. So what you are describing would really be a user preference that would apply to any skin, it's not a reason to keep skins like simple or chick around. In any case your idea will likely not save as much bandwidth as you think it would.

Firstly sizes. The total loaded on an empty cache is 154.3KB (4.3KB is a banner so you might as well make that 150KB). Common.js is 3KB. However site scripts depend on jQuery and our mediawiki JS libraries to function. Those libraries are 45.4KB. In other words even just including the most basic of necessities we already eat up 1/3 of what we load in total.

Another 1/3 is eaten up by a 50.1KB script. This script includes some things like ext.Experiments, article feedback, collapsible elements, and charinsert that you may consider unnecessary. But it also contains mw-jump, the placeholder shim, tabIndex, our core mw.Title, mw.Uri, mw.api, and mw.user libraries that other things depend on, the mediawiki.page.ready which is also a necessity, and also our ajax watch code. All that stuff of course is a mix of necessities, things that necessities depend on, and things like ajax watch. And I won't let you say that ajax watch isn't useful. Because ajax watch replaces an entire whole page load likely over 10KB alone with no caching, with a tiny script that gets browser cached and not re-loaded plus a 390B (not KB, pithy little bytes) api call. That script actually saves you bandwidth.

Simple search and collapsible navigation. The latter probably falling under your selection unnecessary stuff is a mere 5.6KB. Reference tooltips are a mere 2.3KB.

And of course after all this, bandwidth concerns are mooted by the fact that after the page view that 150KB of JS isn't loaded again. It's all cached in the browser. The only JS that is re-loaded is a tiny 4.3KB banner. So trying to micro-optimize is still pointless.

Also I should mention that our long term goal should be to kill Common.js. Site scripts should eventually be compartmentalized into individual gadgets with proper dependency handling, etc... instead of all shoved into one page in the i18n system where it doesn't belong. So it becomes even harder to use the criteria of partial loading that you describe.

But just to finish up. Trying to save bandwidth by getting rid of css or js like this is pointless. It takes up hardly any bandwidth as we already optimize it and then it gets cached into your browser and you aren't loading it anymore. While on the content side, en.wp's homepage loads 111KB of image thumbnails. Visiting an article will likely land you on an article around ~100KB of HTML from all the text with an additional potential 500KB of thumbnails. In other words two simple page views of content you are actually aiming to see eat up more bandwidth than the all of the css and js you are trying to optimize away. That is how insignificant a savings you gain. And in return, you loose accessibility features, and piles of features that improve your experience on the website, whether you know that or simply take it for granted.