This is cool, but the end result is you are basically using WordPress as a document store. Because you need to implement an entirely custom frontend, you lose various wordpress templating abilities. Granted, that might be a worthwhile tradeoff.
Honestly, the sophistication, usability, and hackability* of modern wp-admin makes it worth the price of admission alone (even considering the performance hit from awkward wp_posts schema). I once used a siteless WP as a CMS for a lean CodeIgniter mobile app JSON API.
* Hackable in the positive sense; WP has its security reputation for a reason, but the majority of vulnerabilities are attributable to third-party plugins and themes.
It serves div soup rather than modern HTML5. I am a stuck record on this topic but I think your document structure needs to come first. Simplicity always trumps complexity when it comes to speed, no matter what the discipline.
Yes if the benchmark is speed. The new browser layout engines are quicker than the old floats and divs with billions of class tags. Plus the quickest download is always no download.
Then there is the matter of maintaining the content. Div soup has to get chucked down the drain for the new agency or developer to make more div soup. It is worthless.
Meanwhile, a document with proper markup and judicious use of semantic HTML5 tags is content with value that can be easily re-styled.
SEO matters too, pure speed matters but so does document structure. Hiding your content in div soup does not impress the Googlebot.
Interesting, but somehow missing a point for me. You can have quite fast WordPress pages without rolling out this big of a tech stack.
It all comes down to a good theme (most themes are not good) and utilizing a little bit of tech, most of which is already integrated into WP.
For example, I love the Transients API. You can easily cache database calls for posts with the Transients API and save lots of lookup/query time for complex datasets. One could argue that the Transients API is not meant to be used this way but I've build large sites which run fine (and fast) with that.
In the end it comes down to making smart choices: No tracking, few dependencies, minify all your assets, use browser caching, use scaled images, the whole toolset of good practices.
This will get you fast WordPress pages without worrying much about the tech stack you have to build around it.
The setup is more useful in a mobile situation, where latency is high and connectivity isn't so certain. Imagine you're travelling by metro and reading something on your phone.
That doesn't make sense. You have to deliver the whole markup and assets in one way or another. Keep it small so it gets transfered quickly, even on a slow connection. Once it has been transferred, you're done.
