Blocking=render: Why would you do that? | Hacker News Reader

Blocking=render: Why would you do that?

csswizardry.com

42 pointspinjasaur18 comments

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...

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.

Yes! Perfect scenario. This is a question of a slower but more trustable experience. I would always fight for both, however.

… 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.

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.

How is it justifiable for jira tickets to take 5-10 seconds to load in the first place?

The company bought the Jira dildo and now is forced to jump on it

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.

> 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.

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.

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.

This, generally, is avoidable hand-over-fist. `NoScript` isn’t a plugin—it’s older than most web developers.

>"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...

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.

Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.

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?

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.

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.

Reply on news.ycombinator.com