4 ms·

> For this, we created a small param cache=false. Whenever the url is hit with this URL, the node server makes and API call instead of fetching data from the re

> For this, we created a small param cache=false. Whenever the url is hit with this URL, the node server makes and API call instead of fetching data from the redis cache. And hence the cache is updated with the newer data. > Whenever you deploy, new chunk hash for js and css files gets generated. This means if you’re storing the whole HTML string in the cache, it’ll become invalid with the deployment. Hence, whenever you deploy, the redis db needs to be flushed completely. These arguments sound like over-engineered "solutions" by somebody who did not do their homework. To speed up your SSR, render components, not the _whole_ page. Vast majority of your page is going to remain constant: the head, navigation, footer. Rendering these components in partials will save you the Redis store by a very, _very_ large margin. Once they start caching hundreds of thousands of HTMLs, the Redis server will start swapping the content from memory to the disk. There, you just defied the whole point of using Redis. Also, your users are _still_ going to see the 810ms latency the first time they access your service. How often do you think they'll be reloading right after the page is loaded? And once the cache is invalidated -- which I suppose would happen frequently -- the _visible_ latency is still high.

ateevchopra 10y ago
> To speed up your SSR, render components, not the _whole_ page. That is totally wrong. Rendering components again and again is not performant at all. "Rendering components, storing them somewhere and finally when user requests, stitch them and give it to the user." Is that your solution ? That would be even more expensive than normal rendering. > your users are _still_ going to see the 810ms latency the first time they access your service That is not true too. Only one user will see the 810ms latency. All the users, when access this page, will get sub 20ms response time. Have you ever worked with servers/caching and know how they work ?
- prashnts 10y ago
  > "Rendering components, storing them somewhere and finally when user requests, stitch them and give it to the user." Is that your solution ? That would be even more expensive than normal rendering. String concatenation/substitution is more expensive than DOM parsing? > Only one user will see the 810ms latency. If your whole content is cacheable, then a CDN will be far more useful and have way less than 20ms response time. 20ms is not fast. Selectively invalidating CDN content as new data is available is much more performant. > Have you ever worked with servers/caching Yes. > know how they work Yes, still learning though.
  - ateevchopra 10y ago
    > String concatenation/substitution is more expensive than DOM parsing? Not 100% sure. Theoretically saying, if you have 100 components in your page, you'll be hitting the cache store 100 times for all components. That's not performant at all. > If your whole content is cacheable, then a CDN will be far more useful and have way less than 20ms response time. 20ms is not fast. Selectively invalidating CDN content as new data is available is much more performant. Yes. Thanks for the suggestion. We are experimenting with that :)

ateevchopra 10y ago

> To speed up your SSR, render components, not the _whole_ page. That is totally wrong. Rendering components again and again is not performant at all. "Rendering components, storing them somewhere and finally when user requests, stitch them and give it to the user." Is that your solution ? That would be even more expensive than normal rendering. > your users are _still_ going to see the 810ms latency the first time they access your service That is not true too. Only one user will see the 810ms latency. All the users, when access this page, will get sub 20ms response time. Have you ever worked with servers/caching and know how they work ?

prashnts 10y ago
> "Rendering components, storing them somewhere and finally when user requests, stitch them and give it to the user." Is that your solution ? That would be even more expensive than normal rendering. String concatenation/substitution is more expensive than DOM parsing? > Only one user will see the 810ms latency. If your whole content is cacheable, then a CDN will be far more useful and have way less than 20ms response time. 20ms is not fast. Selectively invalidating CDN content as new data is available is much more performant. > Have you ever worked with servers/caching Yes. > know how they work Yes, still learning though.
- ateevchopra 10y ago
  > String concatenation/substitution is more expensive than DOM parsing? Not 100% sure. Theoretically saying, if you have 100 components in your page, you'll be hitting the cache store 100 times for all components. That's not performant at all. > If your whole content is cacheable, then a CDN will be far more useful and have way less than 20ms response time. 20ms is not fast. Selectively invalidating CDN content as new data is available is much more performant. Yes. Thanks for the suggestion. We are experimenting with that :)