Add "Vary: Accept" header to /_next/image responses#26788
Merged
kodiakhq[bot] merged 4 commits intovercel:canaryfrom Jul 1, 2021
jviide:vary-accept
Merged
Add "Vary: Accept" header to /_next/image responses#26788kodiakhq[bot] merged 4 commits intovercel:canaryfrom jviide:vary-accept
kodiakhq[bot] merged 4 commits intovercel:canaryfrom
jviide:vary-accept
Conversation
jviide
requested review from
huozhi,
ijjk,
padmaia,
shuding,
styfle and
timneutkens
as code owners
This comment has been minimized.
This comment has been minimized.
Member
Failing test suitesCommit: b62ee67 test/integration/image-optimizer/test/index.test.js
Expand output● Image Optimizer › dev support w/o next.config.js › should proxy-pass unsupported image types and should not cache file ● Image Optimizer › dev support with next.config.js › should proxy-pass unsupported image types and should not cache file ● Image Optimizer › Server support w/o next.config.js › should proxy-pass unsupported image types and should not cache file ● Image Optimizer › Server support with next.config.js › should proxy-pass unsupported image types and should not cache file test/integration/font-optimization/test/index.test.js
Expand output● Font Optimization › with-google › Font optimization for SSR apps › should minify the css ● Font Optimization › with-google › Font optimization for serverless apps › should minify the css ● Font Optimization › with-google › Font optimization for emulated serverless apps › should minify the css |
Contributor
Looks like the |
Contributor
Author
|
If I'm reading the compression middleware code correctly it seems that the middleware adds Accept-Encoding to the Vary header for all compressible MIME types. This happens even for files that are smaller than the compression size threshold. Should I modify the failing test to accept Vary headers that also contain Accept-Encoding? The "should maintain vector svg" test already does that. |
Contributor
Yep let's update the "should proxy-pass unsupported" test to use the same regex, thanks! |
styfle
approved these changes
Jul 1, 2021
ijjk
approved these changes
Jul 1, 2021
Member
Stats from current PRDefault Build (Decrease detected ✓)General Overall increase
|
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| buildDuration | 11.3s | 11.4s | |
| buildDurationCached | 2.7s | 2.8s | |
| nodeModulesSize | 49.3 MB | 49.3 MB |
Page Load Tests Overall decrease ⚠️
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| / failed reqs | 0 | 0 | ✓ |
| / total time (seconds) | 2.011 | 2.07 | |
| / avg req/sec | 1243.31 | 1207.52 | |
| /error-in-render failed reqs | 0 | 0 | ✓ |
| /error-in-render total time (seconds) | 1.103 | 1.142 | |
| /error-in-render avg req/sec | 2265.53 | 2188.62 |
Client Bundles (main, webpack, commons)
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| 359.HASH.js gzip | 3.09 kB | 3.09 kB | ✓ |
| framework-HASH.js gzip | 42 kB | 42 kB | ✓ |
| main-HASH.js gzip | 20.2 kB | 20.2 kB | ✓ |
| webpack-HASH.js gzip | 1.49 kB | 1.49 kB | ✓ |
| Overall change | 66.9 kB | 66.9 kB | ✓ |
Legacy Client Bundles (polyfills)
| vercel/next.js canary | jviide/next.js vary-accept | 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 | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| _app-HASH.js gzip | 803 B | 803 B | ✓ |
| _error-HASH.js gzip | 3.18 kB | 3.18 kB | ✓ |
| amp-HASH.js gzip | 526 B | 526 B | ✓ |
| css-HASH.js gzip | 329 B | 329 B | ✓ |
| hooks-HASH.js gzip | 903 B | 903 B | ✓ |
| index-HASH.js gzip | 263 B | 263 B | ✓ |
| link-HASH.js gzip | 1.65 kB | 1.65 kB | ✓ |
| routerDirect..HASH.js gzip | 322 B | 322 B | ✓ |
| withRouter-HASH.js gzip | 320 B | 320 B | ✓ |
| bb14e60e810b..30f.css gzip | 125 B | 125 B | ✓ |
| Overall change | 8.42 kB | 8.42 kB | ✓ |
Client Build Manifests
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 390 B | 390 B | ✓ |
| Overall change | 390 B | 390 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| index.html gzip | 522 B | 522 B | ✓ |
| link.html gzip | 535 B | 535 B | ✓ |
| withRouter.html gzip | 515 B | 515 B | ✓ |
| Overall change | 1.57 kB | 1.57 kB | ✓ |
Webpack 4 Mode (Decrease detected ✓)
General Overall increase ⚠️
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| buildDuration | 10.4s | 10.3s | -64ms |
| buildDurationCached | 4.1s | 4s | -79ms |
| nodeModulesSize | 49.3 MB | 49.3 MB |
Page Load Tests Overall decrease ⚠️
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| / failed reqs | 0 | 0 | ✓ |
| / total time (seconds) | 2.129 | 2.131 | 0 |
| / avg req/sec | 1174.24 | 1173.21 | |
| /error-in-render failed reqs | 0 | 0 | ✓ |
| /error-in-render total time (seconds) | 1.155 | 1.214 | |
| /error-in-render avg req/sec | 2163.63 | 2059.85 |
Client Bundles (main, webpack, commons)
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| 14.HASH.js gzip | 3.11 kB | 3.11 kB | ✓ |
| 677f882d2ed8..HASH.js gzip | 13.4 kB | 13.4 kB | ✓ |
| framework.HASH.js gzip | 41.8 kB | 41.8 kB | ✓ |
| main-HASH.js gzip | 8.07 kB | 8.07 kB | ✓ |
| webpack-HASH.js gzip | 1.19 kB | 1.19 kB | ✓ |
| Overall change | 67.5 kB | 67.5 kB | ✓ |
Legacy Client Bundles (polyfills)
| vercel/next.js canary | jviide/next.js vary-accept | 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 | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| _app-HASH.js gzip | 1.07 kB | 1.07 kB | ✓ |
| _error-HASH.js gzip | 3.83 kB | 3.83 kB | ✓ |
| amp-HASH.js gzip | 531 B | 531 B | ✓ |
| css-HASH.js gzip | 333 B | 333 B | ✓ |
| hooks-HASH.js gzip | 910 B | 910 B | ✓ |
| index-HASH.js gzip | 227 B | 227 B | ✓ |
| link-HASH.js gzip | 1.64 kB | 1.64 kB | ✓ |
| routerDirect..HASH.js gzip | 295 B | 295 B | ✓ |
| withRouter-HASH.js gzip | 292 B | 292 B | ✓ |
| e025d2764813..52f.css gzip | 125 B | 125 B | ✓ |
| Overall change | 9.26 kB | 9.26 kB | ✓ |
Client Build Manifests
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 418 B | 418 B | ✓ |
| Overall change | 418 B | 418 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | jviide/next.js vary-accept | Change | |
|---|---|---|---|
| index.html gzip | 566 B | 566 B | ✓ |
| link.html gzip | 579 B | 579 B | ✓ |
| withRouter.html gzip | 559 B | 559 B | ✓ |
| Overall change | 1.7 kB | 1.7 kB | ✓ |
Contributor
|
This fix is available in next@11.0.2-canary.4, thanks! |
Contributor
Author
|
Awesome, thank you! 🙂 |
flybayer
pushed a commit
to blitz-js/next.js
that referenced
this pull request
Aug 19, 2021
This pull request adds "Vary: Accept" header to responses from the image optimizer (i.e. the /_next/image endpoint). The image optimizer prefers re-encoding JPG files to WebP, but some browsers (such as Safari 14 on Catalina) do not yet support WebP. In such cases the optimizer uses the Accept header sent by the browser to send out a JPG response. Thus the optimizer's response may depend on the Accept header. Potential caching proxies can be informed of this fact by adding "Vary: Accept" to the response headers. Otherwise WebP data may be served to browsers that do not support it, for example in the following scenario: * A browser that supports WebP requests the JPG. The optimizer re-encodes it to WebP. The proxy caches the WebP data. * After this another browser that doesn't support WebP requests the JPG. The proxy sends the WebP data to the browser. - [x] Integration tests added - [x] Make sure the linting passes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request adds "Vary: Accept" header to responses from the image optimizer (i.e. the /_next/image endpoint).
The image optimizer prefers re-encoding JPG files to WebP, but some browsers (such as Safari 14 on Catalina) do not yet support WebP. In such cases the optimizer uses the Accept header sent by the browser to send out a JPG response. Thus the optimizer's response may depend on the Accept header.
Potential caching proxies can be informed of this fact by adding "Vary: Accept" to the response headers. Otherwise WebP data may be served to browsers that do not support it, for example in the following scenario: