[09:00:50] https://news.ycombinator.com/item?id=25151773 https://1mb.club/ https://github.com/bradleytaunt/1mb-club/issues/378 [11:48:04] addshore: saw that, I think our homepage would qualify? [11:48:36] the github issue is gone, what was it? [11:48:59] ah, he shut down requests [11:54:54] oh :P [11:55:01] the PR was for wikipedia.org [11:56:32] I'm sure we'll make the cut once they realise we qualify 🙂 [12:03:34] does en.wikipedia.org come in at under 1 MB too? *looks* [12:04:05] I think maybe? [12:19:33] it's not clear to me whether they count compressed or uncompressed. If it's compressed, then yeah, it's 541kb for me right now, can't get that much higher even if some of the images are heavier sometimes [12:20:07] we've had editors but humongous PNGs on the front page by accident in the past, but that got fixed quickly [13:58:25] addshore: the www portal for sure under a meg as well. [16:40:39] any news on that fun core bug to do with content-size headers compression and post request processing? :P [16:55:52] I'm not aware of anyone working on that currently [17:03:25] I saw gille_s assign AaronSchul_z ;) [17:07:05] ack, we discussed it Monday and I recommended that indeed, since I;m fairly sure we broke it [18:06:31] Yup, it took a while to track it down to a patch. A bunch of people have been reporting random issues with it for mw 1.35. wgDisableOutputCompression = true seemed to be a work around for most people, but still doesn't totally fix my case seemingly (and its only a workaround anyway) :)