Page MenuHomePhabricator

Wasteful tabs, var statements in global variables script
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: minor

attachment Skin.php.patch ignored as obsolete

Details

Reference
bz19382

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:41 PM
bzimport set Reference to bz19382.
bzimport added a subscriber: Unknown Object (MLST).

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.

matthew.britton wrote:

(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. :)

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
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.

Attached:

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.

matthew.britton wrote:

(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.