Blocking=render: Why would you do that?

Blocking=render: Why would you do that?(csswizardry.com)

42 points by pinjasaur 1 year ago | 18 comments

fevangelou 1 year ago |

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 1 year 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 1 year 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 1 year 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 1 year ago | | |

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

csswizardry 1 year ago | |

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

MathMonkeyMan 1 year 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 1 year 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 1 year 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 1 year ago | |

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

ycombinatrix 1 year 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 1 year 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 1 year 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 1 year 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.

wizzwizz4 1 year 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?