• Home
  • Quick Start
    • Configurator
    • Download YUI 3
  • Documentation
    • User Guides
    • Examples
    • Tutorials
    • API Docs
  • Community
    • Gallery
    • Blog
    • Forums
    • YUI Theater
    • Calendar
  • Contribute
    • YUI on GitHub »
    • File a Ticket
    • View Tickets
    • Dashboard
  • Other Projects
    • YUI 2
    • YUI Compressor
    • YUI Doc »
    • YUI Builder
    • YUI PHP Loader
    • YUI Test
    • YUI Website

Blog: Archive for March, 2007

Welcoming Mike Lee and Dav Glass to the YUI Team

Mike LeeWe’re pleased to welcome two new members to the YUI team — Mike Lee and Dav Glass. Both are moving from other roles at Yahoo!, and each brings to the team a unique set of talents.

Mike has been at Yahoo! since 2002 and is among the small group of engineers who established frontend engineering as a discipline here. He has been an engineer and engineering manager for some of our most important sites, including yahoo.com and my.yahoo.com. He brings to YUI a passion for ensuring that what we build is what is most needed by web developers. One of our goals — really, a goal of all open-source projects — is to be more responsive to the community and more communicative about roadmaps, releases, and community processes. With his knowledge of the industry broadly as well as his depth as an engineer, Mike will help us do just that.

Dav Glass; photo by Steve CarlsonAlso joining the YUI team is Dav Glass. Dav is a well known figure in the YUI community already. As one of the most frequent contributors to our forums (with a staggering 307 helpful posts as of this morning), and as the author of one of the most useful YUI-oriented blogs, Dav has distinguished himself as an influential, talented, and prolific contributor to the project. Now that YUI has his full attention, we expect only more of the same. Dav, we couldn’t be happier to have you with us.

In addition to Mike and Dav, here’s a quick snapshot of where the YUI team stands today. Note: Someone asked me at conference the other day how big our "YUI documentation team" is. The answer: 0. The people listed here who engineer the library also write the docs, provide support in the forums, do tools development, and everything else that goes into supporting a project like YUI.

Name YUI Component Ownership
Satyen Desai Satyen Desai
  • Calendar
Jenny Han Donnelly Jenny Han Donnelly
  • AutoComplete
  • DataSource
  • DataTable
  • Logger
Todd Kloots Todd Kloots
  • Button
  • Container
  • Menu (video of Todd introducting the Menu Control)
Nate Koechley Nate Koechley
  • CSS Reset
  • CSS Fonts
  • CSS Grids
  Adam Moore
  • Event
  • Drag & Drop
  • Slider
  • TreeView
  • YAHOO Global Object
Thomas Sha Thomas Sha
  • Connection Manager
  • YUI project founder and director
Matt Sweeney Matt Sweeney
  • Animation
  • Dom
  • Element
  • TabView
By Eric MiragliaMarch 29th, 2007

YUI Theater — Doug Geoffray: “From the Mouth of a Screenreader”

Doug Geoffray of GW Micro presents 'From the Mouth of a Screenreader' at the Yahoo! FrontEnd Engineering Summit in March, 2007

We held our annual internal frontend engineering conference at Yahoo! earlier this month, and one of our invited guests was Doug Geoffray of GW Micro. Doug came by to teach Yahoo! frontend engineers about the history and current state of screen-reader support in software, including the nature of the current challenges we face developing screen-reader-accessible dynamic web pages. While this talk is historically comprehensive and covers a lot of ground related to how screen readers have evolved on the desktop, the context is important for us on the frontend as we begin to confront the same challenges that desktop software developers have been addressing for many years.

