Way back when I first started learning to build web pages [when HTML4 was just a glint in Tim Berners-Lees eye], it was conidered bad form not to prvide a 'width' and 'height' attribute for an image you were placing on the page.
Because if you provided these, the browser would know how much space to leave for the image to occupy after it had downloaded [this was back in the dial-up modem days. So images usually loaded gradually after the rest of the page] and so the layout of the page would not change. Conversely, if you didn't provide 'width' and 'height' attributes, the browser would only leave a default small icon sized space for the image and then you'd have the page content move and shuffle about as each image downloaded and the rest of the page content got elbowed out of the way, to accommodate it.
It's funny how such basic concepts of usability seem to have fallen by the wayside in our new modern Web3 [or whatever version buzzword we're on now] in favour of moving content, modal overlays and the like. And, since so many sites these days just aggregate content from countless other external sources, even that basic notion of pre-defining your image sizes is often neglected too.
> basic concepts of usability seem to have fallen by the wayside
Sadly, the tech may have changed but both our ideas on usability and the incentives at play have remained the same. Which is to say, the devs I know of all know that popup videos, banners, modals, etc. are all trash much like the popup ad banners of 1997. But we do them anyway because the people that pay us have financial incentives that have been proven via misguided A/B testing that they work. And by misguided I mean... we're talking about manipulation, right? That's the whole shell game of A/B testing. You're testing your way to what works best for you and not your users. It's Tinder knowing the perfect match for you but not showing you that person because you'll quit the app if you ever met them.
I can't even take a11y or people that advocate a11y seriously today. You built modals and carousels with frustrating timeouts that slide content before I'm done looking at it! You're a circus clown.
I would suggest that the enormous size of today's pages have taken us back to the behavior seen in the dial-up days.
Then: Page was slow because the delivery was via a 56k analog modem.
Today: Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff.
I work for a large health care company. They got on the JS bandwagon a while ago. We used to have huge sites that loaded fairly quickly (under 2 seconds) and cleanly. Now? The last two years doing accessibility work - a lot of these same sites which have been converted to Angular or React? They're taking in excess of 15-20+ seconds to load.
15-20+ seconds!!! What on earth are they doing to make it take that long? The React app at my last job was taking 2-4 seconds to load I joined the company (which I considered incredibly slow) and I had it at under a second by the time I left.
We did actually test on older machines too, but the machine didn’t make a huge difference in this case, because it was network requests making it slow not JS execution.
Aye, the network is also superb at work... I don't have stats but it won't surprise me if the typical user is on 4G/3G and half of those people will always browse to your site at just the time when they're in an area of poor connectivity (e.g. that may simply be how it is at their home).
> Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff.
I think it's mostly blocking chains of multiple networks requests that execute in sequence (taking a network round-trip each time). I inherited a slow ~2mb frontend app at work, which seemed horrendously bloated to me. It turned out to be not that easy to reduce to the size (due to large amounts of code depending on large libraries), but it also turned out to be possible to make it load fast without reducing the payload size.
There was no tracking or ad code except error reporting to bugsnag. Most of it was the firebase SDK. Which we did work towards removing, but which was a long term project because:
- Every single database read depended on it
- Many of them were subscriptions rather than simple reads, and so couldn’t be trivially replaced by an API call.
That's a lot better than it used to be. IIRC, at the time I was working on the mentioned app the Firestore SDK was 700kb minimum just by itself, and with Auth and Firebase Realtime Database as well I believe we were over a megabyte just for firebase! For comparison, our API abstraction layer for functionality not using Firebase was under a kilobyte.
On one hand: If a tool is being constantly and egregiously misused at large scale, might it not be reasonable to assign a degree of blame to the tool (e.g. tool has a “pit of success” that encourages/permits misuse.
On the other hand: marketing and execs could misuse and abuse an empty room if they do desired, so I wonder why we bother giving them tools in the first place.
A tool that tests a change that puts off a person permanently won't give a good result if that person never comes back. It's often better to think through and ask a few users before starting developement. If your change is made only to lure people in, not improve their life in any way, mabe you should not even start the A/B testing at all...
> If your change is made only to lure people in, not improve their life in any way, mabe you should not even start the A/B testing at all...
Yes. It is totally possible to misuse the tool and run bad tests. That’s why, at least where I work, we don’t run live A/B tests until we’ve done some initial validation that the idea isn’t just terrible, and we have some level of confidence it will work and not harm the user’s experience. For example, we could segment user feedback and customer support issues we received by test variant so we could look for unexpected issues we might have inadvertently caused with the challenger design.
I can’t speak for how A/B testing is used elsewhere, but every A/B test I’ve run has been because we thought it would improve things for the user.
You certainly could run an A/B test to see which banner ad is more deceitful, just like you could use React to build the website that sells the scam medicine that banner ad is advertising.
One of my first jobs as a front-end dev, I was told repeatedly if you released a site and had forgotten to put height, width on images, it was seen as a defect and would affect your year end metrics.
By my second or third job, nobody seemed to care about it and when I brought it up, it was brushed aside as a "browser issue" and not something we devs needed to worry about.
You make a great point, and something I'm seeing a lot more of now that I'm in accessibility.
This - "Cumulative Layout Shift" - is part of Google's Core Web Vitals - https://support.google.com/webmasters/answer/9205520?hl=en - so if people are doing that, they're going to be penalised by Google. (Although probably only a bit, given the number of other factors that go into search rankings).
Meuh - google does this with youtube. Load video: video centered. Oh there's a side bar, let's shift the video. Oh the contents needs a smaller dimension, let's shift again. Rather annoying if you're used to watching videos at more than default speed - the control for that shifts 2-3 times.
Google is so huge that, as we say in the UK, it doesn't know its arse from its elbow - the teams are so disparate that it would be difficult to coordinate. Besides which, the "other factors" that I mention heavily favour a site like YouTube, such as the enormous number of inbound links, to a point where they can ignore the inconvenient bits of Core Web Vitals.
Because if you provided these, the browser would know how much space to leave for the image to occupy after it had downloaded [this was back in the dial-up modem days. So images usually loaded gradually after the rest of the page] and so the layout of the page would not change. Conversely, if you didn't provide 'width' and 'height' attributes, the browser would only leave a default small icon sized space for the image and then you'd have the page content move and shuffle about as each image downloaded and the rest of the page content got elbowed out of the way, to accommodate it.
It's funny how such basic concepts of usability seem to have fallen by the wayside in our new modern Web3 [or whatever version buzzword we're on now] in favour of moving content, modal overlays and the like. And, since so many sites these days just aggregate content from countless other external sources, even that basic notion of pre-defining your image sizes is often neglected too.