Hacker News new | ask | show | jobs
by youngtaff 4139 days ago
Where sites serve the base page through a CDN, then the CDN has the potential to start making intelligent decisions on what should be pushed.

As the simplest level this might be just the CSS, and JS in the <head> but obviously as different UA's behave differently there's scope for much granular optimisations.

1 comments

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.

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!