Skip to content
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

chore: refactor image optimization to separate external/internal urls #61172

Merged
merged 5 commits into from Jan 26, 2024

Conversation

styfle
Copy link
Member

@styfle styfle commented Jan 25, 2024

This PR is refactoring only and doesn't change the logic, therefore no tests were added.

The improvement here is readability:

  • separate functions to fetch external vs internal image (in the future, we could improve perf of internal image routing)
  • types of the arguments are more specific (rather than passing in complete NextConfig)

Note: Its easier to review with whitespace hidden: https://github.com/vercel/next.js/pull/61172/files?w=1

@ijjk ijjk added created-by: Next.js team PRs by the Next.js team type: next labels Jan 25, 2024
@ijjk
Copy link
Member

ijjk commented Jan 25, 2024

Tests Passed

@ijjk
Copy link
Member

ijjk commented Jan 25, 2024

Stats from current PR

Default Build
General Overall increase ⚠️
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
buildDuration 11.6s 11.7s N/A
buildDurationCached 6.2s 4.8s N/A
nodeModulesSize 200 MB 200 MB ⚠️ +5.58 kB
nextStartRea..uration (ms) 427ms 427ms
Client Bundles (main, webpack)
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
3f784ff6-HASH.js gzip 53.4 kB 53.4 kB
423.HASH.js gzip 185 B 181 B N/A
68-HASH.js gzip 29.8 kB 29.8 kB N/A
framework-HASH.js gzip 45.2 kB 45.2 kB
main-app-HASH.js gzip 237 B 239 B N/A
main-HASH.js gzip 31.8 kB 31.8 kB N/A
webpack-HASH.js gzip 1.7 kB 1.7 kB
Overall change 100 kB 100 kB
Legacy Client Bundles (polyfills)
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
polyfills-HASH.js gzip 31 kB 31 kB
Overall change 31 kB 31 kB
Client Pages
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
_app-HASH.js gzip 194 B 195 B N/A
_error-HASH.js gzip 182 B 181 B N/A
amp-HASH.js gzip 502 B 502 B
css-HASH.js gzip 320 B 322 B N/A
dynamic-HASH.js gzip 2.5 kB 2.5 kB N/A
edge-ssr-HASH.js gzip 255 B 256 B N/A
head-HASH.js gzip 350 B 349 B N/A
hooks-HASH.js gzip 368 B 369 B N/A
image-HASH.js gzip 4.18 kB 4.18 kB N/A
index-HASH.js gzip 257 B 256 B N/A
link-HASH.js gzip 2.61 kB 2.61 kB N/A
routerDirect..HASH.js gzip 310 B 311 B N/A
script-HASH.js gzip 384 B 383 B N/A
withRouter-HASH.js gzip 306 B 308 B N/A
1afbb74e6ecf..834.css gzip 106 B 106 B
Overall change 608 B 608 B
Client Build Manifests
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
_buildManifest.js gzip 484 B 484 B
Overall change 484 B 484 B
Rendered Page Sizes
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
index.html gzip 528 B 526 B N/A
link.html gzip 541 B 539 B N/A
withRouter.html gzip 523 B 522 B N/A
Overall change 0 B 0 B
Edge SSR bundle Size
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
edge-ssr.js gzip 94 kB 94 kB N/A
page.js gzip 149 kB 149 kB N/A
Overall change 0 B 0 B
Middleware size
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
middleware-b..fest.js gzip 625 B 624 B N/A
middleware-r..fest.js gzip 151 B 149 B N/A
middleware.js gzip 37.6 kB 37.6 kB N/A
edge-runtime..pack.js gzip 1.92 kB 1.92 kB
Overall change 1.92 kB 1.92 kB
Next Runtimes
vercel/next.js canary vercel/next.js refactor-image-optimization-external-vs-internal Change
app-page-exp...dev.js gzip 170 kB 170 kB
app-page-exp..prod.js gzip 95.6 kB 95.6 kB
app-page-tur..prod.js gzip 96.3 kB 96.3 kB
app-page-tur..prod.js gzip 90.9 kB 90.9 kB
app-page.run...dev.js gzip 142 kB 142 kB
app-page.run..prod.js gzip 90.2 kB 90.2 kB
app-route-ex...dev.js gzip 22.2 kB 22.2 kB
app-route-ex..prod.js gzip 14.9 kB 14.9 kB
app-route-tu..prod.js gzip 14.9 kB 14.9 kB
app-route-tu..prod.js gzip 14.5 kB 14.5 kB
app-route.ru...dev.js gzip 21.6 kB 21.6 kB
app-route.ru..prod.js gzip 14.5 kB 14.5 kB
pages-api-tu..prod.js gzip 9.42 kB 9.42 kB
pages-api.ru...dev.js gzip 9.69 kB 9.69 kB
pages-api.ru..prod.js gzip 9.42 kB 9.42 kB
pages-turbo...prod.js gzip 22 kB 22 kB
pages.runtim...dev.js gzip 22.6 kB 22.6 kB
pages.runtim..prod.js gzip 22 kB 22 kB
server.runti..prod.js gzip 49.7 kB 49.7 kB
Overall change 932 kB 932 kB
Commit: eb8690d

@styfle styfle marked this pull request as ready for review January 25, 2024 23:09
@styfle styfle requested review from ismaelrumzan and leerob and removed request for a team January 25, 2024 23:09
@styfle styfle enabled auto-merge (squash) January 25, 2024 23:09
packages/next/src/server/image-optimizer.ts Outdated Show resolved Hide resolved
packages/next/src/server/image-optimizer.ts Outdated Show resolved Hide resolved
): Promise<{ buffer: Buffer; contentType: string; maxAge: number }> {
const { href, quality, width, mimeType } = paramsResult
const upstreamBuffer = imageUpstream.buffer
const maxAge = getMaxAge(imageUpstream.cacheControl)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're only using cacheControl from imageUpstream to retrieve the max age, would it be worth refactoring to have fetchImageUpstream take care of that for us? And then have the ImageUpstream type return maxAge rather than cacheControl (unless we do need cacheControl for some reason that I'm not seeing in this diff).

Copy link
Member Author

@styfle styfle Jan 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two functions: fetchExternalImage and fetchInternalImage so both of them would need to call getMaxAge().

My PR only requires a single getMaxAge().

I think the inputs here make sense because it allows you to pass in the result of the upstream (buffer from the body plus relevant headers) without needing to create the shape of a NodeResponse or WebResponse.

Maybe I should rename ImageUpstream to ImageUpstreamResponse to make it a little more clear?

styfle and others added 2 commits January 26, 2024 09:30
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
@styfle styfle merged commit 39afdc5 into canary Jan 26, 2024
67 checks passed
@styfle styfle deleted the refactor-image-optimization-external-vs-internal branch January 26, 2024 16:20
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants