Hacker News Reader

Comment by jypepin | Hacker News Reader

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.

View on HN

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.

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.

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.

A lot of seo data is meta tags in the head. These aren’t going to render client side.

Yeh they use a two stage process now but client side is still best - look at the recent JavaScript series on googles webmaster chanel.

Funny that JS has the same SEO problem Flash had.

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.

This is pretty slow though right? Those speed penalties will impact your google search ranking.

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.

really not sure having a separate way to render your page just for crawlers, using a different rendering engine is "simpler" than having SSR.

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.

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.

Reply on news.ycombinator.com