6 ms·

A big one for the need of server side rendering is SEO. Without server side rendering, most web crawlers don't have access to your content and you can't rank fo

A big one for the need of server side rendering is SEO. Without server side rendering, most web crawlers don't have access to your content and you can't rank for SEO.

_bxg1 8y ago
Given the prevalence of client-side rendering, I think all the major players have learned to circumvent this. They can run a full headless browser instead of just looking at the raw HTML, and detect when the JavaScript seems to have rendered the content. That said, user experience (in this case site speed) can be a factor in how Google actually ranks pages, so that could be another motivation.
- jypepin 8y ago
  Well... as everything else with how Google's crawler and algorithms work, there are no official or definitive answer, but what has been communicated is that it could work but definitely more difficult and can lead to more issues. Knowing a bit about SEO, if you want to invest in your ranking, I wouldn't go without server-side rendering.
  - _bxg1 8y ago
    Still, the two buckets I described above hold true. If someone is returning to your web app - Slack, or Trello, for example - you don't care as much about SEO because most of your visitors are return visitors. Your splash page, on the other hand, needs to be optimized for SEO but won't have much interactive complexity, so it doesn't need client-side rendering.
  - davidjnelson 8y ago
    A lot of seo data is meta tags in the head. These aren’t going to render client side.
- walshemj 8y ago
  Yeh they use a two stage process now but client side is still best - look at the recent JavaScript series on googles webmaster chanel.
raquo 8y ago
SSR for the purposes of SEO can be achieved in a simpler way, without complicating your whole app to support SSR. Just pre-render the page in headless chromium / puppeteer when a search engine bot requests it and return the resulting html.
- davidjnelson 8y ago
  This is pretty slow though right? Those speed penalties will impact your google search ranking.
  - raquo 8y ago
    I haven't had a chance to try it myself yet, but from what I've read the extra delay is sub 100ms. Caching or pre-rendering the HTML output for bots in advance is an option too depending on the particular use case. I would certainly consider this ahead of SSR driven by "isomorphic" Javascript for frontend-heavy apps.
- jypepin 8y ago
  really not sure having a separate way to render your page just for crawlers, using a different rendering engine is "simpler" than having SSR.
  - raquo 8y ago
    SSR is only easy if your frontend is written exclusively in SSR-compatible libraries and your backend is node.js, and even then you need to adjust your frontend code for SSR because node.js doesn't have all the browser APIs that your code could be using (like XHR or the real (not virtual) DOM). On the other hand, puppeteer executes your application in virtually the same environment as the user's browser, without polluting your frontend architecture with SSR concepts and limitations. Yes, you'll need to set up a bit of infra initially. Depending on the use case it may very well pay off.
- pcmaffey 8y ago
  I pre-render my pages with puppeteer on build, and then hydrate with the js bundles. Everyone gets the faster experience of an HTML page (not just crawlers), while the full js loads async. Example in my profile.
dplgk 8y ago
Funny that JS has the same SEO problem Flash had.
- draw_down 8y ago
  Not really? They are both imperative programming languages and not markup languages, so it’s unsurprising that they have this in common. Except they sort of don’t have it in common now because Google executes JS. You can even see a PhantomJS rendering error in their search result previews if you get “lucky”.

A big one for the need of server side rendering is SEO. Without server side rendering, most web crawlers don't have access to your content and you can't rank for SEO.

_bxg1 8y ago

Given the prevalence of client-side rendering, I think all the major players have learned to circumvent this. They can run a full headless browser instead of just looking at the raw HTML, and detect when the JavaScript seems to have rendered the content. That said, user experience (in this case site speed) can be a factor in how Google actually ranks pages, so that could be another motivation.

jypepin 8y ago
Well... as everything else with how Google's crawler and algorithms work, there are no official or definitive answer, but what has been communicated is that it could work but definitely more difficult and can lead to more issues. Knowing a bit about SEO, if you want to invest in your ranking, I wouldn't go without server-side rendering.
- _bxg1 8y ago
  Still, the two buckets I described above hold true. If someone is returning to your web app - Slack, or Trello, for example - you don't care as much about SEO because most of your visitors are return visitors. Your splash page, on the other hand, needs to be optimized for SEO but won't have much interactive complexity, so it doesn't need client-side rendering.
- davidjnelson 8y ago
  A lot of seo data is meta tags in the head. These aren’t going to render client side.
walshemj 8y ago
Yeh they use a two stage process now but client side is still best - look at the recent JavaScript series on googles webmaster chanel.

raquo 8y ago

SSR for the purposes of SEO can be achieved in a simpler way, without complicating your whole app to support SSR. Just pre-render the page in headless chromium / puppeteer when a search engine bot requests it and return the resulting html.

davidjnelson 8y ago
This is pretty slow though right? Those speed penalties will impact your google search ranking.
- raquo 8y ago
  I haven't had a chance to try it myself yet, but from what I've read the extra delay is sub 100ms. Caching or pre-rendering the HTML output for bots in advance is an option too depending on the particular use case. I would certainly consider this ahead of SSR driven by "isomorphic" Javascript for frontend-heavy apps.
jypepin 8y ago
really not sure having a separate way to render your page just for crawlers, using a different rendering engine is "simpler" than having SSR.
- raquo 8y ago
  SSR is only easy if your frontend is written exclusively in SSR-compatible libraries and your backend is node.js, and even then you need to adjust your frontend code for SSR because node.js doesn't have all the browser APIs that your code could be using (like XHR or the real (not virtual) DOM). On the other hand, puppeteer executes your application in virtually the same environment as the user's browser, without polluting your frontend architecture with SSR concepts and limitations. Yes, you'll need to set up a bit of infra initially. Depending on the use case it may very well pay off.
pcmaffey 8y ago
I pre-render my pages with puppeteer on build, and then hydrate with the js bundles. Everyone gets the faster experience of an HTML page (not just crawlers), while the full js loads async. Example in my profile.

dplgk 8y ago

Funny that JS has the same SEO problem Flash had.

draw_down 8y ago
Not really? They are both imperative programming languages and not markup languages, so it’s unsurprising that they have this in common. Except they sort of don’t have it in common now because Google executes JS. You can even see a PhantomJS rendering error in their search result previews if you get “lucky”.