A marked change has occurred since the first Velocity Conference a year ago, and while the effects are not yet obvious, they will be. The web is still slow, but we have something now, that we didn’t a year ago: business metrics. This was the year we quantified the impact of performance choices on our businesses, and the results were astounding.

Those of us who worked in the field had a gut feeling that users want a fast web experience, but most of the studies done previously were lacking something, either in experiment design or reliability of the data. They were all strong indicators that more research needed to be done, but they weren’t damning enough to provide real certainty. This year we found a real correlation between websites speed and its ability to establish and keep relationships with visitors. Not everyone could attend, so I’d like to share with you some of the key moments of an amazing conference. Please feel free to add others in the comments.

David Artz at AOL

David Artz from AOL presented their findings from a study which measured page views per visit against performance. They divided users into buckets based on response time and plotted it against PV. The results were startling. Across six AOL sites there was a clear inverse correlation.

The take away: AOL

Users who had a slower experience view far fewer pages.

Goog and Bing sitting in a tree, K-I-S…

Goog and Bing got together (whoa!) to do a study looking at search behavior when performance is worsened over very narrow increments. This study was unique particularly because it followed the same users over a period of time. The data can be used to determine the threshold at which clicks, refined searches, revenue, satisfaction, and time to click are likely to be impacted by features which slow a website. Their methodologies were a bit different, but the conclusions were remarkably similar. A 50MS delay seemed to have no impact, but as little as 200-500MS changed user behavior across the board. Revenue, clicks, and time to first click were most profoundly impacted.

The Take Away: Bing

One key point was that users seem to lose their focus if you make them wait too long. Progressive rendering and flushing the header (which are also recommended by Yahoo!) can help. Bing had this to say:

Notice that as the delays get longer the Time To Click increases at a more extreme rate (1000ms increases by 1900ms). The theory is that the user gets distracted and unengaged in the page. In other words, they’ve lost the user’s full attention and have to get it back.

~ Google & Bing

We’ve all experienced that. We open a new tab and run a search. Multitasking fools that we are, we flip to a new tab or open our email if the results take too long to load.

The Take Away: Google

The most interesting data to come out of the Google tests took place long after the experiment had finished. As much as five weeks later, some users, especially those who saw delays greater than 400MS, were still searching less than before. Performance is a feature users want. Fail them, and they may never come back.

The % change recorded was very small. For instance, a half a second delay caused a -1.2% loss of revenue per user. What does that mean? We need to think big, and simultaneously work on incremental and profound ways to make the web faster.

Shopzilla – Profound improvements

Shopzilla also presented their (profound) performance improvements. They decreased their response time by around 3.5 seconds and the data showed their conversions increased by 7-9% and their page views skyrocketed 25%. This is good stuff. This is how we go to business and make the case that performance is an important feature that deserves attention, not a band-aide that you stick on afterwards. Dave Artz has more details.

JavaScript versus CSS versus Network Latency: Which is killing our sites?

In a separate session with Mike Belche from the Chrome team, he discussed his experiments which tested total time spend on executing JavaScript, rendering the page (CSS), and network latency. He said the vast majority of the time is being spent on network latency. There was a subtle flaw in his methodology, because his rendering time included only one full rendering and painting, because all resources were already in cache and no JavaScript was used, there would be no unnecessary reflows.

The Take Away: Reflows

This got me thinking about images and other fixed dimension media. We should always set height and width of images to avoid reflows being caused when the resource is finally downloaded and available.

I agree with him that, except in extreme cases (and a lot of selector/reflow experiments have been too extreme to really reflect reality), rendering will be much less important that network latency. It is much more important to keep page weight and HTTP requests as low as possible. Over-complicating our CSS selectors to reduce render time would be a mistake. Browsers are really good at parsing selectors, we need to be really good at writing the minimum number we actually need. This is clearly missing not handled correctly in the current suite of testing tools such as Page Speed.

My talk included (not yet released) suggestions for coding performant selectors. More on that later.

Further Reading

• Aladdin Nassir spoke about linking performance and business metrics via Performance-Based Design.
• Lindsey Simon spoke about reflows and an open source tool he is building to better measure these things. The methods for accurately measuring reflows are still a WIP, and the numbers are fuzzy, but that makes this a really interesting project to get involved in.

