God no. The last time I checked, Firebase functions had intensively bad latency times for me. So bad that I decided to learn AWS Lambdas to get my work done. And yes, Lambda just blew Firebase and GCP functions out of the water.
The biggest innovations lately has been our release of v2. V2 is built on Run and can support concurrent executions in the same container. This dramatically reduces the number of cold starts, and makes min instances reservations even cheaper if you want to eliminate cold starts for a given workload. Plus, Firebase lets you configure CPU separately from memory in V2, so you can give functions extra oomph if they need it. Docs are at [1]
Finally, Firestore’s SDK was slower than we liked in GCF so we’ve done a number of improvements there. About half a year ago we redesigned the SDK so we could lazy load the networking layer. This lets you handle Firestore events without loading the bulk of the SDK. We have a more extreme update in the works that will let you configure the Firestore SDK to prefer REST over gRPC so you can avoid heavy dependencies in latency sensitive/event driven environments like GCF.
1. If cold start times are a big deal, you can now set a minimum number of instances with Cloud Functions so they don't scale to 0. You can also now set concurrency on Cloud Functions so one function can run multiple requests simultaneously on a single function.
2. There are tons of other serverless options if you want to, say, have a Firebase front end but a backend API served in your language of choice that uses the Firebase Admin API to do whatever you want, e.g. App Engine or Cloud Run.
You can set that, but the setting gets ignored and latency is still abysmal. That was literally the reason we moved our backend to Cloud Run.
Was this cold start latency specifically or request latency in general? Do you know what region you were deployed in?