6 ms·

Does server side rendering still have better SEO than client side? I thought that was no longer the case, it's hard to find concrete evidence though. I'm also

by burcs 2y ago

Does server side rendering still have better SEO than client side? I thought that was no longer the case, it's hard to find concrete evidence though. I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible?

josephg 2y ago
> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? 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.
- j45 2y ago
  Sending everything to the browser to crunch is a lot of downloading, and then available at the speed/mercy of the client computer, relative to the resources they have, and what they have acvailable (relative to other tabs). 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.
hobofan 2y ago
> it's hard to find concrete evidence though 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.
- gildas 2y ago
  For my part, I've had exactly the opposite experience. Without SSR or equivalent, you often have to wait weeks for your content to be indexed on Google, and the quality of the results varies. I'm talking about sites of at least several hundred/thousand pages.
  - j45 2y ago
    Same. Lots of concrete info out there the more time one spends in SEO openly seeing how non-tech people achieve SEO, and most of the time (not surprisingly) Wordpress is server side.
mdhb 2y ago
Google have run headless chromium for many years now, there are no extra bonus points for serving straight HTML to them. 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.
- gitgud 2y ago
  How does google decide to use the headless chromium? If there’s no metadata in the raw HTML?
- afavour 2y ago
  > there are no extra bonus points for serving straight HTML to them. 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.
  - mdhb 2y ago
    I don’t think this CPU budget actually exists… it’s certainly never been publicly mentioned as far as I can tell. I think it’s another one of those half truths floating around the SEO world. 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.
- j45 2y ago
  Most websites, especially templates are extremely heavy in their assets for first time load. 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.
adamddev1 2y ago
I've also wondered this. I have single page client-rendered web apps that get crawled and indexed by Google just fine. The only problem I've run into is when sharing a link on something like WhatsApp, their crawlers don't get the OpenGraph metadata that gets rendered based on the page/link, so the share preview isn't as nice.
danpalmer 2y ago
As others have mentioned, Google does client side rendering. What I was told by SEO people in my previous role (unverified otherwise) is that there's essentially a CPU budget per site, and while you can client-side render, it takes more of that CPU budget. For a small site this may be fine, for a large site with many pages it may prevent frequent re-crawls of the site. That said, I gather the budget is not the same for all sites, but varies by other factors. As I said, unverified, but it makes sense and seems like a good way to do it.
- PlutoIsAPlanet 2y ago
  > while you can client-side render, it takes more of that CPU budget I wonder how Reddit gets indexed given its client-side rendering is painfully slow.
  - buremba 2y ago
    I believe Google can override its CPU budget manually though.
    - j45 2y ago
      I would suspect there aren't an excess of people at Google to manually override.
  - h1fra 2y ago
    CPU Budget (and page budget) is dependent on website popularity. You can see it clearly when you start a new website, google will index 10 pages at most, and as your website grow in popularity it allows 100->1000->10K etc...
- j45 2y ago
  The CPU budget, for sure, is used in google's ranking of websites because they know how long it will take a site to load, and that is a way to test the speed of a site. Server side is generally lower cpu hit for content that is more SEO specific.
63stack 2y ago
Only tangentially related, but I wonder if "indexability" is even relevant anymore. Google is getting close to useless for searching, and I would bet that all of the big tech companies are racing to write better crawlers to make sure they can suck up all the sweet free content for their next AI model, the incentive for making your site crawlable is inverted in an ironic way. I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.
scraplab 2y 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.
- graemep 2y ago
  "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.
  - gryzzly 2y ago
    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-part-6/ 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-gap/ https://infrequently.org/2021/03/the-performance-inequality-...
_heimdall 2y ago
> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? 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.
j45 2y ago
Client side rendering is harder for SEO than server side. 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.
doctorpangloss 2y ago
If you wanna play in someone's network you gotta follow their arbitrary rules. 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...

by burcs 2y ago

josephg 2y ago

> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? 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.

j45 2y ago
Sending everything to the browser to crunch is a lot of downloading, and then available at the speed/mercy of the client computer, relative to the resources they have, and what they have acvailable (relative to other tabs). 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.

hobofan 2y ago

> it's hard to find concrete evidence though 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.

gildas 2y ago
For my part, I've had exactly the opposite experience. Without SSR or equivalent, you often have to wait weeks for your content to be indexed on Google, and the quality of the results varies. I'm talking about sites of at least several hundred/thousand pages.
- j45 2y ago
  Same. Lots of concrete info out there the more time one spends in SEO openly seeing how non-tech people achieve SEO, and most of the time (not surprisingly) Wordpress is server side.

mdhb 2y ago

Google have run headless chromium for many years now, there are no extra bonus points for serving straight HTML to them. 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.

gitgud 2y ago
How does google decide to use the headless chromium? If there’s no metadata in the raw HTML?
afavour 2y ago
> there are no extra bonus points for serving straight HTML to them. 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.
- mdhb 2y ago
  I don’t think this CPU budget actually exists… it’s certainly never been publicly mentioned as far as I can tell. I think it’s another one of those half truths floating around the SEO world. 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.
j45 2y ago
Most websites, especially templates are extremely heavy in their assets for first time load. 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.

adamddev1 2y ago

I've also wondered this. I have single page client-rendered web apps that get crawled and indexed by Google just fine. The only problem I've run into is when sharing a link on something like WhatsApp, their crawlers don't get the OpenGraph metadata that gets rendered based on the page/link, so the share preview isn't as nice.

danpalmer 2y ago

As others have mentioned, Google does client side rendering. What I was told by SEO people in my previous role (unverified otherwise) is that there's essentially a CPU budget per site, and while you can client-side render, it takes more of that CPU budget. For a small site this may be fine, for a large site with many pages it may prevent frequent re-crawls of the site. That said, I gather the budget is not the same for all sites, but varies by other factors. As I said, unverified, but it makes sense and seems like a good way to do it.

PlutoIsAPlanet 2y ago
> while you can client-side render, it takes more of that CPU budget I wonder how Reddit gets indexed given its client-side rendering is painfully slow.
- buremba 2y ago
  I believe Google can override its CPU budget manually though.
  - j45 2y ago
    I would suspect there aren't an excess of people at Google to manually override.
- h1fra 2y ago
  CPU Budget (and page budget) is dependent on website popularity. You can see it clearly when you start a new website, google will index 10 pages at most, and as your website grow in popularity it allows 100->1000->10K etc...
j45 2y ago
The CPU budget, for sure, is used in google's ranking of websites because they know how long it will take a site to load, and that is a way to test the speed of a site. Server side is generally lower cpu hit for content that is more SEO specific.

63stack 2y ago

Only tangentially related, but I wonder if "indexability" is even relevant anymore. Google is getting close to useless for searching, and I would bet that all of the big tech companies are racing to write better crawlers to make sure they can suck up all the sweet free content for their next AI model, the incentive for making your site crawlable is inverted in an ironic way. I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.

scraplab 2y 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.

graemep 2y ago
"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.
- gryzzly 2y ago
  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-part-6/ 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-gap/ https://infrequently.org/2021/03/the-performance-inequality-...

_heimdall 2y ago

> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? 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.

j45 2y ago

Client side rendering is harder for SEO than server side. 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.

doctorpangloss 2y ago

If you wanna play in someone's network you gotta follow their arbitrary rules. 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...