Sorry, it’s been a while. I’ve been busy at work, I’ve been wringing every last bit out of summer on my bike, and I’ve spent a lot of my free time on my upcoming CSS presentation, so I haven’t been posting as much as I would like. Fall is here. Which means I should have more time for writing. That’s cool.
Anyway, to break the ice here are a few articles that have recently caught my attention. Read the rest of this entry »
Quick, if you were to guess a technology I’d be making commits on an open source project using, would Apache Ant be at the top of the list? I didn’t think so. But yet, here I am committing an Ant Build script to Paul’s excellent HTML5 Boilerplate project. It makes sense since I’ve done work on concatenation, minification and other performance enhancements using Ant, but it’s still a weird technology to be contributing to such a cool project with…
With more and more people embracing the idea of producing HTML5 mobile web apps, research like this is becoming vital. There are a lot of gotchas in this article, especially if you’ve been ignoring this space.
You should read the whole article, but I just want to point out a pair of findings before I send you on your way. One has been a known issue for a while (it’s a ySlow rule, after all,) but it’s still worth pointing out. The other… wow… my emphasis.
Results varied wildly across the three most recent versions of iOS. Astonishingly, Mobile Safari on iOS 3.1.3 did not cache components of any size, despite having an apparently unlimited page cache size. This is troubling since it means iOS 3.1.3 users are likely getting a suboptimal browsing experience, especially if they aren’t using wifi. The unlimited page cache size does little good here, since it only comes into play for back/forward navigations. This behavior is a significant change from what others observed in previous iOS releases and I can’t imagine any good reason for it, so I suspect this may be a bug.
Mobile Safari on iOS 3.2 (which is only available on the iPad) does not exhibit this bug. Its 25.6KB component limit and ~281.6KB total cache limit are better than nothing, but they still seem paltry compared to the other devices tested. Uniquely among iOS devices, the iPad appears to limit the size of pages in the page cache to 25.6KB, the same as its component size limit.
One of the reasons I’m drawn to the performance side of the business is that it’s one of the few pieces of of your site or application where you can really know when you’re doing the right thing.
There are a lot of questions that can run through your head during a site build. Is the design right? How about the feature set? do these labels make sense? Is the language correct for my audience? Does this visualization truly illustrate the underlying data and add meaning? Was I right to use canvas? Should we be using web storage?
Those (and many other examples) are the things that can (and should) your thoughts. You can leverage experience and best practices throughout, but there are always mistakes, miscommunications and surprises waiting around the corner, so sweating the details of a design or interaction model can make or break an application.
One aspect that brings a little bit of certainty is the question of speed.
The site is either fast, or it isn’t.
There are certainly degrees of “fast,” a full featured application won’t be as fast as Google.com, but once you’ve defined a speed goal there are plenty of ways to know if you’re hitting your marks which makes it a bit more satisfying than the stuff that’s a little more nebulous (or takes a little longer) to measure.
I presented at Bocoup last night. It went really well. As always great people showed up and I think I did okay with my side of the bargain. I shot some video, we’ll see how that turns out. If it’s of reasonable quality I’ll be sure to share.
For anyone interested, here are a couple of downloads from last night.
I’m in the middle of finishing up my presentation, so I figured I might as well make an effort to get some people to show up to see the results of my hard work
Here’s the write up:
Front End Performance for the Common Man: Practical Strategies to Speed Up Your Site
Rob Larsen will examine the core concepts and techniques behind the performance of the web’s fastest sites and will translate them into practical examples. This talk will cut across several technologies (JavaScript, CSS, Ant, Apache and more) to present a suite of tools any developer can use to speed up their site- no matter the size or budget. RSVP to The Event Page.
It’s going to be a really good talk- full of practical examples and advice for every flavor and level of web developer. You should totally go.
I recently ran into an interesting CSS Sprite. It contains what appears to be all of a web app’s site’s icons. What was interesting was the fact that it’s a 32 Bit PNG at 1500 x 1500 pixels- many of which are empty. Here’s what it looks like shrunk down for easy consumption and the empty space colored pink for emphasis.
As you can see there’s an awful lot of empty space. It’s mostly empty space. Between the huge dimensions and the empty space at how they would affect memory usage and front end performance.
I did a couple of tests. One was looking at the memory footprint of five sample pages in Chrome and the other was measuring download times with WebPageTest.
I’ll go through each of the variations I tried and then we’ll look at the results.
