Deploy Next.js to the edge

[bates64]

We currently have a response time issue for users not located in Europe, as the server is in Finland. In particular:

• GitHub action runners report a 815ms average response time for GET /
• A vast majority of our users are in the USA, which is far from Finland
  • Presumably their initial latency is large - we can't tell, because we don't track real-user site speed data!
  • I would like to track this data in the future, specifically, web-vitals stats. Would need an update to the privacy policy but its just anonymous timings, nothing anyone would object to I expect.

I think the best solution here would be to change where we host the Next.js server. We can use edge networks to reduce the distance. This shifts the initial effort of connecting to critter from the user to servers that we control. Additionally, if we liberally cache rendered pages (ISR), we don't need to talk to critter as often and can reply with a cached version of the page instantly. It also will reduce memory, storage, and CPU load on critter.

I think we should:

• [ ] Move the API to a subdomain (and preconnect to it with a meta tag)
• [ ] Move the Next.js server from critter to Vercel's edge network (pricing: free for up to 1 TB bandwidth)
• [ ] Vercel automatically deploy a branch, so we would need a release branch that is ffwd'd to whatever version critter is running during deploy. Alternatively it might support webhooks to trigger a build

I'm suggesting Vercel's edge network here because its one I have the most experience with and haven't met any issues so far with other projects. Vercel also make Next.js, so they work very well together. Happy to look into doing something else. It's also worth bearing in mind that these changes are purely deployment changes, and if the hosting provider dies or becomes unsavory for any reason we can just go back to the single server we have right now.

[ethteck]

from discord:

I think at the end of the day, I like owning every aspect of the thing I make that I am able to own. and so giving some of it to someone else is just not really my desire. but yeah I can't think of any great arguments off the top to counter doing this, other than it's added complexity to the site design and I don't wanna do it but I am willing to try it I would just ask that we do it after the page optimization stuff (#608) first and then evaluate performance.

and then we try vercel hosting and we measure the performance impact of that. if that piece itself doesn't make a noticeable difference in performance, I would prefer we move off of it

[bates64]

https://vercel.com/guides/can-vercel-sponsor-my-open-source-project#sponsorship-criteria