无服务器Lambda响应时间Postman vs Deployed App

这更多是基础架构问题。我正在为自己开发一个新的无服务器项目，我对响应时间有疑问。

Architecture: 
Frontend: S3 + CloudFront - React App
Backend: API Gateway + Lambda (Node.js) + DynamoDB

我使用lambda函数进行了测试路由，该函数使用API Gateway + Lambda返回简单的响应。

当用邮递员打电话时，我对冷启动有很长的响应，但是之后我得到80-120毫秒的响应时间，我想这是可以接受的。

但是我正在通过我的实际PC和网络与Postman通话。

一旦我将实际的前端应用程序部署到后端所处的同一区域中的S3 + Cloudfront中，这些响应时间会变好吗-因为一切都在AWS的基础架构中，这是AWS网络在幕后进行的调用从React到Lambda函数？

还是使用该应用的用户在每次通话中仍会收到120毫秒以上的响应时间？

谢谢。

一旦我部署了实际的响应时间，这些响应时间会更好吗？在与后端相同的区域中将前端应用程序迁移到S3 + Cloudfront 驻留-既然一切都在AWS的基础架构中，幕后在AWS网络中拨打电话吗？

您的React应用程序将仅存储在AWS资源上。 S3 + CloudFront会将React应用程序的文件提供给访问者的Web浏览器。 React应用程序实际上在用户的Web浏览器中运行。您的React代码实际上都没有在AWS中“运行”。

所以，不会，响应时间不会更好。

有趣的是，我在AWS中实际执行的lambda执行很小。

以60毫秒为单位。

那么我得到的其他60-80ms是由于从我的地理位置到实际的lambda往返的网络流量？

所以我所有的用户都会收到此附加的ms响应，因为我们在地理位置上离AWS lambda有点远？

有没有解决的办法？还是以某种方式对其进行优化？