marvinhagemeister
commented
1 year ago I like the idea of optimizing the server rendered parts of an application even further. Caching them directly is a bit tricky because partials could render different results depending on what data they received. Navigations typically render the currently active entry differently too. Nonetheless, that could be solved via some sort of cache key that we could generate by hashing the passed data or use a supplied value by the user.
I'm hoping that we can optimize rendering itself first before going down the caching route as such a system comes with its own complexities. There is a bunch of things we could do to make rendering itself on the server faster.
PoignardAzur
This is a concept I've seen come up independently a few times, but I don't think there's a standard name for it. Google calls it "partials" in their Faster multipage applications with streams article.
The base idea is trivial: given that most web pages served by a given domain have chunks of unchanging static bytes (eg header, footer, etc), you can achieve better caching by splitting them into different assets and caching them separately. And if this splitting/caching is done separately, it can be done in a Service Worker transparently to the render thread, which has a bunch of advantages (degrades gracefully, still works without JS, the Worker can also be used by an edge server for better edge caching, etc).
This feels like it would mesh well with the "islands of interactivity" concept: if you know in advance which parts of your page are likely to change a lot and which parts are likely to be fixed, you can do the splitting based on that information without any user configuration.
I'm not familiar enough with Fresh to know how good a fit it would be in practice, but all the talk about islands brought it to mind.