Bandwidth : how does that work?

Ask us anything How do I?
1

Hello,

I’ve just published my app. I’ve the 20$ plan that includes 10 gb of bandwidth.

I had about 1000 connections which consumed 2.1 gb.

So my question is : how does consumption work exactly? What can I do to optimize consumption?

Thanks

2

Is your app a media-heavy platform with a lot of images and videos?

3

No, 0 images or videos. Where can I monitor each page consumption per session of user? Maybe it could be API calls which load data ?

4

You can see the overall bandwidth in the app settings, but the bandwidth per user session wouldn’t be visible. You’d need to create your own way to track it.

Yes, API calls do take up bandwidth. What’s your backend?

5

I use Xano.

How do I know per page the bandwidth consumption? I can’t find it in the app settings.

Thanks

6

@Joyce would you by any chance know?

Thanks

7

Hi @MrUnfreeze! With no images or videos, your bandwidth is going to three places:

  1. The WeWeb app bundle itself - the JS, CSS, and fonts that make up your app. On first visit, every user downloads this. Depending on how many components/plugins you use, this is typically 1–3 MB per fresh visit. If you had 1000 sessions and many were first-time visitors (or returning users with cleared caches), that alone could account for most of your 2.1 GB.

  2. Xano API responses - every workflow call returns JSON, and JSON adds up fast if you’re returning whole records when you only need a few fields, or fetching long lists without pagination.

  3. Other assets - custom fonts, icons, any files served from your domain.

A few things worth checking:

  • Audit your Xano endpoints. Open the browser DevTools → Network tab → filter to “Fetch/XHR”, then click through your app like a normal user. You’ll see every API call and its exact size. Look for responses that are bigger than they need to be - usually it’s an endpoint returning 50 fields when the page only displays 5, or a list query returning all records instead of paginating.

  • Trim your Xano response shapes. In the Xano function stack, use the Output tab to return only the fields the page actually needs.

  • Paginate long lists. If a collection list shows 20 items at a time, your endpoint should return 20, not all 500.

  • Avoid polling and aggressive on page load refetches. If two collections refetch on every page mount, navigating around the app multiplies bandwidth quickly.

  • Reuse collections across pages. A collection fetched once at app level doesn’t need to be re-fetched on every page that uses it.

  • Check for accidental loops. A workflow that triggers a refetch which triggers another workflow can quietly burn bandwidth.

8

How does anything in the Network tab (unless routed through WeWeb’s servers) have to do with WeWeb’s bandwidth? Client-side requests are .. client-side – unless I’m missing something.

So it would make sense for Xano usage/bandwidth/rate limits, but it should not normally count as WeWeb-hosted bandwidth unless WeWeb is proxying the request or serving/caching the response through its infrastructure.

It’s hard to believe “they add up” if WeWeb mostly calls them client-side.

9

CDN traffic is part of “Bandwidth”