Author: Tyler Odean, iGoogle Product Manager
Recommended experience:
In this article we'd like to highlight a few basic steps that gadget developers can take to improve the performance of their gadgets in iGoogle and on other OpenSocial enabled containers throughout the web. Gadgets that load quickly and are responsive to user input are more popular and more likely to remain installed on a user page, and a compact properly-cached gadget reduces hosting and bandwidth costs. With a few simple steps you can accelerate your gadget's performance.
The best practices for designing a gadget are the same as the best practices for maintaining any web property. You can use plugins and tools such as Page Speed and Firebug to profile the requests that your gadget is making to identify bottlenecks. For a list of tools that can help you improve the performance of your gadget, please check the downloads page. We recommend loading containers as a baseline and then compare the latency of the empty container with the latency of the container with the gadget installed in a variety of browsers and cache states. For more information on how to use profilers to diagnose your gadget, check out the latency measurement tutorial.
Most containers offer support for the Cache-Control HTTP header. You have server-side control over how your resources are cached, so be sure to set your headers appropriately for maximum benefit.
The Cache-Control header is best described in the HTTP/1.1 specification but there are some simpler descriptions available as well. If you're not sure about the cache headers your server is currently sending, you can try some publicly available tools to examine the cache headers on your files and see if they need to be tweaked.
Be aware that the Cache-Control header will be examined for all content coming from your server, including XML application specs, responses from makeRequest (both prefetched and not), and proxied images. Be sure to set caching headers for all of this content! You can also take advantage of the container to ensure that your content is appropriately cached by directing requests through gadgets.io.getProxyURL( OrigURL ). Proper caching will not only reduce end-user latency, it will also help minimize bandwidth costs associated with hosting your gadget. For more information on using gadgets.io.getProxyURL you can check out the OpenSocial Latency Combat Field Manual.
The HTTP/1.1 specification states:
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
Because of this, some internet browsers (such as IE7, for example) will only maintain up to two parallel connections to a server and will serialize any other image/CSS/javascript download connections your gadget is making. Inlining and consolidating scripts, spriting your images together and other forms of request batching will significantly increase the responsiveness of your gadget. Aim for a single CSS and a single JS file in production. And of course, if you aren't making use of a particular section of CSS or JS, you should remove it from the gadget code. Ideally any resources which absolutely need to be loaded separately should be distributed over multiple servers so that browsers don't bottleneck the requests because of the concurrency restriction. Batching requests, lazy loading and preloading can all be employed to help reduce the number of open connections and roundtrips that your gadget requires - check out the OpenSocial Latency Combat Field Manual for more advice and suggestions.
|
