So this is not a real issue but just an idea.
I see that today, loading badgen.net takes 144 KB of bandwidth, and it will become bigger every time new badges are added.

As you said on your comment, the bandwidth usage is already pretty high, and I guess the index page is a big part of it.
Also, the response time on uptime robot is now > 500ms, which is a lot more than a few weeks ago.
Maybe you could use the free plan of Cloudflare to cache live badges for a few minutes, and static badges for a whole week!
Docs and index could also be cached for a few minutes
It could even prevent occasional downtime
I assume the total bandwidth usage (in Zeit's dashboard) is already include cached responses.
Currently live badge are cached 3~4 minutes, static badge are cached 1 year, docs pages are cached 1 day, by Now CDN (Cloudflare). Plus 60 seconds cache on user's browser.
Here's scale rules for badgen.net, I never saw it spin up a second instance in sfo1 or bru1, so the server load should be fine (by now):
dc min max current
sfo1 1 2 1
bru1 1 2 1
Events
2018-08-13T15:01:12.811Z state INITIALIZING
2018-08-13T15:01:14.193Z build-start
2018-08-13T15:01:31.432Z build-complete
2018-08-13T15:01:31.490Z state READY
2018-08-13T15:01:33.000Z instance-start (sfo1)
2018-08-13T15:02:14.000Z instance-start (bru1)
2018-08-13T15:02:17.074Z scale-set
2018-08-13T15:02:41.688Z scale-set
2018-08-13T15:02:51.368Z scale-set
2018-08-13T15:02:59.716Z scale-set
But I'm not sure why response time rise from ~300ms to ~500ms recently 馃
Changed the response badge to /npm/v/ava, formerly it's response time from home page.
BTW, saw a traffic spike yesterday :D
dc min max current
sfo1 1 3 1
bru1 1 3 1
Events
2018-08-22T14:24:37.763Z state INITIALIZING
2018-08-22T14:24:39.794Z build-start
2018-08-22T14:25:10.403Z build-complete
2018-08-22T14:25:10.463Z state READY
2018-08-22T14:25:12.000Z instance-start (sfo1)
2018-08-22T14:25:52.262Z scale-set
2018-08-22T14:25:54.000Z instance-start (bru1)
2018-08-22T14:26:23.066Z scale-set
2018-08-22T14:26:28.493Z scale-set
2018-08-22T14:26:34.937Z scale-set
2018-08-23T05:29:52.000Z instance-start (sfo1)
2018-08-23T09:12:31.000Z instance-stop (sfo1)
So, the cache you're talking about is browser cache, meaning I won't call the API multiple times if I reload the index page again and again.
However, if 100 different people visit badgen.net in a short time interval, you will consume 100 * 144kB = 14Mb of bandwidth!
That's where a cloudflare layer could be useful: it would remember the badges responses and serve them again until the cache expires, without even calling the badgen API
Currently live badge are cached 3~4 minutes, static badge are cached 1 year, docs pages are cached 1 day, by Now CDN (Cloudflare)
These are CDN cache by cloudflare. Cache status can be verified by:
curl 'https://badgen.net/npm/v/next' -sI | grep 'cf-cache-status'
# > cf-cache-status: HIT
Maybe you could use the free plan of Cloudflare to cache live badges for a few minutes, and static badges for a whole week!
You can't. Badge service is a tricky thing. Users are constantly updating things, so you can't just say "cache everything for few days or weeks".
And with "tricky" i mean, that it should be fresh and not cached, by design. Yea, some small & smart caches is okey, but not aggressive caching.
As about the home page.. I would answer "And what?". It's preview and that's normal, users are not using the home page, but few badges at their readmes.
But yea, there is a way to decrease the stats for the homepage. Show only Usage & Example's Static sections, but not the Live badges section. And provide search. But still, that's not cool thing, because forces interested people to do more (e.g. type in a search field) - it's just not cool and it's not beautiful.
All right, I didn't realize Now CDN was using Cloudflare ! That's great!
They don't tell if your bandwidth quota is consumed though, but I hope the answer is no..
@olstenlarck The live badges in the home page are _just examples_, they don't need to be exact all the time! I don't know how, but badges could have a longer cache time when seen from the homepage...
I'm just throwing ideas here, cause I think that homepage is using a huge part of your server's ressources, but again, they're juste ideas, I don't have real solutions right now
Now CDN is really a helpful & important cache layer for Badgen Service, glad we have it since the beginning. 馃挭
Most helpful comment
I assume the total bandwidth usage (in Zeit's dashboard) is already include cached responses.
Currently live badge are cached 3~4 minutes, static badge are cached 1 year, docs pages are cached 1 day, by Now CDN (Cloudflare). Plus 60 seconds cache on user's browser.
Here's scale rules for badgen.net, I never saw it spin up a second instance in sfo1 or bru1, so the server load should be fine (by now):
But I'm not sure why response time rise from ~300ms to ~500ms recently 馃