When Stoyan and I created Smush.it we were scratching our own itch. As web developers we had spent way too much time optimizing images by hand, and we thought there must be a better solution. Optimizing images was far more important to overall site performance than people were giving it credit for being. Stoyan found that on average 50% of page weight was comprised of images, and that often those images were 30-40% larger than they needed to be. That translated to a lot of image bloat dragging down the web.

When we released Smush it at The Ajax Experience last year we were really excited to see what people did with it; building on the APIs to create a WordPress extension and other cool tools. Since the release we’ve smushed millions of images and put the web on a much needed diet.

Today is a great day for Smush it because Yahoo! decided to accept it into their family of tools. This will allow the tool to run on fanatically maintained servers, with the Yahoo! style quality of service. It doesn’t get any better than that. I feel like my baby is all grown up and going off to college!

Want to Optimize Images like a Pro?

Stoyan and I have contributed a chapter to Even Faster Web Sites, that outlines all the fantastic tricks you can use to make your sites smaller. We hope you find it useful, and of course we welcome feedback! It will show you how to make image optimization part of your own system, and give you all the information you need to make images as small as possible.

What’s changed?

They’ve been doing all the quiet background work to get things set up at Yahoo!. In addition, Smush.it functionality has been included in YSlow 2.0 (now in beta!), so you can get all of your performance information in one place. You’ll start seeing changes in look at feel, but Yahoo! assures us the APIs and functionality won’t change. We are proud that this tool has helped so many people improve their site performance. Thank you all for supporting us and using Smush.it.

You can help Yahoo! by providing feedback for Smush.it on their mailing list.

My favorite Smush it story

Jaydee, a web developer in Singapore, came to my two-day boot camp. On day one, he heard about optimizing images, when he came back on day two he had already smushed all the images on his site and pushed the changes live. He showed a fantastic commitment to making the Yahoo user experience even faster.

I first started thinking about reflows and repaints after a firey exchange with Mr. Glazman at ParisWeb. I may be stubborn, but I did actually listen to his arguments. Stoyan and I began discussing ways to quantify the problem.

Going forward the performance community needs to partner more with browser vendors in addition to our more typical black box experiments. Browser makers know what is costly or irrelevant in terms of performance. Opera lists repaint and reflow as one of the three main contributors to sluggish JavaScript, so it definitely seems worth a look.

Let’s start with a little background information. A repaint occurs when changes are made to an elements skin that changes visibility, but do not affect its layout. Examples of this include outline, visibility, or background color. According to Opera, repaint is expensive because the browser must verify the visibility of all other nodes in the DOM tree. A reflow is even more critical to performance because it involves changes that affect the layout of a portion of the page (or the whole page). Reflow of an element causes the subsequent reflow of all child and ancestor elements as well as any elements following it in the DOM.

For example:

<body>
<div class=”error”>
	<h4>My Module</h4>
	<p><strong>Error:</strong>Description of the error…</p>
	<h5>Corrective action required:</h5>
	<ol>
		<li>Step one</li>
		<li>Step two</li>
	</ol>
</div>
</body>

In the html snippet above, a reflow on the paragraph would trigger a reflow of the strong because it is a child node. It would also cause a reflow of the ancestors (div.error and body – depending on the browser). In addition, the h5 and ol would be reflowed simply because they follow that element in the DOM. According to Opera, most reflows essentially cause the page to be re-rendered:

Reflows are very expensive in terms of performance, and is one of the main causes of slow DOM scripts, especially on devices with low processing power, such as phones. In many cases, they are equivalent to laying out the entire page again.

So, if they’re so awful for performance, what causes a reflow?

Unfortunately, lots of things. Among them some which are particularly relevant when writing CSS:

• Resizing the window
• Changing the font
• Adding or removing a stylesheet
• Content changes, such as a user typing text in
  an input box
• Activation of CSS pseudo classes such as :hover (in IE the activation of the pseudo class of a sibling)
• Manipulating the class attribute
• A script manipulating the DOM
• Calculating offsetWidth and offsetHeight
• Setting a property of the style attribute

Mozilla article about reflows that outlines causes and when they could be reduced.

How to avoid reflows or at least minimize their impact on performance?

Note: I’m limiting myself to discussing the CSS impact of reflows, if you are a JavaScripter I’d definitely recommend reading my reflow links, there is some really good stuff there that isn’t directly related to CSS.

1. Change classes on the element you wish to style (as low in the dom tree as possible)
2. Avoid setting multiple inline styles
3. Apply animations to elements that are position fixed or absolute
4. Trade smoothness for speed
5. Avoid tables for layout
6. Avoid JavaScript expressions in the CSS (IE only)

Change classes as low in the dom tree as possible

Reflows can be top-down or bottom-up as reflow information is passed to surrounding nodes. Reflows are unavoidable, but you can reduce their impact. Change classes as low in the dom tree as possible and thus limit the scope of the reflow to as few nodes as possible. For example, you should avoid changing a class on wrapper elements to affect the display of child nodes. Object oriented css always attempts to attach classes to the object (DOM node or nodes) they affect, but in this case it has the added performance benefit of minimizing the impact of reflows.

Avoid setting multiple inline styles

We all know interacting with the DOM is slow. We try to group changes in an invisible DOM tree fragment and then cause only one reflow when the entire change is applied to the DOM. Similarly, setting styles via the style attribute cause reflows. Avoid setting multiple inline styles which would each cause a reflow, the styles should be combined in an external class which would cause only one reflow when the class attribute of the element is manipulated.

Apply animations with position fixed or absolute

Apply animations to elements that are position fixed or absolute. They don’t affect other elements layout, so they will only cause a repaint rather than a full reflow. This is much less costly.

Trade smoothness for speed

Opera also advises that we trade smoothness for speed. What they mean by this is that you may want to move an animation 1 pixel at a time, but if the animation and subsequent reflows use 100% of the CPU the animation will seem jumpy as the browser struggles to update the flow. Moving the animated element by 3 pixels at a time may seem slightly less smooth on very fast machines, but it won’t cause CPU thrashing on slower machines and mobile devices.

Avoid tables for layout (or set table-layout fixed)

Avoid tables for layout. As if you needed another reason to avoid them, tables often require multiple passes before the layout is completely established because they are one of the rare cases where elements can affect the display of other elements that came before them on the DOM. Imagine a cell at the end of the table with very wide content that causes the column to be completely resized. This is why tables are not rendered progressively in all browsers (thanks to Bill Scott for this tip) and yet another reason why they are a bad idea for layout. According to Mozilla, even minor changes will cause reflows of all other nodes in the table.

Jenny Donnelly, the owner of the YUI data table widget, recommends using a fixed layout for data tables to allow a more efficient layout algorithm. Any value for table-layout other than "auto" will trigger a fixed layout and allow the table to render row by row according to the CSS 2.1 specification. Quirksmode shows that browser support for the table-layout property is good across all major browsers.

In this manner, the user agent can begin to lay out the table once the entire first row has been received. Cells in subsequent rows do not affect column widths. Any cell that has content that overflows uses the ‘overflow’ property to determine whether to clip the overflow content.

Fixed layout, CSS 2.1 Specification

This algorithm may be inefficient since it requires the user agent to have access to all the content in the table before determining the final layout and may demand more than one pass.

Automatic layout, CSS 2.1 Specification

Avoid JavaScript expressions in the CSS

This rule is an oldie but goodie. The main reason these expressions are so costly is because they are recalculated each time the document, or part of the document, reflows. As we have seen from all the many things that trigger a reflow, it can occur thousands and thousands of times per second. Beware!

Further study

The Yahoo! Exceptional Performance team ran an experiment to determine the optimal method to include an external stylesheet. We recommended putting a link tag in the head because, while it was one second slower (6.3 to 7.3 seconds) all the other methods blocked progressive rendering. While progressive rendering is non-negotiable (users hate staring at a blank screen), it does make me curious about the effects of rendering, repaints, reflows and resulting CPU thrashing on component download and overall response time. If we could reduce the number of reflows during loading could we maybe gain back a tenth of the lost time (100ms)? What if it was as much as half?

