Raible Designs

Thursday July 24, 2008

[OSCON 2008] Even Faster Web Sites by Steve Souders Steve works at Google on web performance and open source initiatives. To begin his talk, Steve is running YSlow in "autorun" mode. This runs YSlow Performance tests on the top 100 sites according to Alexa. Before Google, Steve was at Google for 7 years. You can download Steve's slides from his site (don't ask me where).

iGoogle with an empty cache: 9% of the time is spent getting the HTML document. The % of time of what a webserver does is a pretty small percentage of the overall picture. If the cache is primed, the time goes up to 17% of the time.

80-90% of the end-user response time is spent on the frontend. Start there.

There's a greater potential of improvement on the frontend. If you improve the backend performance by 50%, chances are the end-user only sees a 5% improvement.

The 14 Rules are encapsulated in the YSlow plugin. At OSCON last year, Yahoo released YSlow. 500,000 downloads since it was released. Following the release of YSlow, Steve wrote High Performance Web Sites.

High Performance Web Sites, Vol 2. The 3 most important rules are:

• Split the initial payload
• Load scripts without blocking
• Don't scatter inline scripts

Why focus on JavaScript? A lot of the top sites use JavaScript. For example, up until a few weeks ago, Facebook served up 1MB of JavaScript, uncompressed. Scripts block parallel downloads and page rendering. To see it in action, go to http://stevesouders.com/cuzillion/?ex=10008.

Any content below a <script> is blocked from rendering - even if it's already cached in the browser. Cuzillion is an open source project that Steve is releasing that allows you to add components to a page and test their performance.

Split your JavaScript between what's needed to render the page and everything else. Load "everything else" after the page is rendered. To do this, you can use Firebug to do it manually, or you can use Doloto from Microsoft to automate the splitting of your files.

MSN.com solves the script blocking problem by using JS DOM to allow for parallel downloading. There's 6 techniques for doing this:

• XHR Eval (must have same domain as page)
• XHR Injection (same domain)
• Script in iFrame (same domain)
• Script DOM Element (domains can differ)
• Script Defer (only supported in IE, domains can differ)
• document.write (not recommended, parallelization only works in IE)

How do these techniques cause "browser busy" indicators? XHR Eval and Injection don't trigger any indicators. You need to choose when you want to show busy indicators. It's good to show them when you want to show your users that something is processing (but not for lazy-loading JavaScript that's not required for load). For the different techniques, most don't ensure order of parsing.

Based on 3 factors, Steve can tell you which technique is best to use. These three factors are 1) the URL of the page and script 2) if you want busy indicators and 3) if you care about order. Steve thinks it would be awesome if web frameworks could support this to write out JavaScript appropriately for the developer's input.

Long executing inline scripts block rendering and downloads. If you know you're going to have scripts like this, you can solve it with a couple workarounds:

• Initiate execution with setTimeout(>250 for Firefox)
• Move JavaScript to enternal script with advanced downloading techniques
• Use defer attribute for IE

In Firefox 2, stylesheets block parallel downloads just like scripts. IE doesn't. However, IE will block when you have a stylesheet followed by an inline script. To solve, it's best to move line scripts above stylesheets or below other resources. use <link>, not @import.

