
Show HN: Rendora – Dynamic server-side rendering for modern JavaScript websites - geo_mer
https://github.com/rendora/rendora
======
geo_mer
Hello HN, I've been developing and testing rendora for some time now and
decided to put it publicly today on github, I would love to take feedbacks or
answer any question!

~~~
InGodsName
How do you test that it works when there is no display in headless chrome?

~~~
geo_mer
you can add your user agent to whitlested user agents or (less recommended)
you can even connect to the headless chrome instance (usually using
[http://localhost:9222](http://localhost:9222) but in that case I remind you
that some assets are blocked from being fetched by default such as images,
fonts and CSS to speed up the DOM load. This doesn't affect the resulting
HTML.)

------
metrakit
Hey, thanks for your awesome job. I'm looking for the best SSR option for my
next SPA. I have some questions. Rendora is production ready ? I have some
risks to use it with lot of visitors ? And how about SEO impact ? What are
your results ? Thanks in advance :)

------
chatmasta
Cool idea and implementation.

Question: If the “initial render” of client side code involves JavaScript
mounting nodes on the DOM, how is this transformed into static HTML that can
be rendered without JavaScript? Does headless chrome offer a way to “snapshot”
the DOM in its current state (basically like copy pasting the “elements” pane
in dev tools)? Just wondering if there is a term for this, and/or where it’s
documented.