At SXSW I was trying to convince Steve that reflows are important by telling him about an experiment I’ve been meaning to run for a long time, but just haven’t had time. I do hope someone can pick up where I left off (hint! hint!). While loading the page I’d like to intentionally trigger reflows at various rates. This could perhaps be accomplished by toggling a class name on the body (experiment) versus the last child of the body with no descendants (control). By comparing the two, and increasing in the number of reflows per second, we could correlate reflows to response time. Measuring the impact of reflows on JS responsiveness will be harder because anything we do to trigger the reflows will likely impact the experiment.

In the end, quantifying the impact is only mildly interesting, because browser vendors are telling us it matters. Perhaps more interesting is to focus on what causes reflows and how to avoid them. That will require better tools, so I challenge browser vendors and the performance community to work together to make it a reality!

See it in action

Perhaps you are a visual person? These videos are a really cool visualization of the reflow process.

1. http://www.youtube.com/watch?v=nJtBUHyNBxs

2. http://www.youtube.com/watch?v=ZTnIxIA5KGw

3. http://www.youtube.com/watch?v=dndeRnzkJDU

Reflow gone amok

In order to improve performance browser vendors may try to limit reflows from affecting adjacent nodes or combine several reflows into one larger change such as Mozilla’s dirty reflows. This can improve performance, but sometimes it can also cause display problems. You can use what we’ve learned about reflows and trigger them when necessary to correct related display problems.

For example, when toggling between tabs on our image optimization site, http://smush.it, the height of the content is variable from tab to tab. Occasionally the shadow gets left behind as it is several ancestor nodes above the content being toggled and its container may not be reflowed. This image is simulated because the bug is difficult to catch on camera as any attempts to shoot it cause the reflow that corrects it. If you find yourself with a similar bug, move the background images to DOM elements below the content being toggled.

Smush it on tab change in Firefox only.

Another example is dynamically adding items to an ordered list. As you increase from 9 to 10 items or 99 to 100 items the numbers in the list will no longer line up properly across all navigators. When the total number increases by an order of magnitude and the browser doesn’t reflow siblings, the alignment is broken. Quickly toggling the display of the entire list or adding a class, even if it has no associated styles, will cause a reflow and correct the alignment.

Tools

A few tools have made waves lately. Stoyan Stefanov and I have been looking for decent ways to measure reflows and repaints and there are a few tools which show promise (despite being very early alpha). Beware, some of these seriously destroyed my browser before I got them working correctly. In most cases you’ll need to have installed the latest nightly builds.

When Mozilla announced the MozAfterPaint Firefox API, the internets were abuzz.

• UPDATE: Lindsey Simon at Google wrote a bookmarklet that tests reflow times on any browser. Fantastic. (Note: all that shaking is normal!)
• John Resig wrote a bookmarklet to visualize paint events.
• Kyle Scholz created this tool to visualize paint events before onload.
• Alex at Yoono has created the XUL profiler.

Has anyone else seen any cool tools for evaluating reflows? Please send them my way!

And a couple other tools not directly dealing with reflows.

• IE Visual Roundtrip Analyzer (VRTA), because if Microsoft named it something fun we might actually want to use it.
• Performance Profiling Tools for WPF.

Ultimately, we need a cross browser tool to quantify and reduce reflows and repaints. I’m hoping that the performance community can partner with browser vendors to make this tool a reality. The browser vendors have been telling us for a while that this was where we needed to look next, the ball is in our court.

Object Oriented CSS: for high performance websites and web applications.

Find out more about object oriented css

1. Open source project on github (GIT is having some DNS issues, be patient)
2. Follow along with the slides on slideshare
3. Join the OOCSS google group

Thanks to Havi, Julie, Ricky, Yahoo! Developer Network, and the whole Web Directions North team for their hard work putting this together!

I recently presented Object Oriented CSS for high performance web applications and sites at Web Directions North 2009. If you didn’t attend my talk, you are probably asking yourself “what in the world is OO-CSS?”

Object Oriented CSS: Two main principles

1. Separate structure and skin
2. Separate container and content

I’m writing a framework to demonstrate the technique, but more than anything, Object Oriented CSS is a different way of approaching CSS and the cascade. It draws on traditional software engineering concepts like extending objects, modularity, and predictability. Solutions are judged based on their complexity, in other words, “what happens to the size of the CSS file as more pages and modules are added?”

