first request each morning takes 1.1s and the rest 60ms, is that just cold start Cold Start

Normal, and there are usually two separate sleeping things rather than one. Measure before you touch anything:

const t0 = performance.now()
// ... your handler
res.headers.set('Server-Timing', `db;dur=${tDb}, handler;dur=${tAll}`)

plus a module-scope const boot = Date.now() you log once, so you can tell a cold instance from a warm one.

Then force a cold one and read the split:

• most of the second is before your code runs: that is runtime and bundle init, and the fix is a smaller server bundle or paying for a warm instance.
• most of it is the first database call: your database is probably scaling to zero and waking up, which on managed Postgres with auto-suspend is commonly 500ms to a second. Turning off auto-suspend or picking a plan that stays warm fixes that half.

Guessing between those two costs a weekend. Measuring costs ten minutes.

1.1s for a first request is unremarkable. I have seen worse from bigger teams. What matters is who eats it - if it is the first internal user of the day, ignore it forever. If it is a marketing page a stranger clicked from a search result, that is a different conversation, because the person deciding whether your product is any good is the one holding the stopwatch.

The "comes back after lunch" detail is the giveaway that something is idling out on a timer. Different systems in your stack have different timers - the function runtime, the database compute, sometimes a connection pooler - and they are usually in the 5 to 30 minute range. If you can vary the idle time (10 min, 20 min, 45 min) and watch which threshold makes it slow again, you can often identify the component without instrumenting anything.

Also check it is not a CDN cache expiry rather than compute at all. If your first request of the day is a cache miss on the HTML and every subsequent one is a hit, you will see exactly this pattern and nothing on the server side will look slow. The response headers will tell you - look for the cache status header your CDN sets.

Add the Server-Timing header anyway even if you do nothing else with it. Six months from now when something is slow for a reason you cannot guess, having the split already in the response is worth a lot.

For a first deployed project, honestly: write down the number, move on, and come back when a real user mentions it. There are almost certainly things on that project that would benefit more from a day of your attention than 1.1 seconds happening to you personally at 9am.