Takeaways: focus on the frontend, run YSlow, focus on JavaScript (split initial payload, load scripts w/o blocking, don't scatter inline scripts).

Three Announcements:

• HTTPWatch for Firefox (not public yet, not free).
• Firebug Light 1.2 (can be used with IE or Opera).
• Mozilla is Firebuggin' (Mozilla is dedicating 3 people to work on Firebug).

Posted in The Web at Jul 24 2008, 04:23:12 PM MDT 1 Comment

[OSCON 2008] CSS for High Performance JavaScript UI by Gavin Doughtie Gavin is a front end developer on Google’s Picasa Web Albums and a contributor to the dojo toolkit. The original designer tools for Web 1.0 were the FONT tag, TABLE hacks and spacer gifs. Now we live in the future (shows a picture of the iPhone). Maybe it's time to accept that we're stuck with CSS. "I'm a coder, not a designer" is what happens at OSCON.

There are costs of JavaScript: development, download, parse time and runtime performance. It's extremely powerful and high-level, but it's slow because it's interpreted. Drawing a box with JavaScript in Firefox 3 isn't too difficult. Another way to do the same thing is with CSS. Doing the same thing in CSS is much faster and requires less code. Surrender To Win. You don't have to code it all. You can hand off part of that to your runtime environment (browser).

CSS Fundamentals
You want to how things flow in a page. Browsers were originally designed to render text. They're built to render flowing text. Other important fundamentals include float, positioning, negative margins, relative units, pseudo-selectors. Lastly, you need to know when to use tables. Gavin is now showing an example of using CSS to modify an image so it scales with the browser window. It's pretty simple:

body {
  margin: 0;
  padding: 0;
  height: 100%;
  width: 100%;
  overflow: hidden;
}

img { 
  position: relative;
  width: 100%;
  height: 100%;
}

Relatively Absolutely: "Absolute" in relative to position:relative. If an element has absolute positioning, it will only be positioned relative to it's parent element. To draw a box on an image, it's usually best to calculate the percentage position and sizes in script or on the server. The world's greatest psuedo-selector is :hover. Unfortunately, :hover doesn't work on anything but <a> in IE 6.

With floats, you can "float" elements to the top, right, bottom and left. In Firefox and Safari, you can set a border-radius to draw lines that are curved. Before Firefox 3, these lines where terrible looking.

Tables make a lot of sense when you have a grid layout. Use table-layout:fixed if you don't want table cells to be the width of their contents.

For sizing images and other elements, it's usually best to use em for the height and width and relative measurements. You can then use style.fontSize to resize the images. Using this technique is must faster than using JavaScript to set the height and width on an image.

WebKit, the CSS Wonderland. Gavin loves WebKit. It's on Safari (Windows, OS X and iPhone), Android, GNOME and KDE. With WebKit, you can build expanding lists w/o any coding. To do gradients in WebKit, you use:

background: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#00abeb));
-webkit-border-radius: 0.24em;

To do animation, you can use:

-webkit-transition-property: width, height;
-webkit-transition-duration: 250ms;
-webkit-transition-timing-function: default;

Another thing you can do with WebKit is rotate images (using -webkit-transform: rotate()) and just about anything (divs, forms, etc.). WebKit also supports SVN masks, which means you can open up a hole and view an image through it.

Gecko's pretty cool too. Firefox 3 introduced a new rendering engine based on Cairo. You can do an SVG transform in Firefox 3 to create reflections of elements (divs) in your page.

"With browsers, you cut people off at the knees, but everyone's the same height." -- Alex Russell

IE 6 is not the problem, we're the problem. If you drop support for IE 6, you won't have to worry about coding towards it. It might not be possible if you work for a large company, but if you're small, you should definitely think about it hard.

It's funny to think that IE 6 is the new Netscape 4.

Gavin's slides from this talk will be available at http://xdraw.org/oscon2008.html in the next few days. Posted in The Web at Jul 24 2008, 03:30:32 PM MDT Add a Comment

Friday July 18, 2008

The 416

Posted in The Web at Jul 18 2008, 02:10:37 PM MDT 1 Comment

Monday June 23, 2008

RE: Are people blogging less? James Strachan asks Are people blogging less? Looking at my archives, I don't see a noticeable decline in the number of entries I'm writing. Granted, I don't blog nearly as much as I did in December 2002.

One interesting thing I've noticed though, is I don't read blogs much anymore. I open NetNewsWire about once a week. However, I don't think it's because of the Twitter effect. I think it's because I work in an office full of people now and I get my social interaction from them, rather than from blogs. I also think it's because I'm more interested in what's going on with LinkedIn and social networking competitors. Most of that news I get from LinkedIn News on the homepage.

If there really is a decline in blogging, it may be because of Twitter, but I think it's something bigger. I think it's folks realizing 1) it's summer and 2) you don't get a whole lot of satisfaction out of blogging - you get satisfaction in life from spending time with family and friends. So quit reading this blog and go read your kids a book or invite your friends to happy hour tomorrow. It's a beautiful time of year and it won't last forever. Posted in The Web at Jun 23 2008, 08:54:13 PM MDT 3 Comments

Thursday June 05, 2008

Share on LinkedIn This is a test to see if I can get the Share on LinkedIn widget working on this site. Click below to invoke.

Share on LinkedIn

Seems to work pretty well. I like how you can select text and it'll automatically populate the summary. You can drag the link above to your toolbar in Safari and Firefox if you want to use it like a favelet.

Now I just need to get one of the designers to create a nifty little "Share on LinkedIn" icon so I can add it to all my entries by default. Posted in The Web at Jun 05 2008, 10:13:04 PM MDT 3 Comments

Sunday June 01, 2008

Why no more than 500 connections? I recently updated my status on LinkedIn to read:

Matt is determined not to have 500+ connections. Will start removing connections soon.