The answer, for most sites, is that it grows out of control and becomes an unmaintainable tangle of spaghetti code. People often complain about CSS, and rightly so — even though it inspired a rant, I understand their frustration.

Current methods for writing CSS require expert level ability just to get started. To become a CSS expert, you need to spend couple years coding away in your basement by yourself before you are remotely useful. Front-end engineering needs to accomodate entry level, mid level, and architect level developers, but our sites are too brittle. You may have a perfectly accessible or high performance website, and then the first newbie to touch it, ruins it. Our code should be robust enough that newbies can contribute while maintaining the standards we’ve set.

We don’t trust each others code

Imagine a JavaScript developer wrote a function to return area, and every now and then it randomly returned the diameter instead. The function would never make it through a code review, and yet we tolerate the same thing from CSS, as if it were immune from normal programming best-practices. This is why CSS code reuse is almost nonexistent. An object should behave predictably no matter where you place it on the page, which is why Object Oriented CSS avoids location dependent styles.

What not to do

#myModule h2{...}
#myModule span{...}
#myModule #saleModule{...}
#myOtherModule h3{...}
#myOtherModule span{...}

Developers have tried to sandbox their CSS into individual modules, to protect against the cascade. But in doing so we’ve ended up with a mess.

Object Oriented CSS Grids on github

My Object Oriented CSS grids and templates are open sourced on github. They have all the functionality of YUI grids plus some important features.

• Only 4kb, half the size of YUI grids. (I was totally happy when I checked the final size!)
• They allow infinite nesting and stacking.
• The only change required to use any of the objects is to place it in the HTML, there are no changes to other places in the DOM and no location dependent styling. Eases back-end development and makes it a lot easier to manage for newbies.
• Solution for sub-pixel rounding errors.

http://wiki.github.com/stubbornella/oocss

Check out template.css and grids.css and the docs on the github wiki.

My prediction is that you’ll be writing complex layouts in less than 24 hours without adding a line to the CSS file.

What’s up next?

Template and grids are ready for rock and roll. Please be my alpha testers, put them through their paces. Let me know if you find bugs or want additional functionality. I’m also hoping to contribute some of this back to YUI since they now have a github repository. How cool is that?

Rounded Corner Boxes and Tabs

Next up, modules. There are a million cool ways to create rounded corner boxes. I’m going to take several of my favorites (like CSS Mojo and Arnaud Gueras blocks) and convert them to OO-CSS. This will make it super easy for newbies to create their own modules, without needing to understand the minutiae of browser differences.

Video / Podcasts

YDN will publish a video of my talk and Web Directions North is putting out podcasts. I’ll tweet and post when that happens. The audio contains a lot more detail than the slides, so check it out as they become available.

The cascade is something like a new data structure, and the ways for dealing with it are algorithms you never learned in school. You couldn’t have, because traditional engineering school poo-poos the front-end and web engineering in favor of stale (but still valuable) traditional software engineering.

JavaScript

Perhaps you realized this web thing wasn’t going away, so you learned a bit of javascript. That went OK, how hard is it to add another language to your repertoire? Now you just wish it would compile like a proper language. You hate the browsers, and (foolishly) wish there was only one. You find Ajaxian, and start thinking of yourself as super-engineer; the guy who can just as easily write a web UI as a cronjob to perform background data processing.

CSS

With the confidence of JavaScript success, you decide to tackle CSS, and then the problems begin. You start from scratch rather than using a library, because after all this is just a display syntax. (Do you also rewrite the math class every time you need a random number generated?) You don’t bother to learn proper semantic HTML, they must be joking! Nattering on about web standards and accessibility. It should be cake.

Nothing works as you expect it to. Your columns won’t line up. You never validated your HTML, and you have a sneaking suspicion that there is an unclosed tag somewhere. You can’t make even the simplest design look right, and you are pretty sure CSS is to blame, rather than your understanding of the technology. This should be just another acronym on your resume, right?

No. Resoundingly, no.

Calculating Complexity

