What about cache? In that 1.1s figure, 0.9s are for the download of react.
Is it reasonable to assume that for most subsequent loads the website would load in 0.2s?
Check Eric Meyer's complaints.
Also a very good way to waste traffic quota, e.g. a school network connection vs students computers.
It would be cool to able to build dual-distribution applications, where publicly available assets and content blobs (e.g. app.js) could be distributed in an immutable, cache-able manner, and server interactions and private assets could still be handled in a more traditional client/server way.
Perhaps then we might even be able to realize the original intent of including dependencies from a CDN, being able to share a cached version of React across websites.
(I'm not and IPFS advocate or detractor)
Eric Meyer's "HTTPS busts caching" complaint refers not to HTTP or web worker caching, but man-in-the-middle local servers caching responses. It sits between the internet and your local box, and serves cached requests. This breaks with HTTPS, which is designed to break man-in-the-middle attacks.
https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites...
Wouldn't that number go back to 1.1s every time you deploy a JS change? And isn't it good to deploy often?
So the load time is still short.