« March 2007 | Main | May 2007 »
The user's proximity to your web server has an impact on response times. Deploying your content across multiple, geographically dispersed servers will make your pages load faster from the user's perspective. But where should you start?
As a first step to implementing geographically dispersed content, don't attempt to redesign your web application to work in a distributed architecture. Depending on the application, changing the architecture could include daunting tasks such as synchronizing session state and replicating database transactions across server locations. Attempts to reduce the distance between users and your content could be delayed by, or never pass, this application architecture step.
Remember that 80-90% of the end-user response time is spent downloading all the components in the page: images, stylesheets, scripts, Flash, etc. This is the Performance Golden Rule, as explained in The Importance of Front-End Performance. Rather than starting with the difficult task of redesigning your application architecture, it's better to first disperse your static content. This not only achieves a bigger reduction in response times, but it's easier thanks to content delivery networks.
A content delivery network (CDN) is a collection of web servers distributed across multiple locations to deliver content more efficiently to users. The server selected for delivering content to a specific user is typically based on a measure of network proximity. For example, the server with the fewest network hops or the server with the quickest response time is chosen.
Some large Internet companies own their own CDN, but it's cost-effective to use a CDN service provider, such as Akamai Technologies, Mirror Image Internet, or Limelight Networks. For start-up companies and private web sites, the cost of a CDN service can be prohibitive, but as your target audience grows larger and becomes more global, a CDN is necessary to achieve fast response times. At Yahoo!, properties that moved static content off their application web servers to a CDN improved end-user response times by 20% or more. Switching to a CDN is a relatively easy code change that will dramatically improve the speed of your web site.
Steve Souders
[Steve Souders is Yahoo!'s Chief Performance Yahoo!. This is one in a series of Best Practices for Speeding Up Your Web Site. This article is based on Steve's book High Performance Web Sites, published by O'Reilly.]
Posted by stevesouders at 9:03 AM | Comments (31)
The clever folks down under at Yahoo!7 have been very busy lately; check out their fine new toy at au.alpha.yahoo.com. If you've ever wondered what a crisp, clean, search interface to Yahoo! (and many other sources of data) might look like, this is it.
Featuring results from Yahoo! Search, Flickr, Answers, and News, the Alpha Beta uses several YUI libraries to do its magic, with a little help from some OpenSearch-friendly sites, such as Wikipedia and YouTube.
Like an increasing number of interesting Yahoo! efforts, Alpha Beta began as a Hack Day project. Here are a few words of explanation from team member Brett Poole:
"Whilst aggregating feeds on one page is nothing new, we wanted to take a federated search concept one step further. With this beta, we have introduced personalisation elements that not only allow users to customise their view, but also to add their favourite search service (at least those who syndicate their search results via OpenSearch RSS).
We also decided to add a sharing element for logged in users of the site. Now, if you decide to share your personalised url with others, they can view and effectively use the search configuration you have developed.
We thought the idea was good enough to develop further into a public beta site and get a few ideas from the Australian search community at large.
And, yes, this is indeed a beta, so we expect there are many many improvements to make along the way, so be sure to tell us what you think!"
Please check in at the Alpha Beta blog with questions or comments; the team would love to hear from you.
Kent Brewster, Yahoo! Developer Network
Posted by Kent Brewster at 8:54 AM | Comments (1)
A few weeks ago I spent a day in the exhibit hall at the ETech conference giving demos of Pipes in the Yahoo booth. I was thrilled to see all the interest in and buzz around Pipes. There was a lot of interest from folks who wanted to dig deeper into how Pipes are built and what sorts of things can be done.
In the next few weeks (minus some conference travel), I'm going to try to make some headway on that here. But in the mean time, here some Pipes related items I ran across last week. Each one gives you a taste of how Pipes can be used.
In Mashing my own personal Blogosphere, James Dellow writes about his use of Pipes, Technorati, and Feedburner to track is own personal "cosmos"
Well, in the end I turned to Yahoo! Pipes for help and I'm pleased to announce the release of my first useful published Yahoo! Pipe - its called My Cosmos Feed. The result is a mashup using Technorati, Yahoo! Pipes and Feedburner.
What it does is this: Input the URL for a blog into My Cosmos Feed and it generates an RSS feed that includes the most recent 3 posts from the other blogs that link to that blog, plus all the other blogs that link to the blogs linking to the original blog! To see how this works in practice you can check out, via Feedburner, the My Cosmos Feed for the ChiefTech blog.
Also, be sure to see his follow-up posting: Reflections on mashing my Blogosphere.
Next up we have a random comic generator as described in laying pipes
Last week, I discovered Pipes, a Yahoo feedmashup tool which appears to do all that with a tubular GUI–-no programming or API knowledge required. Only a small amount of rule- and logic-following.
After some tinkering, I managed a four panel strip (RSS version) which takes the feed from the Newsarama Blog (hi, guys!), applies a Content Analysis module, and selects Flickr photos and captions based on the results. The service can be a little buggy, but people seem to be navigating well enough.
And then there's Stephen O'Grady's description of how he used Pipes to solve a problem with the redesign of the RedMonk.com home page.
Well, make it work I did. To see it in action, go hit redmonk.com. The better news was that it literally took not more than 10 minutes to appropriately filter all three of our feeds. As you can see from the Pipe - or the inline picture - the setup is dead simple. Pipes reads in my tecosystems feed from FeedBurner (Sources: Fetch Feed), looks for items that have “links” in the title item, filters them (Operators: Filter), and delivers me a neatly stripped RSS feed. After repointing the parser on redmonk.com from FeedBurner to our newly created Pipes feeds, redmonk.com is now delivering a homepage free of del.icio.us links, while the individual blogs continue unaffected. Beautiful.
The point to emphasize here, as far as I’m concerned, is the efficiency. Fixing this via the original approach was far from an arduous task, but it would still have taken me probably an hour or two (remember, I’m not the sharpest tack in the box) to figure out what’s being done where and test the filtering. With Pipes, it took less than 10 and I was done; apply the filter, look at the output, cut over the feeds.
What will those analysts come up with next?
This post is already longer than I expected, so I'll hold off on posting my personal favorite pipe until tomorrow.
If you've built a cool pipe we ought to show off, drop me a line.
Jeremy Zawodny
Yahoo! Developer Network
Posted by jzawodn at 1:08 PM | Comments (3)
The Yahoo! Shopping APIs have been updated and they're easier to use than ever. The new Catalog Listing call now includes the content from both the old User Product Reviews and Catalog Specs calls. This reduces the number of web service calls you need to make to create a full shopping experience from five to three. The new Product Search web service now returns more robust search narrowing options and the new Catalog Listing now has the ability to query by UPC, ISBN, and brand & model or part number.
Product Search example:
Catalog Listing example:
Did I mention that all the new calls now return JSON (with callbacks!!!) and Serialized PHP as well as XML? Get those badges started!
Here's a quick summary of the new functionality:
Product Search:
Returns merchant ratings with merchant offers in product search results
Returns department & category for catalog products and offers in product search results
Returns UPC, ISBN, Model #, and Manufacturer Part # for catalog products
Additional output formats - XML, PHP, JSON
Catalog Listing:
Returns product specs, merchant offers, and user reviews in a single call to Catalog Listing API
Returns images for merchant offers when image not available in specs
Returns larger images for products where available
Returns detailed components of user review (value, quality, etc.)
Returns link to merchant review page in results
Side-by-side product comparison (up to 5 products)
Additional output formats - XML, PHP, JSON
Merchant Search:
Additional output formats - XML, PHP, JSON
Posted by at 2:05 PM | Comments (1)
One result of the first Open Hack Day was that our expectations of what a developer event could and should be were raised dramatically. Then we had the nice problem of figuring out how to do it again. We resisted the self-imposed pressure to up the ante at first because we didn't think we could. But that seemed like a cop out.
Then the European team started asking some questions about the event, and the answer to our problem became obvious. Hack Day needed to go to London. It needed to happen in the summer. It should be at an amazing venue. We needed cool music. And we should partner with other innovative companies like BBC Backstage.
The wheels are in motion on all those fronts, and now we're on our way to setting expectations even higher.
Event organizer Tom Coates posted his thoughts on why this is such an exciting opportunity and described what people do at Hack Day:
"It is with great pleasure that I'm going to direct you all over to hackday.org and encourage you to sign up to the first Hack Day to be held in Europe. And this time it's not only a Yahoo! event, because it's a partnership with BBC Backstage. And it's not at a campus, it's at London's bloody Alexandra Palace! On June 16th and 17th! Bring a kite!Everything else remains the same. It's a two day event, starting first thing on Saturday morning and running through to Sunday evening. We'll have a whole bunch of speakers from Flickr, Yahoo! and the BBC to start us off. We'll have food - mostly flat - to meet the dedicated needs of our guests. There may be booze. I'm not telling. If you want, you can stay awake all night or crash out in a corner in a sleeping bag. The only requirement or restriction (except for the legal ones, which you should probably read) is that you come to the event and try and build something, ideally using some of the stuff that all the organisations hosting the event have to offer. Did I mention it was free?
You can build robots if you'd like, or things involving televisions or tagging or photos or smart dust. There will be prizes for the best stuff made. And judges! And probably a limited number of free Flickr badges! And yes, there will probably be a band. And no, it probably won't be Beck."
So, if you are a European developer and would like to attend the event, please let us know a little about yourself (including a link to your portfolio or blog or something) via the invitation request form on hackday.org.
We can't wait and look forward to seeing you and your hacking skills on display in London in June.
Matt McAlister
I just couldn't resist the temptation of embedding Beck's Hack Day Puppet video in this post here. It still makes me laugh every time I watch it (which is probably too often). Plus, if you've never heard of Hack Day, then this will give you a little taste of what to expect.
UPDATE: Matt Cashmore, the Hack Day event producer from BBC Backstage, adds some perspective on the historical significance of hosting this event at Ally Pally:
"There’s so much history for the BBC there, and it seems perfect to me that the place of birth for TV, is the place of birth for a whole load of amazing stuff that can be distributed in so many cool ways. Ally Pally was the first place that broadcast regular HD TV transmissions way back when TV sets were 4′’ wide…. it just seems fitting that we’re now trying to work out how we wire the worlds most advanced studios (at the time) for wi-fi!"
Posted by Matt McAlister at 2:13 PM | Comments (1)
Since all the kool kids are twittering these days, this little app might be of interest:
Here's a small Lily program that lets you check the spelling of a word from your cellphone--it uses the Twitter API to send and receive messages from the cellphone and the Yahoo Suggested Spelling web service to look up the spelling. To use it you'll need two Twitter accounts- one for Lily and one for yourself. You'll also need to enable your cellphone in the Twitter account settings. In the patch you'll need to add your Twitter user/pass as an argument to the twitter object.
If you've ever read quick email or blog posts from me, you can probably appreciate how much a good spellcheck has improved my life--when I remember to use it. :-)
Oh, if you happen to be at Web 2.0 Expo this week, say "hi" to the YDN team members you see there (or other Yahoos, for that matter). There will be more than a few of us floating around.
Jeremy Zawodny (jzawodn on Twitter)
Yahoo! Developer Network
Posted by jzawodn at 10:36 AM | Comments (7)
Often times it seems like the APIs that get the most attention are those you can use to produce visual things: mashups, Ajax effects, etc. Not that there's anything wrong with YUI, Flickr, or Maps, of course, but there's a class of APIs that's a bit more behind the scenes and all about getting down to business.
Our friends in Yahoo! Search Marketing (we call 'em YSM for short) just announced their new technology solutions center which includes access to the advertising APIs used for campaign management:
...today we’ve released a new Technology Solutions section that allows Yahoo! Search Marketing Advertisers to apply for API access provided through our Enterprise Web Services (EWS). EWS enables you to develop software that interacts directly with Yahoo! Search Marketing campaign management systems.
So if you're a developer in the Search Marking world and have been hoping to start playing with Panama, head on over and check it out.
Jeremy Zawodny
Yahoo! Developer Network
Posted by jzawodn at 4:24 PM | Comments (2)
This just came across our radar the other day. Over on Google Code you'll find pynswers a simple Python interface to the Yahoo! Answers API.
You'll find basic usage instructions on the project wiki.
Thanks to Shabda Raaj for the heads-up.
If you see other useful libraries for using our APIs, drop me a line.
Jeremy Zawodny
Yahoo! Developer Network
Posted by jzawodn at 10:59 AM | Comments (2)
Over on spindrop.us, Dave Dash writes about his implementation of a cache in Symfony for the Yahoo! Geocoding API:
These REST queries happen a lot and will continue to happen, but this data that Yahoo! provides is fairly static. We’re basically querying a database of sorts. So it makes sense that we should cache this data.
We’ll demonstrate how to cache these queries using symfony’s sfFunctionCache class.
Of course, it's no secret that Yahoo uses Symfony or that our Geocoding Service is quite popular. And, of course, having a straightforward caching implementation means faster apps for your users. Check it out.
Jeremy Zawodny
Yahoo! Developer Network
Posted by jzawodn at 1:56 PM | Comments (0)
Last Fall I had the chance to participate in our University Hack Day program. It's a bit of a twist on a typical college recruiting visit. Instead of simply setting up interviews and buying some pizzas, we decided to bring a little bit of Hack Day to the campuses.
Here's how it worked: modeled after our internal Hack Days (and our public Open Hack Day), a group of Yahoos acted as judges while a number of students (individuals or teams) presented their hacks to an audience of their peers and professors. Of course, there was music, lots of junk food hacking fuel, and a fun atmosphere. The only real rule was that each Hack had to involve some sort of Yahoo! product, service, or API.
I was blown away each time by the sheer diversity of hacks presented. All told, I saw hacks that involved Messenger, Maps, Music Engine, Search, Widgets, Flickr, del.icio.us, YUI, and others I've probably forgotten already.
Last week, we (and by "we" I mean "our excellent recruiting team") invited the winners from the various schools to the Yahoo campus for a few days for a final University Hackdown. Our esteemed judges and a collection of interested Yahoos gathered in a room to participate in the final round. The hackers presented, the judges judged, and a winner was chosen.
Greg Schechter (pictured with the judges above) from UIUC walked away with the trophy. His slide rule widget (yes, slide rules) and entertaining presentation style put him at the top of our list.
Here's a quick video of Greg's winning presentation, thanks to the new YDN Cam and Matt McAlister's Jumpcut editing skills. The widget itself is hard to see, but you'll get a good feel for its capabilities and the thouroughness of Greg's hack.
Congrats to everyone who participated. I look forward to seeing several of the hackers back as Yahoo interns later this year.
Jeremy Zawodny
Yahoo! Developer Network
Posted by jzawodn at 1:27 PM | Comments (2)
In The Importance of Front-End Performance, I reveal that 80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.
One way to reduce the number of components in the page is to simplify the page's design. But is there a way to build pages with richer content while also achieving fast response times? Here are some techniques for reducing the number of HTTP requests, while still supporting rich page designs.
Image maps combine multiple images into a single image. The overall size is about the same, but reducing the number of HTTP requests speeds up the page. Image maps only work if the images are contiguous in the page, such as a navigation bar. Defining the coordinates of image maps can be tedious and error prone.
CSS Sprites are the preferred method for reducing the number of image requests. Combine all the images in your page into a single image and use the CSS background-image and background-position properties to display the desired image segment.
Inline images use the data: URL scheme to embed the image data in the actual page. This can increase the size of your HTML document. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages.
Combined files are a way to reduce the number of HTTP requests by combining all scripts into a single script, and similarly combining all stylesheets into a single stylesheet. It's a simple idea that hasn't seen wide adoption. The ten top U.S. web sites average 7 scripts and 2 stylesheets per page. Combining files is more challenging when the scripts and stylesheets vary from page to page, but making this part of your release process improves response times.
Reducing the number of HTTP requests in your page is the place to start. This is the most important guideline for improving performance for first time visitors. As described in Tenni Theurer's blog Browser Cache Usage - Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these first time visitors is key to a better user experience.
Steve Souders
[Steve Souders is Yahoo!'s Chief Performance Yahoo!. This is one in a series of Best Practices for Speeding Up Your Web Site. This article is based on Steve's book High Performance Web Sites, published by O'Reilly.]
Posted by stevesouders at 9:41 AM | Comments (35)
Copyright © 2008 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Copyright Policy - Job Openings