A few years ago, I made a key lime pie for a party. One of my friends was raving about it. “Oh my God. You have to give me the recipe.”

“Well,” I said. “There’s no secret. It’s the recipe on the key lime juice bottle.”

This is sort of how I feel about my web optimization efforts. Smart people at Filament Group and Google and elsewhere have already figured it out. Just follow the recipe.

If it was that easy, we’d all be Gordon Ramsay. Err, maybe not.

But, like with pie, experience has taught me some finesse. For instance, make your key lime pie crust with vanilla wafers and a little bit of cocoanut.

Recipes are only general directions. Every site is a little bit different. The browser is always right. And sometimes the browser is like a cranky toddler banging a spoon on its highchair.

With this site, my results have been solid. My index page has a start-render time of ~.2 seconds and load time of around 2 seconds. It’s among the top 3 percent of fastest pages on webpagetest.org. Not bad for an image-driven site with giant hero art.

Mainly trying out these techniques was a learning experience. Here are a few insights that I gained that might help others trying to optimize a site.

###What worked

• Inlining “above the fold” CSS doesn’t speed up overall load times so much as make the page seem to load faster. So fast it seems to be loading from cache. In terms of user experience inlining CSS is a big win. Beware, though. It can be difficult – well, crazy-making – to implement and maintain manually. Next time I’ll probably try this.
• Hot-swapping hero images This Google-suggested technique loads a super-low-res version of hero art and then swaps with it a high-res image on DOM ready. Downsides include Javascript implementation, increased page weight, a double download, and the lead art looks gross until the real image loads. The designer in me should hate this. But the most damning thing of all … I think I can live with it.
• Lazy loading fonts gave me a large overall speed improvement. I saw Jason Parmentel’s session on this at Artifact and went home that night and added the Adobe webfontloader to my dev site. My start render time dropped below 1 second after this. The downside is flash of unstyled text, but a blank page awaiting a font download is a worse user experience.
• Lazy loading CSS After testing, I’d scrapped this because it was actually slowing load times. I tried another technique suggested by Google, but the site was breaking in – wait for it – IE. A few days later I took yet another crack at it and inlined all of Filament Group’s loadCSS tool in the header. Success. It cut about a half-second off my start render time. If you are bothered by inline JS, I’d forego this one.
• Inline SVGs were another huge win for initial render times. Codekit made building out pages with inline SVGs quite easy (and fun!). Although inlining them made the HTML5 validator head for its fainting couch like Tallulah Bankhead until I cleaned up the SVG code. The downside of this technique is graphics can’t be cached and your nice, neat HTML pages are a horror show of SVG code. If you do plan to use inline SVGs, this icon sprite method combined with CSS styling is the best way to go.

So that’s the positives. I also learned some negatives and gained some insights, but this post was getting pretty long so I’ll cover those in Parts 2 and 3 in a few days.