Progressive Rendering And Full Page Caching

In his last RailsConf keynote, DHH hinted at a mechanism for Rails 3.1 for flushing partial responses out during view rendering, commonly known outside of Rails circles as “progressive rendering.” Having implemented this for Rails as a plugin, Template Streaming ¹, I will present how we are using this at Patch.com, and how it changes the way you need to design parts of your application. Some key points are:

• Moving javascript includes from the foot of your page to the head, and fetching it asynchronously.
• Using scoped stylesheets to flush styles for rendered fragments in the body, while maintaining HTML5 compliance and cross-browser compatibility.
• Moving logic that postprocesses the response into Rack middlewares, such as for dynamic image spriting.
• Handling errors during rendering by injecting error information into the foot of the page in development, or omitting erroneous partials in production.

In addition, I will present how progressive rendering complements two other full-page caching techniques we use at Patch.com:

• Client-side personalization, for moving small user-specific fragments of the page, such as the user name, into cookies, and injecting them client-side.
• Edge side includes, for injecting larger user-specific fragments of the page, such as an admin menu, from a separate server-side layer (rack middleware or reverse proxy).

By relaxing our freshness constraints a little, these techniques can be used to ensure that for heavily trafficked pages, the initial page render is always served from a full-page cache, with user-specific data pulled in after the initial page load. Meanwhile, progressive rendering can be used to optimize pages which don’t lend themselves to full-page caching, such as search results.

¹ http://github.com/oggy/template_streaming