Manage GitHub pages usage limits

[ddbeck]

This came up in discussion with @atopal and @foolip.

The caniuse frontend requests web-features-signals.json to show a developer signals widget. On many page loads, users are requesting this data. This consumes the web-platform-dx organization's GitHub Pages usage quota:

• GitHub Pages sites have a soft bandwidth limit of 100 GB per month.

[…]

If your site exceeds these usage quotas, we may not be able to serve your site, or you may receive a polite email from GitHub Support suggesting strategies for reducing your site's impact on our servers, including putting a third-party content distribution network (CDN) in front of your site, making use of other GitHub features such as releases, or moving to a different hosting service that might better fit your needs.

I don't think we need to do anything about this today, but I thought it best to record these risks:

• Increasing requests of web-features-signals.json may exhaust the GitHub Pages usage quota.
• The developer-signals repo site shares its quota with other web-platform-dx.github.io sites, such as the web-features | Baseline site and the Web platform features explorer.
• If we exhaust our usage quota (for any of those sites), then it's possible that all of those sites will cease working at once.
• GitHub could change its usage quotas at any time.

If use in any of our resources increase dramatically, we ought to do something more active to manage these risks.

[rviscomi]

Maybe consumers like caniuse should switch over to the webstatus.dev API to get per-feature developer signals?

For example: https://api.webstatus.dev/v1/features/stretch

{
  "baseline": {
    "status": "limited"
  },
  "developer_signals": {
    "link": "https://github.com/web-platform-dx/developer-signals/issues/319",
    "upvotes": 2
  },
  //...
}

[ddbeck]

Oh cool! I didn't realize webstatus.dev was serving that too.

cc: @Fyrd — a possible alternative source for the caniuse frontend. I'll make a note to discuss this on our next call.