Vercel "Usage" tab shows much higher Fast Origin Transfer than Fast Data Transfer

[colin-j-rm]

Summary

My Fast Origin Transfer (FOT) usage is about 4x higher than Fast Data Transfer (FDT). I have ISR on almost all my pages with a 12 hour revalidation period. My site has plenty of traffic in these 12 hour periods, and my understanding is all these users should be hitting cache from ISR and only incurring FDT.

So I thought FDT should be much, much higher than FOT. If I have 10k visits in 12 hours, and all hit the ISR cache, then FDT should be 10k times higher than FOT? Instead it's the other way around, FOT is 4x higher than FDT. I'm quite confused why this is happening, and the Usage tab doesn't give any breakdown of FOT by paths/pages.

Edit: For context, my old Bandwidth metric is also lower than FOT and equal to FDT

Edit: This is super confusing, it seems like a sudden influx of data usage came out of nowhere and was never covered by previous Bandwidth metric

Is this normal/expected? Is anyone else experiencing this?

Example

No response

Steps to Reproduce

N/A

[gersooonn]

Did you find out about ?I also have a high FOD and I use ISR. If I didn't have a cache, my FOD would be even higher, right? In short, the Cachê on the pages that have ISR, does it save money on FOD?

[colin-j-rm]

I haven't found the answer, but I'm also even more confused. Because with the new pricing infrastructure my understanding was old Bandwidth = FDT + FOT

But this isn't the case for me either. My old Bandwidth exactly matches FDT (fast data transfer), and is much lower than FOT. So actually FOT > old Bandwidth = FDT?

This is super confusing, it seems like a sudden influx of data usage came out of nowhere and was never covered by previous Bandwidth metric

[danielbeardsley]

For what it's worth, we have the same situation: The old "Bandwidth" metric has the same values as Fast Data Transfer.

Bandwidth: The amount of data that your Deployments have received or sent.
Seems equivalent to (both in description and in value) to:
Fast Data Transfer: The data transfer between Vercel's Edge Network and your sites' end users.

So, the inexplicable part is that they've added a new metric:

Fast Origin Transfer: The data transfer between Vercel's Edge Network to Vercel Functions.

