I really hated that about twitter too, that for reading a goddamn SMS-lenghty tiny text it couldn't just have been "prerendered" on the server, no, you have to fetch a million things and watch different spinners before you get at it.
In contrast, JSON parsers are a dime a dozen, and HTTP+JSON has been the standard in APIs for well over a decade now. Be happy Mastodon isn't based on XML-SOAP, that would have been a right fucking mess and depending how rigid the clients would parse it, you'd end up with immediate ossification of the protocol instead of people just adding new fields for new functions (e.g. polls).
The forgotten 2000-era web had solutions for all of this in the form of XML and XSLT. The server serves XML, which is "semantic" (data structures). The XML has a header pointing to an XSLT file, which defines a functional transform of the XML to HTML. You could use namespaces to embed semantic info inside other schemas like XHTML if you wanted, also.
It never took off, partly because XSLT was a pretty unpleasant programming language (I actually built a product with it back in the day), partly due to latency reasons and partly because the XML vision wasn't sufficiently backwards compatible with regular HTML.
These days browsers don't support such tech anymore, so you need to treat HTML+JS as an app platform, HTTP as an RPC protocol and JSON as the serialization format but because that arrangement was never really designed per se there are lots of little missing pieces, like being able to discover the RPC protocol a web app uses without actually executing that app.
And people do this?