4 ms·
With JavaScript disabled, you'll get a server-rendered page that renders up to 25 posts per page and relies on traditional prev/next pagination. When you scroll
by rgrove 8y ago
With JavaScript disabled, you'll get a server-rendered page that renders up to 25 posts per page and relies on traditional prev/next pagination. When you scroll to the bottom of the page you'll have to click "Next" to see the next page of posts.
With JavaScript enabled, you'll get a hybrid or client-rendered page that only renders the posts that are visible or likely to be visible soon. More posts will be loaded and rendered seamlessly as you scroll until you reach the end of the conversation.
The benefit of the JS approach is that we can load and render only the stuff you're likely to see, which keeps data usage down and performance up. This is especially nice on mobile devices and slow connections. We think the infinite pagination is also a nicer experience than manual pagination.
But we also want things to work when JS isn't available, primarily because that improves SEO. It's a nice bonus that the tiny percentage of people who prefer to browse with JS disabled can still read Cake.
- js2 8y agoSince 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. :)