Which for some reason is like 5x higher than FDT, and it seems like it ought to be less than FDT because some percentage of our requests are served cached responses which don't even talk to the origin. Please clarify what's going on Vercel! Is there any chance that this is counting the uncompressed bytes or something? (I'd assume requests to origin use gzip encoding).

[colin-j-rm]

From one of my discussions in my support case, they mentioned: "it's expected that FOT could be higher (especially with MISSes) as it includes uncompressed data transferred between Vercel's Edge Network and your projects functions (this includes serverless functions and edge middleware)"

This raises 2 more questions:

1. Why is data transfer between edge network and origin uncompressed?
2. Even accounting for compression, let's assume compression ratio is 4:1, then the ratio between compressed FOT and compressed FDT is 1:1. So it seems like every end user request is triggering data transfer from both origin and edge network, despite all the caching I have setup through ISR. This part is still confusing to me/doesn't seem right?

(waiting on clarification in my support case but sharing more info here for other folks that are confused by this)

[Fungusjuice]

Same here! Would love to see detailed breakdown of my FOT usage

[yekta]

We have the same problem as well (with a projected price increase of 4X). The dashboard doesn’t give any meaningful info. Just shows a breakdown by region or project which doesn’t help at all. We don’t understand how we are pushing that amount of data a day between Vercel Edge Network and Vercel functions.

[wisefool769]

I have the same problem as well. Would be super useful to see a breakdown of FOT.
In addition, mine is almost all "incoming", so that's even more confusing.

[amyegan]

Thank you all for sharing feedback about FOT usage clarity. This has been shared with our product team and they're looking at ways to help you better understand your FOT usage. Please keep telling us what doesn't make sense or what additional information you think would be helpful to see in the dashboard.

We currently have an article outlining what resources are used at each step of a user's journey through an example website. It might give you a better idea of when each resource would be used on your own site: https://vercel.com/docs/pricing/how-does-vercel-calculate-usage-of-resources#calculating-usage-of-resources

In general, the recommended way to optimize FOT is by caching your function responses. When more requests are served from the Edge Network cache instead of running the function again, you'll see both reduced FOT usage and improved performance.

I'll continue to post updates here as I get more info.

[danielbeardsley]

the recommended way to optimize FOT is by caching your function responses

Agreed. But this discussion isn't about optimizing, it's about making sense of a seemingly nonsensical number. For our main project, FOT is 5x FDT, implying that for every byte we send to the user, we had to fetch 5x as many bytes from the origin? Without caching, I'd expect the two values to be equal or FOT to be less because the vercel system ensures assets (css, js, ...) are cached at the edge. With caching I'd expect FOT to go down, yet we're seeing FOT = 5 X FDT and thus left mystified.

Above, someone mentioned it may be because vercel is counting uncompressed bytes? Is that so? Does that mean vercel is responses from the Origin to the Edge uncompressed? Or that they are being sent compressed, but we're billed for uncompressed.

We currently have an article outlining what resources are used at each step of a user's journey through an example website.

I appreciate the intent here and while it looks thorough, it seems to generate more questions than provide answers in this case. The only mention of FOT is:

Data movement charges for fetching cart state from the cache

Not sure what this means. "cart state" ? "from the cache" ? Other places describe FOT as "Fast Origin Transfer speeds up the exchange of data between Vercel's Edge Network and compute functions, such as Serverless Functions".

[alex-windett]

Same issue here, would love to know where all the costs are being accrued from. I am using ISR and have added cache headers to relevant API requests as well

[Ventanas95Dev]

Hello. We have the same problem. The FOT is like 3-4x times more then the FDT.

We are using dynamic routes / SSR so it will always be a miss when enter the website. We cant cache the page we need to go to the server. And we need to have the nodejs runtime. Some libs we use dont work on the edge.

some thoughts

• Why do i need to go throw the edge network (and pay for FOD) when the call is always dynamic. Why cant i go directly to the server?

• Your payment is confusing. When looking at this page. https://vercel.com/blog/improved-infrastructure-pricing

You write that the old bandwidth was the combination of FOT and FDT. But when looking in the usage tab. The FDT and bandwidth are the same. But FOT is much much more. It should be that FOT + FDT === old bandwidth. Right?

[leerob]

It should be that FOT + FDT === old bandwidth. Right?

Not exactly – it depends on what your application is using. There are also Edge Requests, and then possibly Data Cache Reads/Writes, which were previous all included under one large bucket called bandwidth.

Why do i need to go throw the edge network (and pay for FOD) when the call is always dynamic. Why cant i go directly to the server?

Fast Origin Transfer is the "inter-network" communication. So between a Vercel region Iike US West where a customer visits from, and then where your functions are located, like US East.

[Ventanas95Dev]

But how can the pricing be much more now then before? We have not change any code or anything. This is a bit confusing for me. The pricing will increase with like 10x.

Also i don't get why FOD is more then FDT. I guess one problem is that the data is uncompressed, as stated in the earlier comments? But how can it be so much more like 3-4x then FTD?

Will you release some more information how to debug this? or can you point me to some information? I don't really know how I should proceed with this.

[yekta]

It should be that FOT + FDT === old bandwidth. Right?

Not exactly – it depends on what your application is using. There are also Edge Requests, and then possibly Data Cache Reads/Writes, which were previous all included under one large bucket called bandwidth.

Why do i need to go throw the edge network (and pay for FOD) when the call is always dynamic. Why cant i go directly to the server?

Fast Origin Transfer is the "inter-network" communication. So between a Vercel region Iike US West where a customer visits from, and then where your functions are located, like US East.

I’m having a hard time understanding this. Our FOT is 1.5X our FDT, which seems unbelievably high for passing around some JSON compared to serving cached images, fonts etc. It’s so high that it makes me think either we are misunderstanding something with these calculations or there is an error with the calculation. We have a SvelteKit app that does SSR with dynamic content. I don’t understand why it would even go to the edge for these on Vercel. I would expect Vercel functions to serve them directly.

[colin-j-rm]

I also have one more request for the team. Since my new billing cycle has started, my projected price increase is over 10x. I really appreciated the 3 month buffer given before pricing change took effect, but is it possible to extend an extra month (at least until this issue is resolved), especially for those affected by this issue?

For context, I've had a similar support case open since the pricing change was announced in April. Since I'm still blocked on this, I've been unable to prepare and optimize before the pricing took into effect.

I didn't have enough understanding/clarity around the new metrics and didn't want to touch my ISR/cache settings until I could get to the root cause of this discussion thread. Also, the lack of tooling/breakdown of new metrics by functions/paths made it even more difficult to debug.

I don't feel comfortable being charged by numbers that I don't understand and can not optimize for. Another extension/discount would be greatly appreciated for folks who are struggling with this issue, thank you!

[Ventanas95Dev]

+1 for this!

[wscotten]

+1. There is no guidance from Vercel on what specifically "Fast Origin Transfer" is. If I make an API request to a non-Vercel service in a serverless function that returns 1MB of json, am I charged for that 1MB? Even if I don't send it to the client?

[julienkos]

Agreed! We should be able to see at minimum a breakdown to be able to just understand the charge.

[hcentelles]

Same here. Our last month FOT was almost 4x our FDT (2.14 TB vs 597.3 GB) we have 2 serverless functions doing ssr without caching on Vercel CDN because we're caching it on Cloudflare. The uncompressed data moving from functions to cdn seems like a plausible explanation (can you confirm this @leerob), if that's the case, it's fair? Can you expand on why the data moves uncompressed?

[leerob]

👋 Hey everyone. I appreciate the feedback here that our documentation is not yet clear enough about how Fast Origin Transfer works and how you can understand and optimize your usage.

Fast Origin Transfer is incurred when using any of Vercel’s compute products. These include Vercel Functions, Middleware, and the Data Cache (used through ISR).

Usage is incurred on both the input and output data transfer when using a compute products. For example:

• Incoming: The number of bytes sent as part of the HTTP Request (Headers & Body).
  • For common GET requests, the incoming bytes are normally inconsequential (less than 1KB for a normal request).
  • For POST requests, like a file upload API, the incoming bytes would include the entire uploaded file.
• Outgoing: The number of bytes sent as the HTTP Response (Headers & Body).
  • The size of a Function's response is determined by user code. Optimizing Fast Origin Transfer is equivalent to reducing your Function's response size.
  • Common tips:
    • Ensure your Function is only responding with relevant data (no extraneous API fields).
    • Ensure your Function supports If-Modified-Since or Etag to prevent duplicate data transmission (on by default for Next.js applications).

Middleware

If using Middleware, it is possible to accrue Fast Origin Transfer twice for a single Function request. To prevent this, you want to only run Middleware when necessary. For example, Next.js allows you to set a matcher to restrict what requests run Middleware.

Data Cache (ISR)

When using ISR on Vercel, the same optimization suggestions above for “Outgoing” apply.

Investigating Usage

• Look at the Fast Origin Transfer section of the Usage page:
  • Observe incoming vs outgoing usage. Reference the list above for optimization tips.
  • Observe the breakdown by project.
  • Observe the breakdown by region (Fast Origin Transfer is priced regionally)
• If optimizing Outgoing Fast Origin Transfer:
  • Observe the Top Paths on the Usage page
  • Filter by invocations to see which specific compute is being accessed most

Compression is an included feature of Fast Data Transfer. While Fast Origin Transfer does support compression, it depends on if your function respects the accept-encoding request header. Fast Origin Transfer has always been uncompressed. Based on the feedback here, we’re exploring whether we could make compression included by default for Fast Origin Transfer, similar to Fast Data Transfer.

[leerob]

@colin-jiang Responses that serve a cached ISR response do not accrue Fast Origin Transfer. Fast Origin Transfer only applies to distributing a new copy after a revalidation. We will get this updated in the documentation, based on the result of this discussion.

@danielbeardsley Fast Origin Transfer is not currently compressed, however, we are exploring if we can compress this by default based on the feedback in this thread. Thank you for sharing.

[colin-j-rm]

@leerob thanks for clarifying. So this is the part that doesn't make sense to me. If FOT is only incurred for a new copy after revalidation, then given my setup of all pages with 12 hour revalidation and consistent traffic, it seems impossible for FOT to be greater than FDT.

If I have only one page, and that page has ISR with 12 hour revalidation, and for the next 12 hours i have 10,000 user visits, then my FOT should just be 1 hit? And FDT is all the cache reads from edge network. So FDT should be 10,000 times higher than FOT in data usage?

(assuming only one unique network edge, I guess in practice it has to be transferred and replicated to multiple edges?)

[hcentelles]

@leerob following up @danielbeardsley questions and your answer:

the vercel docs say0 next.js compresses responses (using Brotli) by default

1. If compression happens at Next.js level (independently of Vercel) why the data from Functions to Edge Network travels uncompressed?

If that's the case (which seems bananas), is there any way to make that happen?

2. Can you answer this? Because as we speak I'm accruing FOT usage and is getting scary, if I can remediate it now, while you're "exploring if we can compress this by default" it'll allow me to have better sleep.

3. If you start to compress the responses of Functions by default what happens to FOT already accrued? We will have to pay it in full?

[bitttttten]

@leerob it would be great to have a finer breakdown on these graphs too. Our web app has a lot of static pages, and a lot of dynamic pages. It's hard to know where to optimise our FOT since we don't know which dynamic pages are causing the most FOT. And if this FOT is coming from ISR, data cache, or uncompressed traffic between all the moving parts. Knowing a bit more would help a lot since it seems (to me) like a bit of a black box at the moment 🫡

[bitttttten]

Also since there is a separate graph for data cache, why does FOT include that? We assumed that FOT isn't related to data cache as it's in a separate panel. Does this mean we have been optimising for the wrong reasons? 🥲

[vitorsilvalima]

Vercel is starting to bother developers/startups. This makes extremelly nosense. There is no way for us to know why this charge is happening. I do not even use edge functions and now I see a really high number of Fast Origin Transfer...

[colin-j-rm]

Reducing ISR/cache reads also seems to have no effect on FOT

I significantly reduced my caching and daily ISR reads from 3 million to 1 million, and in the same time range, edge requests stayed the same. I would expect FOT to increase since less requests are cached and thus would trigger FOT. But my FOT stayed the same. I think either this FOT metric is incorrect or ISR cache reads are still somehow triggering FOT

[bitttttten]

@colin-jiang it depends how you brought your cache reads/writes down. if you didn't have affect on how your requests get cached on vercel's edge network then your FOT would stay the same (if i understand it correctly).

[Felipedelima123]

Our team is considering canceling Vercel due to these recent changes. We are reaching the FOT limit, which doesn't make sense to us. We've been using Vercel for about a year and have never come close to these limits before.

[yekta]

We are considering the same because we are not able to make sense of the claimed amount of data we push between Vercel’s functions and edge network. No compression is one partial explanation but we don’t understand why that data is pushed to the edge to begin with since it’s not cached (using SvelteKit).

[amyegan]

I really appreciate all of you sharing this feedback. We're listening, and we're currently working on improvements to provide clarity around FOT and help reduce usage.

Please keep telling us about what doesn't make sense and what information would help you, and I'll keep sharing it with the team.

[bitttttten]

Hi @amyegan , what doesn't make sense is that our FOT is larger than our Fast Data Transfer. We are not sure if data cache is related although we are very puzzled about that. Happy to share more info if need be.

[bitttttten]

I think one confusion is that data cache is in a separate section that FOT although data cache is included in FOT.. it seems FOT is one big giant bucket we have no insight into truest optimising. That may not be true, although from my point of view that's how it feels.

[simon-hellomolly]

Not sure if this is the right thread - we have a an e-commerce store with about 15000 products/pages and we are not going to build out all those paths as a lot of products have up to 5 different paths. We are still on pages router and opted for getStaticProps no revalidation time specified with an empty paths array in getSaticPaths fallback true. I would expect that cache-response-header to be something around 1 year or something very hight but it seems to be revalidating on every request.

No idea how this works. As a result our FOT is still very high about double our FDT, the json responses are very small around 10kb each and we have prefetching disabled on most links to the product pages.

[vettloffah]

I'm in the same boat as some others here. We are surprised by the amount of FOT and aren't sure what to focus on to bring it down.

The docs say:

To optimize FOT, you can implement caching strategies for your Vercel Function responses.

How can we tell which functions are incurring the most FOT so we know what to focus on? Is this an available query in monitoring?

[leerob]

Hey y'all. Following up from my previous message.

Fast Origin Transfer usage will be free for all customers in your current billing month.

We hear your feedback that you want more more details on what is causing Fast Origin Transfer—the data transfer between Vercel Edge Network regions and compute like Vercel Functions, Middleware, and ISR. We will soon add deeper visibility into your usage of Fast Origin Transfer on the Usage page, along with default compression to reduce your costs.

We will be covering 100% of your Fast Origin Transfer usage for the current billing month. You will see this discount on your next invoice. Let me know if you have any questions.

[motomic-efdezpolo]

Hello there! Thank you for your response. Is this for all costumers or do we have to open a ticket? I am seeing our spending getting so much bigger, already 300% and three weeks to go.

I hope we can get this discount and spend the month improving our usage.

[addda3786]

it seems we don't need to do something to get this discount, i checked my invoice 3 days ago and saw the price has decrease the amount of FOT.

but i want to know when will the FOT detail data be shown? it means while the detail is provide for user, the price need to be pay until you can solve the huge amount used.

maybe the vercel team should consider the great plan to get balance.

[ebakken]

I've noticed that my projects relying heavily on middleware significantly increase my FOT. I went from staying within the Pro plan to incurring about $50 in excess FOT charges for relatively low-traffic projects.

While some projects can be optimized to reduce middleware usage, others cannot, such as Vercel's Platforms Starter Kit, which requires most requests to go through middleware. This raises concerns about the cost of running such projects at scale on Vercel.

If I understand correctly, moving middleware away from the edge could drastically reduce FOT. This has been a highly requested feature for a while, and with Vercel's new pricing model, it seems even more relevant now.

[comlaterra]

We are facing something we don't fully understand aobut this metric: +99% of the Fast Data Transfer usage froms from one region ( Washington, USA ) despite around 30% of our traffic comes from BR, and only ~4% from US... 🤔 This doesn't make much sense to us... Which makes me have very low trust on the measurement of this usage metric... and so I'm not happy we don't fit anymore in the Pro plan.

While Fast Data Transfer:

Can someone help me understanding what can be the cause for this, and how can we validate this is correct?

[leerob]

Could you please ensure your project's function region is in the correct region you want it to be? You can view this option in your project settings. The default is US East, Washington D.C. (iad1).

[leerob]

We are now default compressing Fast Origin Transfer to help reduce your usage. Please re-deploy your latest production deployment for this to apply 🙏

[github-actions[bot]]

This discussion was automatically locked because the community moved to a new site. Please join us at vercel.community