Two features to optimize SolidStart #edge #CSR #1467

NawfelBgh · 2024-05-03T01:29:46Z

NawfelBgh
May 3, 2024

Hello,

I would like to propose 2 features for SolidStart:

Using service workers and CSR, returning users would not suffer from the double data problem and from hydration cost. Only search engines and new users coming with no cache get to experience that.
By marking user-specific data loaders and session-independent data loaders, old edge caching technologies can be used to improve performance for all users and reduce load on the server.

Details:

1. With little help from Service workers, CSR can be made as* efficient as SSR.

CSR-SolidStart already approaches the performance of optimized SSR-ed apps by starting to load page data as soon as possible in the Back-for-Front server.

My theory is that if we install a service worker that delivers HTML without requiring any round trip to the server, we can start loading data for the requested page as fast as theoretically possible (minus the round trip to the service worker which is negligible). The installed service worker must contain maps from routes to JS and CSS bundles URLs and to URLs that trigger loader functions. When a user requests a page, the service worker should respond with something like:

<html>
<head>
  <link rel=preload  as=fetch href=dataLoadingUrl1 />
  <link rel=preload  as=fetch href=dataLoadingUrl2 />
  <link rel=stylesheet href=routeStylesBundleUrl />
  <script src=routeBundleUrl></script>   <link rel=preload as=script href=routeNonCriticalBundleUrl />
</head>
<body></body>
</html>

So what I'm suggesting is to only use SSR and hydration for first page loads with no cache. But once the service worker cache is installed, SSR and hydration are not used anymore. Instead, simpler CSR happens.

Data loading URLs are loaded early by using preload link tags. Their inputs are sent as query parameters. My guess is that these inputs will consist only of keys that are both serializable and small.

If we go this route and if the service worker loads client side code that doesn’t support hydration, we can have some performance and code size gains, although very negligible I guess.

For reduced page load latency, client side code should be served from the edge and it should be small.
We can optimize the delivery of this code further by splitting it into code that needs to run for initial rendering and non-first-paint-critical code that is loaded later and whose job is to install event handlers and to execute non-render effects. This will require changing how SolidJS compiles its JSX and will require collaboration from the bundler to split the code correctly introducing some complexity. I think that such an optimization can get us to a very good place with little work compared to other approaches like resumability from Qwik.

2. Using the edge to cache data that is common to all users

Websites scale better the less the server is solicited and the more we can respond directly from the edge. To facilitate this, I suggest that SolidStart should provide a way to declare which loader functions are session-independent and which of them are user-specific, and that SolidStart should provide a mode where :

page data is loaded with two different requests: one fetching only session-independent loaders data and another fetching user-specific loaders data.
When doing SSR, only the session-independent loaders are run, making it possible to cache the response in the edge for use by other users. A preload link tag should be streamed in the initial HTML chunk to trigger the request for user specific data as soon as possible.
When doing CSR, session-independent loaders route should return appropriate HTTP headers so that its results is cached in the edge and reused by other users.

So these are two features that I would like to see SolidStart implement. Because I believe they will make it more efficient while not introducing too much complexity and while taking advantage of simple caching provided mostly by stable and old edge technology.

ryansolid · 2024-05-06T16:35:44Z

ryansolid
May 6, 2024
Maintainer

These are both interesting ideas.

I was going to ask if it can be done in userland but the fact you need both hydratable and non-hydratable bundles would probably make that a no. In general these sort of multi-bundle approaches are interesting if we are willing to concede potentially shipping all the JS twice in non-critical way.
I've wondered if this solution would have to be a bit proprietary for deployment platforms.. That being said I don't see why this couldn't be done in userland to a degree if offered the right primitives. Like we only call the load function on the client after the fact or (in single flight mutations) so to me the current cache function with custom caches would basically solve this. Like we could have certain cache functions setup with a KV with a KV store. You could set up those session independent cache functions there, and then the user and session ones get cached in the client.

So initial load for everything just fetches everything... After that point, new users would hit the KV session independent stuff on their initial load and there user stuff fetched from the DB. Navigation after that would cache in the client, or on miss try the edge, or go to the DB.

3 replies

NawfelBgh May 6, 2024
Author

Using the edge to cache data that is common to all users

I've wondered if this solution would have to be a bit proprietary for deployment platforms.. [...] Like we could have certain cache functions setup with a KV with a KV store.

