-
Notifications
You must be signed in to change notification settings - Fork 89
feat: move static pages out of function bundle #728
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
const pagesManifest = await readJson(pagesManifestPath) | ||
// Arbitrary limit of 10 concurrent file moves | ||
const limit = pLimit(10) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
y?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to avoid having too many files open errors if there are loads of them, but equally we want to avoid blocking on a single large file. A better number might be 1, or 2, or the number of cpus, or soemhting else. In lieu of actually testing (yet), I picked an arbitrary number.
|
||
return readfileOrig(file, options) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the comments are so great!! 🙏 this is genius
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it's great or terrible, tbh
Because we're using Next's routing, we're serving all pages via the function. This includes static pages. This has a couple of downsides. First, some users have large numbers of pre-rendered pages, which can lead to large zip sizes. Second, it means we're not making the best use of the CDN.
This PR moves static page files out of the
server/pages
directory so they're no longer bundled with the function, and instead puts them directly into the publish directory so they're served by the CDN instead, and with redirect shadowing these are served instesd of calling the function. This is mostly fine, but unfortunately there are still some situations where Next will try to load the files. This is mostly where there are rewrites that point at these static pages. In this situations, if there is no file then the user will incorrectly see a 404 rather than the page from the CDN. This PR adds an extra workaround for this. There is only one place in the Next codebase where these files are loaded, which is in IncrementalCache, wherefs.promises.readFIle
is used. By monkey-patchingpromises
with a wrapper forreadFile
, we can check if Next is tryign to read one of these files. We know which files they are, as we've written out a manifest of all the files we moved. If it is one of these files then we load the file from the CDN, cache it in the lambda, then return the cached file instead. Next sees it as having loaded the file directly, and is none the wiser.I hate monkey-patching, but this should be a relatively uncommon code path. I've put the whole thing behind a flag
EXPERIMENTAL_MOVE_STATIC_PAGES
for now, and can let users who have lots of prerendered pages try it. With some instrumentation, tests and maybe improved implementation this might be worht makign the default.