3 ms·

> 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. "Render

> 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 :)

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 :)