Hacker News new | ask | show | jobs
by scraplab 795 days ago
By using client side rendering you’re effectively playing SEO on hard mode. It’s all possible, but you’re making life very difficult for yourself.

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.

1 comments

"Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate."

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.

Generally very few people care, unless it’s "an impact metric" tied to that team. Or there is a "performance sprint" or something. "DX" has been more important than "UX" in the current mainstream JS community for a while. To give an example: babel, that enabled syntactic sugar, also caused many versions of runtime implementations of various ES6+ syntax to end up in bundles, or polyfills for browsers the clients aren’t actually using etc.

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-...

DX can't be at the cost of the user's priorities and needs.

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.

it’s not true. Many people are forced to use MS or Google products, people are using things for many reasons, like where their community is (Instagram, FB), or what they are forced to use by their employers. Or for example one tool has bad UX but is complaint in one way or another. It’s simply not the case that people "will go to where the best experience is".
> like where their community is (Instagram, FB)

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).

just check https://grumpy.website there’s lots of mainstream, popular apps/websites/tools that have plain broken UX and users have to work around that, but keep using them.
Cost is one of the most important criteria for end users; often much more important than speed. If something lowers the cost of development, that has a direct benefit to end users.
Do you mean… Server side is usually less work and less labour cost to develop.
I believe it’s not true as well, UI specialists aren’t often working with backend templates and backend release cycles, and backenders generally have bad UI skills.
Either way, more work to generate the same HTML/CSS in the end creates a longer experience, one that's too often more brittle in the long run.

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.

I think it's more about that SEO as less important for those people.