A pair of colleagues and I (Adam Parrish and Charles Fulnecky), while working for a major media company, developed what we believe to be a novel approach to dealing with the problem of dynamic, client-side content being ignored by search engines. This post is a primer describing our work. If there's interest I can write more detailed tutorials. Here is a github repo with a few examples of our implementation.

PhantomJS is a headless webkit browser that can be invoked from the command line. Our team discovered that one can integrate PhantomJS into their stack in such a way that Phantom pre-renders any HTML/JavaScript/CSS pages ahead of the content being served up to the client. This means that when a page is loaded, all of the initial JavaScript has already been executed, and it looks to the client as though that content is part of a static page. We have, in effect, turned client-side javascript into a server-side language. In the sections that follow, I’ll describe a trivialized nodejs example and define what challenges lay ahead.

The example is made of 3 parts. An index page that includes a jquery reference and displays a basic message, a phantomJS rendering script, and a nodejs server that calls the phantom script and serves the web page.

Our content is a simple index.html page that uses jQuery to set a heading tag.

The output of this PhantomJS script is then served to the client with all initializing javascript pre-rendered.

As mentioned at the beginning of this post, this example is trivialized. Within our team, we've built functional prototypes that are pre-rendering thousands of lines of non-trivial, enterprise grade JavaScript. In order to accomodate PhantomJS, we created an infrastructure that differs from the example in this post. Our HTML5 pages are being served by nginx. Between nginx and the client is a Varnish cache layer, though we could have used the built-in nginx cacheing. If the cache layer has the requested page, then the response is the cached, pre-rendered, page. If the cache does not have the page. The cache layer passes the request down to nginx which in turn fires PhantomJS through a java based origin app. The results of Phantom are sent to the client via the cache, where they remain until the cache is expired.

Here is a diagram of our setup.

Deciding how to fire the PhantomJS process should be based on your infrastucture. There is no reason the process must be triggered by a client request. For instance, PhantomJS could run on a scheduler, or could be hooked into some adjacent content monitor. In a production environment, one could even build and nginx or apache module that functions as a pre-processor. The possibilities are wide open. We really believe we are on to something interesting, and hope the community gets involved in improving our work.