This document describes the different options for publishing your gadget.
Gadgets run in a variety of applications and environments. The API Overview page lists some of the more popular choices.
Not every gadget is suited to every environment. See the documentation for your container, application, or site for details about what features are supported in that environment.
Before publishing your gadget, you should test it, bearing in mind the requirements and limitations of the target environment in which the gadget will run.
You should do the following tests for all gadgets:
- Try all combinations of
- Run it in different sized screens, from 800x600 to as wide as you can. Link to the Firefox web developer extension, which makes it easy to resize Firefox to a specific size.
- Test your gadget in different sizes, as described in Testing Width and Height.
- Test your gadget in every environment in which it might run.
- Test your gadget on the following browsers: IE 6+, Firefox 3.0+, Google Chrome 5.0+, Safari 4.0+.
- Try different font
- To change your font size in Firefox, choose Tools > Options > Content. Click Advanced in the "Fonts & Colors" area. Change the font settings, and uncheck "Allow pages to choose their own fonts, instead of my selections above."
- To change your font size in Internet Explorer, choose Tools > Internet Options > General. Use the Fonts and Accessibility dialogs to change your font settings.
If you are using
what happens if the data source is down or returns an error. You
can simulate this by changing the URL temporarily to another URL.
How a gadget is sized depends to a large extent on where it runs. See the documentation for your container or site for details.
In designing and testing your gadgets, be prepared for arbitrary widths from 200 pixels to as wide as 600 pixels. For certain gadgets, the width should be even larger. As a general rule, design the gadget to display properly if it's given extra space. For example, maps gadgets should fill their areas, picture gadgets should center themselves in the frame, and text gadgets should float their text to the top (for example, click-for-more-details links that are typically at the bottom should stay close to the content rather than floating to the bottom of the gadget window).
If you write a gadget that you expect to experience heavy traffic, there are steps you can take to ensure availability and good performance. If your gadget gets more than 200,000 views per day, or approximately 1-2 requests per second, you should consider following the tips in this section. Even a 50 KB gadget that receives 200,000 requests per day consumes around 300 GB per month in bandwidth.
There are different reasons a gadget might attract a lot of users. It might simply become popular in the content directory. Or, if the gadget is used in a special promotion or advertisement, that might cause it to experience heavy traffic.
Your goal for a high traffic gadget should be to get it to render in 0.25 seconds (250 milliseconds) or less. The Latency Measurement guide can help you with the details of measuring your gadget's performance. Improving the responsiveness of your gadget is a sure way to make a positive impact on the user's experience. For tips on optimizing gadget performance, see Optimizing for Heavy Traffic. For management tips, see Managing Heavy Traffic. The general testing guidelines are also especially important for highly popular gadgets.
If you think that your gadget might experience heavy traffic, follow these guidelines:
- Use a
type=htmlgadget. Gadgets that are
type=urlgenerally render more slowly than
type=htmlgadgets because of the poor performance and poor cache support of other hosting servers.
makeRequest()method caches your content for approximately 1-2 hours by default. You can use the
refreshIntervalparameter with these
functions to refresh the cache more often. However, caching helps gadget performance by minimizing the number of requests sent to remote servers hosting content. Do not request greater freshness than needed from the cache, or you will reduce the percentage of requests that are served from the cache. Also, do not use cache-busting techniques such as including random numbers or timestamps in fetch URLs, because this can overload the systems that respond to those URLs. See Refreshing the Cache for details on how to set a refresh interval.
- Cache frequently used content or values by using one or more of the following techniques:
- Fast, loads with the gadget and requires no additional server-client round-trip
- No browser requirements
- Data is passed in via URL, and subject to URL length restrictions (there is a lot of data passed into gadget URLs, so this makes the practical size of data low, a few hundred characters max)
- Effectively unlimited storage
- Requires browser support
- No browser requirements
- About 10 KB of storage space (including keys, and depending on per-container restrictions)
- Requires a second request once the gadget loads to fetch data
- Any data stored in AppData is potentially visible to other people within the user's social graph
- Hidden UserPref
- Check out the Latency Measurement guide for ways to observe your gadget's performance. Then eliminate the bottlenecks.
- Specify height and width for all
<img>tags in your gadget's HTML. This makes your gadget render faster. If you're using
gadgets.io.getProxyUrl()and inserting the image element directly into the DOM, you don't need to set the width and height properties.
- Instead of linking directly to your hosting provider, use the
functions to cache all embedded images, and
embedCachedFlash()to cache Flash content. Below is an example of a gadget that pre-loads images using
These guidelines can help you manage a high volume gadget:
- If you are receiving large quantities of email from your
gadget users, use Gmail and
set up filters to manage the volume. We recommend using
an address of the form
<username>.feedback+<gadgetname>@gmail.comin your gadget spec. This helps you to filter the messages you receive from gadget users. Gmail drops everything after the plus sign (+), so this email address maps to
<username>.email@example.com. Note that Gmail has a high quality spam filter.