Take for example, calculating the complexity of a given solution. If you were to calculate O(n) in CSS, n is adding more pages and modules to the site. What happens to the size of the CSS file? It goes up, right? But does it grow like a fifteen year old boy? If so, you’ve found the CSS equivalent of O(n^2). When you keep that stylesheet lean and mean by effectively using the cascade, the fundamental solutions are algorithms, but no, your engineering professors won’t have mentioned them.

If you did manage to get a site up and running, you’ve noticed how fragile your code is. You touch it on one side and it breaks somewhere else entirely. You try to sandbox individual components to prevent this, and your CSS file just keeps getting larger. It is unmanageable, unmaintainable, and it doesn’t scale. Again, you think, CSS sucks, with all these inherent flaws.

Communication Breakdown

You think of people who do know CSS as designers, not giving any credit to the engineering prowess required to tame the stylesheet of a multinational corporation because (self-taught as they are) most true front-end gurus don’t speak the same language as you do. Their skill appears to be a black-art, some kind of magic, or internalized instinct for browser flaws. This is your guess anyway, because you simply can’t communicate with them. They didn’t go to the right school, or maybe they studied japanese modern literature instead of databases and sorting algorithms.

Furthermore, you don’t understand why it is so hard to hire them. You said to me once, “I can sit at the exit of the best engineering schools in the country and scoop up software engineers, but I have no idea how to find you people!”. You’ve been writing CSS yourself for a couple weeks, so you decide you are ready to hire a web developer / designer / front-end engineer. The role is pretty unclear, but in your organization they’ll either be alone in a team full of software engineers, or they’ll report to the Artistic Director in the marketing department. You’ll give them goals like “learn SQL” or “some C++ would be really helpful”.

I once said in an interview, “If we talk about what I know, we’ll arrive at the limits of your understanding very quickly, and if we talk about what you know, we’ll arrive at the limits of my understanding very quickly. So what do we talk about?”. The engineer interviewing me took it well, and I was even more impressed with the company.

By now you have 3-4 weeks of CSS under your belt and you can confidently say, “CSS sucks, our organization will use tables.” Excellent choice grasshopper, if you can’t win, blame the game.

An attempt at a solution

We need your help. Web development and client-side technologies need a dose of best-practices from software engineering. We don’t need you to solve problems for us, nor will our solutions necessarily be the same as yours, but we need to learn from you rather than reinventing the wheel, so that the front end can mature as a proper engineering discipline.

This is virtually impossible unless we develop a mutual respect for each others’ skills, and software engineers make an effort to understand what makes a good front-end engineer. Hint: it may not be exactly the same skill set, and certainly not the same technologies. Like it or not, managers tend to be software engineers, and you need to understand how to work with your developers to improve the state of the art.

Hiring

You might be an engineering manager, with a self-taught front end engineer sitting before you in a fish bowl conference room you use for interviews. Look for:

• A sense of design, attention to aesthetics. Tattoos, weird hair, artistic hobbies, or slight OCD are good things to look for here. They need to care that the h3 are 1px off from where they should be. [1]
• Semantics and clean HTML – foundational, if they don’t have this, be very afraid. If you hear DIV DIV DIV, be very afraid. Note: you may need to study up yourself to judge this. I print out a mockup (psd for example) that I am currently building and ask them to draw squares on the paper representing the different HTML tags. I draw a box around one paragraph to get them started. I’m not looking for perfection, just the ability to comprehend the difference between the meaning of things and the display.
• Approach and problem solving – make the problem concrete and visual if possible, move slowly toward more abstract questions to judge their ability to generalize a solution.
• Algorithmic mind – assume no prior knowledge of traditional algorithms, but they should be able to understand algorithms you’ve explained and tie that back into the code they write. Again, make it visual.
• Complexity and scalability – they might not be thinking in this way (yet!), but if you talk about what happens if there are thousands of pages or an unknown number of user generated modules they should be able to explain the failure points of their code.
• Experience – Be aware of the team the developer will join. If they are alone, you can’t hire a beginner. Their skills won’t develop, and you will be frustrated by the fragility of the code they write.

To solve the communication difficulties, think:

