Beyond caching: Google engineers reveal secrets to faster websites
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.
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.
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.
“Closures scare me,” McAnlis said, referring to how unpredictable they can be in terms of the amount of memory they can consume.
How to improve performance
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.
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 tagcalls 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.