Further FB on that little top/bottom feature ... I don't know if this is a client side (ie browser) or server issue, but is there any way to prioritise loading the entire html for a page before the images, or at least high enough that it can keep a good way ahead of the image stream?

It might even have been down to the janky programming (and the "inherent rate limiting"?) of the old version, but the old behaviour was that it could be made to jump to the bottom pretty soon after loading a thread / whilst the browser was still showing the first screenful in progressive-loading cases. If it hadn't yet loaded in the entire html of a longer page, it would at least jump to the end of what had already loaded (IDK if there's a particular anchor code for that?) and you could click the link on one of the visible posts there, or just manually scroll the then much shorter distance to the bottom... skipping the loading of all the pictures / thumbnails in-between.

Now it seems like, although it doesn't really start loading until you start scrolling a tab (especially if you had many opened in the background), it does so in a very progressive manner, ie as soon as an image tag is encountered in the code it will load in the image as a priority, progressing only a little bit further through the html, or maybe none at all. Hitting the "down" button whilst it's doing this full page load just has it flicker (1/10th sec if not a whole lot less) to where it's reached so far then right back to the top, very very rarely sticking there for maybe a half second when caught in between two loads but still returning to the top. Only once the entire page - seemingly with all the pictures - has loaded can you do skip-to-bottom.

And, well, that's where all the new shit is... you don't really want everything else you've already seen to have to load in first, even if it's only thumbnails, especially on a page with 100+ images... double especially if you're on a slow link, or a metered one (two things that often go hand in hand). Particularly this could be murderous for capped mobile data access; my wallet has probably a lot to be thankful for in terms of being able to skip right to the bottom of more frequently visited threads when phone-browsing, seeing if there's anything new or not, and either closing that tab even before any of the immediately visible images started to load into their placeholders, or sticking around to let those 2 or 3 of the newer pics actually download, then scrolling up slowly, loading as you go, to see if there's more than just those.

It's ok on desktop with a fast, unlimited link, but that's not the case for everyone or every access situation.

(in fact, this isn't even so much about the operation of that particular button, but how things load up in the browser, if you have any influence over that at all and it's not just Chrome / Chromium / Webkit weirdness; its effect on the button is just what led me to discover the change. Besides the significance for mobile / slow connection users, it has implications for server load and total bandwidth consumption also. A channer browsing a thread with their browser pulling down 100 images when they're only really interested in the newest two or three is placing a lot more load on the server in terms of file requests, and using up a lot more of your monthly bandwidth with entirely needless data transfer)