[cm2187]

That's the easy, but relatively rare scenario. Today most content is dynamic.

Naively, it looks to me that server push will mostly be an improvement for small websites that do not use a CDN, but I can't see how it can coexist with a CDN.

Or it would require a new syntax, where the html tells the browser to start connecting to the CDN with this particular URL, which contains a token, and should be downloaded first which would tell the CDN that a particular list of assets will be needed for that page, and then the CDN will use server push to send these static assets.

Alternatively the CDN would become a proxy for the underlying html page, which would still be generated by the application server. That would probably be simpler.

[youngtaff]

CDNs aren't limited to just static content, it's quite common for large dynamic sites to deliver their base pages though CDNs.

They can use features like ESI to assemble the final page on the edge from static and dynamic parts, or they can just act as a proxy to the origin with the dynamic page generated there.

Even when the CDN is just acting as a proxy back to the origin there can be performance advantages e.g. lower latency TCP and TLS negotiation between edge to client, and permanent connection between edge and origin i.e. single TCP negotiation for all clients, larger congestion windows leading to higher throughput.

In short CDNs aren't just for static content!