Proxies are already complicated as is. Caching proxies more so. (Think of how Varnish has a - probably Turing complete - DSL to decide what to serve and/or cache and when, and how.)
The HTML parsing approach is probably great from a 80% of the benefit for 20% of the effort on small-scale websites (i.e. majority). A super accurate inference engine might use deep learning to train what to serve on a very personalized level if you have a lot of users & the CPU/latency trade-off makes sense for your business model (i.e. more accuracy for a larger slice of your population). A less accurate one might just collect statistics in a DB & make cheap less accurate guesses from that (or use more "classic ML" like Bayes) if you have a medium amount of users or the CPU usage makes more sense and you're OK with the maintenance burden of a DB. It's a sliding scale IMO of tradeoffs with different approaches making sense depending on your priorities.
That said a simple heuristic like "after requesting an URL the server got these requests on the same HTTP/2 connection in less than 1 second, and those were static assets served with Expires headers" could work.
Similarly, it should be the backend behind the reverse-proxy that knows what's the page that has been just rendered, and knows about the user's session (is it brand new, or maybe it's not new, but still needs to push things because it's too old, and since then that particular page's background changed, etc.).
And in case of an Angular/React/SPA thing, then the "bundler/compiler" should create a list of things to push for various URLs. Or the Angular/React team should talk with the Nginx team to figure out how to speed up things. (In case of SSR - server side rendering - the NodeJS server can emit the necessary Link headers, for example.)