I feel like this is the death-knell for server-rendered content. [LWN.net]

I feel like this is the death-knell for server-rendered content.

Posted Aug 30, 2026 6:49 UTC (Sun) by WolfWings (subscriber, #56790)
Parent article: Ryabitsev: Creepy crawlies

Anubis was always a short-term band-aid because the server-side resources of the scrapers scale VASTLY faster than folks five-year-old tablets and laptops they're using to do real work.

Long-term CGit and similar server-rendered stuff (RRD based graphing tools I'm staring REALLY hard at you all, or even some Grafana setups) will need to stop doing any server-side calculations and just chuck all the work to client-side javascript computation and rendering with proper byte-range fetches, at a minimum, if it survives at all at a larger scale at this point.

to post comments

I feel like this is the death-knell for server-rendered content.

Posted Aug 30, 2026 13:53 UTC (Sun) by marcH (subscriber, #57642) [Link] (1 responses)

Free/open web services should certainly offload as much as they possibly can to the client side for many good reasons, but... would it really make a lot of difference in this particular kernel.org case? When you think about it, all this abuse is consuming... less than 20 CPUs! Pretty impressive... :-/ Could this really be optimized/offloaded further?

I feel like this is the death-knell for server-rendered content.

Posted Aug 31, 2026 5:45 UTC (Mon) by WolfWings (subscriber, #56790) [Link]

It's using 20 CURRENTLY, but it's a tiny fraction of the bandwidth being used as mentioned in the article.

It's certainly at a point where shifting the radio of network bytes : compute would benefit from being ratcheted the other way I feel at least.

And it would mildly penalize the scrapers for requesting things from a ton of separate endpoints because they'd need to each deal with the same data chunks while a real browser would be able to have chunks cached between requests.