And Doug, of course, has been there all along, developing some of the earliest voiced applications for the Macintosh in the early 1980s and eventually founding GW Micro and becoming one of the most important guiding figures of the accessible software industry. (A few years ago, AFB AccessWorld did a profile of Doug with some nice detail about his background; please refer to that document for a more complete version of his biography.) Of late, Doug been a touchstone for us at YUI in the research and development of our Menu Control, a project that is helping us to lay a foundation for what is possible in terms of DHTML accessibility as YUI evolves. (Slides are available from a talk given by Doug and YUI Menu Control author Todd Kloots, “Designing RIA Accessibility: A YUI Menu Case Study.”.

Doug was kind enough to allow the YUI Theater team to record his talk, and we’re excited to share that with you here. The talk is divided into two parts (Part One, Part Two), with some excellent discussion about screen readers and web browsers in the second half of Part Two. Part One is embedded below:

Note: A downloadable and iPod-compatible MPEG version of this video is available for download. The .m4v file format we’ve used for this video (and many others in the YUI Theater) signifies that it is an MPEG-4 file with video; if you’re not downloading to view on an iPod, and/or are using a system that doesn’t recognize the .m4v extension, try renaming the file to .mp4.

By Eric MiragliaMarch 28th, 2007

YUI Implementation Focus: Dustin Diaz’s DED|Chain

Dustin Diaz authors /with Imagination, a hip and sage blog about the world of frontend engineering. Dustin is also a valued former Yahoo! colleague who, I’m sad to say, traded in the world of purple and yellow recently to strike out for new territory. Dustin recently released DED|Chain, a new JavaScript library that sits on top of YUI and allows you tap into YUI using the chaining syntax popularized by John Resig‘s excellent JQuery. We got together with Dustin to learn more about DED|Chain, his motivations in writing it, and where he hopes to take it in the future.

Many people are acquainted with your blog, /with Imagination; for those who may not read it as assiduously as we do at the YUI team, tell us a little bit about your background. When did you get started in programming? What drew you to frontend engineering, specifically?

(As I pour myself a nice tall glass of Widmer Hefeweizen Beer…) At CSU Sacramento, I was on track to receiving my Bachelor of Arts in Spanish, and a minor in Cultural Anthropology. I even wrote for the school newspaper (www.statehornet.com) as the assistant opinion editor. However during that journey I took Computer Science 01 (1999). That class taught me Q Basic and the power of goto. Aside from that, there was a two week portion of the class where the instructor taught us basic HTML. I was simply fascinated by the idea of having a webpage… so much that I spent the next six weeks working on making my webpage even cooler.

All that being said, that’s the only formal education I have in computer science. However, I do have a degree in a foreign “language.” Which perhaps made me more adept at writing in other languages.

The draw to frontend user interfaces is that frontend engineering just logically seems like the funnest place to be. But beyond that, it’s “web interfaces” that makes it most exciting. I don’t think I would have as much fun developing desktop applications simply because there is a removed layer that connects people. It is, in fact, building websites and web applications that hits the spot.

You’ve been writing JavaScript and writing about JavaScript for a
long time now, but DED|Chain is your first foray into the world of
JavaScript libraries. What motivated you to work on this project?

D|C started off as a plane ride sandbox experiment (I literally began the project on my laptop flying on an air plane). The motivation wasn’t exactly clear; I just felt like prototyping to get my mind off of things. One thing that did come to mind, however, was that when visiting new people at SxSW, many designers preferred jQuery over any other library hand over fist. It wasn’t because they thought it was sexy, or lightweight, or even cared that it had a stable development community around it. It was just easy to use with a very low learning curve.

JQuery engenders a lot of love among its users. As someone who
has studied JQuery in some depth, what (beyond John Resig’s genius)
do you think makes JQuery so special and unique? What is it about
the JQuery syntax that is so attractive to those of us who do web
development?

jQuery entails many sexy attributes that attracts several kinds of developers. It truly is the library for everyone. It’s object-oriented at heart, but has a procedural “get things done” interface. One of the biggest complaints I hear about YUI is the large namespaces. Comparatively speaking, YUI does it right, whereas jQuery gets it done. In today’s real-world development practices, web developers just want to get it done. People don’t want to think about OO structures, namespaces, closures, extending classes, and clever abstractions. The goals of both libraries are obviously vastly different. The core bread and butter of YUI is the utilities (not to say the widgets aren’t great), and it felt like YUI is the kind of library you can use to build something like jQuery, but not vice versa. The two have polar opposite design styles.

With D|C, I wanted to take the jQuery style and philosophy a step further, but build on top of Yahoo! UI. There are of subtle differences in some syntax choices; for instance, every callback in D|C is executed in the scope of the DED bolt (yes, I’m calling them DED bolts). A DED bolt is the outer-most selector from which each chain is derived. For instance in jQuery, you could have something like this:

$('#content a').click(function(){
  $.post(this.href, function(resp) {
  $('#result').append(resp);
});
  return false;
});

In DED|Chain, it would look like this:

_$('#content a').on('click', function(el) {
  _$('#result').populate(el.href);
}, true);

You could even take this a step further and make it a better user experience:

_$('#content a').on('click', function(el) {
  this.fetch(el.href, {
    before: function() {
      _$('#spinner').show();
    },
    after: function(resp) {
      _$('#spinner').hide();
      _$('#results').setContent(resp);
    }
  });
}, true);

If the _$ creeps you out, you can easily change the default namespace (just as you can with all methods in D|C).

DED.register({
  namespace: 'IAMSAM'
});

Now all chains begin with ‘IAMSAM’ instead of the default ‘_$’.

DED|Chain joined the ever-expanding JavaScript library world in the same week as
the library from another well-known name in the JavaScript community,
Dean Edwards and his Base2. In the YUI-related space, we’ve seen Jack Slocum’s YUI-EXT (now just EXT, and supporting not just YUI but JQuery, Prototype, and perhaps more in the future), Peter Michaux‘s Fork, and now DED|Chain. Have you given any thought to where you see DED|Chain evolving in the future?

I see DED|Chain becoming the library of choice for people who just want to get things done. By the same token, I’ve built in a simple mechanism for easy extendibility for plugin developers (or other people who get bored on plane rides). For instance, if someone wants to build in a cool tooltip script for D|C, they can do the following:

DED.extendChain('tooltip', function(config) {
  // make cool tooltip script
});

The behavior instantly becomes available in the chain and one can use it like any other method:

// keep in mind this plugin is not currently available
// it's only used as an example of what one could do
_$('#content a').tooltip({
  id: 'unique_id',
  duration: 2,
  pause: 0.5
});

If I’m a YUI user, how should I approach using DED|Chain at this
point — something to look at for immediate use? something to look at
now and as it evolves? something to roll up my sleeves and contribute
to?

D|C is easy to pick up. If you’re a seasoned Yahoo! UI developer, take a peek at the source and you’ll know exactly what’s going on. You might want to just start prototyping out simple pages and see how comfortable you are with chaining. One thing to keep in mind is the philosophy behind DED|Chain. Its main goal is take the cruft out of development, and have more fun while you’re writing code. The tagline is, of course, “Less cruft, more fun.” Every “cruft cruncher” method has a direct purpose to make your life easier. Take for instance YAHOO.util.Dom.setStyle, which allows you to set a style property directly on elements. One problem I always encountered when using setStyle was the inability to set multiple styles at once. Of course I could use something like YAHOO.util.Dom.addClass and YAHOO.util.Dom.removeClass, but in some situations it wasn’t ideal. So for this case, you could simply do the following in D|C:

_$('ul#nav li').setCSS({
  color: 'red',
  textTransform: 'uppercase',
  position: 'relative',
  left: '2px',
  fontFamily: '"trebuchet ms"',
 fontSize: '1.2em'
});

It encompasses the sexiness JavaScript developers like as well as the familiarity CSS authors know and love. In fact, JSON looks stuningly similar to CSS property values. They are both, in fact, just name:value pairs. And it’s that very detail that lets developers not have to think about screwball API’s that bridge JavaScript and CSS.

How good is the documentation at this point?

It is good, and it is accurate. At this point, however, I am more interested in putting up live examples of practical uses, of which I do not have many at the moment. Nonetheless, finishing the documentation was a very important goal based on a conversation I had with a good friend, Jim Rutherford, who teaches a web development class at a university in Canada. At a certain point in the class, he teaches JavaScript to his students and allows them to pick out a JavaScript library to get their hands dirty with and do a little trick here and there. He tells me that each semester since YUI has been released, 100% of his students pick YUI. I asked him why, and he simply replied “they have excellent documentation, and my students know what to do with that.”

As a former Yahoo of meretorious service, you’re familiar with
the corporate design mantra of “wow, delight, and love.” What about
DED|Chain will get implementers to the Wow stage and what is needed to
get them to the Delight state? How do you keep ‘em coming back and
finding true love and a sense of oneness with the DED|Chain’s
approach to solving problems?

D|C will hopefully give developers the “wow” factor simply by example. The goal of “cruft free, more fun” in all honesty was carefully worded. If developers aren’t saying “wow, you can do that?” I have failed. The example of setCSS would perhaps be one example that will hook in CSS authors because the syntax is near identical. The selector interface (thanks to Jack Slocum) is also a huge benefit that gives developers simplicity of DOM selection. We simply don’t want to see getElementById and getElementsByTagName. I truly think css selector and xPath selector interfaces are the future for any JavaScript library. In fact, I’m looking forward to seeing a YAHOO.util.Dom.getElementsBySelector (hint hint, Matt Sweeney). [Note: Matt Sweeney is the author of YUI's Dom Collection. -EM]

I think users of D|C will move onto delightness for the sheer fact that once they’ve learned it… they’re done learning. There’s no secret to DED|Chain. It works cross-browser, it’s customizable, and the interface is dirt simple. I wouldn’t be surprised if CSS developers begin building D|C plugins.

To the extent that you’re using YUI as a underlying framework
today, what do we need to do to help you ensure that DED|Chain
matures to the point of generating Wow, Delight and Love in all its
users?

Yahoo! needs to stay in business, and YUI needs to keep working. It cuts down on my own QA time, and also allows me to release headache free knowing that the underlying API from which I built it on “just works.” From a D|C user perspective, one doesn’t even have to know it’s built on Y! UI. For D|C Developers (people who modify the framework), it would be nice for you to keep your docs online, because much of the functionality is based on YAHOO.util.*.

What’s next for Dustin Diaz — beyond being a full-time blog author?

I’m co-authoring a book with Ross Harmes called “JavaScript Design Patterns” which is due sometime near September this year. We are both admittedly writing the book we’ve always wish existed, and Apress is helping us do that. This book is ironically targeted at intermediate to advanced JavaScript developers.

Usually I ask people what their pain points are working with
YUI. I’m going to turn that around this time and ask this instead: Was there
anything you learned about YUI in this process that inspired Wow,
Delight, and/or Love for you as you went about creating DED|Chain?

I love YUI, hands down. It works for me because it does exactly what I want out of a JavaScript library. It fixes the quirkiness that exists in JavaScript development across browsers. It’s not JavaScript’s fault, it’s browser implementations of it that are bad. YUI fixed it. On top of that, they’ve made utilities, not a cluster full of widgets (yes, I understand there are widgets). Basically what that means is that I learned that, contrary to what might possibly be YUI’s vision, I’ve always felt the goal of YUI was to give JavaScript developers the tools they need to build the “other” advanced interfaces they need to build. I can only hope D|C is reciprocal in the sense that D|C developers and users are working with something that allows them to “get stuff done.”

Do you have a YUI implementation that would be of interest to the YUI community? If so, please share your link and post a message to the community forum at YDN-JavaScript, or leave us a message in the comments section below.

By Eric MiragliaMarch 26th, 2007

Happy Birthday to the Pattern Library, Too!

We recently celebrated the one-year anniversary of the open-source release of the YUI Library. It is also the one-year anniversary of the public release of the Yahoo! Design Pattern Library. Not wanting to miss out on the fun, we published two new patterns: Calendar Picker and Alphanumeric Filter Links.

This is also a good opportunity to introduce myself. My name is Christian Crumlish. I am an information architect, interaction designer, writer, and the new curator of the Pattern Library. I think of myself as a pattern detective because a big part of my job is to uncover successful patterns on the Yahoo! network and “in the wild” and capture and document them for eventual publication in the Pattern Library.

I’ve got some big shoes to fill. Matt Leacock was our first pattern librarian, launched our internal pattern library, developed many of the earliest patterns, and established a structure and process for the library. Bill Scott oversaw the public release of the pattern library as you you probably remember from his posts on this blog and the slew of fantastic Ajax patterns (among others) that he shepherded into the library. Fortunately they’re both still nearby for me to hassle when I’m not sure what to do, as is Erin Malone whose leadership has driven the development and release of the library all along.

The two newest patterns

The Calendar Picker comes in handy when users need to select dates or date ranges. Probably the canonical scenario is travel planning. Airline reservation systems all use some variation on the calendar picker pattern and the best ones do a good job of anticipating the date vicinity, especially for the return portion of a round trip. The YUI Library has a Calendar control which this pattern complements.

Alphanumeric Filter Links sound deceptively simple: a common segmentation of large information repositories for easier navigation. (Of course this only works in alphabetic languages!) However, our internal review process uncovered a number of gotchas related to alphabetization and found a number of variations of this pattern to address distinct scenarios. Basic list filtering driven by text-links is so “Web 1.0″ so we’ll be sure to relate this context to Auto Complete and other dynamic ways of sorting and filtering long lists of data. As we build up the Pattern Library we’ll group them together under an umbrella parent pattern.

As always, we welcome discussion, feedback, and suggestions about these patterns on the ydn-patterns list. I’ll be announcing new pattern releases here on the YUI Blog, and will continue the series of exploratory posts and essays Bill Scott started. Together I expect we will contribute to the public discussion of design pattern, interaction design, information architecture, and user experience in general.

By Christian CrumlishMarch 5th, 2007

YUI Theater — “Browser Wars Episode II: Attack of the DOMs”

Browser Wars Episode II was moderated by Yahoo!'s Douglas Crockford; Chris Wilson attended on behalf of Microsoft, Hakon Lie on behalf of Opera, and Mike Shaver on behalf of Mozilla

On February 28, four estimable figures from the world of browser development and frontend engineering took the stage at Yahoo! for an event entitled “Browser Wars Episode II: Attack of the DOMs.” The goal was to get representatives from the IE team, Mozilla, Opera, and Apple’s Safari team together to talk about the reawakening of browser development after the long slumber of the IE6 era — a slumber that came to an end with the ascendance of Firefox from the ashes of Netscape, the birth of Safari on the open-source foundation of KHTML, and the increasing interestingness of Opera as a fast, robust browser running on myriad platforms. The Safari team declined to participate, but Yahoo!’s Douglas Crockford served as the moderator for a lively discussion between Chris Wilson of Microsoft, CTO Håkon Lie of Opera, and Mozilla’s Mike Shaver. The event was organized by the Silicon Valley WebBuilder group; attendendees filled our biggest presentation venue to standing-room-only capacity.

The YUI Theater team was there with cameras and we’re happy to be able to share with you the opening statements from all four participants.

Note: A downloadable and iPod-compatible MPEG version of the video will be up on YUI Theater later today. The .m4v file format we’ve used for this video (and many others) signifies that it is an MPEG-4 file with video; if you’re not downloading to view on an iPod, and/or are using a system that doesn’t recognize the .m4v extension, try renaming the file to .mp4.

Dion at Ajaxian has a nice writeup of some of the highlights from the video.

By Eric MiragliaMarch 5th, 2007

Free Excerpt: Nicholas Zakas on YUI Connection Manager, from Professional Ajax 2nd Edition

Yahoo!’s Nicholas Zakas is the author of two excellent books from WROX Press. His fist book, Professional JavaScript for Web Developers, is a volume we rely on at Yahoo! for internal training classes on JavaScript. Nicholas’s second book with WROX is Professional Ajax, the 2nd Edition of which has just been released.

In this new edition, Nicholas spends part of Chapter 4 exploring the YUI Connection Manager. He dives into its usage and steps through the implementation of asynchronous XMLHttp requests including the passing of arguments, form handling, callbacks, scope, timeouts and more. This chapter also includes a look at Connection Manager’s file upload feature. With his cogent style and clear examples, Nicholas provides a wonderful introduction to the Connection Manager and how to use it as the basis of your ajax-driven workflow.

We asked Wrox Sr. Acquisitions Editor Jim Minatel, Nicholas’s editor, if we could share a PDF version of this content on YUIBlog, and he graciously agreed. Thanks to Jim (and to Nicholas) for letting us make this available:

  • “Chapter 4: Ajax Libraries,” from Professional Ajax 2nd Edition by Nicholas Zakas, Jeremy McPeak, and Joe Fawcett (PDF, 716KB)
By Eric MiragliaMarch 2nd, 2007

Performance Research, Part 3: When the Cookie Crumbles

This article, co-written by Patty Chi, is the third in a series of articles describing experiments conducted to learn more about optimizing web page performance (Part 1, Part 2). You may be wondering why you’re reading a performance article on the YUI Blog. It turns out that most of web page performance is affected by front-end engineering — that is, the user interface design and development.

HTTP cookies are used for a variety of reasons such as authentication and personalization. Information about cookies is exchanged in the HTTP headers between web servers and browsers. This article discusses the impact of cookies on the overall user response time.

HTTP Quick Review

Cookies originate from web servers when browsers request a page. Here is a sample HTTP header sent by the web server after a request for www.yahoo.com:

  HTTP/1.1 200 OK
  Content-Type: text/html; charset=utf-8
  Set-Cookie: C=abcde; path=/; domain=.yahoo.com

The header includes information about the response such as the protocol version, status code, and content-type. The Set-Cookie is also included in the response and in this example the name of the cookie is “C” and the value of the cookie is “abcde”. Note: The maximum size of a cookie is 5051 bytes in IE 6.0 and 4096 bytes in Firefox 1.5.

The browser saves the “C” cookie on the user’s computer and sends it back in future requests. The “domain=.yahoo.com” specifies that the browser should include the cookie in future requests within the .yahoo.com domain and all its sub-domains. For example, if the user then visits finance.yahoo.com, the browser includes the “C” cookie in the request. Since an Expires attribute is not included in this example, the cookie expires at the end of the session.

Here is a sample HTTP header for finance.yahoo.com sent by the browser:

  GET / HTTP/1.1
  Host: finance.yahoo.com
  User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; ...
  Cookie: C=abcde;

Notice that the “C” cookie, originating from www.yahoo.com, is also included in the request for finance.yahoo.com.

Impact of cookies on response time

The performance team at Yahoo! ran an experiment to measure the impact of retrieving a document with various cookie sizes. The experiment measured a static HTML document with no elements in the page. The primary variable in the experiment was the cookie size. We ran the experiment using a test harness that fetches a set of URLs repeatedly while measuring how long it takes to load the page on DSL. The results are shown in Table 1.

Table 1. Response times for various cookie sizes
Cookie Size Median Response Time (Delta)
0 bytes 78 ms (0 ms)
500 bytes 79 ms (+1 ms)
1000 bytes 94 ms (+16 ms)
1500 bytes 109 ms (+31 ms)
2000 bytes 125 ms (+47 ms)
2500 bytes 141 ms (+63 ms)
3000 bytes 156 ms (+78 ms)

Note: Times are for page loads on DSL (~800 kbps).

These results highlight the importance of keeping the size of cookies as low as possible to minimize the impact on the user’s response time. A 3000 byte cookie, or multiple cookies that total 3000 bytes, could add as much as an 80 ms delay for users on DSL bandwidth speeds. The delay is even worse for users on dial-up.

How big are users’ cookies set at the .yahoo.com domain?

Cookies set at the .yahoo.com domain affect the overall response time for users visiting web pages across the Yahoo! network. Figure 1 shows the percentages of Yahoo!’s total page views with various cookie sizes set at the .yahoo.com domain.

Figure 1. Percentage of Page Views with Various Cookie Sizes

Figure 1. Percentage of Page Views with Various Cookie Sizes

About 80% of page views have fewer than 1000 bytes of cookies, which correlates to about a 5 to 15 ms delay for users on DSL bandwidth speeds. While the data shows that the majority of page views aren’t impacted by a significant delay, it also shows that about 2% of page views have over 1500 bytes of cookies set at the .yahoo.com domain. Although 2% sounds insignificant, at Yahoo! this translates to millions of page views per day, a compelling motivation for us to investigate this 2% and eliminate unnecessary cookies, reduce cookie sizes, and set cookies at more granualar domain levels.

In an earlier post about browser cache usage, one user made a comment about the side-effects of different browsers. Since Internet Explorer and Firefox have different implementations for the maximum size and number of cookies supported, we also analyzed the data by browser type and found no significant difference between the cookie sizes. It would be interesting to further investigate whether there is a difference in performance across browsers.

Analysis of Cookie Sizes across the Web

To show how Yahoo!’s cookie usage relates to those of other companies, we analyzed the cookies set by other popular web sites. For this experiment, we cleared all our cookies and visited only the home pages of these web sites. Table 2 shows between 60 and 500 bytes of cookie information included in the HTTP headers.

Table 2. Total Cookie Sizes
  Total Cookie Size
Amazon 60 bytes
Google 72 bytes
Yahoo 122 bytes
CNN 184 bytes
YouTube 218 bytes
MSN 268 bytes
eBay 331 bytes
MySpace 500 bytes

Note: We only requested the home page.

The data in Table 2 reflects only cookies set at the top domain levels to eliminate any cookies that may have been set by ads. The total cookie size for Yahoo! (122 bytes) in Table 2 differs from the cookie sizes indicated in Figure 4 because in this experiment we visited only the home pages of each web site. The data in Figure 4 reflect real users, many of whom visit multiple Yahoo! web pages. To illustrate, if tv.yahoo.com and movies.yahoo.com wanted to share information within a cookie, the cookie must be set at the .yahoo.com domain. The total cookie size set at the .yahoo.com domain for a user who visits multiple Yahoo! sub-domains is typically higher than the total cookie size set for a user who only visits www.yahoo.com.

Setting cookies at the appropriate path and domain is just as important as the size of the cookie, if not more. A cookie set at the .yahoo.com domain impacts the response time for every Yahoo! page in the .yahoo.com domain that a user visits.

Takeaways

  • Eliminate unnecessary cookies.
  • Keep cookie sizes as low as possible to minimize the impact on the user response time.
  • Be mindful of setting cookies at the appropriate domain level so other sub-domains are not affected.
  • Set an Expires date appropriately. An earlier Expires date or none removes the cookie sooner, improving the user response time.
By Tenni TheurerMarch 1st, 2007

Pages

  • About
  • Contribute
  • YUI Jobs

Recent Posts

  • YUI Weekly for May 17th, 2013
  • Yahoo’s International Team Is Hiring!
  • YUICompressor 2.4.8 Released
  • YUI 3.10.1 Released to Fix SWF Vulnerability
  • YUI Weekly for May 10th, 2013

Archives

Categories

  • Accessibility (25)
  • CSS 101 (6)
  • Design (51)
  • Development (590)
  • Frontend Jobs at Yahoo (13)
  • Graded Browser Support (8)
  • In the Wild (63)
  • Miscellany (11)
  • Open Hours (44)
  • Performance (23)
  • Releases (25)
  • Target Environments (11)
  • Yeti (3)
  • YUI 3 Gallery (29)
  • YUI Events (45)
  • YUI Implementations (55)
  • YUI Theater (146)
  • YUI Weekly (37)

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
© 2013 YUI Blog