-
Notifications
You must be signed in to change notification settings - Fork 28.1k
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
Don't cache null
responses
#27403
Don't cache null
responses
#27403
Conversation
@@ -1641,7 +1646,10 @@ export default class Server { | |||
} else if (isRedirect) { | |||
value = { kind: 'REDIRECT', props: pageData } | |||
} else { | |||
value = { kind: 'PAGE', html: html!, pageData } |
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.
This is the underlying issue that this PR addresses: It's valid for html
to be null
in some cases, but not for a cached page. The !
just breaks downstream consumers who expect a valid value here.
This comment has been minimized.
This comment has been minimized.
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.
LGTM! Do you want to create a type for ResponseCacheEntry | null
?
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.
Looks good! Just needs an integration test!
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Stats from current PRDefault Build (Decrease detected ✓)General Overall increase
|
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
buildDuration | 13.3s | 14.4s | |
buildDurationCached | 3.2s | 3.1s | -103ms |
nodeModulesSize | 49.5 MB | 49.5 MB |
Page Load Tests Overall decrease ⚠️
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 2.252 | 2.278 | |
/ avg req/sec | 1109.91 | 1097.5 | |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 1.259 | 1.288 | |
/error-in-render avg req/sec | 1985.49 | 1940.54 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
359.HASH.js gzip | 2.96 kB | 2.96 kB | ✓ |
745.HASH.js gzip | 180 B | 180 B | ✓ |
framework-HASH.js gzip | 42.2 kB | 42.2 kB | ✓ |
main-HASH.js gzip | 21 kB | 21 kB | ✓ |
webpack-HASH.js gzip | 1.53 kB | 1.53 kB | ✓ |
Overall change | 67.9 kB | 67.9 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31.1 kB | 31.1 kB | ✓ |
Overall change | 31.1 kB | 31.1 kB | ✓ |
Client Pages
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
_app-HASH.js gzip | 803 B | 803 B | ✓ |
_error-HASH.js gzip | 3.06 kB | 3.06 kB | ✓ |
amp-HASH.js gzip | 554 B | 554 B | ✓ |
css-HASH.js gzip | 329 B | 329 B | ✓ |
dynamic-HASH.js gzip | 2.52 kB | 2.52 kB | ✓ |
head-HASH.js gzip | 2.28 kB | 2.28 kB | ✓ |
hooks-HASH.js gzip | 903 B | 903 B | ✓ |
image-HASH.js gzip | 5.61 kB | 5.61 kB | ✓ |
index-HASH.js gzip | 261 B | 261 B | ✓ |
link-HASH.js gzip | 1.66 kB | 1.66 kB | ✓ |
routerDirect..HASH.js gzip | 319 B | 319 B | ✓ |
script-HASH.js gzip | 387 B | 387 B | ✓ |
withRouter-HASH.js gzip | 320 B | 320 B | ✓ |
bb14e60e810b..30f.css gzip | 125 B | 125 B | ✓ |
Overall change | 19.1 kB | 19.1 kB | ✓ |
Client Build Manifests
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
_buildManifest.js gzip | 490 B | 490 B | ✓ |
Overall change | 490 B | 490 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
index.html gzip | 530 B | 530 B | ✓ |
link.html gzip | 543 B | 543 B | ✓ |
withRouter.html gzip | 525 B | 525 B | ✓ |
Overall change | 1.6 kB | 1.6 kB | ✓ |
Webpack 4 Mode (Increase detected ⚠️ )
General Overall increase ⚠️
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
buildDuration | 10.9s | 10.5s | -457ms |
buildDurationCached | 4.3s | 4.1s | -182ms |
nodeModulesSize | 49.5 MB | 49.5 MB |
Page Load Tests Overall increase ✓
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 2.46 | 2.274 | -0.19 |
/ avg req/sec | 1016.45 | 1099.53 | +83.08 |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 1.325 | 1.279 | -0.05 |
/error-in-render avg req/sec | 1886.98 | 1955.01 | +68.03 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
17.HASH.js gzip | 2.98 kB | 2.98 kB | ✓ |
18.HASH.js gzip | 185 B | 185 B | ✓ |
677f882d2ed8..HASH.js gzip | 13.7 kB | 13.7 kB | ✓ |
framework.HASH.js gzip | 41.9 kB | 41.9 kB | ✓ |
main-HASH.js gzip | 8.4 kB | 8.4 kB | ✓ |
webpack-HASH.js gzip | 1.22 kB | 1.22 kB | ✓ |
Overall change | 68.5 kB | 68.5 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31.3 kB | 31.3 kB | ✓ |
Overall change | 31.3 kB | 31.3 kB | ✓ |
Client Pages
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
_app-HASH.js gzip | 791 B | 791 B | ✓ |
_error-HASH.js gzip | 3.76 kB | 3.76 kB | ✓ |
amp-HASH.js gzip | 552 B | 552 B | ✓ |
css-HASH.js gzip | 333 B | 333 B | ✓ |
dynamic-HASH.js gzip | 2.71 kB | 2.71 kB | ✓ |
head-HASH.js gzip | 2.97 kB | 2.97 kB | ✓ |
hooks-HASH.js gzip | 911 B | 911 B | ✓ |
index-HASH.js gzip | 231 B | 231 B | ✓ |
link-HASH.js gzip | 1.64 kB | 1.64 kB | ✓ |
routerDirect..HASH.js gzip | 298 B | 298 B | ✓ |
script-HASH.js gzip | 3.02 kB | 3.02 kB | ✓ |
withRouter-HASH.js gzip | 294 B | 294 B | ✓ |
e025d2764813..52f.css gzip | 125 B | 125 B | ✓ |
Overall change | 17.6 kB | 17.6 kB | ✓ |
Client Build Manifests
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
_buildManifest.js gzip | 500 B | 500 B | ✓ |
Overall change | 500 B | 500 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | azukaru/next.js dont-cache-resolved-responses | Change | |
---|---|---|---|
index.html gzip | 577 B | 577 B | ✓ |
link.html gzip | 588 B | 588 B | ✓ |
withRouter.html gzip | 569 B | 569 B | ✓ |
Overall change | 1.73 kB | 1.73 kB | ✓ |
It's possible for `renderToHTML` to return `null` if `res.finished || res.headersSent` is `true` after `getInitialProps` or `getServerSideProps`. In such cases, we can't generate a valid `ResponseCacheEntry` or `ResponsePayload`, so we shouldn't try. I took the opportunity to add an invariant for when we expected a cacheable response, but didn't get one. This could happen because Next.js or an application erroneously mutated the underlying `res` during the rendering of a page with `getStaticProps`. This shouldn't normally be possible because `res` isn't exposed in such cases, but it's theoretically possible with a custom server, so it seemed worth flagging.
It's possible for
renderToHTML
to returnnull
ifres.finished || res.headersSent
istrue
aftergetInitialProps
orgetServerSideProps
. In such cases, we can't generate a validResponseCacheEntry
orResponsePayload
, so we shouldn't try.I took the opportunity to add an invariant for when we expected a cacheable response, but didn't get one. This could happen because Next.js or an application erroneously mutated the underlying
res
during the rendering of a page withgetStaticProps
. This shouldn't normally be possible becauseres
isn't exposed in such cases, but it's theoretically possible with a custom server, so it seemed worth flagging.