Beyond Caching: Google engineers reveal secrets to faster Web sites

Better JavaScript memory management and HTML prefetching tags could make Web sites more responsive

In the fiercely competitive world of Internet services, Google constantly seeks ways to speed up the delivery of content to its hundreds of millions of users.

At the O'Reilly Velocity conference this week in New York, two Google engineers presented some of their favorite tips and research for expediting delivery of Web pages and applications. Such knowledge could be handy for other Web developers looking to make their products more responsive.

Google developer advocate and performance expert Colt McAnlis tackled one of the thorniest problems for mobile Web developers today: JavaScript performance.

Web based JavaScript applications can suffer from performance issues, especially on mobile clients, because JavaScript parsing engines use garbage collection (GC) to manage memory. "You shouldn't rely on garbage collectors," McAnlis told the audience of Web developers.

GC helps programmers by automatically returning to the operating system the memory a program no longer needs. Writing code to manage memory in low level languages such as C and C++ is a laborious process, though, and such languages aren't natively supported by browsers anyway.

The problem with many JavaScript Web applications is that JavaScript engines will launch their garbage collection routines at seemingly random times, which will cause applications to momentarily slow down. The frame rate of a video application, for instance, may decrease. Or the time it takes an application to execute an operation may jump to a noticeable 20 milliseconds, up from a typical 3 to 5 milliseconds.

Overall, for GC to work without being noticed by the user, the system memory must be six times as large as the amount of memory being used, said McAnlis, referring to a well known study. This can be a demanding requirement given the limited memory of mobile devices and the number of memory-hungry applications they run.

Add to this issue the increasing use of closures, a programmer-friendly technique of widening the availability of locally defined variables. jQuery, for instance, is a widely used JavaScript library that relies on closures and as a result, creates a lot of splurges in memory allocation.

"Closures scare me," McAnlis said, referring to how unpredictable they can be in terms of the amount of memory they can consume.

To improve performance, and better manage memory, developers should use an approach similar to the one used by the middleware library Emscripten, which is being used to build high performance HTML5 Web games.

Emscripten converts code written in C or C++ into JavaScript, allowing it to manage memory from within the application itself. An Emscripten-based program will pre-allocate a block of memory from the system. The programmer, along with Emscripten itself, decides when memory is no longer needed, and Emscripten returns this unused memory to its pool of internally available memory. The JavaScript engine does not do any garbage collection on the program and so would not affect the performance of the program.

Generally speaking, programs written with this technique can run two to four times faster than typical JavaScript programs and do not suffer from the occasional lag in performance that GC operations can cause, McAnlis said.

Another Google presentation, from Google Web performance engineer Steve Soulders, pointed to some of the emerging browser techniques of fetching Web pages even before they are requested by the user.

The idea is that the browser, Soulders explained, should be able to anticipate the next page that its user might want to see, even before the user requests the page.

"You don't know what the user's next step will be, but you could get more clues as to [his or her] intent on the page" they just requested, Soulders said. He then explained several techniques for exploiting this knowledge.

Developers can add the HTML dns-prefetch, pre-fetch and pre-render tags to a page's hyperlinks. Once a page is loaded, such tags can tell the browser to fetch some of the contents of the pages that are linked to in that original page, even before the user requests them.

The dns-pre-fetch tag tells the browser to look up the domain name of the Web page link. The pre-fetch tag tells the browser to grab the entire page, and the pre-render tag calls for the browser to construct the entire page, as if it were displaying the page on a hidden tab.

All three of these tags, when deployed, can shorten the period between requesting a Web page and seeing that Web page.

Soulders warned developers to use such tags wisely, because they can drive up bandwidth and processor usage. But in many cases, such as a log-in page, or for a page of search results, there is a fairly high likelihood that a user will click on one of the links found on the page they've been delivered.

Browser support for these tags varies, but most browser makers seem to be adding support for them in their new and upcoming editions.

Browsers themselves have a number of processes to speed page delivery as well, such as DNS pre-resolve and TCP pre-connect. With DNS pre-resolve the browser can anticipate the domain name of the next site to be visited, through actions such as watching what letters a user starts typing in the navigation bar, or even by routinely fetching the IP addresses of that user's most visited Web sites.

A TCP pre-connect anticipates the user's next move through similar means. It "warms up" connections to sites, Soulders said, by opening ports and setting all the protocols in place for an eventual request.

Joab Jackson covers enterprise software and general technology breaking news for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab's e-mail address is Joab_Jackson@idg.com

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies