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..... ;-)
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.
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.
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.
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.
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.
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 )
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.
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!
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.
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"?
> 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).
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.
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.
> 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.
29 comments
[ 2.8 ms ] story [ 77.0 ms ] threadIf 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.
On any preview, hit the gear icon in the bottom-right.
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.
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 )
Sadly all too common in my experience. Disappointing? Absolutely. But few things of this sort surprise me anymore.
Also, is it really working for them? We're responding to someone who thinks it isn't.
More background: https://phabricator.wikimedia.org/phame/post/view/146/migrat...
> 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).
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.