Blocking=render: Why would you do that?

[fevangelou]

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]

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]

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

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.

[csswizardry]

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

[MathMonkeyMan]

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

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]

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]

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

[ycombinatrix]

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

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]

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