来自 AWS CloudFront 的外部 Next.js 图像的缓存控制策略对于 Google Lighthouse 效率不高

Question

I'm trying to optimize my Next.js app by fixing all the issues reported by Google Lighthouse.

One of the most important pitfalls it has right now regards to images:

As per the documentation , Next.js automatically does so for media in the static folder

Next.js automatically adds caching headers to immutable assets served from /_next/static including JavaScript, CSS, static images, and other media.

As all of those problematic images are coming from an API, which serves them from AWS CloudFront, I can't find a way to fix the problem.

I guess adding the suggested Cache-Control policy in CloudFront may help but I don't know

1.) If that's the right solution 2.) How to do so in AWS Console

Answer 1

Next.js automatically adds caching headers to immutable assets served from /_next/static including JavaScript, CSS, static images, and other media.

This is not the case when you are using next export and deploying a static site to S3 & CloudFront, see unsupported features (although they do not state that explicitly). What you can do is set these Cache-Control headers yourself manually with S3 object metadata . This is a preferred way for a next.js app because you can specify the headers for each object separately.

Generally (see Caching best practices & max-age gotchas ) you should add max-age=31536000,public,immutable directives to the whole _next/static folder since these will have the hash appended to the file name, thus the cache gets invalidated on every new change.

Other than that it's for you to manage & depends on what type of app you're building, but it's common practice to set the HTML documents to public,max-age=0,must-revalidate (even no-cache,no-store ). Since you are using CloudFront it's fine to keep them in the edge cache as long as u have a proper invalidation set up.

You also might have non-statically imported images with src="<path string>" , these also won't be exported to the _next/static folder so if you want to add long max-age & immutable content to these you have to manage the versioning/hashing yourself to invalidate properly when the images change.

With AWS Console

Checkout editing object metadata in the Amazon S3 console , to add Cache-Control headers to _next/static objects metadata:

1. Open the Amazon S3 console and your bucket.
2. Select the check box to the left of the _next/ directory.
3. On the Actions menu, choose Edit actions, and choose Edit metadata.
4. Choose Add metadata.
5. For metadata Type, select System-defined.
6. Select Cache-Control for the key and add max-age=31536000,public,immutable as the value.
7. When you are done, hit Save Changes and Amazon S3 should edit all the _next/static files metadata recursively, you can verify it by opening a specific file and scrolling down to the metadata section.

With CDK

If you are using AWS CDK you can use multiple BucketDeployment constructs to specify different Cache-Control headers for different out directories (see examples ):

// _next/static - long max-age & immutable content
new s3deploy.BucketDeployment(this, 'BucketDeployment', {
  ...
  sources: [s3deploy.Source.asset('./out', { exclude: [ '/**/*', '!/_next/static/**/*'] })],
  cacheControl: [s3deploy.CacheControl.fromString('max-age=31536000,public,immutable')],
  ...
});

// revalidate everything else
new s3deploy.BucketDeployment(this, 'BucketDeployment', {
  ...
  sources: [s3deploy.Source.asset('./out', { exclude: ['/_next/static/**/*'] })],
  cacheControl: [s3deploy.CacheControl.fromString('max-age=0,no-cache,no-store,must-revalidate')],
  ...
});

Improving without Vercel

I'd also suggest (if using some additional AWS resources and terraform is not an issue) taking a look at this terraform module or very least their image optimizer which can be dropped in as a standalone image optimization loader for the Next.js image component, so you get all the next/image component benefits (there's also this issue for bunch of other workarounds).