^^ have you been able to measure/quantify at all? Or just “felt” experience (which, to be clear, is as important). Just wondering out loud if we can start attempting to benchmark these things. Definitely agreed I often feel like cold boot can be slow on both Netlify and Vercel.
Of note → I think DB also plays a significant role. Might be worth testing to see if higher performance DB also seems to resolve issues around “cold start”.
Vercel update → it’s still being tested in development, but Vercel will soon be using a different tool at build time to package a Redwood projects’ API/functions. In tests so far there’s been a 60% reduction in total size of Graphql.js function This should have a positive effect on cold start time reduction.
Render → at one time I know @peterp had success with a self-hosting setup on Render. I’m also seeing https://fly.io/ come up in conversations but cannot confirm a successful Redwood use-case (just don’t know if anyone’s tried).
Just read this short thread and remembered many references to slow Redwood applications (mostly on Windows) - which led me to propose writing the document addressing Windows-specific issues encountered in developing the Redwood applications. As I am winding down the first draft of this document I want to propose my next writing adventure covering the performance analysis of Redwood applications. Interested in a) defining your wish list for items to be covered in that performance analysis, or b) being the co-author?
Note that I am still working on the profiling section, of my first document, where I want to show how to use VSCode in profiling a Redwood app. This brings another question for you: is there a well-known Redwood app from the Redwood cache of existing apps that you would like me to use in this profiling exercise?