Since you are talking about KV stores and proprietary technology, I think that I have to expand a little bit more on my proposal, where I intended to only rely on widely available transparent CDN caches:

As a disclaimer, most of my experience in web development is with intranet apps, and I have limited knowledge on cloud providers offerings, so my assumptions may be wrong.

The experience inspiring this proposal is the one time I worked on a slow plugins-heavy wordpress website of an international company. The website was so slow to load that people were telling us that it was down from remote locations... We fixed the problem by configuring our server to send adequate cache response headers and by activating a transparent CDN service (from OVH) that would automatically store things in its cache (while of course honoring our response headers).

So what I was envisioning in my proposal is for SolidStart's server to not have to know anything about the caching layer. Instead, it has to provide APIs that allow developers to specify the HTTP response headers in order to control when things are allowed to be stored in CDN (and user devices) caches and for how long.

A possible API for specifying cache headers would be to require the cached functions to always return a Response object. I concede though that this doesn't match perfectly with what SolidStart does today (like streaming the responses of multiple loader functions in a single response-request). We may need an API that defines how to combine different caching headers if different loader functions results are combined in a single HTTP-response.

In all of this I've been assuming that transparent caching CDNs are available for cheap in basically all cloud offerings. So, by using this instead of proprietary technologies like KV stores, we reduce maintenance costs for framework authors and avoid locking users to any cloud provider.

I don't see why this couldn't be done in userland to a degree if offered the right primitives.

I agree. I haven't though much about all the API design though.

NawfelBgh May 16, 2024
Author

Note that all these CDN related optimizations are already doable with normal API routes. But I would like do be able to do the same with SolidStart’s server functions to not have to write two styles of code depending on the cache-ability of the data.

I would like to refine what I said here:

A possible API for specifying cache headers would be to require the cached functions to always return a Response object. [...] We may need an API that defines how to combine different caching headers if different loader functions results are combined in a single HTTP-response.

After further thinking, I realized that I conflated things a little bit. Actually, we can support both CDN caching (of some server functions) and getting the results of multiple server functions with a single HTTP request.

Let me divide server functions into 4 types:

server function	1. session-independent	2. session-dependent
a. HTTP-cachable	stored/reused by CDNs and browsers	stored/reused by browsers’ private caches
b. non-HTTP-cachable	always get freshest data	always get freshest data

So what SolidStart can do is:

Provide an API to mark server functions as HTTP-cachable (1.a and 2.a)
Apps can still get the results of multiple non-HTTP-cachable server functions (1.b and 2.b) with a single HTTP request.
Apps will have to make a separate request for each HTTP-cachable server function. We end up wasting some network resources by doing multiple requests for HTTP-cachable server functions but we do save server resources and some network resources because of the caches’ proximity to the end user.
Apps do the same on single flight mutations. Although some apps may want to start fetching some or all HTTP-cachable server functions of the destination route in parallel with the mutation request to the server.

NawfelBgh May 20, 2024
Author

I just realized that because of SSR, we still need an API to combine caching headers when different loader functions results are served together: When the App does server side renders a page, it awaits all cachable session-independent data loading functions (1.a) before streaming the HTML. The framework should provide an API that the App can use to produce the HTTP headers that determine how long the caches should keep the resulting page.

With this API, point 3 (in my previous comment) is not valid anymore: Apps will be able to serve multiple HTTP-cachable server function results in the same HTTP response provided they are of the same type. That is, in the same request/response, we can have either cachable session-independent server functions (1.a) or cachable session-dependent ones (1.b) because the later can only be stored by private browsers' caches.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Two features to optimize SolidStart #edge #CSR #1467

{{title}}

Replies: 1 comment 3 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Two features to optimize SolidStart #edge #CSR #1467

NawfelBgh May 3, 2024

Details:

1. With little help from Service workers, CSR can be made as* efficient as SSR.

2. Using the edge to cache data that is common to all users

Replies: 1 comment · 3 replies

ryansolid May 6, 2024 Maintainer

NawfelBgh May 6, 2024 Author

NawfelBgh May 16, 2024 Author

NawfelBgh May 20, 2024 Author

NawfelBgh
May 3, 2024

Replies: 1 comment 3 replies

ryansolid
May 6, 2024
Maintainer

NawfelBgh May 6, 2024
Author

NawfelBgh May 16, 2024
Author

NawfelBgh May 20, 2024
Author