A couple of days later, I received the following message from a connection:

I noticed the other day you mentioned that you are determined to not have over 500 LinkedIn connections. I'm wondering what the reason is? Not just because LinkedIn shows 500+ after that, is it? As you work for LinkedIn, I assume there's some other reason. I'm interested to know what it is...

I joined LinkedIn May 27, 2003, 22 days after it initially launched. For the first few years, I accepted invitations when I received them. Some folks I knew, some I didn't. When I started consulting for LinkedIn last summer, I had somewhere between 200 and 300 connections. Most of them were people who had contacted me, not folks I had contacted.

One day, I used the import webmail contacts feature to pull in my contacts from Gmail. My number of connections quickly jumped by 100 and it's increased quite a bit since then (mostly due to co-workers from LinkedIn). Of the almost 500 connections I have, I believe there's a good 100-200 of them that are folks I don't know, have never had contact with, and will likely never benefit from being "connected" with.

I guess the main reason I'm planning on trimming my connections is to make my network higher quality. I admit I'm somewhat motivated by the 500+ icon, but it's also a genuine feeling that there's quite a few folks I won't benefit from being connected to. I'm not a LION after all. I believe my LinkedIn network should resemble my real-world network.

What's your opinion? Should I have folks in my network that know me, but I don't know them? Posted in The Web at Jun 01 2008, 06:40:59 PM MDT 17 Comments

Tuesday May 20, 2008

LinkedIn Groups This afternoon, I noticed there's a LinkedIn "GlassFish" group now available and it reminded me of a couple things:

• LinkedIn currently doesn't have a way to search for groups, but Jason Bailes has setup a LinkedIn Groups Search with Google Custom Search. Thanks Jason!
• I created a Apache Software Foundation group on LinkedIn a few months ago. If you're a committer or member, you're more than welcome to join the group.

LinkedIn Groups don't provide a whole lot of functionality at this point, but I've heard there's big things in store for them. Chances are they'll be very valuable in the future. Posted in The Web at May 20 2008, 02:16:18 PM MDT 5 Comments

Wednesday March 19, 2008

The Thin Server Architecture Working Group From The Wisdom of Ganesh:

Peter Svensson has set up a website where like-minded people can discuss the brave new world of applications whose common characteristic is that no aspect of presentation logic resides on the server side. I admit that's an overly broad-brush generalisation, and it will be necessary to read what the various authors of this camp have to say.

I thought about doing something similar when I first read about SOFEA. I'm glad to see that someone has taken on this challenge. However, doesn't it seem ironic that this site doesn't use SOFEA/SOUI for its own architecture?

IMO, if this site isn't written with some sort of SOFEA-based framework like it advocates, it's pretty much worthless. Posted in The Web at Mar 19 2008, 09:23:56 AM MDT 2 Comments

Wednesday February 13, 2008

WebORB: Have you ever heard of it? A colleague sent me an e-mail today and asked me if I'd ever heard of WebORB today. Since I hadn't, I figured I'd write this post and see if any of you have heard of it? If so, what is it and what does it do? It it similar to Appcelerator, but server-side only? Or is it more like Granite DS?

[Read More] Posted in The Web at Feb 13 2008, 01:42:38 PM MST 8 Comments

Saturday February 09, 2008

YUI Grid CSS and Rails Performance From Stephen O'Grady, I learned a couple interesting tidbits yesterday.

The first is Jeremy Zawodny talking about Yahoo's new Grid Builder in YUI Grid CSS and Grid Builder Kick Ass! The last time I looked at YUI Grid CSS (that's a mouthful) was almost 2 years ago, when it first came out. It's obvious that this library is better supported than Mike Stenhouse's CSS Framework. Maybe it's time to switch in AppFuse? Anyone know of themes available for Grid CSS?

The second item is Charlie Savage's entry titled Must Read Rails Performance Article:

Using a patched version of ruby and ruby-prof, Alex was able to more than double performance (with hints of more to come) and reduced memory consumption by 75%, or 750MB (yes - that is Megabytes). Alex does a wonderful job of documenting his approach with a series of blog posts here and here.

This reminds me of Don Brown's recent work on Maven. This is how open source is supposed to work - instead of complaining about the problems, fix them. In both Rails' and Maven 2's cases - it's somewhat surprising these issues weren't fixed earlier. Kudos to Alex Dymo and Don Brown for stepping up to the plate. Well done gents. Posted in The Web at Feb 09 2008, 08:14:18 AM MST 2 Comments