Good points, but I'm not sure "push", "pull", "user", or "owned" were particularly well described at the beginning.

I've always found that thinking about "static" vs "dynamic" content to be the most useful breakdown. Services often produce a mix of static and dynamic, i.e. it's not all "owned" just because it comes from the service. Similarly "push" and "pull" are a little tricky to reason about, but "upload via a web form" and "deploy via a build pipeline" are much clearer to me.

"static" and "dynamic" leads to an easy definition too – if it's in the codebase it's static, and if it's in the database (or referenced by it) it's dynamic. The same rules as in this blog post apply though, high cacheability on static and lower TTLs on dynamic content.

In systems of a certain scale this stuff starts to blend together (e.g. if your company runs an internal CDN then everything is dynamic from the perspective of the CDN), but in my experience, static/dynamic and deployed/uploaded is a good place to start that allows for good caching behaviour.

I guess caching is as hard as writing about caching, then. The author, while not sure if to teach or to preach, did a lousy job at both.

One of the first web projects I worked on involved a dozen iframes and calling postMessage to pass around data, it was chaos. Still remember the senior dev of the project did a pull request, the variable was called “cacheMeOutside” I chuckled and approved.