High Edge Requests

[Ghonghito]

Summary

Today, I noticed that after the bill is paid, my Edge Requests are quite high, at 1.1M/10M at the time of writing this (bill was paid 7h ago). Can you help me understand how it works and how I can optimize it?

Example

No response

Steps to Reproduce

no steps

[mtr1990]

I also get a huge number with just static resources.

According to estimates, the cost will increase 3 times for the Pro package

[leerob]

Hey y'all, have you seen this page in our documentation?

https://vercel.com/docs/pricing/networking#edge-requests

On the Usage page, you can view resources that are causing the most requests, which will allow you to see where you can optimize.

[mtr1990]

Checked but it doesn't do much besides finding accidentally unused projects and deleting it.

For the current project, the number of requests still increases to more than 500k/day even though the number of users is not too much.

Edge Requests
The number of cached and uncached requests that your deployments have received.
=> So caching doesn't make any sense here? The number of requests still increases even when cached?

I just know that the bill will triple for the Edge Request feature. (Not to mention other features)

In previous billing periods, these features were only used 30% of the Pro plan that I purchased.

Fast Data Transfer
Fast Origin Transfer
Edge Requests
Edge Request CPU Duration
Data Cache Reads
Data Cache Writes
Function Duration
...

[leerob]

For the current project, the number of requests still increases to more than 500k/day even though the number of users is not too much.

Can you share an example of your top paths from the usage page, by requests?

So caching doesn't make any sense here? The number of requests still increases even when cached?

A request is independent of whether the response is cached or not cached. If you are making a request to a Vercel Function for example, there is always one request, but then if it's cached, then you wouldn't accrue any function usage.

[mtr1990]

For example, popular files like favicon.ico were requested more than > 10k in just 2 days

[leerob]

You could reduce many of the requests there by consolidating to one variable font file.

[vexus2]

I am experiencing the same issue.
Where can I check the actual accessed URLs for Edge Requests?
That is not mentioned in the documentation.
Without that list, I cannot proceed with optimization.

[Carduelis]

I am experiencing the same issue, @leerob .
We're serving a free app for Miro marketplace, called Planning poker. Due to the way how Miro works, we get ~30 millions requests per month.
It makes the project is not sustainable anymore. All the other metrics except the "edge requests" count is far below the threshold given us by a pro plan. And only this new "Edge requests" is about 3.6 above the limit.

We had to enable Monitoring, that cannot be throttled, and paid extra $36 for a couple of days of operation just to understand where the problem comes from! Had to disable Monitoring.

1. https://miro.com/marketplace/planning-poker/ the app
2. https://vercel.com/gorazdo/ -- our account
3. The only app uses 98.8% of all of our projects (see screenshot)
4. Support case https://vercel.com/gorazdo/~/support/cases/253481

Currently, I'm trying to disable chunk optimization, by consolidating webpack.xxx.js, framework.xxx.js chunks into one. But there are others like: _middleware, _ssgManifest, .etc. Each extra file multiplies amount of requests very heavily.

I do not know what to do.

[Carduelis]

After consolidating chunks, I got the following requests:

• Not sure, it is possible to optimize it further, all the manifests seems to me obligatory.
• Potential migration to app router can potentially help here by eliminating _app.js chunk.
• But It feels like saving on matches and hurting performance
• Considering the other metrics, like compute-hours or bandwidth, the cap for Edge requests feels like too low
• With this Edge Requests it will lead us to migrate from Vercel unfortunately. Another app in Miro marketplace, and we're bankrupt.

[leerob]

Are you using a middleware file in your application? If yes, does it have a matcher? Could you share a code example?

[Carduelis]

@leerob Thank you for the prompt reply!

I'm using next 12.0.8 with next-plugin-preact 3.0.6, and preact 10.6.4. No custom middleware (if, of course, the preact plugin doesn't apply it under the hood).

My plan is to upgrade to the App router. I see from the Next.js Boilerplate example, there will be at least 3 requests: main-app-xxx.js (if we join the chunks), page-xxx.js and the html endpoint.

3 requests is still better than 10 before optimizations, but it still limits us from using /favicon.ico, /manifest.json and better .css files just because of the "Edge Requests" metrics.

My entire account with this app uses:

• 360% of Edge requests
• 10% of Edge requests CPU duration
• 5% of Function Invocations
• 0.9% of Edge middleware infocations
• 0.00006% of Edge Function Execution Units
• 1.8% of Function Duration

After the change in the Pricing model, Edge requests metric blows our entire account budget.
Unfortunately, I can't even reduce the cost by Firewall, cause it won't reduce Edge Requests but can save other metrics like "CPU Duration" or "Function Invocations" which aren't a concern.

It feels like that Vercel makes CDN very expensive.

[Carduelis]

After spending some time of migrating from Preact to React and using app router from latest Next 14, the total amount requests went to 4.

1. HTML endpoint
2. Layout chunk
3. Page chunk
4. Main chunk

I do not know, is it possible to join the chunks even further. But joining them to beat the Edge Request metric will harm performance.
UPD. I'll citate @SamShakusky

Because this way we are optimizing not for users, but for Vercel, which is kind of unhealthy.

[SamShakusky]

I'm facing the same problem. My project, written in Gatsby, has exceeded the limits three times this month, as a result I will pay almost $50 more than usual.

I tried optimizing the number of requests and probably the biggest result came from disabling prefetch on links, as the documentation suggests. But to be true I find this advice rather harmful. Because this way we are optimizing not for users, but for Vercel, which is kind of unhealthy. After disabling prefetch, page transitions became noticeably less pleasant. And still the problem with requests didn't go away.

In my case, it all comes down to three things:

1. Gatsby is constantly requesting app-data.json and page-data.json to function properly. These are 1-2kb files, but the requests happen quite often.
2. I'm using code-splitting, which can cause quite a few chunks to be loaded on each page.
3. the site loads a service-worker using gatsby-plugin-offline, which uses a workbox under the hood and consists of 6 chunks, and which are loaded on every page.

There's not much I can do about the way Gatsby operates. And removing code-splitting is the antithesis of optimization in my opinion. Perhaps the point with the service-worker could be solved somehow (maybe by using workbox directly and configuring it more finely to load as one big chunk), but at the moment I don't see the need for that in terms of optimization for users, since those files are cached.

In the end, I decided that for my fairly simple static site it was easier and much cheaper to rent a vps and serve static using nginx, which is what I did. Vercel was a pleasure to work with, a lot of things were convenient out of the box, but unfortunately it's now too expensive for my project.

[IVEN21]

I’m dealing with 50 million edge requests, and the invoice is five times my previous billing. You're right, disabling prefetch isn't about optimizing the user experience; it’s about cutting costs. I really hope Vercel addresses this and finds a way to reduce the cost of edge requests.

[amyegan]

Hey! I wanted to share some tips that were posted elsewhere because I think they'll help you too.

• Look under top paths in the Usage page to see what's causing the most edge requests. That will give you info about where you can optimize usage or remove sources of edge requests.
• Move lower priority assets, such as some images, to blob storage
• In cases where one region or IP address is causing unexpected high user, you can restrict traffic to your site (and thus reduce usage) through the Vercel Firewall: https://vercel.com/docs/security/vercel-waf/custom-rules
• Disable Cloudflare Proxy
• If the project uses Middleware, make sure it has an appropriate matcher

There's some documentation that can help as well:

• Understanding Vercel resources
• Edge Requests

[IVEN21]

Many of these bullets point wouldn't apply. I'd tried optimizing images request, and disable auto prefetch, but the edge request still persist as high. Can we cut down the price for edge request?

[github-actions[bot]]

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