3 ms·
Since this conversation has 19 posts, I didn't notice the pagination. There's less than 20k of actual text with all 19 posts though (which is somewhat sad since
by js2 8y ago
Since this conversation has 19 posts, I didn't notice the pagination. There's less than 20k of actual text with all 19 posts though (which is somewhat sad since the full page source grabbed via curl is nearly 300k). If this 19 post conversation is typical, how much are you saving by using client-side rendering?
As well, how many conversations are more than 25 posts? Looking at your front page I only see one and it's just 26 posts (https://www.cake.co/conversations/x97rrxl/why-can-t-apple-make-great-laptops-anymore https://www.cake.co/conversations/x97rrxl/why-can-t-apple-ma...). Pulling it up, there's just not that much text there across all 26 parts (less than 30k of actual text).
I don't mean to be grumpy-old-man here, but it seems like you've added a bunch of complexity and broken ctrl-f for questionable gains.
- rgrove 8y agoI know it's not easy to see the justification when looking at the front page, especially since Cake is still pretty young, but we designed Cake to scale to conversations with thousands of posts in order to allow for the kinds of long-lived conversations that continue to attract a trickle of new posts for months or even years. Cake also uses client-side routing when JS is enabled. While the initial pageview might be on the large side since it contains all the data necessary to render the entire page (albeit gzipped for most clients, so typically much smaller than the uncompressed sizes you shared), subsequent pageviews will load a much smaller amount of data. We also use a few heuristics to avoid serving a server-rendered page if we know the client can render it more efficiently, which can further reduce the size of the initial pageview (pretty significantly actually). So you're pretty much measuring our worst case scenario. :)