> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML.
server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS.
there are also many frameworks faster than React (Solid, Marko, etc)
To add to the list: Svelte is also faster and lighter for most cases. And with SvelteKit the server sends only the bare minimum JS to make the page dynamic while being SEO friendly depending on the adapter of choice.
The cost of server-side rendering feels pretty trivial to me these days.
Fly.io will sell you a 256MB of RAM container for $1.94/month, which is perfectly capable of server-side rendering dozens (maybe even hundreds if you write efficient code) of requests per second.
I'm sure you can get even better deals if you shop around.
Is that kind of a container less capable than just about any client (except embedded of course)? Sorry if it's a stupid question. I'm not familiar with web SSR.
Yes, and if you've got a fairly complex website it's unlikely it could render more than a couple dozen rendered requests per second. If you're not rendering and instead getting them from a cache, that would be different of course.
The question makes no sense and your answer is wildly misleading and inaccurate.
A server is not 'rendering' a website the same way a client does.
A couple of dozen requests a second? In drupal in dev mode maybe but even then... I feel like we need to have a bit of a knowledge reset before spouting supposed info about csr v ssr
> A server is not 'rendering' a website the same way a client does.
While this is technically true, there is still "rendering" happening on the server when you JIT-compile JSX/TSX templates and transpile everything from your ES6 modules and includes to HTML/CSS/JS that a browser can parse.
In a sense you're splitting the load between client and server because you're right some stuff always has to run client side (like the actual layout engine work).
Very much depends on the code you are running. If you're running something like React server-side rendering it may not be enough resources - in which case you'll probably want an instance that costs $10-$50/month instead.
Most server-side frameworks I've worked with will perform just fine in 256MB of RAM though. These days I'd expect people to get the best results from Go or Rust, if they want to be able to run on as little RAM or CPU as possible.
I know not the same use case, but nginx will serve near 100K requests per second of a static site on a moderately powerful server. Server side generated SPA empowered by K8 solution drops that to a dozen. Those number discrepancies are comical.
I must be too old to enjoy recent resume building architectures....
they just use docker api, hence why I don't think there is the resource waste typical of k8s
I haven't run benchmarks but speed wise containers shouldn't slow down app requests (except in a few cases with very specific kernels, which I unfortunately experienced in production - but I was told it was just bugs)
fly.io is simply a VM provider. You can achieve the same requests per second there as any VM host. The person you're replying to just has a comically low expectation of performance.
This was my thought, too. In reality, client side rendering today is “cheap” because you typically put a CDN in front of your application to serve static resources and scripts, and your backend only serves the API requests (if needed). Rendering everything on the backend means by contrast that you’re limited to the capacity of your server and the latency based on where it’s located.
Counter-point to this is that edge computing addresses the latency for compute in the same way that a CDN does for static assets.
SSR definitely has drawbacks in the old "run your app from a single VPS somewhere" model, but in a globally distributed edge computing model, you remove a lot (but not all) of those drawbacks.
modern JS runtimes are extremely fast on all hardware that's not a 2000-era phone or an embedded micro-controller with 4MB ram. if your CSR is slow on a modern client, then that same JS code will bring your server to its knees when you simply migrate it to an equivalent V8-powered JS backend. scaling the server will not solve this; you just have to write fast JS code and pay attention when you write it, not merely optimize as an afterthought. test on crappy hardware, test with huge datasets, test on slow connections, test with asset caching disabled, target 60fps+.
The other is that those API requests need to be rendered with JS which means downloading the JS upfront + rendering time. JS rendering will always be slower than pure HTML rendering.
I will agree for small apps this is negligible, but for bigger apps this means downloading, parsing, and executing MBs of JS. See the Google Cloud console for example or the Spotify web app.
And yet there is another point which is that with SPAs, ignorant developers can cause more "damage". The other day I opened a simple password recovery form, and it rendered dozens and dozens of divs and downloaded (I shit you not) 2MBs of JS.
Also it's not like CSR is mostly used just to render out a flat document. It's used mainly for interactive stuff, often just banging internal client side state and not even talking to an API. And even when the client is talking to an API to update a small part of the document, this is more straight forward, than having a full client-server round trip, just for updating that small part.
Nowadays i prefer static site generation and if interactivity is needed, additional client hydration.
The only scenario, which i can think of, which does not match this model are highly frequently updated dynamic content sites. Am i wrong?
Even for moderately frequently updated dynamic content sites, statically rendering say 10 times a day might suffice. When the hydration kicks in, you can always fetch the info, which changed between the 10x/day updates and still have a low time to interactive.
SSR with caching maybe comparable in terms of time to interactive, but does feel less elegant imo.
> server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
Considering mobile, embedded or even considering that my grandmother still owns a i3 4th gen, maybe would be better SSR, but for modern machines i'm not in for SSR, still feels a little bit clunky to me.
> for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS.
Yes, cache here helps alot, but saving mobile data still be pretty good, considering some SPAs doesn't chunk it's script files very well.
> server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
Expensive not in money terms, but in user experience.
Also: if you are doing e-commerce, 100ms added latency can cost you 7-8% in conversions. Spending 5% more on hosting to do SSR just makes economic sense.
> 100ms added latency can cost you 7-8% in conversions
i hear this metric (or something equally absurd) cited frequently and have never seen it to be true in my own experience.
i guess if you have to load a product page with 100 images (or assets) and each has 100ms network latency, then it will add up to much more than that. but 100ms for a single interaction or network request (e.g. process payment POST) is not going to move the needle on conversions. 100ms will feel instantaneous to 97% of users, and more than satisfactory for the remaining 3%.
(i say this as someone who profiles aggressively and strives to optimize every stray 5ms in JS and every 1kb over the wire)
I did a study on this (N>100m) at a previous employer who had quite a lot of e-commerce traffic.
It's sort of true but also a massive over simplification. The relationship between conversion and speed is not linear. Some people are beyond help, and others already have it so good they only notice the most extreme degradation in performance.
It's also hard to isolate confounding factors like users who have fast infrastructure tend to be rich and rich people buy more stuff. Making pages load faster doesn't give them more money to buy stuff.
Overall faster is definitely better but the specific magnitude will depend on your customer demographics. In our case the Amazon 100ms saved = 1% more sales was close enough for a rule of thumb.
I could see the 100ms/7% impact coming into play for a super impulsive shopper going from page to page compulsively until they pull the trigger on a product. I wouldn't be surprised if that was a lot of Amazon's business—people buying things they had not set out to buy.
Makes less sense the smaller an e-shop gets since the consumer already needed intent to shop there. If I know I already want product X on Shop Y today, 10 second load times are rather inconsequential.
I've been thinking about that a lot lately. I have a medium-sized e-commerce. We sell hyper-customized products and, to be honest, the site's overall performance is not good. But when I looked into other stores in the same niche as ours, who are making a lot more money than us, I saw that their performance wasn't better than ours. I don't think people shop impulsively in our store because they have to customize the product and then make sure the customization is correct (it's a pretty complex customization). I believe that because the journey to checkout is so long and requires so much attention, the customers just don't give up due to high latency or slow responsiveness overall.
I've worked in e-commerce for a while and have heard similar stated from time to time and seemed like someone was trying to fit a linear line over what's almost certainly an s-curve distribution.
At lower latencies no one is going to leave your site because it takes 1200ms instead of 1000ms to fully load a page. But at some point almost everyone is going to leave your site rather than wait.
I also find these stats really confusing because whenever someone talks to me about site performance they're always talking about a different metric (server response time, first paint, time to interactive, etc). If you're first paint is quick then users aren't going to care if content half way off the page doesn't load instantly.
I've always tried to focus on how fast things feel rather than worrying too much about specific metrics. If you can just get something (ideally the important bit(s)) to load really fast a site can feel extremely fast even if it's mostly just an illusion. Users like to click things and see stuff happening. It's things like reloading the page when adding items to cart then making them wait on a white screen for multiple that increases bounce times as abandoned carts in my experience. Making add to cart buttons an ajax request probably helps far more than making the page load 200ms faster.
I guess that's not really performance, but I agree that UX is one of those things that can subtlety annoy someone enough that they'll just give up and go elsewhere. That's a pretty extreme example, but even simple things like asking the user for too much information over too many pages at checkout can dramatically increase bounce rate. If a user can't land on your site, find what they're looking for then checkout within a few minutes, something is wrong.
On payment failures, an interesting solution an ecommerce I used to work for came up with was just to place the order on payment failure. They figured it was better just to send out an email after the fact asking them to try again and if that failed they could call and take the payment over the phone if need be. We targeted an older demographic and sold fairly pricey products though. I guess that model wouldn't work so well if you're selling $10 tshirts. I believe Amazon does something similar. I know they've sent me emails in the past letting me know my payment failed after placing an order.
Google did a large study. If your page load is 5s then adding 100ms does not matter. I got the raw data from them and it mattered in the curve closing in on the whole page taking 200ms or so. It’s level, and then around 2.5s, each 100ms made more and more of a difference.
Yeah I think the main thing for a website to hold on to users it should at least be interactive and responsive quickly (with clear loading indicators) even if it is taking a while to load everything on the page. If a page looks like it is stuck or feels like it is stuck then I am likely to abandon it. But if it has clear indicators and animations to indicate something is happening, I will be more patient with it.
I think if frame it as, “each 100ms you shave off a critical consumer shopping checkout flow page increases conversions by X%” it starts to seem more defensible.
Agreed that in the general case 100ms to full paint (with interactivity not far behind) is really good.
Doesn't really matter if the relationship isn't linear like that. I suspect it's more likely conversions start to drop off after certain thresholds are met e.g. 3 seconds causes conversions to drop by 5%, 20 seconds causes them to drop by 30%.
Just averaging out those numbers could result in engineering time being wasted chasing rapidly diminishing returns, if the site is already below one of those thresholds.
It seems like an inference from correlation that someone extrapolated out in a linear fashion.
In isolation, I don't think that 100ms in delay before paint really causes enough impatience in people that you'd lose 7-8% as a direct result. Humans don't really make that kind of decision within such a minuscule window of time; to a degree, we expect our devices to have delays.
More likely, that loss of conversion is correlated because sites that have longer than 100ms latency have latency that's extreme enough to reach the "I give up" threshold. A site where its pages take 3 or more seconds to load would see a big difference, but that doesn't mean that a site with exactly 100ms latency will see any meaningful loss of conversions outside a margin of error.
People will also be much more patient with a high-value site. For instance, I'm willing to wait a few seconds for each page to load on the McMaster-Carr website because it's an otherwise good experience and a high-value store. But I'm far less willing to tolerate delays on some horseshit Shopify page plastered with ads and reselling crap from Alibaba. And if you've got a blog that's poorly formatted and overall signals low value content, I'll dip out the moment I detect the slightest monkey business slowing things down.
server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS.
there are also many frameworks faster than React (Solid, Marko, etc)