This isn’t something WordPress provides at the moment, “PJAX” is a general term and technology that has lots of implementations and tradeoffs, similar to how there is no one way to do your CSS.
There is talk of something similar to this with the interactivity API for block themes though, but that’s in the highly experimental proposal stages and locks you into a very specific way of doing things (it’s not PJAX as you’ve described it).
Fundamentally, there are literally thousands of ways to do this, there’s no one specific method, and it isn’t the free meal you think it is.
When it works great it’s great, but there are lots of downsides too, a lot of it is perceived snappiness rather than actual speed, and there’s no guarantee it will actually be faster. You may also find in addition to accessibility issues that there are fundamental compatibility issues with certain plugins and themes around javascript event handlers and DOM ready handlers that don’t fire when you load a new page, or plugins that conditionally register their JS to try and speed things up not working because you started browsing on a page that doesn’t use it.
On top of that, the huge variety of ways to do this from small JS snippets to headless applications means the tradeoffs are wide and varied. At a minimum ensure that:
- your solution uses the browser history API, if it does not the URL and the forward/back buttons in the browser will not work as they’re supposed to, neither will browser history or sharing
- your solution has timeouts and handles poor network connectivity. E.g. if I click on a link and it takes 10 seconds to load, what happens in those 10 seconds? What should the browser address bar say during that time?
And importantly, in a normal page load the browser can progressively render the page piece by piece as it’s loaded. This is what most of google page speeds tests are trying to optimise. You throw all of that away by doing this, the DOM sees none of that until the JS has gotten all the HTML and updates it.