It can even output static, precompiled, pages with the adapter-static so no heavy backend processing involved and response times are best-in-class: https://github.com/sveltejs/kit/tree/master/packages/adapter...
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.
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
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).
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'll keep on sticking with Python!
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)
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.
https://betterprogramming.pub/creating-a-web-performance-cul...
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.
It's not the same because on the server you usually have some form of caching, and the V8 engine will have already JIT'd that code as well.
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.
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.
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.
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)
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.
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.
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.
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.
So, y’know, maybe a slightly different ballgame.
Agreed that in the general case 100ms to full paint (with interactivity not far behind) is really good.
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.
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)