Apr 29
ClaudeArticles, Presentation, Video Dojo, Gears, HTML5, Performance, Storage
Web developers now have the ability to store large amounts of persistent data on the client-side, way beyond the 4K limit of cookies. Options include HTML 5 Storage, Gears, Dojo Storage, and more. Brad Neuberg talks about the latest ways to achieve browser-based client-side storage and how it can help you make better web apps.
Seen at the Yahoo! Developer Network Blog.
Dec 08
ClaudeArticles Image Optimization, Performance, Yahoo!
This article, part 5 of a series on image optimization, talks about the use of transparent PNGs with IE6 and why the AlphaImageLoader hack is bad and a very interesting solution
This installment of the image optimization series is about the IE-proprietary AlphaImageLoader CSS filter, which developers often use as a workaround to solve transparency issues with truecolor PNGs in IE. The problem with AlphaImageLoader is that it hurts page performance and, therefore, hurts user experience. I argue that AlphaImageLoader should be avoided when at all possible.
The rest is here.
Nov 18
ClaudeExt JS, Framework, JavaScript, Platform Ext JS, Performance
This is great news for the Ext-JS community. Here is why you should take advantage of a content delivery network.
We are pleased to announce that Ext has partnered with CacheFly, a global content network, to provide free CDN hosting for the Ext JS framework. Cachefly’s globally distributed network and aggressive caching accelerate the delivery of web content like JavaScript and CSS, making for an even faster Ext experience.
The Ext CDN also provides the ability to create your own custom builds using Ext’s Build It! tool, and host them on the CDN. The custom builder implements features to intelligently cache your component selections, adapter, and Ext version to create a unique custom build. These custom builds are cached across sessions and used by anyone who makes the same selections as you have – allowing for caching of custom builds across applications to fully realize the benefits of the CDN.
Oct 01
ClaudeJavaScript, Presentation Firebug, JavaScript, Performance, Testing
Improving performance starts with metrics. How long does it take for the page to load? Seems like a simple question to answer, but gathering accurate measurements can be a challenge. In my experience, performance metrics exist at four stages along the development process.
Enter Hammerhead.
- real user data – I love real user metrics. JavaScript frameworks like Jiffy measure page load times from real traffic. When your site is used by a large, diverse audience, data from real page views is ground-truth.
- bucket testing – When you’re getting ready to push a new release, if you’re lucky you can do bucket testing to gather performance metrics. You release the new code to a subset of users while maintaining another set of users on the old code (the “control”). If you sample your user population correctly and gather enough data, comparing the before and after timing information gives you a preview of the latency impact of your next release.
- synthetic or simulated testing – In some situations, it’s not possible to gather real user data. You might not have the infrastructure to do bucket testing and real user instrumentation. Your new build isn’t ready for release, but you still want to gauge where you are with regard to performance. Or perhaps you’re measuring your competitors’ performance. In these situations, the typical solution is to do scripted testing on some machine in your computer lab, or perhaps through a service like Keynote or Gomez.
- dev box – The first place performance testing happens (or should happen) is on the developer’s box. As she finishes her code changes, the developer can see if she made things better or worse. What was the impact of that JavaScript rewrite? What happens if I add another stylesheet, or split my images across two domains?