Self-hosting breezewiki -- even on the same machine that you browse from -- gets neatly around the way fandom wikis block the breezewiki public nodes. I've got it self-hosted and now I never see that damn fandom interface.
By "this stuff" I mean BreezeWiki, Invidious, Nitter, whatever that one for Reddit was called.
We're essentially reliant on these serverside solutions to proxy requests because that's the easiest way to do cross-origin requests without making whatever browser deity you annoyed that morning suddenly angry at you. (Extensions can mark domains to be allowed to run on, but this is restricted by the manifest, allowing for really easy whack-a-mole by server authors, not to mention the fact that each update would need signing from Mozilla/Google.)
Irritatingly, the same mechanism that's used to stop fraudulent sites can also be used as an easy deterrent against deshittification interfaces.
I skimmed the docs looking for an architecture overview, but couldn't see an answer to this. The low resource requirements cited for the docker container install suggest it's just doing page-loads and re-rendering them.
EDIT: So I've now set this up as via docker on my nomad cluster, and it's just proxying the pages and searches to and fro. It's a bit heavy - sitting at about 410MB while idle, but doesn't feel like there's any performance impact compared to hitting upstream directly.