3 ms·

> your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it What about cache? In th

> your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it 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?

pjmlp 8y ago
HTTPS everywhere kills caches, in the sense that only end devices can provide them, but other network nodes not. Check Eric Meyer's complaints.
- iaml 8y ago
  Does it also affect caching via service workers? Pretty standard practice in PWAs.
  - pjmlp 8y ago
    No, but it impacts the initial download as it needs to be end to end, instead of the closest access point. Also a very good way to waste traffic quota, e.g. a school network connection vs students computers.
    - pythonaut_16 8y ago
      Which interestingly is a problem IPFS would solve, right? But IPFS potentially introduces other drawbacks. 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)
  - judah 8y ago
    No, HTTP caching and PWA web worker caching works fine. (In fact, web workers require HTTPS to even function.) 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.
- iicc 8y ago
  >Eric Meyer's complaints https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites...
nathan_long 8y ago
> Is it reasonable to assume that for most subsequent loads the website would load in 0.2s? Wouldn't that number go back to 1.1s every time you deploy a JS change? And isn't it good to deploy often?
- paraditedc 8y ago
  With service worker, after you deploy the new changes, user will still load the cached version first, before downloading new version in the background. So the load time is still short.
- deleted 8y ago
  [deleted]

pjmlp 8y ago

HTTPS everywhere kills caches, in the sense that only end devices can provide them, but other network nodes not. Check Eric Meyer's complaints.

iaml 8y ago
Does it also affect caching via service workers? Pretty standard practice in PWAs.
- pjmlp 8y ago
  No, but it impacts the initial download as it needs to be end to end, instead of the closest access point. Also a very good way to waste traffic quota, e.g. a school network connection vs students computers.
  - pythonaut_16 8y ago
    Which interestingly is a problem IPFS would solve, right? But IPFS potentially introduces other drawbacks. 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)
- judah 8y ago
  No, HTTP caching and PWA web worker caching works fine. (In fact, web workers require HTTPS to even function.) 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.
iicc 8y ago
>Eric Meyer's complaints https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites...

nathan_long 8y ago

> Is it reasonable to assume that for most subsequent loads the website would load in 0.2s? Wouldn't that number go back to 1.1s every time you deploy a JS change? And isn't it good to deploy often?

paraditedc 8y ago
With service worker, after you deploy the new changes, user will still load the cached version first, before downloading new version in the background. So the load time is still short.
deleted 8y ago
[deleted]