miss cloud front on browser

[hokidoki]

Before opening, please confirm:

• I have checked to see if my question is addressed in the FAQ.
• I have searched for duplicate or closed issues.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id

d2joh8jz57nkvq

Region

ap-northeast-2

Amplify Console feature

Performance

Describe the bug

Hello .

I installed Next.js following the AWS guide and hosted it on amplify.

However, every time I made a request to my service, the response was so slow. So, looking at the response header, the x-cache: Miss from cloudfront header is always present on browser. So I followed the instructions and enabled performance mode on my brunch in amplify but I'm still having the same problem.

The curious thing is that if you look at the x-cache header with the curl command, it was hit.

curl -X HEAD -i https://v.place.hitit.xyz/store/80e0a902-490f-4d96-b18d-988c852b2975 -s | grep -Fi x-cache x-cache: Hit from cloudfront

I suspect this is region related. Could you please check this as well ?

lambdaEdge : us-east-1
lambda : us-east-1
s3 : us-east-1
amplify : ap-northeast-2

Expected behavior

I don't have any customHttp.yml . it was problem ?

Reproduction steps

just enter my website.

https://v.place.hitit.xyz/
https://v.place.hitit.xyz/store/80e0a902-490f-4d96-b18d-988c852b2975

Build Settings

No response

Additional information

No response

[github-actions]

Hi 👋, thanks for opening! While we look into this...

If this issue is related to custom domains, be sure to check the custom domains troubleshooting guide to see if that helps. Also, there is a more general troubleshooting FAQ that may be helpful for other questions.

Lastly, please make sure you've specified the App ID and Region in the issue!

[Narrator]

Hello, this is a known issue and we are working on a permanent fix.

As a workaround, please disable caching in your SSR distribution (Go to Behaviors in the CloudFront console and set min/max TTL to 0 for all behaviors). This should resolve the issue until we have a permanent fix in place.

[hokidoki]

@Narrator hello Narrator

it work .but It's not a good idea to manually set the TTL every time I deploy.

When I asked the support team, they said that TTL is set by default and there is no way I can change it before deployment. Does any way exist?

[beam36]

@Narrator I tried the workaround you suggested but doesn't seem to work for me
My app id is d3aaj2ksbpdnai, region ap-southeast-1
We use this script to test

while true; do curl -X HEAD -i https://truck.isuzu-tis.com/product/gxz -s | grep -Fi x-cache; sleep 2; done
x-cache: Miss from cloudfront

[beam36]

After turned on the performance mode, the script does return 'Hit' but when I look at the network tab in Chrome, I still see 'Miss'

[saadataz]

@beam36, can you double check if you have "Disable cache" unchecked in Chrome Network tab

[beam36]

@saadataz I don't disable cache. Screenshot attached

[saadataz]

Thank you for confirming @beam36. We are actively working on fixing the issue.

[beam36]

@saadataz So there is no workaround?

[beam36]

@Narrator @saadataz It's been almost 2 months. Is there any update? If there's no fix soon, we'll have to consider moving to another platform.

[saadataz]

@beam36 This is still work in progress. We will update this thread as soon as the issue fixed.

[beam36]

@saadataz Is this something you guys are still actively working on? No update at all?

[oliver-leung]

We have deprioritized the fix for this issue, since it will be resolved when we release the next iteration of our SSR service.

[beam36]

@oliver-leung Can you confirm if there's any workaround (the one mentioned above doesn't work for me)? And can you say if the next iteration is weeks, months, or years?

[oliver-leung]

Unfortunately, we don't have a workaround, nor an estimated date by which it will be resolved.

[70ki8suda]

still not fixed ? I face same issue.

[oliver-leung]

@beam36 @70ki8suda @hokidoki We've since released our next iteration of our SSR provider - please follow the steps here to migrate your app: https://docs.aws.amazon.com/amplify/latest/userguide/update-app-nextjs-version.html

If you're still facing this issue, please let us know on this issue and we'll take another look!

[70ki8suda]

