Wikipedia's JavaScript Initialisation on a Budget | Hacker News Reader

Wikipedia's JavaScript Initialisation on a Budget

phabricator.wikimedia.org

96 pointsabbe9828 comments

I am surprised to discover that wikipedia appears to not use a standard minifier on their JS, but rather they have a custom one (written in PHP) that appears to just do whitespace-style removal, which they appear to run in part of the critical path of serving (?!) rather than as an offline build step.

https://www.mediawiki.org/wiki/ResourceLoader/Architecture#R...

You can 'view source' on a page to confirm that their JS doesn't even do "safe" transformations like local variable renaming.

One of the benefits mentioned is "a transparent "build"-free environment for the developer", so they don't have a build pipeline at all. Plus, with heavy caching thanks to Apache this would probably only get hit on server startup. Given the (self-imposed) design constraints it seems like a reasonable solution. Definitely some room for improvement on the minifier implementation.

They mention (in https://www.mediawiki.org/wiki/ResourceLoader/Architecture#J... ) that even with the cache, they can't afford a stronger minifier.

Don't get me wrong, I really like the "just ship less code" approach to making apps fast. I am just shocked that running a processor on the code that they do ship to make it smaller was not one of the first things they tried. (Disclaimer: I work in this space and have even tinkered with writing such a tool. http://neugierig.org/software/blog/2019/04/js-minifiers.html )

Does it really surprise you that people write their own? Or perhaps more importantly here, that people write their own and then never revisit that decision as the industry builds up around them?

Sadly all too common in my experience. Disappointing? Absolutely. But few things of this sort surprise me anymore.

I'm not at all surprised they wrote their own, because it's often the case that people have different use cases, design constraints and so on. I am surprised here that someone attempting to reduce the JS download bundle size after the fact didn't start by running the standard programs (uglify/terser/etc) used to reduce JS download size!

They have something that works for them. Why change?

Because it's a form of vendor lock-in, but for an internal vendor.

Also, is it really working for them? We're responding to someone who thinks it isn't.

Turns out we've already partially migrated to using webpack.

More background: https://phabricator.wikimedia.org/phame/post/view/146/migrat...

Were you logged in? MediaWiki treats logged-in users completely differently. It's also possible that mediawiki.org doesn't minify at all purposely to make it easier to view the JS/CSS. There's definitely a minifier at work for anon users.

Doesn't gzip already do a good enough job at minimizing the number of bytes used by repeated strings such as variable names? I don't think the ultimate byte count is much smaller (post-gzip) if you change all the variable names to minimal length random strings.

> Wikipedia's startup payload now neatly fits into the target budget of 28 KB – chosen as the lowest multiple of 14KB we can fit within subsequent bursts of Internet packets to a web browser.

But (according to their linked article) 14KB is only the max size of the _first_ burst of packets, after which TCP will usually double the size in each subsequent burst. So two bursts equal 14 + 28 = 42 KB, not 28.

Are they doing this to assume a connection limited to only its initial burst size? I imagine this might be relevant in low-data areas (developing countries, etc.), but they don't go in to it.

The "Startup manifest size" graph is misleading. The Y-axis doesn't start at zero, which makes the Sep 2019 size look like it is multiple times smaller than the Sep 2018 size. In reality, it's only ~22% smaller.

who cares. look at the numbers. continue with your life... it's not like the text claims something that isn't true

I care a bit. It's misleading by the standards of anyone who's used to reading graphs. Wikipedia is an organization I care about and trust and it sucks to skim a graph and realize that the axis was changed to mean something that the shape didn't convey. The entire value of graphs is using shapes to convey meaning.

I care. I hate misleading charts like this one.

This is the kind of Javascript work I love. All too often we see terrible, overly-engineered Javascript monstrosities that actively make the web worse for everyone, and that can make some of us anti-JS zealots. But JS can improve users' experiences as well, and the folks at Wikipedia are good at it.

Tangential, but wikipedia without javascript enabled is a great experience.

I have to admit, I couldn't name one javascript "feature" on the site other than one that incessantly pops up when you mouse-over links. Which I find highly irritating, but ultimately useful. I have a definite hate/love relationship with that thing. Maybe it just needs to wait a second before trying to stop me from reading the existing article.

Given that encyclopedias work without javascript enabled I would hope that's the case.

What is "the size of two 14 KB bursts of Internet packets"? MTU is 1500 bytes before overheard. How did they get 14 KB? What significance does that have? And what is "burst"?

Looks like they referenced it later in the article: https://tylercipriani.com/blog/2016/09/25/the-14kb-in-the-tc...

> So why try to squeeze a website into ~14KB? Seems like you should be trying to squeeze it into 1432 bytes.

> I found my answer in IETF RFC 6928 – a proposal to increase the TCP Initial Window to 10 segments. The Initial Congestion Window (cwnd) is the maximum number of bytes that a server can send without receiving any acknowledgement that the bytes were received via a client ACK packet. This maximum number of bytes to send is calculated by multiplying some number by MSS. As of RFC 6928 some number is equal to 10 (initially).

This is a great article. Wikipedia is the only site I have used in a long time that works better with Javascript turned off.

Really? Most sites I go to other than ones like hackernews work way better without javascript.

If you create an account on wikipedia you can tell them to serve you formulas using images or mathml but without doing that formulas stop working. Those hover previews hang midori though, I wouldn't mind losing those.

> Those hover previews hang midori though, I wouldn't mind losing those.

On any preview, hit the gear icon in the bottom-right.

Dat Y-axis.

Kudos to the Wikipedia/Wikimedia teams for all this hard work!

Not to abuse this post's comment section but I recently noticed that on IE11 mobile, image captions overlap with the article's text. I don't think this is relevant enough to formally file a bug report (browser seems to be grade c) but in case someone working on the site's CSS reads this and feels overly bored, well..... ;-)

It may never be prioritized, but it's much better to have a bug report/ticket than to casually mention this in a comment no one will ever see.

Reply on news.ycombinator.com