~~~
geo_mer
Rendora uses internally cdp
[https://github.com/mafredri/cdp](https://github.com/mafredri/cdp), a golang
client implementation for "Chrome Devtools Protocols" which works on top of
websockets, when Rendora detects a witelisted request, it instructs the
headless Chrome instance using cdp to render the corresponding page and waits
for the DOM load event, after that the content of the page is copied to
rendora and then returned back to the client while preserving HTTP headers and
status code.

It's all about using the chrome-devtools-protocol, if you are interested, you
may want to read about it in [https://chromedevtools.github.io/devtools-
protocol/1-2](https://chromedevtools.github.io/devtools-protocol/1-2)

>If the “initial render” of client side code involves JavaScript mounting
nodes on the DOM

That's the raison d'être of rendora, if your website doesn't add DOM nodes
using some javascript framework (e.g. React, Vue, etc..)in client, basically
the HTML will be exactly the same and thus you don't need rendora in that case

------
murukesh_s
Good luck with the launch. Looks like a great idea, was wondering if there is
any other existing product in the market.

Ability to provide ssr without changing a single line of code is awesome and
can help teams who are trying for a solution which requires code changes.

Wish the crawlers incorporate something like this into their crawling logic so
that we really don't need to worry about server rendering anymore. Until then
this product can be a bridge!

~~~
geo_mer
Thank you for the kind response

>was wondering if there is any other existing product in the market

yes, there is rendertron; here is the comparison between rendora and
rendertron and why I think rendora is better
[https://github.com/rendora/rendora#what-is-the-difference-
be...](https://github.com/rendora/rendora#what-is-the-difference-between-
rendora-and-rendertron)

also there is prerender.io but this is a commercial paid product and also
needs change in your backend; and I guess they didn't use headless Chrome
until recently

>Wish the crawlers incorporate something like this into their crawling logic
so that we really don't need to worry about server rendering anymore

Except for Google, probably all other search engines don't even execute
javascript to render pages (Bing claimed to be rendering js very recently but
I haven't seen it in my production website :D), they claim that the web is too
big and the computational complexity of executing javascript in every page is
unreasonable. Even Google can't render pages correctly if you have
asynchronous content from my own experience.

------
InGodsName
What's the disadvantage or advantage of headless chrome over chrome with head
intact?

Is headless chrome faster? Can we control popup windows in headless one? Does
it support proxies? Is it possible to control tabs? Close and open in new tab
etc...

~~~
geo_mer
>What's the disadvantage or advantage of headless chrome over chrome with head
intact?

I am not aware of any. You just don't use headless Chrome for typical browsing
:D

>Is headless chrome faster?

I guess it slightly is, because it doesn't need to paint the rendered page but
tbh Chrome/Chromium is an enormous project so I can't comment in details.

>Can we control popup windows in headless one? >Does it support proxies?

I believe they are not possible because chrome-devtools-protocol doesn't
support that yet, but you can add http/socks proxies inside Chrome and then
run it as headless to use a proxy if you insist

> Is it possible to control tabs? yes

if you're that interested about headless Chrome, I recommend you read about
chrome devtools protocol [https://chromedevtools.github.io/devtools-
protocol/1-2](https://chromedevtools.github.io/devtools-protocol/1-2)

------
chrischen
I’d be curious between using Chrome headless vs a Node server. Was this
tested?

~~~
lucideer
node is a JavaScript runtime, it has no rendering component, and—more
notably—no DOM or any other equivalents to many browser APIs in its core API.
This would mean you would have to emulate the browser environment with many
3rd-party implementations which are unlikely to match a modern, complex
browser in aggregate.

------
gitgud
So a regular browser will receive a js bundle, but a crawler will recieve a
html page?

How does Rendora determine which version to give the requester? Is it the
"User Agent String"?

~~~
geo_mer
No, both receive HTML, the real problem is that websites built with modern
javascript frameworks (e.g. react, vue, angular, etc...) render most of the
content using the javascript engine in browsers, search engines don't execute
javascript and thus they see almost nothing but a header and almost an empty
body (of course it depends on your use case to be more accurate). Rendora
solves the SEO problem for such websites, by being a lightweight reverse HTTP
proxy in front of your backend server, it detects crawlers by checking
whitelisted user agents and paths, if it finds one, it instructs a headless
Chrome instance to request and render the corresponding page and then returns
the final server-side rendered HTML back to the crawler (or according to
whatever whitelisted in your config file). This is called dynamic rendering
and has been recommended by Google and Bing very recently (see the links in
[https://github.com/rendora/rendora#what-is-dynamic-
rendering](https://github.com/rendora/rendora#what-is-dynamic-rendering))

~~~
gitgud
So if I'm hearing correctly, if a User Agent is white-listed it Rendora will
render the page on the server and return less assets (no CSS, fonts etc)

If it's _not_ white-listed it will just let the request pass through normally
to the server (eg static file server) is this correct?

~~~
geo_mer
>and return less assets (no CSS, fonts etc)

no, it returns the whole page, it's just equivalent to rendering pages on your
browser, everything in the initial HTML is the same in addition to HTML
generated by javascript frameworks added to the DOM after the webapp scripts
are loaded.

~~~
gitgud
Okay, so it renders the javascript webapp (Angular/React/Vue) on the fly into
HTML, (just as it would appear in a _client 's browser_), but only for the
whitelisted UserAgents, which can be crawlers right?

~~~
geo_mer
yes exactly :), as if crawlers see exactly the same HTML of what browsers see
after DOM load not the initial incomplete HTML sent by servers

------
candtoro
So, Rendora is comparable with [https://prerender.io](https://prerender.io)?

~~~
geo_mer
* prerender.io is a paid service; Rendora is FOSS and self hosted

* prerender.io needs additional code in your backend to filter requests and asks for SSR from a remote server then returns back the resulting HTML; Rendora doesn't because it does all that automatically by being a lightweight reverse HTTP proxy server in front of your backend

* with Rendora you can control caching (using an internal local store or Redis), prerender.io claims caching on their servers I guess but then you can't control it espcially if you have fast chaing pages

* Rendora provides Prometheus metrics to measure your SSR latencies, count of cached and uncached requests and an API rendering endpoint

* Rendora supports asynchronous pages where content is loaded after the initial DOM load

* you can simply choose which Chrome version you want to use with Rendora

* Rendora instructs headless Chrome to skip fetching unncessary assets (e.g. fonts, CSS, images, etc...) which makes the DOM load much faster then when loaded and rendered by default

