• Engine Yard
  • LivingSocial
  • VMware
  • Heroku
  • Rackspace Hosting
  • Blue Box Group
  • JetBrains
  • New Relic
  • Percona
  • Pivotal Labs
  • Rails Dog
  • WyeWorks
  • Chargify

Sponsorship Opportunities

For information on exhibition and sponsorship opportunities at RailsConf, contact Yvonne Romaine at yromaine@oreilly.com.

Download the RailsConf Sponsor/Exhibitor Prospectus

Contact Us

View a complete list of RailsConf contacts.

Progressive Rendering And Full Page Caching

George Ogata (Patch)
General
Location: Ballroom I
Average rating: **...
(2.81, 48 ratings)

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 [1], 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.

[1] http://github.com/oggy/template_streaming

George Ogata

Patch

George Ogata has been a Ruby enthusiast since 2001, and Rails developer since 2006. Born in Sydney, Australia, he now works for Patch.com, a network of local news sites across the United States. Patch, acquired by AOL in 2009, underwent extremely rapid expansion throughout 2010, expanding its coverage from 30 to 770 towns across 18 states. Now serving well over 5,000 requests per minute during the day, the scalability requirements have led the Patch team to explore some innovative optimization techniques in Rails such as those to be presented here.

Comments on this page are now closed.

Comments

George Ogata
05/24/2011 9:31am EDT

Thanks for the feedback, Keenan.

I’m @gogata on Twitter, although I’ve been pretty Twitter-shy to date. That’s not cool, though – I’ll be better at posting updates there.

Picture of Keenan Brock
Keenan Brock
05/22/2011 11:02pm EDT

Great presentation giving the details of streaming events. If you look closely, the ideas can be extracted to map out pitfalls in 3.1’s streaming, and ideas on what portions of the code can be extracted into separate ajax calls.

I did feel this overlapped a little with Tenderlove’s keynote. But since this came first, can’t really fault George on this one. Also, please post your twitter id to make it easier to follow you?

George Ogata
05/19/2011 5:27pm EDT

Thanks Louis – the slides are now up.

Louis Leung
05/18/2011 11:23am EDT

Hey George,

Great presentation! Can you post the slides online?

Thanks.