@oliver-leung
Hi, I migrated my app(using Nextjs ver13) to web computing platform. (https://ver-13-production.d2471u3n4mcim4.amplifyapp.com )
When using performance mode, instant cache invalidation on deployment does not work and a cache from a previous deployment remains in Cloud Front and references an old non-existent static file, resulting in a bug that does not display properly.
This does not happen in every browser. But if one browser picked up old CDN cache, it remains showing inappropriate display until CDN cache expires.

[ArmanNisch]

Status? Been a while now....

[MVMS1994]

Hi team, we are also facing this issue. We have hosted our webpack built web application. The assets are always miss from cloudfront and the downloads are delayed because of that. Can you share some ETA on this fix?

[anatolzak]

I am having the same issue with a simple next.js ssr, ssg apps, gatsby apps. All requests come back with X-Cahce: Miss from cloudfront

This issue was opened more than 1.5 years ago. I would expect a solution by now

[kkak10]

I'm having the same problem. In the React CSR App environment, the requesting Asset is not doing Cache Hit. Because of this, there is a problem with the initial loading speed.

I think this is a big problem.

[anatolzak]

Are there any plans on fixing this issue?
We will be forced to move away from AWS Amplify to a service that actually works

[adidoes]

is this still an issue?

[anatolzak]

@adidoes yes, it's still an issue

[rubengommers]

Just chiming in to confirm this is still an issue as of September 2023. We've been using AWS for a while but are new to Amplify. We're evaluating it as an alternative to Cloudflare Pages or Netlify, so this performance bottleneck is concerning.

Piggybacking on earlier comments that pointed out discrepancies between script-based and browser-based cache tests, I dug in a bit. There are two hosting options in Amplify: "Managed Hosting" initiated via the AWS Console and "CloudfrontAndS3" via CLI. The former is great until you hit issues like this; the latter lets you control CloudFront and S3 settings directly.

My focused hypothesis is that "managed hosting" doesn't adequately ignore cookies. When running curl -I {url}, I get x-cache: Hit from cloudfront. Browser-based tests almost always return Miss. However, clearing cookies and reloading will yield a Hit, if the cache is propagated (otherwise when you clear cookies and try again it will).

Quick tip aside: If you're still getting cache Misses, double-check your cache-control headers. Enabling performance mode will set s-maxage=600, but you can also use settings like s-maxage=60, stale-while-revalidate=7200, stale-if-error=86400 for more nuanced control.

It seems like a straightforward fix for the AWS team—just adjust the cache or origin request policies for managed CloudFront distributions to ignore all cookies.

As for a potential workaround, you can go with the "CloudfrontAndS3" option. However, that's at the expense of added complexity and maintenance on your end.

I'll be keeping my eye on this issue. I'm not interested in the added complexity of "CloudfrontAndS3." I want the simplicity that comes with using the console, but also want effective caching and, as a result, better performance. Fingers crossed for a fix soon.

[teamzz111]

+1

[airton]

+1

[cercao]

+1

[Timfts]

+1

[EsteBustamante]

@rubengommers, good catch! I was able to observe the behavior you suggested the x-cache: Hit from CloudFront is returned when I manually flush the cookies and refresh the page. However, increasing the TTL through the cache-control headers didn't resolve the issue. I suppose we'll have to wait for AWS to provide input here, but being close to 2 years, i don't feel optimistic

[oshyn-inc]

I believe this would work if we could override the Cloudfront policy for Amplify so we could modify the Cookie settings in the Cache key. It is very common for cookies to update their TTL every request. This behavior is causing the default Managed-Amplify policy (which uses Cookies - All Cache Key Setting) to think the request is a brand new cache entry (causing way more cache usage than necessary). If we could attach our own custom policy we could change that Cookie setting by excepting Cookies or including only ones whose Expiration Date does not change every request. Without this, amplify does not cache and the utility of the entire service is in doubt.

[EsteBustamante]

@Narrator @oliver-leung any thoughts?

[6mdx]

Very frustrating for nearly two years and the issue has not been fixed 😔

[wujashek]

+1

[sszlaga]

+1

[canuysal]

+1

[EleazerToluan]

+1

[ShwareAPI]

+1

[mauops]

+1

[hasadata]

+1

[guy-a]

+1

[gvsakhil]

Its been more than 2 years and still the issue is not fixed.... So baddddd AWS.....

[wujashek]

Just wanted to say "Hi" from Vercel :)

[mauerbac]

Hey everyone - Matt from the Amplify team here. First, I want to apologize for the delay in communication. The GitHub issue has a few themes - cache hit ratio, Instant cache invalidation and cookies in cache key. Cache hit ratio improvements and the ability to remove cookie from the cache key we are activity working on. This will greatly help the cache hit ratio and from this issue seems to be root of the most pain around cache. Instant cache invalidation has been addressed and is supported today.

We are hoping to have the ability to remove cookies from the cache key in the next couple of months. I will update this issue when that is released. Thank you for your patience.

[benebrice]

I have the exact same behavior described previously. For now, the only solution I found is to load the page from a private navigation (working on Safari). If version is not up to date, I close the window and try again. 🤦🏻

@mauerbac do you have any news for us? It's been a really long time since the opening of this issue.

[evokelabs]

I'm experiencing this same issue from two years ago. Using AWS amplify to build a git repository results in all public assets having a max-age of 5 seconds in cache-control. The files in the public folder don't cache on CloudFront, and will always return as a miss when it ought to be a hit via X-Cache. This leads to poor and costly performance as public assets are fetched from the origin every time to rebuild the cache, only to be removed 5 seconds later.

None of the fixes listed in this thread or others work (creating custom header ruleset in the build, or in customHttp.yml, or setting it to performance mode) - so max-age is always 5. I've tested the same build (Next 12 SSR) on Vercel and Netlify and they all cache the files in the public folder using CloudFront just fine out of the box, with the max-age being increased to hours/days by default. Right now I've circumvented this issue by creating a S3 bucket, storing the public asset files in there, using another CloudFront instance to distribute that S3, and then update the URLs in the Next application to use that CloudFront URL instead so caching will work.