3 ms·
>how the author of this website managed to take plain text content and literally make it slower to load I didn't comprehensively debug the whole page but in a
by jasode 10y ago
>how the author of this website managed to take plain text content and literally make it slower to load
I didn't comprehensively debug the whole page but in a cursory 2 minute trace in Chrome Dev Tools, I found javascript that makes an XHR request for a 265k text file[1] with 36000 lines. The javascript code then parses the names (which takes ~300ms) and then seemingly does nothing with the information. It doesn't show up anywhere on any subsequent DOM rewrites. The actual visible content that people read is only 10k.
For mobile users, you punish them twice by (1) subtracting 265k from their data plan and then (2) wasting battery power on cpu to parse it for no reason. That one example of useless bloat is probably multiplied dozens of times elsewhere in the lifecycle of the webpage.
[1] don't click on this if you're on mobile phone:
http://wiki.c2.com/names.txt http://wiki.c2.com/names.txt
- dom0 10y agoIt doesn't seem to be the JS, though. The request that takes a whoppin' 33 seconds - server-side - for me is http://c2.com/wiki/remodel/pages/TipsForReadingCode http://c2.com/wiki/remodel/pages/TipsForReadingCode
- twiss 10y agoIt seems like a list of all the pages on the wiki, presumably to turn mentions of those pages in the text into links automatically. Still, it seems better to do this on the server, if possible.