“My web developer is smart, so smart she learned a kind of engineering for which there is no school. The technologies she knows are as relevant, complicated, and legitimate as those with which I am more comfortable. I may never be an expert in those areas, but I can help her learn the vocabulary of algorithms, complexity, modularity, and scalability so that she can write better and better code. Furthermore, I will never again say that CSS sucks rather than admitting my own discomfort with a different problem space.”

Stay after school and write that last line on the board 100 times.

CSS doesn't suck.

CSS can be predictable, scalable, modular and even object oriented. If it is written correctly, beginners can be productively participating in creating clean, reusable code in 2-3 weeks. It is simply a matter of changing our approach, understanding that the fundamental algorithms for a display language are different than a programing language, and borrowing everything we can from software engineering, so that we don’t spend time reinventing the wheel.

And If you still want to be an F2E?

Check out this F2E skills list presented by Leslie Jensen-Inman at Web Directions North as a part of her dissertation on the state of web education. Note: even the non-acronyms count as skills.

[1]Thanks to Nick Fogler of Juku at Yahoo! for his ideas on aesthetics and F2Es.
[2] The Ajaxian post that made me feel like ranting: http://ajaxian.com/archives/css-for-layout-another-rant

I visited Yahoo! last week to record a talk I had given at the Front End Summit in October. If you are a designer or an F2E it is essential that you understand the ways in which design choices impact overall site performance. This talk establishes guidelines for High Performance Design including 9 Best Practices.

9 Best Practices

1. Create a component library of smart objects.
2. Use consistent semantic styles.
3. Design modules to be transparent on the inside.
4. Optimize images and sprites.
5. Avoid non-standard browser fonts.
6. Use columns rather than rows.
7. Choose your bling carefully.
8. Be flexible.
9. Learn to love grids.

Baby Steps to a Faster Site

In honor of the video being made available on YUI theater, I’ve removed the non-standard browser fonts from my site. While the design was changed slightly it is infinitely more maintainable and I also eliminated an unnecessary HTTP request at the same time. One more step to a faster page.

Web Directions North, Denver, February 2-7

I’ll be speaking more about Design and also CSS best practices at Web Directions North in February where I’ve been invited to give both a Performance Bootcamp Workshop and a CSS Performance for Websites and Web Apps Presentation. I look forward to seeing you there!

They have some really amazing speakers lined up. I’m especially excited to talk to Dan Cederholm, who wrote one of my favorite books.

Nous aborderons les principales problématiques et les solutions à mettre en œuvre. Forts de l’expérience de l’équipe performance de Yahoo!, à la fin de cette session vous saurez aborder la question des performances Web du point de vue du visiteur et mettre en œuvre les actions correctrices sur vos sites Web.

Video de la presentation (dailymotion)

Slides de la presentation (slideshare)

I’m at Ajax Experience this week with my teammate, Stoyan Stefanov. This morning we did a lightning-demo of our new tool SmushIt.com. Smush it allows you to automate image optimization by using the best of open source algorithms to achieve the smallest, high performance images possible.

Smush it comes in different flavors:

• You can upload a bunch of pictures in your browser
• You can provide us with a list of image urls or
• You can get a Firefox Extension to optimize the images found on any web page

Our fundamental principal was that the images we produced needed to be 100% pixel for pixel faithful to the original quality. That means that our techniques are completely lossless. We decided to let designers decide what quality level was necessary, then, given that quality, we use the best open source compression algorithms to make the image as small as possible.

Smush it also generates a zip so that you can easily download and replace all of the images in your page.

The tool smushes your images in several ways and outputs the best result, or gives you a bravo if your images are already optimized. Some of the options we test are:

• Crush PNG
• Convert GIF to PNG
• Convert JPG to progressive JPG
• Remove Metadata
• Compress animated GIF

We would love feature requests, bugs, or suggestions so that we can improve the tool. I am nicole at my domain. At Ajax Experience I showed the tool on Korea Yahoo, BBC News, and Barack Obama’s site. Can you guess who had over 300K of useless image bloat?

Modern sites are doing more than they ever have before, this tool will help keep them lean, mean, and (of course) fast.

Christian Heilmann recorded a video of our demo for YDN. The audio is a bit wonky, I’ll link to the official AE recordings as they become available.