-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loading apps from esm.sh is very slow #46
Comments
This implements an HTTP client that will (mostly) respect `Cache-Control` headers. Architecture of the cache: * Cache is persisted to discuss in a JSON file * Deserialization does not seem to cause noticeable delay on startup (tested with ~6MB cache) * Serialization blocks esbuild (cache saving is done at the end of the esbuild pipeline), but the overall perf was unaffected even when this was done concurrently/skipped * Cache contains byte size, and a hashmap of URLs -> entries. Entries store a deadline (or nil for immutable), contents as string (esbuild takes a string pointer rather than a byte slice, so it was faster to just store as a string), and an int64ptr that holds the time of last use. * Retrieving a value from the cache causes the time of last use to be atomically updated (not fully atomic, since we generate and then write, but worst case, this causes a few nanosecs diff) * On retrieve, we delete the entry if it has passed its TTL * On save/flush, the cache performs a 'compaction' cycle, where it evicts all expired data and then finally deletes from the least recently used items until the cache reaches the desired size. It then flushes the cache to disk. --- It significantly helps with #46, though does not fix it completely. * On main, cold loading `@robinplatform/app-example` takes around 22s. * 16.5s to render `base.html` * On httpcache, cold loading `@robinplatform/app-example` takes around 0.3s. * 150ms to render `base.html` * On either, cold loading `@robinplatform/app-example` from disk takes around 0.14s. (how on earth is this a different order of magnitude.........) * 70ms to render `base.html` --------- Co-authored-by: Albert Liu <[email protected]>
|
Hey, @ije! Thanks for the comment. The specific issue we are facing is for invalid files / loading TS. When loading TS/TSX off your CDN, they don't seem to get transpiled, so all the imports are still relative. To get around this, we implement our own node resolution algorithm to resolve the imports. However, esm.sh specifically asks for 404s (or I guess it is throwing a 500 for some reason) to not be cached, even for immutable URLs:
From my understanding, this should be safe to cache at the edge since react v18.0.2 did not have a file called 'foobar', and package releases are immutable. Of course native transpilation of TS & TSX from esm.sh would also fix this - but I understand that JSX might be out of scope for your project. |
I see. there is a plan to add support for ts/jsx transpiler |
Looks like
esm.sh
does not use edge caching, but rather relies on client-side caching. Not doing so is really slowing down app loads fromesm.sh
.For example:
my-ext
in theexample
project builds in 200ms, but when it imports a sass file (and therefore the sass library from esm.sh), it takes about 4s.The text was updated successfully, but these errors were encountered: