I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible?
Google will crawl and render client side only sites, but the crawl budget will be reduced.
The bigger factor is that Google cares a lot about long clicks - clicks on results which don’t immediately produce another search or a return to the results page. Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate.
And now Web Vitals includes things like Largest Contentful Paint and Interaction to Next Paint, you’re going to find it much harder to bring these metrics under the target thresholds.
If you want to perform well in search, make things easy for yourself: use mostly SSR HTML and CSS and some sprinkles of JS on top.
I assume that people who create client side rendered sites disagree. Surely no one wants to make user performance worse, and I struggle to see advantages sufficient to offset that.
You can read more about the things that are absolutely mainstream and are problems in very popular libraries in the "Speeding Up JavaScript" series from Marvin Hagemeister – like this one https://marvinh.dev/blog/speeding-up-javascript-ecosystem-pa...
Also, most devs are testing on powerful devices, and there is a big disconnect between their experiences and that of their users – https://infrequently.org/2021/03/the-performance-inequality-...
Whatever is developed is for the user, not the developer.
If developers making their lives easier (or appearing to through more layers of abstraction in some cases) is more important than the user, the users will go where the best experience is.
Beyond things like developer products, End users overwhelmingly don't care what anything is coded in.
I loathe FB but use it for exactly that reason.
I even admin and moderate FB groups and it is a constant struggle against the system - but that is where the community is, I have no choice. Other admins do not like it either, but it is where all the related groups are, and people are nervous of relying on solutions from volunteers (e.g. me setting up an old fashioned forum).
Where SEO is involved, simplest wins. There's a reason why Wordpress focused on making words easy to publish, organize, and connect, and from there try to be a CMS.
To render something in the browser, you have to first send the browser javascript, which then needs to run. Server side rendering can usually be able to generate HTML faster than the javascript renderer can generate DOM. And the HTML itself is often smaller than the javascript needed to render the html. (And you can generate HTML from your server, not from your user's slow android phone via javascript).
Server side rendering almost always gets you a faster time-to-first-paint. Which is good for blogs and news websites. But if you need client side rendering anyway (eg you're writing Figma), then its not as big a deal.
Server side caching is pretty good these days and a valid option in more cases.
A lot of devs just started client side and the other side naturally seems bad or unknown. The time where this was an issue server side was when linux didn't network or perform so well with lots of traffic (and the cloud became popular). That's been largely solved.
I wonder how Reddit gets indexed given its client-side rendering is painfully slow.
Server side is generally lower cpu hit for content that is more SEO specific.
I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.
That's really a tough one to answer since every site is different, but here's a few things to keep an eye on when doing CSR.
You don't own the hardware rendering your site. Slow devices will render pages more slowly and there's really nothing you can do about it beyond optimizing the rendering logic itself.
CSR will always add more network requests to the page. For a small site, or a user close to your servers this may not be an issue. Caching on CDNs will help for any static files too.
Any API requests that are required for rendering will likely introduce waterfall network requests. If the APIs live on your servers, that could have been drastically reduced or removed all together if the HTML rendering was handled by server in the first place.
For accessibility, I'm not aware of anything that can't be done accessibly with CSR, but there are things that can get tricky. Every accessibility tool is different. Making sure that content added and removed is updated properly, changes are notified to users when necessary, and that focus is handled properly are all up to you when you decide not to "use the platform" as they say.
It's hard to find concrete evidence for anything in SEO. However, from what I've seen (and is also shown by some big websites that index just fine) at least Google seems to do handle client side rendering just fine and has been doing so for ~5+ years.
The only thing you might get pinged on is if you have crappy core web vitals scores as a result of the client side rendering.
There is, in the sense that every site gets a CPU budget allocated for indexing. SSR means less of that budget gets used per page.
Is there some concept of a budget regarding how many pages they should index on your website? Yes. Is it the same thing as CPU budget, no. Does it impact what position you rank in absolutely not.
The vitals bvetween the average client side compared to the average server side can be staggering.
For example, if you take a website that is using client side, on a headless cms or something vs Wordpress, wordpress has many, many plugins that obsess on optimizing the assets and delivery of the file beyond most client side implementations.
I love building myself a client side site, it feel so fast, until the need to communicate better or at scale increases and it is a reminder why the website should just be something that is good at being a website.
Server side has many advantages.
If the key is delivering SEO information, client side dynamic UX might not be the core of that experience, and may not be the best application for that part of it.
Google's? A bunch of random ass metrics.
Facebook's? Well, I guess you're making a Business Page.
Apple's? The list is so long.
JavaScript frameworks masquerade as SDKs and whatever, when really something like Next.js is a middleware with the same eventual product development complexity as Unity. Web developers think they have 2 browsers (Mobile Safari and Chrome). It's really like 10+ game consoles: Meta Instagram, Meta Facebook, Meta WhatsApp, TikTok iOS, TikTok Android US, TikTok Android Worldwide, Google Search destination, App Store iPhone, App Store iPad...