Among the potential improvements is Gzipping components. For those not familiar with Gzip, it’s a compression method Apache web server uses to squeeze your text-based files into smaller packages so that there’s less data to transfer to the browser. Typical javascript and css files will be sent at 25-50% of their file size. (e.g. if you have a 6k css file and you ask Apache to Gzip it before it sends it, the browser will only have to wait for a 2-3k file.) It may not seem like a big deal when viewed in the context of one browser making one request but, when you multiply that by thousands of users making many requests, the bandwidth and time savings become very tangible.

The other improvement that isn’t self-explanatory is minifying javascript files. Essentially, javascript files have line-breaks and extra spaces for human legibility and these cause extra bytes to be added to the total file size. However, computers can read the syntax without the white space. So, by running the finished javascript through a little tool like JS Minifier you can reduce the download size to 50-75% of the original. Again, we apply the same logic as above regarding the exponential savings with more users and requests.

The last rule says “Configure ETags” and although I’ve read Yahoo’s entry explaining it, I haven’t managed to implement it. So, if you’ve got advice or tips regarding ETags (or anything else concerning performance optimization) please share!

Everyone who has anything to do with markup should read this article. Even those of us who think we know it all; it’s safe to assume you’ll learn something valuable.

I’ll share some highlights from my notes after the jump.

• Joel Dehlin
• The Church is a supply chain arrangement. We have a product to deliver and we have to deal with overhead, spoilage, etc. just like any other supply chain setup.
• His focus is to deliver the technical platform to spread the Gospel. His primary points are:
1. deliver high-quality content to a global audience
2. decrease administration in order to increase ministration
3. bring souls to Christ
• Church websites not including familysearch.org receive around 50 million pageviews per month!
• The same websites welcome 5 million unique visitors each month!
• The new online application system for missionaries has cut the time from start to call-received in half.
• They are working toward providing portals for various user-groups within the Church in order to decrease administration. For example, allowing a bishop to login from his home to check on numbers/stats/callings/etc. Also, a new focus for web-based training for various callings.
• The top four challenges the team faces are:
1. Scale — how to deal with technology challenges in third-world countries and rapid growth
2. Languages, customs, and context
3. Complexity of content and requirements
4. Spending the Lord’s money wisely — how to have a top-notch IT department while spending sacred funds
• Tadd Giles
• The Interaction Design team is quite new and emerging inside the Church.
• He expects the team to be “jacks-of-all-trades/masters-of-a-couple-things”. For example, business analysts, UI developers, user researchers, and content analysts, etc.
• They use a process that seems to reflect the Getting Real approach in that they use a rapid prototyping process that heavily involves the customer and makes use of real screens to reach agreement.
• Some of the challenges that Tadd et al. face:
1. demand far exceeds supply. (this I like to hear as I’d love to work with this group )
2. maintaining consistency
3. globalization/localization of content/styling
4. accessibility
5. mobility
6. doing things the Lord’s way

That pretty much sums up my experience. I’m very glad I drove the six hours total to attend.

First, and arguably most importantly, Google drives behavior through incentives. Engineers working on important projects are, on average, rewarded more than those on less-important projects. You can choose to work on a far-fetched research-y kind of project that may never be practical to anyone, but the work will have to be a reward unto itself. If it turns out you were right and everyone else was wrong (the startup’s dream), and your little project turns out to be tremendously impactful, then you’ll be rewarded for it. Guaranteed.

Does that not make sense to anyone? Sounds pretty good to me. He continues with regard to the distinct culture that Google has cultivated from the beginning. It is one of giving praise and recognition where due. It becomes one of the major driving forces for the engineers and creates a feeling of friendly competition that encourages focus and effort to finish a great project.

There are other incentives. One is that Google a peer-review oriented culture, and earning the respect of your peers means a lot there. More than it does at other places, I think. This is in part because it’s just the way the culture works; it’s something that was put in place early on and has managed to become habitual. It’s also true because your peers are so damn smart that earning their respect is a huge deal. And it’s true because your actual performance review is almost entirely based on your peer reviews, so it has an indirect financial impact on you.

Seems to me like a great place to work. Now, if only I were up to snuff…