Last modified: 2009-07-28 00:45:45 UTC
Created attachment 6261 [details] Remove whitespace delimiters in global variables script (Skin::makeVariablesScript) Each entry in the global variables script is delimited by two tabs and a newline on output. These prettify the output, but waste 21 bytes per page per gzipped response in the HTML header (the most time-critical portion). Wikipiedia gets over 300 million pageviews a day ( http://infodisiac.com/blog/2008/09/wikipedia-page-requests-per-day/ ). I do not feel the benefit to source readers outweighs the cost to them.
The tabs are unnecessary, but without newlines you've got a big ugly blob that's insanely difficult to work with. The savings of a few bytes here aren't convincing.
(In reply to comment #1) > The tabs are unnecessary, but without newlines you've got a big ugly blob > that's insanely difficult to work with. The savings of a few bytes here aren't > convincing. Yes, newlines are needed. The <head> could be entirely untabbed with no harm done, but bytes are pretty small things; anyone wishing to save Wikimedia some bandwidth could probably make a lot more difference by editing a couple of the more obscene meta-templates on en.wikipedia. The footer in Monobook also has tabs, but they are more useful to keep (though the indentation they create is a bit inconsistent).
I care more about the fact that the bytes have to be transferred to the client than that Wikimedia has to serve them. This is aimed at improving site responsiveness for users, not cutting bandwidth usage. Every byte you cut out of the head (or the head scripts) is a byte that does not have to be downloaded and processed before the browser can start displaying the page. No, this change would not make a huge difference by itself. Nor is removing comments like "<!-- Head scripts -->" or "<!-- end of the left (by default at least) column -->". But if we can save 1kb with 20 such changes, that *does* mean a faster page, especially for those on mobile devices or limited connections. And a faster site is one which people are more likely to edit. Wikimedia has spent a lot of time on improving server responsiveness. As those problems become less of an issue, we need to look at the gains that can be made on the front-end. All the cool sites are doing it: http://royal.pingdom.com/2008/07/08/best-website-performance-tips-from-velocity-2008/ - http://code.google.com/speed/ Brion rightly points out in IRC that perhaps removing the "var" would provide even more gains. How about removing tabs and also the vars, while retaining the newlines?
To clarify: the modified suggestion is to go from: <![CDATA[*/ var skin = "monobook"; var stylepath = "/skins-1.5"; var wgArticlePath = "/wiki/$1"; ... var wgGlobalGroups = []; /*]]>*/</script> to something closer to: <![CDATA[*/var skin="monobook", stylepath="/skins-1.5", wgArticlePath="/wiki/$1", ... wgGlobalGroups=[];/*]]>*/</script>
I'd keep those newlines at the top and bottom for legibility, but otherwise looks good to me. :)
Removed tabs in r52389.
Reopening to add patch that removes "var" on each line but the first, and the spaces before and after the = on each line (which oddly saves 15 bytes just by itself).
Created attachment 6262 [details] Also removes "var" on every line but the first, and the spaces between = on each line. There may be a more subtle way to handle the first element of the array, but this appears to work well. Newlines are preserved on the first and last lines, although they are not technically required there.
Fixed by ^demon in r52380. Total savings ~60 bytes per page, gzipped. Removing newlines only saves 2 or 3 bytes more as the difference is eliminated by gzip.
(In reply to comment #3) > I care more about the fact that the bytes have to be transferred to the client > than that Wikimedia has to serve them. (In reply to comment #9) > Total savings ~60 bytes per page, gzipped. Or 0.00006 seconds on a 1 Mbit connection. :)
If only! But unfortunately TCP/IP does not work like that, thanks to slow-start, ACKs, and other mechanisms designed for a less reliable, slower age. Check out the sites in comment #3, or grab a copy of Wireshark (http://www.wireshark.org/) and see for yourself. Bytes saved in the head are especially precious because they have to be downloaded and processed before the browser can start to display the rest of the page. Many visitors - we're probably talking from 20-50% - come to Wikipedia and other wikis with a clean cache, so having to download the JS and CSS before they can see the page . . . and they can't start on *that* until the <head> has arrived. There should be a strong justification for every element there - _and_ for any whitespace in-between them, which gzip cannot always eliminate.
