Once ad agencies/networks take note of this feature, they will 100% start using it and abusing it.
We're already seeing some ad networks using initialization scripts to bootstrap their ad setup, with dynamically constructed secondary scripts that have a high fetchpriority (so they supposedly load faster than others).
For reference, modern news/media sites may load multiple ad networks (3-4 on average perhaps) in order to optimize ad performance (revenue) or inject different kinds of ads or sponsored content. If we take Google's Ad Manager (or similar) as the base network to serve ads (own or third-party), many times we see additional networks like AdSense, Taboola, Outbrain, Vidverto (to name a few) or other local ad networks that do some sort of header bidding, ad injection, sponsored content display, in-read ads/videos and so on.
I don't see why some won't abuse this spec to force-inject their stuff earlier than other ad networks and of course at the expense of a site's performance...
thanatos519 275 days ago [-]
Could this be used to prevent me from clicking on or tapping the wrong thing because new items keep appearing causing a reflow just as I jab? I would really appreciate it if pages would render after they have made up their mind.
arghwhat 275 days ago [-]
… No, because the cause of this tends to be content loaded dynamically (i.e., not part of the original HTML) or content not handled by this spec (e.g., img without dimensions known in advance).
On the other hand, there is no real reason for a web app to have jumping content as is - it’s just a bug in said app.
don-code 275 days ago [-]
That's very much a double-edged sword. Jira is probably the product I use which has the worst UX around this - fields jump around the page for 5-10 seconds when I load a ticket. That said, while the likelihood that I personally (team/tech lead) am going to edit a ticket is quite high, I imagine the rest of my team (there are more of them than me) would be suffering through 5-10 second load times just to read a ticket.
daelon 275 days ago [-]
How is it justifiable for jira tickets to take 5-10 seconds to load in the first place?
psd1 275 days ago [-]
My friend, I've worked in a Remedy system where tickets would routinely take over a minute to load.
Senior management keeps buying shit, so shit is what the market offers.
Woshiwuja 275 days ago [-]
The company bought the Jira dildo and now is forced to jump on it
csswizardry 275 days ago [-]
Yes! Perfect scenario. This is a question of a slower but more trustable experience. I would always fight for both, however.
MathMonkeyMan 275 days ago [-]
> The short answer is: generally, you wouldn’t. Unless you know you need this behaviour, you don’t need it.
So... it will be on every website.
f33d5173 275 days ago [-]
Seems like a summary is: "scripts that don't use document.write (the majority) can use this to marginally increase performance". Unless I'm missing something.
don-code 275 days ago [-]
I've noticed there's a behavior of newer React apps, to load the static text "You need to enable JavaScript to run this app" (or similar). It'd be nice if they could instead use this feature to gate rendering the page, as I assume that plugins like NoScript would be implemented to ignore it entirely and render whatever static content is there.
It'd for sure still be up to content designers to degrade gracefully.
csswizardry 275 days ago [-]
This, generally, is avoidable hand-over-fist. `NoScript` isn’t a plugin—it’s older than most web developers.
ycombinatrix 274 days ago [-]
>"I've noticed there's a behavior of newer React apps, to load the static text "You need to enable JavaScript to run this app" (or similar)."
There's an HTML "<noscript>" tag that works perfectly well...
CM30 275 days ago [-]
The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.
csswizardry 275 days ago [-]
Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.
CM30 275 days ago [-]
Ideally it should be on the server side, so you're right there. Client side A/B testing isn't the best way to handle things.
However, it's sometimes a necessary evil due to:
1. The original company not budgeting time/effort from their existing dev teams to work on A/B testing, and wanting to outsource it instead.
2. Said company and their tech department being nervous about letting outsiders actually access the source code for their site/app.
3. Or said company wanting the analytics/features that VWO/Target/Optimisely/whatever offer, and not wanting to have code up the same analytics toolbox themself.
csswizardry 275 days ago [-]
All three of your points are correct, so please don’t resent my response: Client-side A/B testing exists because ‘we should be able to do this without a deploy’. And they’re right.
wizzwizz4 275 days ago [-]
But sorting all the paragraphs in alphabetical order increased reader engagement metrics! How would I ever have discovered readers wanted that without A/B testing?
275 days ago [-]
Rendered at 04:34:34 GMT+0000 (UTC) with Wasmer Edge.
We're already seeing some ad networks using initialization scripts to bootstrap their ad setup, with dynamically constructed secondary scripts that have a high fetchpriority (so they supposedly load faster than others).
For reference, modern news/media sites may load multiple ad networks (3-4 on average perhaps) in order to optimize ad performance (revenue) or inject different kinds of ads or sponsored content. If we take Google's Ad Manager (or similar) as the base network to serve ads (own or third-party), many times we see additional networks like AdSense, Taboola, Outbrain, Vidverto (to name a few) or other local ad networks that do some sort of header bidding, ad injection, sponsored content display, in-read ads/videos and so on.
I don't see why some won't abuse this spec to force-inject their stuff earlier than other ad networks and of course at the expense of a site's performance...
On the other hand, there is no real reason for a web app to have jumping content as is - it’s just a bug in said app.
Senior management keeps buying shit, so shit is what the market offers.
So... it will be on every website.
It'd for sure still be up to content designers to degrade gracefully.
There's an HTML "<noscript>" tag that works perfectly well...
However, it's sometimes a necessary evil due to:
1. The original company not budgeting time/effort from their existing dev teams to work on A/B testing, and wanting to outsource it instead.
2. Said company and their tech department being nervous about letting outsiders actually access the source code for their site/app.
3. Or said company wanting the analytics/features that VWO/Target/Optimisely/whatever offer, and not wanting to have code up the same analytics toolbox themself.