>>5777

> HTML links, namely href attributes make it think you're a bot

Weird... I think I *might* have tried to insert a weblink, or at least type something that might have looked like one, but I certainly wasn't dumb enough to format it like a full HTML anchor, seeing as markup doesn't work on most imageboards. Not even sure if I put aitch-tee-tee-pee on it, because I know *chans tend to choke unless you use "hxxp" or whatever. Bit of a pain if you just want to type in an "innocent" (ahem) link to something useful and relevant.

> nothing fancy, it just has fixed CSS3 positioning

thinks: "wat" :)

> and should display correctly on any modern mobile browser.

"Should" is a dangerous word... but, weirdly, I still haven't had oppo to pull GC up on my phone since last checkin, so still can't confirm. All I can say is that even in the last week I've had to deal with websites that try to do special effects and my 'droid 5-point-something (6.sth?) 3-ish year old midmarket phone has suffered a bit of a headache as a result. Not displaying properly, dragging when trying to type into textboxes etc, when other sites are much smoother and better behaved. Might not be anything of the sort you use, it just makes one a bit wary.

> For professional use, the task is usually divided between several specialists: backend, frontend, UI designer, etc.

*phew*

> Whereas here I have to fit into all of these roles, and I am no professional in any except general programming (I'm a C programmer) and databases (I'm a professional DBA.)

That sounds advanced enough to me...! At least, it's probably a good combination for this kind of work, and enough to make my head spin when looking at it.

> a lot of security concepts employed are the wisdom of ryonaloli, who is an information security professional

Well, likewise. Maybe it's just that my mind is permanently anchored in about 2001 :D

And if it hadn't been reiterated enough by myself and others - the effort is much appreciated, and it definitely seems to have paid off.

>> is there any way to prioritise loading the entire html for a page before the images?
> That cannot be truly controlled, the loading-rendering sequence is fully governed by the browser as it sees appropriate. The issue is well-known, and I plan to address it by introducing paged threads view.

I guess the server can't really take the liberty of assuming that the IP requesting some HTML and also a bunch of pictures is actually doing so for the same browser thread / page, or that it's even actually the same machine instead of multiple ones behind a NAT-ing router or whatever, as it might end up breaking more things than it would fix, as well as being extra server load keeping track of things, and a pain in the ass to program to boot...

Would there be any way to address it as a QoS issue or the like, though? As in, literally prioritise the delivery of HTML files above all others, and CSS/etc at the second level if it proves necessary, with picture and video third? So a client requesting mixed content would get the core page code fastest (which in a perfect world should happen first anyway as it should be considerably smaller than everything else, on a site like this), and the style sheet/scripts/whatever if needed to successfully render it to the point where a seek-to-bottom would succeed (or, of course, for the buttons to even appear), so it can start building the framework whilst the images then load in to fill it out...? And even if it was trying to REQ a squillion images at once, it would only see HTML/style/script packets appearing until there were no more due for that IP (or at all...) and just have to wait for them.

ISP level traffic management, like.

There's a chance it could cause general congestion and slowdown, but the amount of html files, and the data in them, is so small vs the images that they then cause the client to download that it doesn't seem particularly realistic, and even with a perfect storm of a 100 users all requesting new pages at the same time as there's 1 waiting for image(s) to load in the latter shouldn't see a -huge- slowdown ... at least, not until the situation switches over to 101 users waiting for images anyway :D

(example, downloaded a threatened thread earlier for archive / re-dumping purposes earlier; pretty long page, took a couple minutes to save as "web page, complete"... the HTML is a fairly meaty 258kb, the collected JS and CSS another 20kb... and the 268 images add up to 114mb, or about 420x (ayyy) larger, with 278kb being just below the median image size, i.e. there's a couple more pics larger than the page code than there are smaller, so we can simplify that as the code for a huge page being equal to a single below-average image. Can't say that's at all representative of everything on the site, particularly the smaller pages, but it's certainly true for one of the heavyweight ones I had in mind when asking the original question...)

In any case, that in itself shows that things are definitely running faster now than they used to, so it's sort of give-and-take. In fact, dumping a couple dozen images onto a similar sized but not yet autosageing thread was fairly painless even though my ISP throttles uploads pretty hard (it's a good day when it manages 1:10...), as well as at least as dynamically as the downstream bandwidth, and the server has to regenerate then send the html plus its own version of that same picture back down the pipe each time... in fact the wait for the larger ones to squeeze their way out of the router was the biggest yawn, the reload time was fairly short. Though of course that still doesn't say anything about the mobile performance where the width of the downstream pipe and system processing power is more important and could benefit from traffic shaping ;)

>> it could be made to jump to the bottom pretty soon after loading a thread
>That cannot be true: the #bottom anchor is at the tail of the page; you cannot navigate to it if it hasn't been loaded. I added a simple JavaScript workaround. Also, there's the "s" hotkey.

*shrug* IDK, maybe it was loaded but hadn't rendered or something? All I can report is what I experienced, and how things changed between one version and the other. Maybe the spaghetti code of the old site, and the lower overall bandwidth that seemed to cause (especially for images?) meant that the browser had a mare building and displaying the DOM with any speed (and in fact sometimes *still* seemed to receive and decode a lot of the images before that happened) but it was still able to set the caret position and knew that there was a #bottom anchor that could be sought to? So it would then jump down to meet it once the local document was built?

(yeah, guess who started reading the dummies guides to javascript and html5 literally yesterday :p ... somewhat underwhelmed at this point fwiw, as the largest part of it seems to be Universal Programming Fundamentals And Childishly Simplistic Webpage Construction 101, even from the perspective of someone stuck in 2001 and whose experience so far essentially amounts to BASIC, html 2.0 in notepad, and some very elementary PHP/MySQL... I at least know enough more now that I can take a guess at what you did for the workaround, though it's probably wrong...)